[kh]jman

You can set affinity if you like but I find that windows distributes the cpu load across all cores by default.

Thanks and please do PM me if there is any new information or corrections that need to be made I've tried to make it as concise as possible but since there is no official ArmA2 documentation at present it seems like a practical thing to do.

1. Sorry typo. I've corrected it. 2. They can be defined globally in the server.cfg 3. As I explain in the guide, I have omitted these from ArmA2.cfg since they are generated automatically and are not related to multiplayer. 4. No you only need UDP

It's actually: class Missions { class Mission_01 // name for the mission, can be anything { template = mymission.Chernarus; // omit the .pbo suffix difficulty = "Regular"; // difficulty: Recruit,Regular,Veteran,Expert as specified in *.Arma2profile }; class Mission_02 { template = anothermission.Chernarus; difficulty = "Veteran"; }; }; Refer to my guide.

Kellys Heroes Guide to ArmA2 Dedicated Server

Nope ArmA2's xml schema (I assume you mean squad xml) is identical. [link]

I'm going to write a full tutorial on how to setup the ArmA2 dedicated server. I'll post something up shortly.

Our server is high end it's based in the UK it's colocated in Rapidswitch UK which is independently rated by SpeedTest.net as the fastest network in the UK, and third fastest network in the World. Thats all I'm gonna say anything else would be pointless.

There is only one default and that is the server limit. You'll find it in the 'server.cfg' maxPlayers= ; All playable slots are defined by the mission.

Not sure about the player halos specifically but try: difficulty="regular"; as opposed to difficulty="recruit"; in the *.ArmA2Profile. You never know, I don't see them in our server but never had in multiplayer on 'recruit'. Our server configs: [Link]

That would explain it! - just post a link to the v0.2 Key - that will fix it for this 0.6 release ;) and in future maybe use the same version *.biprivatekey and *.bikey to sign all your future releases :)

