killswitch

It will be sufficient if the mod and/or addon makers in question uses versioned signature files. Yes.

In order to be able to edit the difficulty settings, you'll need to add a class Difficulties section to the end of the player/player.arma2profile file on your server. An example class Difficulties can be found here: ArmA II server profile. Copy that text into your server's player.arma2profile. Then, edit the 3rdPersonView value for the veteran difficulty level.

I get you. I am unable to reproduce the problem you describe. In a HC mission I have here, I can have the ACE marker system enabled alongside with the HC system, in which case both marker systems are displayed once in HC mode. I can then disable the ACE marker system, which makes the map area "clean" if I'm not in HC mode. Once I switch into HC mode, the map icons and the 3D icons appear as normal.Does it happen when you preview the mission in the SP editor or is it only when playing in MP it happens? In MP, is the mission run on a dedicated server or is it hosted by one of the players? If possible, could I have a look at the problematic mission?

The HC markers are displayed to the HC player when he or she shifts into "HC command mode" (CTRL+Space) (I don't know if there's a way to make the High Command markers be visible all the time and to all the players.)

The SB600 was notorious for it's non-working AHCI implementation. The later SB700 southbridge SATA controllers have been fixed.

There was an error in a recent build of CBA that the ACE beta program distributes. The latest build however, has this error fixed. Get your ACE/CBA updated and the problem will be gone. Have a look at the text file called ".version.txt" in the @CBA folder. It should contain the number 47 (or larger).

Why do you go to all that trouble of doing a server check and then publicVariable the boolean again? (Don't answer - it's a trick question) It's not needed. Just have the line as I wrote it in your init.sqf. That will turn off the ACE marker system on all machines. The ACE marker system is not connected to the HC system. The HC markers will only be shown for HC commanders, AFAIK.

ace_sys_tracking_markers_enabled=false;

It looks as if there are several server instances running at the same time. First, run "./arma2server stop", and then use $ ps ax|grep "arma2server" to find the other arma2 server processes. There are going to be two processes for each arma2 instance running - one bash script watchdog process and the actual arma2 server. Example: $ ps ax | grep "arma2server" 11722 pts/0 S 0:00 /bin/bash ./arma2server watchdog 11724 pts/0 Sl 0:24 /home/foo/a2s/server -server -config=server.cfg -port=2302 -pid=/home/foo/a2s/2302.pid In this example, one would have to do $ kill 11722 11724 to get rid of it. Then kill all of them and their associated watchdog process (it will be a bash process). (If that's too complicated, just reboot the server) Also, could you show us how your "server.cfg" file looks? I think it has a few errors in it...

The nohup message is diagnostic and should not affect things. However, it shouldn't be visible at all if you use the original arma2server script that comes with BIS dedicated server tar archive. As an example, here's how it looks when you do it for an A2 server installed in the home directory of a user called "foo", in a subdirectory named "a2s": [foo@localhost a2s]$ ./arma2server check ArmA 2 directory: /home/foo/a2s/arma2server OK Server executable: /home/foo/a2s/arma2server/server OK Port number: 2302 Config file: server.cfg OK PID file: /home/foo/a2s/arma2server/2302.pid RUN file: /home/foo/a2s/arma2server/2302.run [foo@localhost a2s]$ When I run the server using the start script, this is all that's printed: [foo@localhost a2s2]$ ./arma2server start Starting ArmA 2 server... [foo@localhost a2s]$

It is - you get it when you install the ArmA II 1.05 patch.

Keep the default values there: ARMA_DIR=. CONFIG=server.cfg PORT=2302 PIDFILE=${ARMA_DIR}/${PORT}.pid RUNFILE=${ARMA_DIR}/${PORT}.run LOGFILE=${ARMA_DIR}/log.${PORT}.txt SERVER=${ARMA_DIR}/server When you use for example RUNFILE=/2302.run it means that the server will try to write to a file in the root of the file system ("/"). You aren't allowed to do that.

That's good news. Most likely, the difference we have stems from the Eagle Wing hotfix - you don't have it yet, which would explain the file size difference. If you have a local, known good installation, you could use rsync to fix the server's copy of the addons folder. See my post #8 in this thread (on page 1) for an example rsync invocation. If it's only a few of the files that got corrupted, that will save you a lot of time. I don't think it is. The hotfix is simply an archive with two files that you extract into the Addons folder, overwriting the old ones.

That'll be my suggestion aswell. :) ARMA_DIR should be left at "." or be set to the full path to the directory where ArmA II is. For example: ARMA_DIR=/home/someuser/arma2

The thing in red may indicate that one or more of the addons were corrupted during the transfer. How did you transfer the files to the server? If you were using the FileZilla FTP client, here's a tip - make sure to check the Transfer->Transfer type menu and set it to Binary (The "Auto" setting has a way of failing, corrupting transfers). yep, that would be very nice. There's a complete class Missions for the server.cfg at the BIS wiki now: here My addons folder (1.05 ArmA II with the Eagle Wing campaign hotfix applied) is 8 840 778 390 bytes in size. On the Linux server, using du, I get the same result (Actually, du will add the size of the "." directory entry, making the sum 4096 bytes larger.) du -b --max-depth=1|grep "./addons" 8840782486 ./addons (8840782486 - 4096 yields 8840778390, which is the same as my Windows installation Addons folder size.) The core.xxxx file is a core dump, which is written by the system when the server crashes. The number is the process ID the server had when the crash occured. You can safely remove these files. Only two, as above: Compare sizes of the addons folder with your Windows installation Make sure the files weren't corrupted during transfer. If you have applied the EW hotfix, you can use this MD5 checksum file for the addons folder: here. Perform the MD5 check from the server root (user home in your case): md5sum --check addons-105-ewhotfix.md5sum PS. CentOS 5.3? That's at 5.4 now. In the name of security, do a "yum update" ASAP :)

