Every time I play ARMA, I have reason to curse the action menu.

The action menu is an incredibly powerful tool. So powerful that it has been abused by many mission/mod makers that have come to call the addAction function. This isn't really their fault, they have only less desirable alternatives to provide the player with ways to trigger these actions. BIS themselves have used it as a dumping ground for any player action that doesn't quite need its own key configuration.

Placing of explosives and interacting with vehicles/objects have the worst default implementations. 'Place {explosive}' actions have very high priority ratings, which means that they are often always at the top of the list. And if you happen to be a demo expert, you have an action for each type of explosive listed. Then, after you have placed an explosive that can be remotely detonated, the 'touch off' action appears and has an even higher priority. That's great when triggering an ambush, not so great when you accidentally place a satchel in an area that you will be spending the unforeseeable future in close proximity to.

As for interacting with objects, a lot of the problems come from plain just not using the addAction function properly. You can make action menu items only appear for a player if certain conditions are met. You can reference the player or the object carrying the action, or any other value derived from those references, as part of the conditional statement. You can make it, from positional data alone, determine if the player is looking at the correct vehicle door for the action to appear.

Even if correctly used, the action menu cannot bear the multitude of actions being thrust upon it. BIS needs to add more actions menus (radial or otherwise) and they need to make contextual sense,

i.e. A menu for each (and a separate key for each) of:
-Interacting with objects/vehicles/people (open/close, board, greet)
-Interacting with kit - non-weapon (healing myself, healing others, binoculars)
-Interacting with my kit - weapon (toggle silencer, place/remove/trigger explosive)

That alone would remove the ambiguity of the action menu and cause far less frustration.

I don't think it's the roads per se, but rather the number of objects in the player's field of view. This includes objects hidden behind other objects, but not objects hidden well behind terrain. This is why the hilly areas seem to run better. The flat plains to the East seem more troublesome. I'm not sure if it's the number of total objects or the number of unique objects.

When there are too many objects, the program can no longer store them all in the memory it has access to. The program now has to start juggling objects in and out of memory. This is when the heavy stuttering occurs. The last update increased the default amount of Virtual RAM that the program has access to. This just makes the problem less likely to occur.

This also wont necessarily solve the stuttering when you travel between new areas, or teleport, or drop into a town, or even turn your view in some places.

Markedly improved performance for me. I have roads again!

Increasing Virtual Memory limits is just papering over the cracks though. Hopefully we'll see some optimization that prevents this happening at all.

If you are still having the issue, check that you actually have sizable pagefiles configured on your computer. If possible, make one on each HDD you have. This solved similar issues I had with Arma 2.

I am still getting framerate dropping to below 5 FPS in some locations on the map while I'm on the ground.

The worst areas seem to be on the eastern side of the map. Roads are everywhere on the map, so it could be the road objects in the map_altis_data.pbo that cause this issue. There may also be objects stored in other files that can cause this issue too.

Those geodesic domes near Altis International are a prime spot for it happening. I approached on foot and the framerate bombed out. So I lowered the draw distances until the framerate was 30. I then continued approaching until it happened again. This time I had to drop the draw distance to minimum. I was able to get into the base but as I approached the southeastern side it happened again. If I turned away, the framerate would recover.

Something within 500m (or a little further) of that area in the East to South arc is causing this too.

"Roads? Where we're going, we don't need roads"

I only tried it out from aircraft, so I didn't notice the missing roads. I hope they'll be able to issue a replacement file soon.

IMPORTANT!

I have managed to get Altis running at framerates that I expect my computer should achieve.

Suspecting that the fault lies within the actual Altis data itself, I started renaming the Altis map data files. Only one of these files is causing the problem:

map_altis_data.pbo

Renaming this file to map_altis_data.pbox will let you run Altis without the super low FPS and the Splendid Config Viewer becomes responsive too. I believe that this file contains just the map images used in the editor, map screen and the map preview thumbnail. You will get an error when Arma 3 can't find them, but you can dismiss them with no problems.

All the LOD issues have gone too, they must have been caused by the game engine just not getting around to running certain functions.

