killswitch

CBA is not yet compatible with installations using just OA(*), but Sickboy and I are working on getting an improved CBA out. Stay tuned... :)(*) It works with a combined ArmA II + OA installation, though, even if it's not technically complete.

The safest way to accomplish that would be to create a BIS Functions Module: _h=[] spawn { if (isNil "BIS_functions_mainscope" && isServer) then { _side = createCenter sideLogic; _group = createGroup _side; _logic = _group createUnit ["FunctionsManager", [0,0,0], [], 0, "NONE"]; }; }; waitUntil {bis_fnc_init}; // The Functions module is now ready for use (CBA does this for you, so if your addon depends on CBA ( requiredAddons[]={"cba_main"}; ), you won't have to do this yourself)

Usually, you start the server like this: ./arma2server start If you did, you can then stop it using ./arma2server stop

Note that it needs to be -exThreads=1 (with an "s" in "threads").

You can choose to only allow the addon by having only the key on the server. None that we know of. (And if there are, we need to know about it)

If the file didn't change at all (same checksum as before), then you could keep the old ibr.bisign/bikey for that file. (The v1.7 isladuala.pbo file though ought to use a new key/sign file that correlates to the version, as suggested earlier in this thread)Many thanks for Isla Duala and all the other islands you've made!

What I meant is this:If you install one of the ArmA II betas on your Windows machine, a mod folder called "beta" will be created. You could transfer that folder to your Linux server and start the Linux server with -mod=beta That won't actually update the server program to the same level as the Windows beta releases, but you would get the fixes (if any) that are present within the addons of the beta mod folder. (The current beta has two addons in there - hotfix.pbo and ui.pbo)

When one uses the BIS-provided start script "arma2server", a log file named "log.2302.txt" will be created and stdout and stderr is redirected there. Re-formulating that for your setup, I'd ask "are there any errors or warnings in the output from the arma2.sh script?"I see you're running a Xen kernel. This begs the question if you're running in a Linux virtual machine (VM), ie if you're renting a slice of a bigger server? ( A common term for that seems to be "VPS", virtual private server). Another possibility is that you are in full control of the machine and use Xen to host VM:s for other purposes. If it's a VPS, there's a slight possibility that what you're seeing is a result of the host having put CPU and/or I/O limits on your VM, causing the slow startups. OTOH, if the OFP server doesn't exhibit this problem, that's not the reason for the slowness. It could be the many addons and mod you're loading - perhaps the ArmA 2 server log ("output from arma2.sh") may hint at a problem.

Aye - I realised that this little nugget of info isn't stated anywhere, so perhaps I was a bit too curt there. My apologies. Ouch...if it really takes that long to get ready, something's not right. (I can launch an ArmA II dedi server on my very old 2001-era Athlon XP 1700+ server and it will be ready in under a minute. Of course, it can't run missions very well, but it starts relatively quickly :) )Could you tell us a few details about the setup? (What distribution, server specs, if there's any oddities in the log.2302.txt file that gets printed out when you launch the ArmA II server) The BIKI is the correct one. The class names you use in the profile should correspond to the game's own class CfgDifficulties, which you can see here: ArmA II 1.05 CfgDifficulties

Here's a crazy idea - try launching the server and see if there are any interesting files created. (Answer: player/player.arma2profile) Using -name=poohatch will create a new file in poohatch/poohatch.arma2profile. The names are not customizable. The correct names for the Difficulties classes can be seen in the BIKI: server.armaprofile I suspect it's possible to have only one of them there, whereby the settings for the other three would be the game's defaults.

What whisper said. (I do understand the rationale for the shorter -s and -b variants though, seeing as how there's not too much space in the in-game game browser for the server name field)

Yeah, that's not easy to do. While CBA/XEH can help you with the fired EH itself, the functionality you require would need loads of "handshaking" between the server and clients.What exactly is it that you want to achieve by having the server conditionally run an event handler only if a client doesn't have the addon?

CBA doesn't have a "userconfig". You'll have to take this problem up with the authors of the specific mod/addon you're using.(Phrased otherwise: this is not a CBA problem) Having said that, there's no easy way of doing what you want to do, since the "userconfig" folder will be shared between those two Windows accounts, since the "userconfig" folder exists in the ArmA II installation folder.

No. At least, there shouldn't be, because if there is, that's probably a breach of the ArmA II software EULA.What you can do is compress the addons folder. Using 7-zip, the ArmA II addons folder gets down to around 6,3 GiB which isn't exactly small, but smaller than 8 GiB.

It's the graphics card. It's an entry-level graphics card and it's entirely inadequate for ArmA II. (The other parts are fine)EDIT: leon86 beat me to it :)

Here's some statistics to help you figure out what's out there: We have roughly nine or so different configs(*) for our three ArmA II servers, but the three game servers are almost never being used at the same time. One server is the "production" one used for public gaming nights and another one is used for mission testing. The third is a passworded one that's sometimes brought up for pubbie-free gaming sessions. (All on the same physical machine) (*) By "config" here is meant a set of ArmA II launch pararameters ("-mod=...." and whatnot) and "server.cfg" variations. Out of curiosity, what are the use cases you're addressing with this app? A tool for GSP:s to manage several ArmA II services on a machine?

Yoma, when running the AddonSync2009RepoGenerator.exe application, is there a way to specify (in the input XML file) that a certain mod folder should be optional in the resulting repository? By that I mean that when a user looks at the "download addons" tab within the YAS application, this optional mod folder is not marked for download (checkbox not checked). (In the resulting YAS repo metadata, I've noticed that the Server.xml has two suggestive elements - <RequiredAddons> and <OptionalAddons>. What are they? )

You can't - the beta releases are built for Windows only.(You can of course load the beta mod folder with the Linux server executable, but you won't get any engine improvements that may exist in the Windows beta arma2server.exe)

Yes: You have edited the arma2server start script nicely, yet you launch the game by running the server executable... ( "./server"). That's not going to do what you want. Start the server with the script. Always: ./arma2server start You have to create the server.cfg yourself. Use the one on the BIKI as a template: server.cfg article Once you launch the server with the start script, the log file will be log.2302.txt

Usually, they aren't, but... *cough*Me, I want zombies :-)

The error messages mean that the server has a different set of ACE addons - most likely, the server hasn't been updated yet.

The six-updater application is continually improved, so you're probably best off first uninstalling the version you have. Then, install the latest one available from here and follow the instructions under "Install the mod", variant b) "Ongoing development" as seen here

That log entry is just a warning. One or more of the mission files is lacking a class Header section in the description.ext file, a file that every MP mission has. (In Windows, that warning message is written to the arma2.RPT file.)

Yep, you're right on the money there. ACEX_PLA has Chinese army units. :)

I've seen the same thing - if you run the 70256 dedicated server "normally", the symptoms when trying to load a MP mission are what the first post describes. Adding -exThreads=1 solved it, and apparently 3 works aswell.