Mirror was never implemented, the wiki was wrong, and the wiki has been fixed since then.
5/6 are fixed in 2.20

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

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.

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

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.

Reporting problems is good.
Creating new, duplicated tickets, even though you're fully aware that tickets for the issue already exist, is spam.
You insulting and throwing slurs at developers, now that gets you banned. Try to behave.

Also btw the old script join method that pressed buttons in the server browser no longer works

Profiling branch v18 and 2.20

If server has no config file (like player hosted server) many config dependent entries will be missing.

That is not a new bug. We're aware of it, and its unlikely to be fixed. You can play in fullscreen windowed instead.

We cannot just add RCON commands, RCON is done by BattlEye, and them adding commands and forwarding them to us is unlikely to happen at this point.

"The cloud file provider is not running."
Put that into google.

Your CPU is too old.
That issue is already fixed on profiling branch, you could switch to it to get a temporary fix until the next game update
https://community.bistudio.com/wiki/Arma_3:_Steam_Branches

Won't do

You are loading mods that require ACE and CBA mods, but you are not loading ACE or CBA mods.

Fixed in v17 tomorrow

Ah the good old optimizer.
Specifically wrote code that does it without popcnt, the optimizer detected what I was doing and replaced it with popcnt... Thank you

sorting by count is done.

in cases of

This crash was only present on profiling branch for a very short time.

Correct, we do not support cloud saves. And we do not plan to change that.
The default user profile name, is the username of the account playing the game. If the username stays the same, every new profile will have the same name.

This happens when joining a server, and the mission download fails.
So you are joining into a mission, while you don't even have the mission file.
This was already fixed, the server must've been running the pre-hotfix A3 version.

That error is directly forwarded from Steam.
Why steam says it, I don't know either.

So basically, it tells the HC to turn it on locally, and print into its own console.

Ihre Organisation hat diese App unter Verwendung von Device Guard blockiert.

And why is this a problem or a bug?

Illegal instruction. Your CPU seems to be quite old.
The bug has been fixed on the performance profiling branch https://community.bistudio.com/wiki/Arma_3:_Steam_Branches, it will be quite a while until the fix makes it to the main branch.

https://community.bistudio.com/wiki/setObjectScale
Scaling is not supported. Bugs like this will not be fixed.

I can see you were pirating our DLCs. If you want support with the game, you better not pirate it.

The game now uses Visual c++ redistributable 2022, not 2013 anymore.
You have 2022 installed, but only the x86 version, the game by default uses the x64 version, which seems like you have not installed.

What is a jamming tower?

What is a "MED pod"?
What are naval scooters?
Which base?

What tank are you talking about? What active protection? This sounds like some mod, which is not anything we would deal with.

What sectors?
What mission are you talking about?

What mission?
Are you talking about some server?
If it doesn't seem like a bug, why are you reporting it in a bug ticket then?

This is fixed. But it would still be broken if a player joins your server using the old Arma version who has disabled automatic updates.
So to fully protect against this, you need to set minBuild in your server.cfg to 152405

The code responsible for this, has been removed on performance/profiling branch, and will also be gone in 2.20. So the issue is already fixed, but won't make it to stable release until 2.20 next year

Fixed 2.20

deleteVehicle has received a local check and should be fixed.
If there is a repro, I need a repro to see whats happening

Oh I see the mistake.