What server are you playing on? Does that server allow people to connect with whatever mods and addons they like? If so, it seems as that other player had some extra addons loaded that add countermeasures (flares etc). If not, he's using "other means" :rolleyes: of defeating the Stingers.Maybe the particular Warfare mission you're playing has implemented a countermeasures system? You can not get a fair game on servers that don't at the very least uses signature verification to limit what people connect with. If you persist in playing on servers that allow everything, well...

What if you set the server's name to include the word "HOLD", for example hostname="ArmAcalypse.com PvP (ex-BMF) [HOLD]"; Then, if you filter on the word "hold", your server would show up.

I noticed they were a bit difficult to find, so I've added a section with a few tips for dedi installations here. Hope that helps! :)

Hmm... try having this: class Extended_Init_Eventhandlers { class Man { NOU_MapInit="diag_log text 'Maptools init';[] execVM '\MapTools\script\add_ruler.sqf'"; }; }; Here, I've used a made-up OFPEC tag in order to make your XEH init entry (hopefully) unique. This should log something to your ArmA2.RPT file when a mission is started. (Please head to the OFPEC tag registry and register a tag for yourself, then use that) Yes, the XEH documentation isn't very clear on this. The general rule/convention is: make up a name for your extended event handler entry that's unique. One way to do that is to to name it eg <TAG>_<somethingunique>. There isn't any other documentation than that which is in the CBA wiki, but have a look at other addons out there that make use of the extended event handlers system, such as the ACE addons (like Sickboy mentions). That's a good way of learning a few tricks. :) Hmm...interesting... that may need some poking at to see if we can solve it. :)

Have a look at the install script - it t does a few other minor things aswell, but if you've changed all file names to lowercase, you're good to go. The install script will Compile tolower.c into the tolower tool. Run tolower and convert all filenames. Sets some file permissions Removes Windows-specific files (DLL, EXE, CHM) and removes the tolower.o object code file [an intermediate file created during compilation] No, there's no need to re-upload all those files - judging from the server log, you managed to get it working in the end. Glad to see you got it going! :)

In stock ArmA 2 (up to and including 1.05), there are no event handlers for the two classes House and Land_Fire. Furthermore, I've just tested with CBA v0.2.0 and the slightly newer one delivered in the ACE2 beta program and in both cases that which the default ArmA 2 init event handler does for Land_Fire_burning is being done - the fireplace is burning, showing that the default ArmA 2 init EH behaviour for Land_Fire_burning is intact.Did you mean to say that your variant of the Land_Fire_burning init EH as per the config.cpp in above doesn't work when CBA is loaded? Yes, that won't work. You'll need something like class Extended_Init_Eventhandlers { class Land_fire_burning { XYZ_GL4_init="_this execVM ""\GL4_Burning_FX\GL4_Camp_FX\GL4_Camp_FX.sqf"""; }; }; Change "XYZ" to your registered OFPEC tag. (The extended event handlers system has made the default BIS init EH for that object CBA-compatible so that you can add more event handlers to the fire object if you need to) Don't worry about the default ArmA II event handlers - CBA retains them. Add your own init EH:s in a Extended_Init_EventHandlers class like example above. Once all the GL4 init EH:s are "ported" to extended event handlers, you won't need the CfgVehicles section at all. Good luck!

The Core i5-750 one is the faster and therefore better choice. And no, you can't play "at high level with no lags", but you should be able to tune the graphics settings to get decent performance.

That's an error on that web page. The file you download is arma2server-1.05.62021.tar.bz2 which contains the 1.05 server. BIS has forgotten to update the install shell script with the new version number. Don't worry. Have a look at the readme.txt. The very first step in the installation instructions. It says this: You get those two errors because you don't have gcc installed on your machine. Do that. Install gcc: # yum install gcc Yes. Since you didn't install gcc, the install script was unable to compile the tolower program, which the script needs to convert all the file names to have lowercase letters. You failed to follow step 1 of the installation instructions, which then led to the problems you've had. Try it again once you've got the gcc compiler installed. Yes, that's the output you see normally.Good luck! :)

Sweet! Yeah, I've had FileZilla bite me in the behind with it's disfunctional "Auto" file type functionality. Set that thing to Binary and be done with it. :-)

Ok - it's a 32-bit Etch - thanks. I'll try to reproduce the problem here - I just need some time (and sleep) to set up a virtual machine with a 32-bit Etch. Hmm...in the mean time - is the OS up to date with the latest Debian updates? Maybe there's been a bug fix to one of the system libraries or tools: apt-get update; apt-get upgrade Sometimes, it will tell you that some packages have been "kept back". If so, you'll get those by apt-get dist-upgrade Once the machine is fully up-to-date and rebooted, try running the server again. (It's possible that the server is already fully updated and none of this will help) Another thing is to check that the server executable isn't corrupted. Here's the MD5 checksum for a 1.05 server: (Stab in the dark, but...) $ md5sum server 7584ea5d76380acc8dd659ff9e51e7b7 server