Great addon. Love it :) One problem, your public key does not work :( be nice if you could re-sign the pbo and post a new *.bisign. I'd be happy to test it before release. Thanks.

Multiplayer viewdistance is enforced by server/mission so it will not have been 10K as per your ingame video setting, the server default is 1600 so with that in mind turn your viewdistance down in singleplayer for a better framerate. I would suggest somewhere between 1600 and 2000

You'll need to use something like Kegetys 'cbpo' which is a .pbo extractor/repacker [link]

That would be defined in the mission scripts within the mission pbo. The server cannot set it directly only the overall server maximum.

Yes I think they are they are on the ArmA Biki somewhere which is down right now.

Our nic configuration is as follows: Adaptive Inter-Frame Spacing = 1 Coalesce Buffers = 128 Fast Transmit Completion: On Enable PME: Disabled Flow Control: Enabled Jumbo Frames: Disabled Offload Receive TCP Checksum: On Enables the adapter to verify the TCP or UDP checksum of incoming packets. With Offloading enabled, the adapter completes the verification for the operating system. This feature enhances reception performance and reduces CPU utilization. Offload TCP Segmentation: On Enables the adapter hardware to segment data into valid Ethernet frames. With TCP Segmentation enabled, the adapter segments the data into frames. Because the adapter hardware is able to complete data segmentation much faster than operating system software, this feature greatly increases transmission performance. In addition, the adapter consumes fewer CPU resources. Offload Transmit IP Checksum: On Enables the adapter to compute the IP checksum of outgoing packets. With Offloading enabled, the adapter completes the verification for the operating system. This feature enhances IP transmit performance and reduces CPU utilization. Offload Transmit TCP Checksum: On Enables the adapter to compute the TCP or UDP checksum of outgoing packets. With Offloading enabled, the adapter completes the verification for the operating system. This feature enhances TCP and UDP transmit performance and reduces CPU utilization. QoS Packet Tagging: Disabled Retransmit Inter-Frame Spacing: 6

for info: sceneComplexity is enforced by server but viewDistance & terrainGrid are. The render distance is 3/4 of view distance - for 1600m, objects will be render up to 1200m

Sorry crossed wires! They only extended netlog that I'm aware of is: NetStats=1; in the server.cfg That'll give you extended info in the logfile. Is that what you mean? EDIT. I see what you mean. It only works in 1.02 Patch update onwards.

@ JaKe.OnE The command has not changed since ArmA Place the following in the server.cfg logfile = "mylogname.log"; If you are not seeing it then it maybe a permissions issue on your server i.e the logfile cannot be created/written to. Either create an empty logfile in your serverpath or check the server's read/write permissions. The logfile is situated in the same directory path as the server.cfg by default so if for instance your startup line is: -name=myServer -config=myServer\Server.cfg -cfg=myServer\Arma2.cfg -profiles=myServer the logfile will be created in \myServer

I like the thoery but only a Bi dev could answer that one I think. I guess it comes down to exactly how the engine is programmed and what the sequence of proceedures it actually goes through during jip. Bi improved jip in ArmA 1.16b considerably but it still couldn't cope with custom faces & sounds particularly well. I'm not sure that the same 'update' has been applied to ArmA2, one would hope so but I'm not convinced.

@SRRViper The desync we see tends to be generated when players connect - jip lag basically, the jip netcode tranferring the mission data, unit postions and other environmental conditions. The desync will get worse the longer the mission has been running since there's more netcode to transfer to the client. I've never really fully understood why the jip process lags all the other players that are sync'd up, perhaps thats part of the netcode that can be looked at again and optimised (devs comment?). Obviously the more players you have on the server the more potential there is for desync jip lag. From the joining players point of view, they will observe that in circumstances where the mission has been running some considerable time they may find themselves sitting on 'waiting for host' for some considerable time and once in-game still see the 'red chain' (desync'd) for a further 30 seconds or so whilst their client 'catches up'. As a clan we have a policy whereby we tend to lock the server as soon as we start seeing jip lag and wait for the joining client to sync up before unlocking the server again and allowing more clients to join this prevents a roll on jip lag effect. This is exactly the same policy we ran for ArmA, it's a shame we stilll have to do it for ArmA2 but there you go I blame the netcode. I was very careful in choosing a good nic card for the server as it was important for the card to support a TCP/IP offload engine so our server's network card does all the work shifting network I/O load away from the cpu's. The server is co-located in Rapidswitch's new D3 building. The Rapidswitch network has been independently rated by SpeedTest.net as the fastest network in the UK, and third fastest network in the World so I very much doubt we have any issues on that front. Since we've had the new server we see no warping so thats certainly confirmation that server's under no real stress. The *.ArmaProfile we use contains the following numbers which seem to work well on 100Mbit MinBandwidth = 15000000; MaxBandwidth = 100000000; MaxMsgSend = 1024; MaxSizeGuaranteed = 1024; MaxSizeNonguaranteed = 64; MinErrorToSend = 0.0025; On our public server we allow VON but not custom faces and sounds since just as in ArmA it causes additional jip lag on client connect. Watch for players with pings higher than 300 they will lag the server and everyone else on it.

Respawn is dependent on the mission scripting. What mission were you playing?

We can run 50 just fine as long as we lock the server from time to time - the lag tends to be caused by 'jip' as players connect & disconnect. Our server runs at around 35-45% load when full - plenty of overhead. We run Firedaemon, a mailserver, Teamspeak, Vent, IIS and several other web services as well. We can always add another Quad into the 1U if we need to. Our old server was on ArmA1 and was a AMD single core 3800+ with 1GB of ram on Win 2003 x64; it did us proud for a year and a half with 30 player coop's and 60 player pvp's, it did max out the cpu @ 100% load so there's your minuim spec right there. Run a nice tight server install, keep your server services optimised and make sure your on a good network (100MB).

1U rack server funded & bought by Kellys Heroes clan members. All components purchased from Broadberry Data Sytems (tell'm I sent you) Spec'd and built by myself. Co-located @ RapidSwitch UK SM 813M TQ SM X7 DCL-3 Xeon Quad Core L5420 Low Voltage processor 4 GB DDR 280 Watt PSU 1TB Raid 1 Windows Server 2003 Outputs only 0.4 amps on full load!