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.

////////////////////////////////////// Warfare V1.8F Proton Mods 1.3 ////////////////////////////////////// LATEST UPDATE: 12/08/2009 4:21 UK time - 1.3 released. Download link: MP_Warfare32V18E_PE13.zip This is a modification of the Superpowers 1.8F Warfare mission of ARMA2 v1.03. It was inspired by the excellent ARMA1 Warfare mod of Benny (XR). Check the changelog for a complete list of modifications. Credits: Most of the code is a hack of BIS's warfare. I am using Kronzky's string scripts. The options dialog is based on a dialog in Benny's warfare2 edition. Please report bugs in this thread. LIST OF CHANGES: 1.3: + Increased overall AI skill to the highest. + Added an option to the communication menu to unflip selected vehicles. + Added an options dialog where it is possible to 1. set the view distance and terrain grid, 2. transfer money in a more convenient way, 3. compact and sort group member icons and 4. set the default vehicle lock/unlock. + Fixed bugs in the buy units menu hack. + Fixed: added arty server script timeouts to handle non-responding clients. + Fixed: destroyed AI teams are now re-added to high command properly. + Fixed: AI groups defending base will now leave their static defenses if base is too far. + Fixed: AI commander now moves its building location with the HQ, so it is possible to relocate the MHQ and give the command to the AI again. + Fixed: AI commander will not build in water anymore. + Fixed: Improved vehicle placement around factories. + Fixed: Mission works again on a shared client/server. 1.2: + Added artillery. + Found a workaround which made the addon unnecessary. + Added more weapons/vehicles. + Merged with changes of the 1.03 update. + Fixed game ending with a single deployed MHQ. + Fixed: base construction menu for non-AI first commander. + Increased starting money to $1000. + Increased minimum side starting distance to 4km. + Changed MHQ repair cost to $15000. 1.1 BETA: + Fixed buy unit menu for multiplayer clients. + Fixed bugs in supply truck autopilot. + Server-side execution of MHQ wreck placement. + Made lock/unlock faster for the owner. + Added more vehicles. + Fixed: minimum HQ deployment range from town centers works now. + Fixed: structures now updated for new clients. + Fixed: AI supply trucks do not refill anymore at undeployed or destroyed HQ. 1.0 BETA: + Buying units is now possible anywhere on map and from vehicles. + New vehicles now locked by default to prevent stealing. To lock/unlock, select the action menu of the AI in the vehicle (button '6') or stand next to it, and select "Lock" or "Unlock". + Service points now refill supply trucks. AI supply trucks are aware of this and use them. + Added an action to the player's AI driven supply trucks to automatically resupply a selected town (to make their management easier). + You can now respawn at any base structure and the undeployed/destroyed MHQ as well. + You can respawn at mobile ambulances if you died closer than 800m to it. Their price is increased to reflect their utility. + You CANNOT respawn at a camp or a mobile ambulance anymore if you died closer than 100m to it, or there are more or equal enemy troops than friendly closer than 50m to it. + MHQ wreck cannot be salvaged anymore and AI salvagers are no more aware of it. + If the deployed HQ is destroyed, an MHQ wreck is created in its place. + A destroyed MHQ can be repaired with a repair truck for $25000. + Enabled victory for capture all towns. + For a destroy base victory one side must destroy the MHQ and *all* existing factories (regardless their position). + Town information on the map now shows the maximum supply value in 'actual/max' format. + Added lots of weapons to both sides (like the AT13 to counter the Javelin) with updated costs. + Added vehicles (like the MLRS and the GRAD and airplanes to the air factory). + Increased supply costs and build time of structures. + Added a tag to identify ammunitions in the buy gear menu. + Fixed: removed build menu for destroyed vehicles. + Fixed: second crewman now properly placed into turret. + Fixed: items in buy gear menus are now shown only once. + Changed maximum number of players to 32. + Increased respawn time to 30 sec. + Increased maximum group size to 20. + Number of AI supply trucks was increased to 5 and AI salvagers to 2. + Increased base deploy distance from towns to 500m. + Changed mission setting default to "FastTime" (nights are fun!). HINTS: Currently there are 3 types of artillery: mortars, howitzers and rocket launchers. To start a fire mission you have to own some of these, and they should be manned with your own group's soldiers. Only one type of artillery can be used for a fire mission at once, and each player can conduct only one fire mission at a time. Each mission will cost you money depending on the type of the mission and the amount of arty pieces used. You cannot control the artillery while the fire mission takes place. To use the artillery, select the fire team members by the F-keys. Then select "Communication" from the menu and choose "Fire mission". The available missions are different for each type of artillery. Pick the type of the mission from the menu which fits into your budget, and choose "Start". The fire control team is now allocated and the artillery pieces will be moved under the HQ's control. Wait a couple of seconds, and you should receive a menu with only one option of the selected fire mission; confirm this buy pressing '1'. The HQ will ask you to pick a target on the map and then the artillery will conduct the fire mission. Shells may fly for a long time so be patient. The artillery will join your team again after the fire mission finishes. If you die during an ongoing mission setup, you may loose your money but get no effect - make sure you are staying in a safe place. To use the auto supply truck function, buy a supply truck or command a soldier to drive one. Display the map, select the truck driver with the F-keys, and select "Supply town..." from its action menu (key '6'). Then click on the (friendly) target town's name on the map. Your command is echoed and the driver starts commuting between this town and the nearest service point (or the HQ), hopefully making money in the process. It will still announce "waiting" when it stops, but it will immediately move on. The driver will automatically change its resupply point if it becomes invalid (when it is destroyed or the MHQ is mobilized), and it stops at the supply point if the target town was taken. It *only* checks for these when the driver is idle (for example because it has just finished its previous move), so be careful to keep an eye on them if their route is threatened. You can change the supplied town anytime and the driver changes its current target immediately (or turns back for resupply if it does not have enough supplies to resupply it). To stop the autopilot function select the action again and do not click on the map for 10 seconds. Never forget buying supply trucks and protect them, as they are intended to be the most important source of your team's income. The new respawn rules are designed to encourage players 1. not to abuse camp spawning by multi-spawning on the same camp, 2. to capture more camps of a town to get safer spawning, 3. to try protecting captured camps from enemy troops, 4. when defending, to try recapturing camps. I hope the changes will make defending a town somewhat easier, and make the camps more important (so you need to think in real area defense). Using mobile respawn points for town capturing is strongly recommended, and as a defender, you may want to send out raiding parties to destroy or disable it by moving your team close. Hope you will enjoy the mission. Any comments and suggestions are welcome. I am quite sure for example that the costs should be refined. Proton http://www.armaholic.com/users.php?m=details&id=11836

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.

