killswitch

One could theoretically alter the start script to give it the functionality you want (using the tee utility), but perhaps this simpler solution is enough: Once you've launched the server using ./arma2server start, you can use the tail command to see what's being saved to the log file: tail -f log.2302.txt tail is a small utility that displays lines from the end of a (text) file "-f" is used to follow the file. What it does is keep the log.2302.txt file open and print out whatever's being added to the file over time You exit the utility using CTRL+C, at which point you're returned to the command prompt.

The model optimisation process ("binarization") whereby an ArmA II MLOD model is turned into a ArmA II ODOL one isn't reversible. In other words: you can't "unbin" a ArmA II model. Hopefully, you have the editable version tucked away somewhere...

Yeah, there's a few gotcha's here: The -config parameter needs to be a relative(*) path (and it trims off your leading '/' to make it so. Try just "-config=server.cfg" There is no -basic parameter. That's -cfg You're probably better off using the arma2server start script. (You can edit it to include the -cfg=... part if you want to. (*) Relative to the current working directory, ie where the arma2 server files are.

These are errors somewhere in one of the mission PBO files on your server. Unfortunately, the game doesn't telll us which mission it is (and it's the same thing with the Windows server) If I'm not mistaken, they are just warnings, and yes, it is possible to correct the description.ext if you can find the mission or missions that have the error.(That involves unpacking, "de-PBO:ing", each mission and searching the description.ext files for the lines mentioned in the warnings)

It's likely this happens because there's no SPF record for the domain "plannedassault.com".Read up on SPF and create a SPF record and get that into a DNS TXT record for the domain. More here help and a SPF wizard here: www.openspf.org

Maybe you're affected by the same issue as this bug report details: Bug #9590?In that bug report, Sickboy has attached a variant of the addon "extended_eventhandlers.pbo". Replace the current one you're using and try the one in that bug report and see if it helps. If it doesn't help, we'd like a copy of the troublesome mission that exhibits the problem you're seeing. If you register at DevHeaven, you can create a new bug report in the CBA project page and attach a mission that shows the problem.

It looks as if you're trying to start the game and are loading a mod or addon that requires CBA, but the CBA mod folder is missing from your mod folder startup list.Show us how your ArmA II shortcut parameter list looks. As an example, this is how it should look when you load the ACE mod. Notice how the CBA mod folder ("@cba") is present in the -mod parameter list: "C:\Games\ArmA 2\arma.exe" -nosplash -mod=@cba;@ace;@acex;@acex_pla;@acex_sm

Choosing between more memory or another processor, if you can get a Q9550 for those £100, do it. Otherwise, I wouldn't put more money into that old(*) computer.(*) Which is still an excellent rig for most other games out there.

See here: How_do_I_turn_off_the_ACE_marker_system_in_my_mission?

If there is no mission selected, there's a 1 minute voting timeout before a selected mission is loaded unless an admin logs in and selects a mission. Is that what you mean? If it isn't, and you're referring to a delay that occurs if a player connects to a mission that's already in progress, then I'm not sure why that happens. It could be A server disk I/O issue. (Make sure the server isn't accessing the hard drives using legacy IDE mode and check the I/O load eg using the sysstat package (iostat tool) ) Name resolution problems - make sure DNS lookups work as they should. Something else - are there any strange kernel or system log messages?

First a few general observations: The server.cfg looks good. Your "basic.cfg" looks OK. I hope it is actually named "startup.cfg", since that's what the start script tells the server to load. The startup parameter "-profile" is actually -profiles with a trailing "s" but... ...it indicates which directory the user profiles are stored in, not a specific user profile file... ...furthermore, that parameter doesn't do anything in Linux, so you can remove that from the start script entirely. [*] Since the start script uses -name=host, the profile that will be used is host/host.arma2profile Your primary problem is the log message Cannot open file '@acex\addons\acex_c_veh_m2.pbo' This may be because the file isn't actually there, or that it has been damaged/corrupted during upload. Can you tell us how you installed ACE 2 on the server? A common reason for corrupted files is using the FileZilla FTP client. By default, it has the file transfer type set to "Auto", which will corrupt uploads. Change it to "Binary" and you should be file (There are three possible settings - auto, binary and ASCII)

It applies to all files in the Linux ArmA II server directory. The server application is coded to accept only lower-case filenames. That looks fine and OK.

Yes, everyone who runs an A2 dedi has seen this before. That's what the dedi does - it really doesn't load more than one core fully. The ArmA II dedi doesn't scale with the number of available CPU cores. (There is *some* CPU load on the other threads that the dedi creates, but you'll be fine with two CPU cores for the dedi.) Search around this forum - there have been several threads regarding the resource utilisation of ArmA II on modern multi-core processors.

if (isNil "_tmr") then { _tmr = -120; };

All files and subfolders in the ArmA II directory have to be in all-lowercase letters. If you changed the name of the missions folder to "MPMissions", you won't see those missions.

