harakka

Client FPS != server FPS.

Chiming in with our community's experience. We have a Xeon E3 @ 3.4GHz on 100mbit connection. We play primarily coop missions taking from 30 to 90 minutes, no Domi or any other long running public server mission style stuff. All missions are custom made (using the F2/F3 framework) and are usually fairly simple, with minimal scripting, and based on monitoring with ASM there's no runaway object generation or anything similar going on. We do not run any mods aside from minor clientside ones such as STHud. As background, with Arma 2 we've been able to play 80 player coops with ~300 AI with SFPS tanking to 5-10SFPS. Usually we have playercounts of around 30-50 players with 3-4 times the AI, and A2 can handle these numbers with 20-35 SFPS. We could accept losing some performance but being able to sustain playercounts up to 60 is almost a necessity for us, and we've had no problems with that on A2. With Arma 3 we run into trouble with coop missions as playercount exceeds 30 on Altis, we've not experimented much on Stratis. With 20-30 players we see 40-25 SFPS. With 30-40 players and 70-150 editor placed AI, SFPS is around drops to around 10-5. With 40 players we go below 5 into the realm of completely unplayable. No amount of tweaking server settings, such as MaxMsgSend and min and max bandwidth, will alleviate the issues, or in fact have much discernible impact at all. Pure TvT missions run much better, 35 players still can get 50SFPS on a good day, and we had one instance of 50 players and 5SFPS. Unfortunately not being able to sustain anywhere near our A2 playercounts in A3 is starting to make A3 seem like not an option. For us the issue isn't with missions or scripting but with a combination of 30+ playercounts and seemingly any 50+ number of AI. As a strange sidenote, it seems dead players in spectator mode have much, much smaller impact on server performance than live ones. Will happily post example missions if so desired, but as far as we can tell it really isn't up to specific missions, but in general coops with decent playercounts.

The stance system in Arma 3 is pretty cool, but it's sometimes hard to tell which stance you are in, especially from first person view. FA_stance to the rescue! Your current stance (stand, crouch, prone) is displayed as a human silhouette on the HUD, and an small arrow next to the silhouette shows the current stance modifier (high, low, sidestep). When player is in one of the three basic stances, the HUD element fades out, and it's hidden completely when you're in a vehicle or in a cutscene. The HUD element can be positioned in any corner of the screen by editing the included userconfig file. Latest version: 1.2, released on 17th April 2013. New features: support for the new left and right prone stances, V2 signatures. Here's the download link for FA_stance. You will also need the Arma 3 version of CBA. Please read the installing instructions in the included readme.txt file, especially if you're not familiar with installing mods that have an userconfig included! The authors, Head and myself, thank Folk ARPS for support and testing, and JamesF1 for the UI hiding and main loop code. Here's a video of showing the addon in action: ksDqtnQhfbI Here's a cropped screenshot of what the current version looks like in the top right position, next to the ammo/weapon indicator. Version history 1.2: The new prone left and right stances are now supported. V2 keys added. 1.1: Darkened silhouette outlines are now used instead of a background image to improve visibility. Fading can be customized via userconfig. 1.0: Improved modification arrow and background graphics for better visibility, display now fades in main stances and hides when player is in vehicle or in a cutscene, debug or some other view. Stance display's position can be customized by editing userconfig\fa\stance_config.hpp. 0.9: Initial release. FAQ Q: Why don't you have a separate icon for each stance? A: It is difficult to make small graphics for each of the stances and their modifications that can still be distinguished with a quick glance. We found the arrow system to be more informative and recognizable.

A new version is out, link and info updated in the 1st post. Support added for the new left and right prone stances, and V2 key and signatures.

There are no slots, it's all based on weight as far as I can tell.

What Head meant is of course version 1.1, which is in fact out now! Details in the first post.

Version 1.0 is now out, first post updated with new info and download link. The addon now includes an userconfig file for customizing the stance indicator's position on the screen, and some graphics updates for better visibility. Please read the included readme.txt for install instructions, especially if you're not familiar with userconfigs!

Nice work Kerc Kasha, sent you a PM about this.

Thanks! Your solution worked, even though Kegetys' script itself needs a lot of adaptation. If you succeed in updating the script please post a followup here or PM me, we would be very interested in seeing it!

We're trying to get the venerable Kegetys's spectator script to work. However we are hitting a hitch even before executing the actual script. Good old spawning as a seagull works, but attempting anything else, like overriding onPlayerRespawnAsSeagull.sqs and onKilled event handlers, seem to both result in a black screen that we can't dispel by any means. Any ideas on where the black screen is executed from and how to get around it are welcome.

