killswitch

1) Which Debian Etch do you have? 32-or 64-bit? 2) What does "uname -a" say? 3) If you're using a 64-bit variant, do you have the package ia32-libs installed? 4) What's the output of the following two commands, run in the arma2 server directory: ldd ./server ldd ./battleye/beserver.so

1.05 Yes.

Here you go: class Missions { class WhenDiplomacyFails { template = "MP_WhenDiplomacyFails.Chernarus"; difficulty = "regular"; // one of "recruit", "regular", "veteran" or "mercenary" }; };

If I read the specs of that motherboard correctly, it could be the infamous AMD/ATI SB600 southbridge's SATA controller causing you problems. The AHCI implementation in that one is known to be... unremarkable, and that's being polite to the SB600's SATA controller. (Also, from your mentioning UDMA 6 mode, maybe the drivers know this and switch the drives back to non-AHCI mode.)(I'll be blunt - the SB600 is a broken POS)

Here's a few tips: Keep view distance at the default 1600 m and work with Benchmark 1 from ArmA II 1.05 until you get "acceptable" performance for your particular graphics card and settings. Benchmark 2 is more of a system killer and seems to bottleneck all existing computers today. Put shadows to High or Very High - that way, the shadows are handled by the graphics card. (Normal and down are done on the CPU, and you don't want that) Video memory set to "Default" should make ArmA II auto-detect the amount of VRAM you have, but that doesn't work for everyone. A suitable fallback is High or Very High there. Turn off Antialiasing and see if that helps. As others have noted, disabling Hyperthreading in the BIOS may help, but as we can see from this thread and others, the results of doing that varies. Instead of disabling HTT on your Core i7's, try adding -cpuCount=4 to the ArmA II startup parameters. Defragment the hard drive that ArmA II is installed on. Technically skilled users can use the contig utility to defragment just the ArmA II installation folder. An Intel Core i7 processor overclocked to 4 GHz and beyond seems to be a good entry-level processor for ArmA II. :D

Excellent - then I suggest you work on your own machine until you can get the Linux ArmA II server to start without errors there. Then you'll have a "known good" setup to compare with. The errors in red are errors in one of the missions and they need to be fixed - I recommend you remove all missions from the mpmissions folder on the server and only test with the stock BIS multiplayer missions. Once you have the server configured and working properly, you can add the third-party misssions to the mpmissions folder again.

You have several files and/or directories in the "addons" directory that shouldn't be there - [email protected] autorun.dat bin.pbo bin.pbo.bi.bisign core.pbo core.pbo.bi.bisign languagecore.pbo languagecore.pbo.bi.bisign license mpmissions product.bin server setup.crc setup.dat tolower Remove them and try again. There should be 104 files in the addons directory (ArmA II 1.05)) Ok, that log output shows two things: (Lines 2-13) That the arma2.cfg file can't be read, is empty or is malformed. Remove whatever arma2.cfg you have there and just launch the server executable once. That will recreate a "clean" arma2.cfg file. That something is very wrong with the core addons. This is most likely due to the extra files in the addons directory (specifically, the bin.pbo, core.pbo, languagecore.pbo and product.bin files, which should not be in there at all). If you have a Linux installation at home(*) and SSH access to the server, prepare a server installation at home, verify that it's working and then use rsync to synchronise the folders on the local installation with that on the server. Make sure to use the -z (--compress) option with rsync. Example: $ rsync -avz -e ssh --delete /path/to/local/arma2/addons [email protected]:/path/to/remote/arma2/addons No, a 64-bit Debian is fine. When the server does work, a fresh "log.2302.txt" should look like this (1.05 Linux dedi used): WATCHDOG (29184): [Thu Dec 31 12:28:07 CET 2009] Starting server (port 2302)... 12:28:17 Dedicated host created. 12:28:18 BattlEye Server: Initialized (v1.071) 12:28:18 Host identity created. Good luck! :) (*) You can do this from Windows aswell - there are ports of rsync and ssh that run in Windows (Cygwin). Make copies of the addons and dta folders in your ArmA 2 installation, then convert the filenames of the copied files to lowercase (can this be scripted?) and finally use rsync from Windows to the Linux server.

