Proton

New standalone server hotfix 1.57.76903 was released. Is it supported? Seems working...

Does 1.4.6 support the 1.57 patch?

I have a problem on XP64 with OA 1.56 and the 1.4.2 release. The new 93696 byte 'dsound.dll' crashes with both arma2oa.exe and arma2oaserver.exe upon loading. Crash says the problem is within dsound.dll. If I replace 'dsound.dll' with the old 47104 bytes long 'dsound.dll' from the 1.3.8 lib release, it works flawlessly.

Just to clarify the status of this mission: I had another non-released version back in 2009, but then Benny started editing warfare of A2. I realized that in the long run I do not have the necessary amount of time to compete with him, and it makes more sense to modify his edition, rather than parallely replicating everything. My efforts to contact other warfare editing people to create a joint project failed. I am currently running a custom edition of Benny's warfare at 155.198.117.142 ([iMPERIAL] Warfare VETS) which is used in a scientific project.

Some of the environmental sounds in v1.04i look buggy. As these sound are prominently used in the game, it is extremely audible and disturbing, like having a permanent shell shock. By unpacking the .pbo manually and examining the samples without the game, this is caused by Forest_Day.wss, Forest_Night.wss, Meadow_Day.wss, Meadow_Night.wss having a constant pitch, which gets stronger towards the end of the sound. Same problem with hilux_int_* sounds in vehicles.

If I understand correctly, long loading times cannot be created by verifySignatures. All what the client does is that it downloads the keys from the server (a few kbyte), and checks that the files were signed with that key. Only the client works, the server does not use any CPU time while checking. It means that the load wait times are caused by something else. It happens at the latest phase of the progress bar, the waiting can take many minutes, and the game looks frozen. Does somebody know what happens at that time? Probably the client downloads all changes what was made in the game world (like flattened trees/destroyed buildings), and publicvariable'd data.

Legislator I see you created more addons and signed them with the same key. I want to enable the FLC mod but not the others, which is impossible of you use the same key for each. Therefore by adding your key to the server I create unknown security risks. In general, a server admin simply has no time to hunt down all addons of a modder, and check that all are safe. This is one reason why enabling mods is rare on public servers. Modders do the best if they sign each of their addon with a different key, or group their addons according to what they modify (pure config-based, etc.), and sign each group separately. Even better, they should maintain a public list for each key, which lists all addons which were signed with that key. So we have an idea what do we enable with adding a key.

Deadfast just a recommendation: as you produce multiple mods, please generate a separate public/private key for each. I want to enable the FPS mod on my server, but not the others, and because you use the same key for each, it is impossible.

