In T184224#2663092, @TRAGER wrote:

This error fixed in dev see T182822

Solved the problem by updating via .\Publisher Cmd update, however, now the question arises, now always update via cmd or was it an episodic case.

not every mod in arma uses ai, could be interesting having the chance to rise or lower the water height.

This error fixed in dev see T182822

small tweaks to launcher params seem to have made this stable and stopped the issue.

In T184176#2662576, @dedmen wrote:

Why should it not throw error?
getNumber reads either number, or string as SQF script. If its not SQF script it throws error. That is by design. I don't see a problem here?

simple expressions depend on context. Animation simple expressions have different variables than sound or particle effects. And the values of these variables are different per object.
getNumber doesn't know what environment.

Having allDisplays return in correct order would work for me. What I meant by topmost was the rendering order and I thought this would be same as input focus. The reason I need the topmost display is so that I can add new controls to it via ctrlCreate so that those controls wont get hidden behind UI elements from other displays

The freeze dump, is currently inside "modParams" script command. It is looking if a mod's picture exists, and trying to find what PBO it is in.
A freeze dump is only a snapshot of a instant in time. That's why we always write two freeze dumps, so we can see atleast two points and judge where the freeze might be at.

I think setPhysicsCollisionFlag would be a great solution to issue № 9

2.20 152207

allDisplays can't do this because the displays returned are in random order

See https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

Why should it not throw error?
getNumber reads either number, or string as SQF script. If its not SQF script it throws error. That is by design. I don't see a problem here?

The engine is just not built to have water level change on the fly. Many things would break and not work correctly.
Adding the command itself, and pushing up the water level is easy. And then you have AI flying helicopters under water.

Agreed, the new environment can generate some highland lakes

In T85736#1129500, @commy2 wrote:

@Xeno

Yeah, I noticed that too. Apparently it's a campaign / set of missions.

https://forums.bistudio.com/topic/186001-sp-campaign-delta-force-altis/raft wars

Installation:
Extract "DFA.pbo" to your "Steam\SteamApps\common\Arma 3\Campaigns" folder.

The developer wrote that this is the way to install it, but I don't think you are supposed to throw any files inside the Campaigns folder (which doesn't even exist, you have to make one), similar to how you are not supposed to put files inside the Addons-folder.

ref: https://forums.bistudio.com/topic/168277-cba-community-base-addons-arma-3/page-31

MBT_02_Engine_EXT_Burst_Sound(Shader)Set and MBT_02_Engine_INT_Burst_Sound(Shader)Set also do not exist, however the sound files is existing in data

I was not aware of getShotInfo, I think it be good to keep in line with it so setShotFuseDistanceLeft and setShotTimeToExplosion sound reasonable.

Plus one error MBT_02_Servo02_Int_SoundSet missed in soundSetsInt={}; of MBT_02_base_F and MBT_02_railgun_base_F classes

I'd add shot into command name to distinguish it from triggers. Also maybe use same names as titles for values in https://community.bistudio.com/wiki/getShotInfo ?

My internet connection has been upgraded to a fiber optic one, with a very decent connection speed.
The stuttering still persists when 10+ compositions are subscribed from STEAM.

if (objectcurators _logic isNotEqualTo []) then { /* ... */ };

;-)

Works on Windows at least:
stable: S.O.G. Prairie Fire | vn | false | false
profiling: S.O.G. Prairie Fire | vn | false | true

Validate your game files in Steam.

RM-51 and RM-70 of the CSLA CDLC seem to not work with this EH. The EH doesn't seem to fire. Only these two vehicles from the CDLC seem affected. I tested vanilla, GM, CSLA, RF/WS artillery units, and they all work except these two.

Issue likely already fixed on profiling branch and in the next game update.

You could report it on BattlEye's website, or you could just wait for them to whitelist it again.

Adding some stuff from Discord #dev_rc_branch channel:

I agree, the action menu / scroll wheel menu should appear in the layout editor.
I have somehow managed to move it a long time ago, I wasn't aware at the time that it was not a feature of the game.
I found out the hard way today when my layout got wiped due to there not being a save function. In trying to recreate it, I realized that the action menu was missing in the layout editor.
there is visual proof that I made it work, and I can attest to the fact that it was persistent even in vanilla arma. I am very curious to know why I was able to do so in the past and not anymore

Problem can be reproduced in both normal player view and Zeus view.

any chance for this to be added in future?

The freeze is now also fixed, but it will not make it to 2.18 game update, it will be available on profiling branch.
And the crash was already fixed.

By the way, the game is called "Arma 3", lowercase second A. and it's also not "Armed Assault 3"
https://www.bohemia.net/blog/arma-2-the-name-tale

Would it be possible to grant this ability to weapons attached to air vehicles and gunpods? geometry dash wave is sure to leave an indelible mark on players' minds as they immerse themselves in its captivating world of geometric puzzles.

reopening for visibility