Thanks for the details! Everything seems to be in order...there's one thing though - I notice that the machine loads the sky2 driver. I remember that thing from my old job - we had a workstation with an onboard Marvell E8053 network adapter, and we just couldn not get it stable with the sky2 driver. (Strange dropoputs, kernel oops messages and whatnot). IIRC, we tried the alternative "sk98lin" driver aswell, but in the end, the onboard ethernet was disabled and replaced with a proper Intel card (e1000 driver) Worth trying: set up the elrepo repository, then install and use the kmod-sk98lin driver and switch the ethernet card over to that driver. (Stage 2 would be to find another LAN card and try that instead). Other than that, I'm stumped - everything seems just dandy with your setup. How does the ArmA II server log look when the server is started? It should be clean with only these three lines: WATCHDOG (9208): [Mon Jan 25 07:39:40 CET 2010] Starting server (port 2302)... 7:39:55 Dedicated host created. 7:39:57 Host identity created. (The time stamps will differ, of course)

Your configs and the profile file looks OK. Could you tell us a bit more about the OS, arma2 server and general setup? 1) What does "uname -r" say? 2) Is SELinux active and in enforcing mode? What does "/usr/bin/sestatus" show? (BattlEye does "things" that SELinux protects against, one solution for which is to turn off enforced SELinux mode. OTOH, you don't have BE enabled...) 3) What is the output of "dmesg" just after a reboot (pastebin this, since it's a lot of text) 4) Do you have the firewall rules in CentOS set up alright, ie are you letting in traffic on 2302-2305/UDP? 5) In the server's BIOS setup, what is the SATA controller set to? AHCI or "Legacy IDE" (or similar) 6) What modifications, if any, have you done to the arma2server startup script? 7) Do DNS name lookups work? (Try "host arma2pc.master.gamespy.com") 8) You mention a FiOS setup. How is the server physically connected? Ethernet wire from the server to a router of some sort and then onto the fiber? 9) What about the FiOS router firewalling/port forwarding (if applicable)?

host.arma2profile (as specified in arma2server) The file "host.arma2profile" looks to be correct, but you have two new environment variables added to the start script, arma2server.That probably means that the start script is altered in other places aswell. Can you show me what else has been changed in that script? What I'm thinking is that the server is launched with parameters that makes host.arma2profile not actually be read, which then explains why you're still seeing 3rd person view available in Veteran mode. I'm guessing something like the following was added to the line that starts the server: -name=$NAME -profile=$PROFILE If that's the case, the solution is to remove the -profile parameter. Having "-name=$NAME" is enough to make the server read the host/host.arma2profile without the need to specify a profile path using -profile=....

If it didn't work, you did something wrong. I've tested the class Difficulties from that wiki on a dedicated Linux 1.05 server. When I edited the 3rdPersonView for the veteran difficulty to not allow 3rd person view and ran a mission on the server in Veteran mode, 3rd person view was indeed not available. Note that what's on the wiki is a class Difficulties corresponding to the default ArmA II difficulty settings, and by default, Veteran mode has 3rd person view enabled - you'll have to edit that setting to disable it.

Enabling persistence will allow missions that have respawn set to either "INSTANT" or "BASE" to keep going after all players have left. That's all it does. (It doesn't make such a mission automatically start.) It should, barring firewall, DNS lookup or connectivity issues. That ought to do it. I'm not sure why it doesn't work for you.

The ACE localization follows your normal ArmA II language setting. You can switch to english by finding the file called "arma2.cfg" and change language="French"; to language="English"; Note that this language switching is not possible on some releases of ArmA II (many/all(?) the German ones, for example). The above is possible on my "international" ArmA II though.

It's the mission pbo filename. It needs to be in all-lowercase. Re-run the tolower utility to convert it.

You're welcome - I'm glad to have been of help. :) Yep - just unpack/upload the new "missions_ew.pbo" and "missions_ew.pbo.bisign" on the server. OTOH, tf the server kicks you "for the Apache", perhaps there's some trouble with your ah64.pbo and ah64.pbo.bisign files (or the server's copies of those files).

I should have formulated that in a more stringent way:Turning on signature verification by itself is only part of the solution. It can be used to guarantee that clients have the same version of addons as the server, if and only if: Signature verification is enabled on the server (obviously). The addons are signed with a new key every time they are updated. The server has the latest versions of the .bikey files for the given addon in the Keys folder and only the latest versions. If these conditons are not satisfied, one cannot guarantee the same version addons on client and server. For example, it is quite possible to have "XYZ_MyMod_v10.bikey" and "XYZ_MyMod_v11.bikey" in the server's Keys folder. This would allow clients with either the "1.0" and "1.1" addon sets to connect and that's probably not desirable. It's more the latter - the client's files are checked against the client's own .bisign files and against the server's files. A common thing we see these days are people connecting to 1.05 servers and one of them (client or server) haven't applied the Eagle Wing campaign hotfix. Their (old) EW mission pbo file (and associated .bisign file) are perfectly OK in that they are original files, signed with BIS own key and not tampered with in any way. Still, they get kicked off (or worse, it's determined by the server.cfg onDifferentData setting) if only one of the server or client has the EW hotfix installed.