The reason looks like to be that checkFile does not work if verifySignatures=0. If it is 1, the regularCheck line above works. Looks like verifySignatures turns on/off the entire checking facility at once :(

Playing with #exec gave some hints. If you actually let the script return a value, it shows up correctly, like '#exec 1 > 2' prints 'false'. I checked that you can define local variables. So you can try what is possible or not. If you peek into the .exe, the 'checkFile' command has an internal help, and it looks to be incorrectly documented in the BIKI. Instead [id,name] it should be called with [id, file_index]. Issuing '#exec 0 checkFile [3,x]' (if player id is 3 from #userlist) does show up in Process Monitor as disk activity on different files with changing x, starting with the bin.pbo and core.pbo, so it is reasonable to believe that it does what expected. Based on all of this, I tried the following in server.cfg: verifySignatures = 0; regularCheck="_id = _this select 0; _req = _this select 1; if ( _req < numberOfFiles _id ) then { 0 checkFile [_id, _req]; };"; This should let players in, but check each file once later. The problem is that it does not work. I have 'session lost' after loading the mission, probably at the first run of 'regularCheck', no error or kick messages in any of the logs. Whats wrong?

I have an idea to replace verifySignatures=1 with a 'lazy' checking, because signature checking can take serious time on a heavily loaded server before connecting, somewhere in the range of 5-10 mins. People turn this feature off regularly because of that. The idea is to set verifySignatures=0 and run 'checkFile' commands in the regularCheck event handler *after* people connected, so people can connect immediately, but their files are still checked later. The only disadvantage is that until they checked, they can do harm, but in this case they got banned anyway. Anybody has an example of a server side script which actually does something else than kick or ban? BIKI says that My problem is that the command set looks like to be extremely limited or even non-existent beyond the set of 'users, ban, kick, checkFile, numberOfFiles' listed there. An exception is 'select', which works, as we can see from the examples. However, I cannot even output a string. 'diag_log' does not work. I have seen others trying ' server globalChat "foo" ' but it does not work either. Using a wrong 'localize' does not put anything into the .rpt. 'Compile' does not work (so the trick of making a wrong line and compiling the info into the code does fail). So how in hell can I actually get some info what my event handler is doing? regularCheck threads do get executed, as if I place there a line with a syntax error, like ending it with {, the error does show up in regular intervals in the rpt.

Here is the result of a small study I made over the weekend. I use a modded Warfare mission on Chernarus with the latest beta (72197) of OA, where each town immediately spawns all defending teams. The mission was started by a client, who immediately disconnected after start (server is persistent DS). I measured the performance in the first couple of minutes after that. Considered parameters: Hardware/OS. Two pieces were used, one running Q6600/XP64 Pro, the other one is i7 920/Win7 64-bit. Number of groups/units created. Each group consists of 6-12 units. I tried 30 and 120 groups. The effect of AI. After creating the groups, one version let the default AI run and created random patrol waypoints for each group which kept them moving. I also set the group behaviour to "COMBAT", but this was almost immediately set back by engine to AWARE for most groups. The other, "AI disabled" version immediately sets the group behaviour to SAFE, and issues { doStop _x; _x disableAI "TARGET"; _x disableAI "AUTOTARGET"; _x disableAI "MOVE"; _x disableAI "ANIM"; } foreach (units _team); Location. One version used a limited distance from town centres which kept all units close to or within town borders. The other one let the groups randomly spawn over the entire map. This is 2^4=16 parameter combinations, of which 12 were actually tested. The benchmark consists of 4 parameters: Real execution time vs. engine time. This measures whether all the scripts could run in their devoted time. Measures were scheduled to run in each 30 seconds via the 'time' function. If the measures executed at longer intervals in real time, it means that the engine was unable to run all scheduled scripts as requested, and the mission will inevitably slow down to a crawl (until it can reduce the data input to match its processing capability), or crash at some point. I waited for at least three measurements. server FPS via diag_fps, minimal server FPS via diag_fpsmin, the running time of a small benchmark script: for "_i" from 1 to 1000 do { [_i] call {_this} }; The results are usually getting worse with later measurements as the player teams (controlled by AI here) start buying units and vehicles for themselves. Results: Conclusions: It is definitely worthy to own the latest hardware for a DS. The i7/Win7 combo seems to handle scripts much better, even when FPS is low - or it just has enough power to finish in the scripting time slice, unlike the Q6600. The single most important factor is the number of units in play. As a rule of thumb, 4x more units make the server run 4x slower, even when the AI is not doing anything! AI seems to have a significant effect, somewhere between 5-10 FPS. However, (at least per-unit) AI calculations seems to come only second to the impact of the actual existence of units. It is not true that towns slow down AI calculations, at least random starts looks like being harder to crunch. Two questions remain: why in hell does it matter that a non-moving, non-controlled unit is created? It should be treated like a tree or a house. Why does it push the FPS down almost linearly? The other thing I do not really understand yet that why my server goes down to 10 FPS by time, as it rarely have more than 30 of these groups spawned at the same time. Temporal analysis follows.

Even if the FPS is dependent on mostly AI pathfinding, in the end, the scripts *do* influence FPS by making the choices to do a lot of pathfinding. So it is worthy to know what is actually making the server running slow. Your observations about AI in urban areas is important, however I do not understand why a standing unit in a town is consuming more time. ---------- Post added at 02:33 AM ---------- Previous post was at 02:32 AM ---------- I believe -exThreads=7 is the automatic choice with 4 cores. And the server actually runs 4 active threads, so it is obviously distributed amongst the cores. But do they all run on 100%? I doubt it. I also doubt that you can run Benny's Warfare with 50 FPS, especially with hard resistance/occupation defenses.

Not really. You imagined a world where, I quote you, "Any added co-processing with the GPU would be beneficial on any dedicated server". This is simply false. If you understand "beneficial" which concerns the entire A2 project, you have to consider development time as well. What is more important, a new extension pack, or figuring out how to do GPU computing? And as we discussed, plenty of examples exist where off-loading to the GPU makes the app slower. You do not know that A2's bottlenecks are not alike. Neither can you (or me) be sure about the opposite, although you seems to be confident about the first being true for some reason (just bought a new NVIDIA card? :) )... What I am saying is that the engine is lacking in many other aspects, and it is ridiculous to ask the devs to spend months on an obscure GPU acceleration which probably gives some benefit on limited architectures, all that by using still evolving APIs. Even using up all CPU cores should come before GPU computing. There are still hundreds of bugs listed on dev-heaven. Fix at least half of them first. I am actually running a dedicated server on a machine with a unused but powerful NVIDIA card in it, still, this is my honest opinion.

I doubt that the problem is with the .cfg settings as I barely use networking now. What kind of data output you get via #monitor? I have around 1800 Kbps when the mission runs in its full glory. Probably I took them from the same place... :) ---------- Post added at 06:40 PM ---------- Previous post was at 06:22 PM ---------- If its true, it does that in a strange way. I just tried respawning one side's entire army, destroying all vehicles and units when the mission was already running for a long time. It means removing hundreds of units and vehicles at once. It had no hit on the server FPS. So what is going on here? This is indeed the best hardware option. The devs said something that the next betas are going to speed up AI pathfinding... fingers crossed. I get a decent server FPS with no AI. My question is more about how to improve FPS with lots of units. For example, if I change group waypoints less frequently, it may have an impact on AI pathfinding. Does it matter? From the experiment above, it does not. So only the number of AI units counts? Thanks for sharing this insight. I suspected something alike, so until scripts do finish in a reasonable time, I should not worry about them.