Check the file ownership *and* permissions for all files in the directory where the ArmA II server is installed. Then do the same for the directory where the the server is (aka "./") Maybe some of them are owned by root or another user than the one running the server process? Show us the log output from when the server starts. Stop the server, then remove the file "log.2302.txt" and then launch the ArmA II server again. Wait a moment, then copy&paste the log contents into a message here. (If there is a lot of text, google for a so-called pastebin, post the log output there instead and tell us the URL to that pastebin entry. Those errors are due to slightly broken files within a mission - there are syntax error in several .hpp files. If you can't launch the stock BIS missions, the server simply isn't setup correctly.

He ate 8 Hellfires in a tincan Tunguska? :rolleyes:There's your problem... tip? ban.txt /thread

That which is in the ticket at this time is a link to a page that describes how you make a proper bug report. You report is missing crucial information regarding your problem. There is NO way for anyone to help you with what scarce information you've provided in that ticket so far.

Try connecting without the (known to be broken) sound mod and see if that makes a difference. If that doesn't help, tell us about the server (what GNU/Linux distribution and version are you using). I suspect that you have corrupt game files though, judging from the Warning: preNLOD format in object ca\weapons\dshkm_mg.p3d part of the log. Check the MD5 checksum of the file addons/weapons.pbo. For ArmA II 1.05, it should be 7a9ef4a4a5b649c313c311adc0d9ad07: $ md5sum weapons.pbo 7a9ef4a4a5b649c313c311adc0d9ad07 weapons.pbo In Windows, you can use the HashTab file explorer extension to see several checksums for a given file.

Ah yes, I see the problem. Unfortunately, there's no way to surgically remove a specific XEH event handler addition that another addon does. (When XEH initialises, it will parse all Extended_****_EventHandlers and then concatenate them all into one string that then gets compiled to a final event handler for a given vehicle) What you could do is kick off a script that warns user of the conflicting addon and suggest to them that they remove it if they want to use your addon: ... if ( isClass (configFile>>"CfgPatches">>"dbo_counter") ) then { // Print a warning about the conflicting countermeasures addon }; ... Maybe we need a new engine feature for the CfgPatches part of an addons config - a counterpart to requiredAddons were you can list conflicting addons? :) (Like Linux packaging systems such as RPM and Debian have, where you can indicate not only dependencies (requirements), but also if your creation either obsoletes or conflicts with another package)

No. (There are no global variables in XEH that lets you "disable a XEH class")

Which of the two event handlers are you referring to with "this XEH", ie which of the two IncomingMissile event handlers is it that you want to remove? Yours or the one from the other addon?(If it is the one from the other addon, then no, there's no way to remove only that one)

Hi. The answer to that can be found in the first post of this thread.

Check and make sure the server has the new key files that were issued with the beta2 release of ACE2 in it's ...\ArmA 2\Keys folderThey new ones are "CBA_Test2.bikey", "ACE_Test2.bikey", "ACEX_Test2.bikey", ""ACEX_PLA_Test2.bikey" and "ACEX_SM_Test2.bikey", whereas the old ones were called "*_Test.bikey"

Hi Opticalsnare. Let's see if we can solve this before the holidays are over. :) EDIT: Longer post removed - now that I think of it - what you have in the first post should work... I'll need to ponder this...

As a step on the way, this actually "works": (group this) setVariable ["MARTA_customicon", ["b_recon", "group_3"]] Why did I say "works"? Well, you will see that the icon for the group in question will change, but the group size indicator (team/squad/section/platoon etc) will be reset by the HC system. The group_3 name above should put three little platoon size dots above the recon icon (and for a while they are there), but looking at the code in ca\modules\Marta\data\fsms\marta_local.fsm, that part of the custom icon functionality is broken at the moment and commented out in ArmA II 1.05. Maybe in the future? I'll keep digging...

You're special, you know?In case you've actually lost your legit key - contact the company you bought the game from.

In what way is the script arma2server modified? Two things here:The part in red usually indicates that the server cannot read the "arma2.cfg" file properly. This may be because it doesn't exist, is empty, or that the script arma2server has been altered to use the -cfg=... parameter to point to another .cfg file that can't be read for the same reasons ("arma2.cfg" is the default name unless you specify one using -cfg=...) Furthermore, I advice you to connect without the mod in blue until you get the server working. (The VOPsound mod suffers from config.cpp errors which may be the reasons for your problems) Neither arma2.cfg nor player.arma2profile should be blank. They should exist and have text in them. The Linux server executable will create them if they don't exist.

Yes. :)

Yep, don't worry about that warning - it's like tpw says. The ArmA II beta is available as a mod managed by the six-updater, but if you take care of installation of the beta yourself, you see this warning.

Protegimus, FYI, that which used to be in "ace_c_ai_other.pbo" has been moved into the "ace_c_ai_skill.pbo", which now looks to contain all(?) the properties of class CfgAISkill, whereas before they were spread out over a few addons. Oddly enough, the latter addon is named "ace_c_ai_aiming" in it's CfgPatches entry... (ACE beta build 188) BTW - thanks a bunch for your hard work on this. This combined with ACE is starting to bring back the good feeling I had in large AI / CoC CE battles from the days of OFP with WGL. "Oh look, they're actually engaging...wonderful. Now charge, minions!" :D EDIT: For ACE beta 1, build 188, one needs to change the requiredAddons property of the following three addons: zeus_c_ai_aiming, zeus_c_ai_other and zeus_c_ai_spotting to: requiredAddons[] = {"ace_c_ai_aiming"};

Looks OK - that's what I have on my 1.04 ArmA II Ca.pbo.