As of yesterday afternoon, the VON issue has magically fixed itself. Would still love to know what was behind it though.

First of all, if this post would better be placed in Multiplayer or Servers & Administration, I apologize profusely, this is the only thread I could find on the subject. Our group may have run into the described issue , and it still persists as I'm writing this. Yesterday evening (3rd March), somewhere around 16:00GMT we got a report that VON wasn't working at all on our server, which is running on stable Windows OA 1.62 (not beta). This was troubling because we use a combo of VON and TS3 for our comms, and caused some feverish troubleshooting but nothing we tried had any effect. Server box was rebooted, firewall disabled completely, etc. We also had done absolutely no server config changes whatsoever in the prior week. The issue is also present on two other stable Windows OA servers we have running. We also tested with the last beta server version before VON port change (95417), but it didn't help. A few people even hopped on a random public server running 1.62 stable, and VON wasn't working there either. A few hours later in a session of about 60 people on our server, all of whom were (hopefully) using the OA 1.62 stable client, the issue persisted. There was apparently one person who could talk and was audible to everyone else for some reason. Weirder still, we run an A2Free server as well and VON works absolutely fine there. We have a tentative report VON was working on our server on Saturday evening (2nd March), and we know for certain it worked on Tue (26th Feb). My only two ideas are that this could be something either Gamespy, or Battleye related. Any info and ideas would be greatly appreciated.

I'm curious, can anyone elaborate on what changed in betas > 100697 that broke the previous CBA versions?

Possible bug: I was testing 1.5 by playing some Flashpoint Zargabad, and managed to get an error popup with the message "Sound snip2_tail3 not found". I didn't notice any sniper weapons on people I killed in the vicinity, though there was a Lee-Enfield. Otherwise, amazing job on the audio! I loved the previous release already and this is even better, the interior echoes and gun mechanism sounds are great. The latter work particularly well with silenced weapons.

This post by Maruk explains what the various PP levels do.

Once you've bought the game, you can use oktNoBlur to get rid of motion blur without having to disable postprocessing.

Moving player units and creating markers reliably via scripting during the briefing phase is a huge pain. I spent hours trying to get it to work in a completely random-generated adversarial mission I made (called Cratesistance, which BlackMamba may be familiar with) and eventually ended up with just doing it all post-briefing. For example it seemed like public variables don't get sent during briefing at all, some players saw the markers and some didn't, some players got moved and some didn't. Waiting for the players to initialize didn't help, or at least I didn't find any reliable method for doing it. One technique that I recall being promising though, was running the scripts from the init of an editor-placed unit. This is probably because unit inits are run on the server before the briefing phase starts.

We just tried to play the addon version on dedicated server, had no problems with up to 7 people but with 9-10 the mission froze every time after finishing the planning phase, we waited for ten minutes or so on the loading screen without any progress.

@brzozowsky yep, looks like the same thing.

Every piece of documentation I've ever seen indicates that localVRAM and nonlocalVRAM have no effect, they're decided and written to by the engine when starting the game. Setting TexQuality and TexMemory to 3 makes the 'High' and 'Very high' options available but 'Default' is still missing. Playing with both Texture Detail and Video Memory on Very High via editing the profile file causes constant HUD and texture LOD flickering, I can provide a video if needed. I assume this has something to with the fact that I have a 512MB card though... :)

Since I started using the -maxVRAM=512 parameter, I've still seen the HUD flicker occasionally. It's very rare though and I can't reproduce it. I haven't noticed any LOD flickering at all any more. I still don't have any other options available in Texture Detail and Video Memory than 'Low' and 'Normal', I don't know if that's intended?

We played 053B+addons version with about six ARPS people today for a couple of hours. This is one of the best small playercount missions I've ever played, thanks for making it work in multiplayer! All the effort and polish put into it really shows. The only bug we encountered was that sometimes when exiting the insertion vehicle some players' weapons would reset back to what I assume were class defaults. One small request: any chance of an option in MP that would let you start playing from say, 3rd mission onwards, to get straight into the more challenging missions? We didn't play on dedicated this time but will definitely do so in the future. Will report any findings and possible issues. Again, huge thanks!

This seems to have fixed my issue, so apology totally accepted. Thank you Dwarden!

Not yet, getting to my PC case and taking stuff out is on the borderline of what I'm willing to do to de-bug a game, especially since I wouldn't keep the lower RAM configuration in daily use anyway to fix the situation, as I do other stuff too on this machine than just play ARMA2.

Tested those settings with both 1.60 and build 90242 to no effect.