I think I've figured out what is causing the low framerates, but not the root cause of the problem.

I flew an MH-9 at 10,000 ft on a heading of 270 on an intercept with the south-eastern tip of Altis. The view distance was around 4000m, so only small area of the sea below me was within the fogging distance.

The framerate out at sea was poor, I didn't record it but 15-20 is a good guess (I'd get 60+ on Stratis). As the land approached the view distance, the framerate began to deteriorate. When the land came into view, I noticed something curious. Each frame that rendered, the land took a different shape. The LOD was constantly changing! And with each LOD change, the game is loading in the textures and geometry for that LOD level.

In support of my LOD theory, there is also this:

1 frame after turning head - http://steamcommunity.com/sharedfiles/filedetails/?id=173192965
Each frame thereafter - http://steamcommunity.com/sharedfiles/filedetails/?id=173192988

When I'm facing forward, the correct LOD model is being used for the co-pilot, but when I turn to look at him it drops to a very low resolution mesh. Also, the external view of the helo has the pilots missing.

I think that the values that are used for determining the LOD level used for rendering objects are being corrupted. This is resulting in a high frequency of LOD changes across a high number of objects and in turn an incredibly high demand for loading assets. Frame rendering is delayed until the assets are loaded or a timeout on asset retrieval occurs.

The trend of this occurring on 32bit OS only seems to be building. It's possible that on 32 bit operating systems, some very large numbers are being subjected to bit-wise truncation or some 32-bit values are being overflowed.

Not sure if this is related, but the Splendid Config Viewer also runs slowly, the main editing screen is fine though.

Editing Stratis mission, the Splendid Config Viewer is fine.

I have this issue too. Stratis runs fine, Altis 0 to 1 FPS.

CPU: Intel Core2Quad Q9550
GPU: Radeon HD 6870 1GB
RAM: 4GB
OS: Vista 32bit

Between each stutter, more and more textures load into the world. However, when all textures appear to have loaded in, the poor performance continues. Arma3.exe registers 25% CPU usage, the GPU is idling.

I have tried:

• Verifying the downloaded files
• Defragging the files (didn't have too, zero fragmentation)
• Making sure there are no Addons being loaded
• -nologs
• -cpucount=4
• -exthreads=7
• Starting the mission at night
• Lowering settings
• Checking display drivers are up to date

Every time I play ARMA, I have reason to curse the action menu.

The action menu is an incredibly powerful tool. So powerful that it has been abused by many mission/mod makers that have come to call the addAction function. This isn't really their fault, they have only less desirable alternatives to provide the player with ways to trigger these actions. BIS themselves have used it as a dumping ground for any player action that doesn't quite need its own key configuration.

Placing of explosives and interacting with vehicles/objects have the worst default implementations. 'Place {explosive}' actions have very high priority ratings, which means that they are often always at the top of the list. And if you happen to be a demo expert, you have an action for each type of explosive listed. Then, after you have placed an explosive that can be remotely detonated, the 'touch off' action appears and has an even higher priority. That's great when triggering an ambush, not so great when you accidentally place a satchel in an area that you will be spending the unforeseeable future in close proximity to.

As for interacting with objects, a lot of the problems come from plain just not using the addAction function properly. You can make action menu items only appear for a player if certain conditions are met. You can reference the player or the object carrying the action, or any other value derived from those references, as part of the conditional statement. You can make it, from positional data alone, determine if the player is looking at the correct vehicle door for the action to appear.

Even if correctly used, the action menu cannot bear the multitude of actions being thrust upon it. BIS needs to add more actions menus (radial or otherwise) and they need to make contextual sense,

i.e. A menu for each (and a separate key for each) of:
-Interacting with objects/vehicles/people (open/close, board, greet)
-Interacting with kit - non-weapon (healing myself, healing others, binoculars)
-Interacting with my kit - weapon (toggle silencer, place/remove/trigger explosive)

That alone would remove the ambiguity of the action menu and cause far less frustration.

This is the same as Issue #0002015 http://feedback.arma3.com/view.php?id=2015