killswitch

Sorry about that guys - I've added a link to the hotfixed 0.7.0 to the first post.

In case this thread is later found via a search... 1.08 is out. See here: Arma 2 Linux Standalone Server 1.08 /thread

I pasted the wrong checksums before - I have the same MD5 checksum for that file How do they differ? Do they differ in that it exists (is present) for one of them but not the other, and that would explain why Dave4291 and others are seeing this problem?Just like HitmanFF, I too can reproduce the problem - if I remove/rename the expansion/dta/product.bin file, I get a similar cascade of log errors that the OP presented.

Dave4291, thanks for the MD5 lists. I have found two differences with the fileset I have: Your addons/missions_ew.pbo differs from mine, but our missions_ew.pbo.bisign files are the same.Yours:10b1bd01465de246cdc0dc24b4da62f2 missions_ew.pbo e87d1c4d3ded3163f10180cbe7ba805a missions_ew.pbo.bi.bisign Mine is the hotfixed Eagle Wing campaign: 607c163746c2f72970337de56a9bca12 missions_ew.pbo e87d1c4d3ded3163f10180cbe7ba805a missions_ew.pbo.bi.bisign You are missing a file called expansion/dta/product.bin. For reference, here's the MD5 checksum of minea40b12d0eb0906bc982bf1a2e6db94f8 expansion/dta/product.bin EDIT: I do infact have the same MD5 checksum that Dwarden has (see below) - I pasted the wrong MD5 checksum value before.

Could it be that you have uploaded the British Armed Forces DLC files aswell? If so, remove them, since they are not needed on the server and seem to cause problems. If you look in the Linux 1.55 OA server thread you'll notice how some people were able to resolve their issues with the Linux server by removing the BAF DLC files from the server.

That looks OK(*). I wonder if there are invisible, "strange" characters in that file put there when you edited the file. How did you edit the file? Did you use a text editor on the server itself? Did you edit the file on your Windows computer and then upload it? What editor did you use? (If you used the Windows Notepad.exe editor, perhaps there are some hidden DOS-type line endings in the arma2oaserver file that are causing trouble) (*) The line CONFIG=arma2.cfg is suspicios. The file named "arma2.cfg" is automatically generated when you start the old ArmA II 1.0x Linux server and usually contains this: language="English"; adapter=-1; 3D_Performance=1; Resolution_Bpp=32; The file intended for the CONFIG parameter is the one usually called "server.cfg" and would contain lines like this: // GLOBAL SETTINGS hostname="My ArmA II server" password = "" // Password for joining eg connecting to the server passwordAdmin = "secret" // Password to become server admin ... ... more stuff here ... Naturally, if your "arma2.cfg" contains game server config lines like the second example above, everything is alright. (I would rename it "server.cfg" or anything except "arma2.cfg" since that name is used for a file that may get automatically created if you start the old A2 Linux dedi server) I can't see anything wrong with your arma2oaserver file, but it's worth a try to unpack a fresh copy from the a2oa-server-1.55.75619.tar.bz2 archive and then edit it on the server using Vi, emacs, gedit or whichever favourite editor you have. There may be strange characters hiding in the file that got there during editing or when (if) you uploaded it from your Windows machine. Good luck!

Lima9999, the problem is a broken third-party addon ("VX_FleckcaDes"). Load your game without any extra addons and mods and the error should go away. Report the error to the authors of the faulty addon. (A google search suggests it could be a Bundeswehr mod desert unit addon for one of the older BIS games and thus isn't compatible with ArmA II) If it doesn't go away, you have placed third-party addon files into the core game data folders and that's a mistake. Remove all extra (non-BIS) addons from the games' own addons folders.

Spike1986, could you post the part of the arma2oaserver script where you set the configuration parameters. Sometimes, an extra character in a bad place can cause problems further down in shell scripts. I'm referring to this section of the script: #======================================================================= #======== CONFIGURATION PARAMETERS ======== #======== MUST BE EDITED MANUALLY TO FIT YOUR SYSTEM PARAMETERS ======== #======================================================================= ARMA_DIR= CONFIG= PORT=2302 PIDFILE=${ARMA_DIR}/${PORT}.pid RUNFILE=${ARMA_DIR}/${PORT}.run LOGFILE=${ARMA_DIR}/log.${PORT}.txt SERVER=${ARMA_DIR}/server OTHERPARAMS=-cpucount=2 #=======================================================================

It wants the "dta" and "keys" folders aswell ;) Addons, common, expansion - great. Get the "dta" and "keys" folders there aswell and you should be OK. (Remember to run the "tolower" tool to convert all filenames to lowercase)

You can use the same exact code in the config of an addon. Unlike normal event handlers, you should not write it inside the class of a vehicle. Instead, you simply add it as it is outside of any class definitions. As an example: class CfgPatches { class TAG_Example { units[]={}; weapons[]={}; requiredVersion=1.00; requiredAddons[]={ "Extended_EventHandlers" }; }; }; class Extended_IncomingMissile_EventHandlers { class Air { lion_incoming="my code here"; } }; // rest of addon config here Yes. No. "lion_incoming" isn't a variable at all, it's a config entry name. The kind of "events" that the CBA function deals with is entirely different from the events that Extended Eventhandlers works with. XEH is used with normal, existing event types that the game engine already supports, such as "IncomingMissile", "Init", "Fired" and so on. The CBA (not XEH) event system can be used for your own user-defined events. You can read more about those here It needs to be named uniquely, indeed, similar to how global variables need to be unique. Take note though - "lion_incoming" isn't a global variable, but it needs to be unique so that another addon maker can add his or her IncomingMissile event handler to class Air without conflicting with yours. You see, when the game loads all the addons, it will collect all the Extended_event Name_Handlers and if two other addons also define their incoming missile handlers, the result (as seen by the game) could be something like this: class Extended_IncomingMissile_EventHandlers { class Air { xyz_eek_heelp = "code here"; lion_incoming = "hint (str 1)"; abc_somethingelse = "more code here"; }; class Man { ... }; ... // loads more here }; Then, as an IncomingMissile event is generated, XEH will call all three event handlers for the targeted vehicle. Due to this, one has to make one's event handler code entry name unique.