You seems to assume there is some automatic way to move processes from the CPU to the GPU. The truth is that they are quite different at the hardware level, and the potential speedup is entirely subject to the nature of the computation. We can just guess as we do not know what is the actual bottleneck in the engine. "AI" usually means pathfinding in current games, and definitely the CPU hit of AI is mostly pathfinding in A2, as there is no other complex process - like learning - takes place. Here is a study on accelerating A* with a GPU: http://portal.acm.org/citation.cfm?id=1413968 The authors claim a significant speedup, but as usual, the details are quite important here. For example they used small graphs with lots of agents, and even with that Which A2 has nothing close to. And what if A2 is using huge graphs with a small amount of agents? It is possible that it changes the nature of the computation in a way which makes the GPU worse. Probably the devs are just laughing on this as the pathfinding is already multi-threaded and is not a limiting factor. You can easily check with ProcessExplorer that the A2 server uses 4 CPU-consuming threads, only one of them being bottleneck.

language="English"; adapter=-1; 3D_Performance=1; Resolution_W=800; Resolution_H=600; Resolution_Bpp=32; Windowed=0; MinBandwidth=800000; MaxBandwidth=25000000; MaxMsgSend=256; MaxSizeGuaranteed=512; MaxSizeNonguaranteed=256; MinErrorToSend=0.003; MaxCustomFileSize=100000; Although I am testing the mission with just a single client at the moment.

I am also trying to improve the dedicated server's performance with a complex MP mission. Just right now the mission runs with 554 units and 124 vehicles, usually hovering around 10 FPS. A bit higher would be desirable. The question is what is the most important influencing factor. I can view the CPU usage of threads in ProcessExplorer. According to that, the server runs 12 threads, of which 4 is taking measurable CPU time. One is fully using a core (25% on my quad machine), and 3 others using half of a core together (7%, 4% and 1%). Probably the one consuming 25% is the bottleneck. Can a developer please enlighten us that what actually the threads do? Especially the 25% one. I would split the server into 4 main threads: one for general game logic, one for scripting, one for network and one for AI pathfinding. Is this guess true? The reason I am asking this is to decide how to try optimize performance. If the scripts actually take a separate thread and they are not executed in the 25% one, it makes no sense to reduce the amount of running scripts, as the advantage is going to be zero. The mission uses about the same number of scripts at start and has 40 FPS, so probably not the *amount* of scripts which matters. If the number of AI units is the most important factor, does it help if I do not move them when not necessary (to reduce pathfinding)?

You quite misunderstood parallel computing. CUDA or any of these APIs is not a silver bullet which boosts anything easily. The real question is that whether you have anything to boost at all, that is, what is the most time spent upon in the game and can this be implemented on a massively parallel architecture. Simulations usually has lots of parallel processes, but sometimes it is harder to exploit than it looks. One may consider e.g. putting path finding on the GPU, but does the increased communication cost worth it? In reality, GPU applications perform well only on quite specific problems (e.g. multiplying a large dense matrix with another), and sometimes even on strongly parallel problems the GPU is beaten by the CPU, especially when lots of program flow control is necessary (e.g. when the matrix is sparse). Considering the fact the the A2 server currently uses about 4 CPU-active threads which can easily run on about 2 cores, there is plenty of unused processing power for ArmA2 even on current CPUs. I am happy if the devs increase the parallelism of the engine just twice the amount, and really use 4 cores. Even 2x is hard and it is possible that cannot be done without re-writing significant portions of the entire game. I doubt that asking them to put the architecture on 400 threads is realistic when they could make only 4 at the moment.

I can confirm that the 71900 beta fixes it.

I know the opinion of Jaynus on supporting beta versions, and I totally understand and acknowledge the reasons behind it (it makes no sense to spend hours on each beta), but the latest OA beta solves important bugs which are really cruical. For example, http://dev-heaven.net/issues/11731 makes OA unusable with Chernarus. It is solved in the latest beta. Please consider adding support to the 71900 OA. (Isn't it possible to automate the patching process?)

I have the same problem here. Posted an entry on dev-heaven: http://dev-heaven.net/issues/11731 Vote for it.

You mean the retail 1.50?

In my case the problem was not there with the 71548 beta over 1.05, but exists in the 1.07 patch. Not tried the betas in-between and I cannot go back after installing 1.07. Reproduction is trivial in my case, as simply loading Utes in the editor and starting to run circles anywhere causes permanent stutter after completing a few rounds. Mouse input is also lagging. I cannot confirm that it is caused by the orange trees, as the framerate drop occurs when just looking out to the sea, although heavily forested areas with those trees definitely worsen the problem. Running xp 64-bit, 6GB ram, nvidia 295, i7 920.