The crash happened inside Microsofts XAudio code. Nothing we can do about that. We cannot fix Microsoft's errors.

Well I don't know either...
You have submitted 7 crashes.
Each of these is something different, and they all look random and seem to make no sense, and I have never seen any of them before.

The crashing thing seems to be some joystick that you have attached, "vJoy Device"
The crash is actually inside a windows library, nothing we can do about that. Probably just remove your joystick or gamepad.
In the rpt log I also see there are some issues with your joystick

Relates to T66212

Ah I didnt think to try out for AI, thank you very much

It was ignored for player used weapons, not for AI.

2.20 also adds config entry for map controls
useRealViewport = 1 to enable it by default, then you don't need to use script command

Fixed in https://feedback.bistudio.com/T189016
due to backwards compatibility you need to run a command, or add a config entry to enable it.

Fixed in https://feedback.bistudio.com/T189016
due to backwards compatibility you need to run a command, or add a config entry to enable it.

Fixed in https://feedback.bistudio.com/T189016
due to backwards compatibility you need to run a command, or add a config entry to enable it.

Okey.
Due to backwards compatibility, we need to mess around a bit.

Per @dedmen request here is a PBO where once this issue works the suppressor (on MX rifle) should reduce the recoil o 25% of its original value when not prone, or if prone to 5%. Other fields like the hit coef dont appear to work, so if it gets fixed then with this suppressor they should do 10x more damage (Picked an extreme value to test with). I imagine typicalSpeed value also doesnt work, unsure how to test on my end.

It is easier to see if you also change the position of the background like this

with localNamespace do  
{  
 private _display = findDisplay 46 createDisplay "RscDisplayEmpty";  
 private _ctrlGroup = _display ctrlCreate ["RscControlsGroup", -1];  
 private _ctrlText = _display ctrlCreate ["RscText", -1, _ctrlGroup];  
 _ctrltext ctrlSetPosition [0.2, 0.2, 1, 1];  
 _ctrlText ctrlSetBackgroundColor [1, 0, 0, 0.5];  
 _ctrlText ctrlCommit 0;  
 private _ctrlMap = _display ctrlCreate ["RscMapControl", -1, _ctrlGroup];  
 _ctrlMap ctrlMapSetPosition [0, 0, 0.5, 0.5]; // effect is immediate  
 _ctrlMap ctrlMapAnimAdd [0, ctrlMapScale _ctrlMap, player];  
 ctrlMapAnimCommit _ctrlMap;  
 _ctrlGroup ctrlSetPosition [0.2, 0.2, 1, 1];  
 _ctrlGroup ctrlCommit 0.3; // non instant transition  
 _ctrlMap ctrlMapSetPosition []; // instant sync to new _ctrlGroup position  
};

You can see that when you click above the red area, the map control is moved. But clicking outside the map area, it is not.
Also the map ignores the ctrlSetPosition, it should be positioned at 0.2/0.2 from the top left. But it is rendered at 0/0

I believe there is none unless we use EachFrame/Draw3D and call it a day. Smooth transition wouldn't be a concern to consider IMO, from what I can see firing an EH upon cameraView has changed is good enough to detect Visual/Pilot LOD change etc.
However and just thouht of, "BeforeCameraViewChanged" might be an addition to suppress the viewmode update etc I guess. Not really sure how it would have a usecase, so just sayin'.

In T188318#2754101, @dedmen wrote:

Won't fix. I have no idea where to look.

2.20

Is there currently some non-eventhandler script way to detect this?

Won't fix. I have no idea where to look.

Very nice find, thank you.

Video of the abuse of this problem in multiplayer embedded:

Me ha pedido Dedmen que agregue un pbo en cual se pueda replicar el problema, ademas de eso os envio una captura del error que sale simplemente seleccionando el modulo de curva rica, el de la linea de tiempo o el de el punto de clave de llave rica el que tiene un simbolo de llave.

I honestly believe, that it's not really the issue, that civilians or their vehicles getting damaged. It's the Mission Eventhandler "BuildingChanged". Every damage on "buildings" get tracked (I guess this was intended anyway, also for fences and other objects) but the problem is, that AI drives over everything too. Means fences, tiny objects and other things. Limit the check only for the player would minimize the risk for the Mission getting failed.

This person visibly has a problem, fixating and harassing on Arma/BattlEye. Banned on request, please resume your usual activities

Can I suggest, this command should be able to take a position as a parameter

is it hard to implement those variables for vest, heagear (/ weapons)?

This problem also affects the use of BIS_fnc_exportEditorPreviews, the resulting images are very lightened. As we can see, the BI author who makes Editor Previews for vanilla assets has no such problems. Can he please share a secret so that we don't have to keep using batch proces in photoshop to correct images?

Title correction:
The problem is that inAreaArrayIndexes throws an error on profiling branch if you pass it an array of marker strings as the left-hand input. This works correctly on stable 2.18.

Confirmed as fixed closing.

This functionality is required for a lot of custom game modes focused more around dynamic player groups than predefined scenario factions. Mods like WasteLand, Rogue Extract, Everon Life etc could all benefit from the factions system being more dynamic and factions being creatable at runtime via scripts, most of these kind of mods just have some janky work-around solution like repurposing squads/groups as player factions.
Anyone saying there is no need for this is simply thinking too small or only speaking for their own needs.

tested in 2.18 - seems fixed.