CBA_fnc_addEventHandler can't do that. (I know, it's not very clear what it can and cannot do from that documentation page).You can do it like this instead: In your mission, create a new file called "description.ext" if you haven't already got one. (It goes in the same folder as the "init.sqf" you already have) Edit that file with a text editor and add this to it: class Extended_IncomingMissile_Eventhandlers { class Air { lion_incoming="hint (str 1)"; }; }; Save the file, then return to the ArmA mission editor and re-load the mission into the editor. Preview it and you should get a hint message every time an aircraft is locked up and fired at with a guided missile.

That's the problem right there. Dont't run "./server" directly. Instead, run the launch script called "arma2oaserver". That script will start "server" with the proper set of startup parameters.

Thanks for the reports guys - follow the problem here and you can note your experiences/troubles with parachutes and CBA 0.6.0. It's possible that an old problem has resurfaced due to changes in CBA 0.6.0.

The latest ArmA II OA client beta version is 1.52.72291 and the latest Linux ArmA II OA beta server is 1.52.71900, so people should be able to connect just fine since they are both version 1.52. In fact, I just connected to my Linux 1.52.71900 server with the latest ArmA II OA beta client and it works just fine. Here's the 1.52.71900 build of the Linux OA server: link and the forum thread is here

In reference to this posting Can it?Maybe - I don't actually know. Submit a feature request in the CBA issue tracker so it can be further discussed - maybe there is a way to do something to do what you need.---------- Post added at 01:27 PM ---------- Previous post was at 01:26 PM ---------- No, it shouldn't be needed unless you have other addons on the server that require it.

It shouldn't (and couldn't), unless it is somehow loaded anyway. Check the the in-game "Expansions" menu - if @CBA_OA or @CBA_A2 was enabled in there, perhaps that's why it's being loaded processed. So double-check that no mods are enabled in the in-game "Expansions" menu. OTOH, if one uses -mod=... the choices made in the Expansions menu are disabled/ignored anyways, so that's not likely the reason.(The error message you saw may also be printed if you have the ArmA II compatibility folder loaded, @CBA_A2.) The error message is part of a sanity check built into @CBA_OA and @CBA_A2 and is meant to print a warning message to people when/if they load only @CBA_OA or only @CBA_A2 - both of these expect @CBA to be loaded aswell. In your case though, the specific error message you saw indicate that something odd has happened and that the Extended Eventhandlers system (which lives in the @CBA mod folder) hasn't been loaded properly. Ok. Now, does this error message show when you're running Combined Ops or when you're running the older ArmA II executable? (When you run ArmA II, you need to load both the @CBA and @CBA_A2 mod folders) In either case, try isolating the problem to a case when you're using as few mod folders as possible. Once you have this minimal set of mod folders that still exhibit the problem (and the order in which they are listed in the -mod=... startup parameter), tell us. I'll try to recreate the problem here.

It's this error message, right? That's an an error message generated by an addon in the @CBA_OA mod folder (used along with @CBA by users of a standalone Arrowhead installation). Can you tell us exactly what addons and mods you're using when this error appears?

What Rafalski said above - the game will store the mods you select in the Expansion menu in your .ArmA2OAProfile file. That file lives in a sub folder of the "My Documents" folder. For example, if you play ArmA II as "MyNickName", it will be in My Documents/ArmA 2 Other Profiles/MyNickName/MyNickName.ArmA2OAProfile.Open that file with a text editor, for example Windows' own "Notepad" and edit or remove the whole section called class ModLauncherList.

Big Dawg KS - no, CBA doesn't have that kind of functionality. Everyone: please continue the CBA discussion in the new 0.6.0 thread here

Nope, not CBA. The "issue" is with acre_settings.pbo which does this in its config: #include "\userconfig\acre\acre_clientside_config.hpp" The solution is simple enough - on the server, install both the "userconfig/..." files that come with ACRE, even if one of them has a suggestive, non-server name. :)

How do you launch the server when using mods? Are you using the supplied arma2server script? If so, how have you altered it to load the mods? (One modifies the OTHERPARAMS variable to do so) Post the relevant parts of the start script or an example of how you launch the server where all startup parameters are visible.

More human than what? What specifically have you read so far? Please enlighten us as to the problems with the overview of what ACE is that's present on the ACE homepage, the link to which you can find in the first post of this thread. You have read that one, haven't you?

Not by a long shot, unfortunately. That computer is now going on five years of age and it is no longer of much use for modern computer games and in particular ArmA II. Have a look at the ArmA II system requirements here. I would say that what they state as the "optimal" requirements should be taken as the actually minimal requirements. That said, as you can tell from the so-called minimal requirements, your specs almost cover it, so you could try the ArmA II demo and see how it works. I doubt you'll be pleased with the performance in A2 with that old rig though.

At what point does the crash occur? Is it some time into the mission or does the server crash when you try to load the mission? (If both, specify that) EDIT: You mention above that it's intermittent, so I guess it happens while a mission is played.Can you offer the specific mission files that cause the crashes for download - maybe I or someone else can reproduce the crashes on other Linux dedis?

The default MP missions you see come from the addon "missions_e.pbo" in Expansion/Addons. If you delete that addon (or perhaps better yet, move it out of there for safekeeping elsewhere, in case you want to put it back), the MP mission list will be empty when the MPMissions folder is empty.