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.

Validate your game files in Steam.

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.

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

Some mod is deleting a magazine inside a Reload eventhandler.
Bug was fixed 2 months ago, and is available on profiling branch (Which you can select in the steam beta branches settings)
It will also be fixed with next game update

Those are not the required files. I'd expect a Report zip file. Containing RPT and .mdmp crash files

https://feedback.bistudio.com/T175612

When shadows are to be drawn. The game needs to render objects that are not inside field of view, because objects outside of it, might throw shadows into the visible area.
So what it did on max shadow view distance, was render all objects in 3km radius, even if they are not visible to player. Because they might show shadows. That code forgot to check if shadows are even enabled.

2.18

Only happens when you really spam it. Opening the map while the fade-in from closing the map isn't done yet.

Note: message insert crash, memory corruption, Schaer

No repro, ping me if wrong.

No repro, closing. Ping me if you have some working repro

Initial issue was about mortar, if same is with tank then new ticket with repro

I know this bug. But I don't know why it happens. We've had reports for over 2 years and I cannot reproduce it. It doesn't happen to me.

Was caused by invalid start parameters. Something like -mod= that should have an argument, but doesn't.

First one
"Include file x\cba\addons\main\script_macros_common.hpp not found."
Missing mod.

ACE Mod implements rotating and moving and easier type selection.

Should be fixed next profiling branch, I have not tested it.

All that command does, is read
"vehicleTransportingDisabled" config entry or previously set via https://community.bistudio.com/wiki/enableVehicleCargo

It is a remoteExec for BIS_fnc_setTaskLocal.
The "mini"-dump doesn't contain enough information to see why this crashes.
It could be related to one bug that was already fixed on profiling branch. I'll assume that's the case

Also inconsistent, as scheduled scripts in general should have _thisScript. So you'd assume that if canSuspend, that you can access _thisScript too.
remoteExec and particle scripts and init.sqf and action scripts were also missing it.

First crash.
Bug in mod that adds dbo_base_Cargo
That vehicle has no model.

Checked the code, it is definitely loading it like the other events.
If you can give me a example config to try it I can try, but from what I can see it should be working fine.

Would you expect the same to happen when doing this

l = getUnitLoadout player;
player setUnitLoadout l;

When not setting it to nil, but just leaving it unchanged. Would you also expect it to keep the game backpack?

Especially your northern edge is totally messed up.
Some of the terrain heights up there are NaN.

"Out of memory (requested -788108 KB).\n footprint 50066368 KB.\n pages 131072 KB.\n"

Ah yes. The good old -788MB of memory. A true classic.

Ah the good old map icon crash.
Have seen it before, don't know what causes it and cannot reproduce it.
You could try switching to profiling branch, its possible that the fixes on there might affect this crash too.

Never seen that before. But google results are pretty clear its some thing that causes alot of issues.
https://www.google.com/search?q=%22EZFRD64%22

A UI element was deleted while you were mousing over it.
This crash was already fixed a couple months ago and the fix is available on profiling branch.

Objects, shield other objects behind them.
The game checks, how visible the CenterOfMass of the building is, when viewing from the position of the explosion.

Client1:

addMissionEventHandler ["MarkerCreated", { 
    params ["_marker", "_channel", "_owner", "_local"]; 
    systemChat str markerDir _marker;
}];

Disable one-drive.

[B Alpha 1-1,B Alpha 1-1:2,B Alpha 1-1:1 (dedmen),B Alpha 1-1:1 (dedmen),true]

Behaves as expected. Classes inherit from it, so if you hide their parent, subclasses inherit that scope too.
That is just how configs work.

Need RPT log file.
https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

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

Please follow: https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

Ref T180426

I suspect this is solved, by fixes for other bugs that caused memory corruption

1st Method

I think this should be fixed in 1.26 too.
I actually never saw this issue during any of my testing so its a bit confusing.

Should be fixed on current dev-branch, if not then next. Its fixed internally

toJSON/fromJSON are in 2.18

We do not want to spam empty/unused namespace files on every game shutdown. That's why it only saves if you manually save.
Though. It would expect that after the first manual save, we consider it "enabled" and also save on shutdown. Because the file is already there anyways, so we wouldn't spam unused files in that case.
Maybe we can just detect and only save on exit, if the file is already there.

I fixed it now.
You can either remoteExec it, or change some other state of the vehicle to force it to update.

The answer is simple.
There is no door state synchronization :D
It is sent when other things are synchronized, but for the door state itself, there is no check if it needs sync. So changing it doesn't trigger a sync

Please open your game installation folder. In steam right click your game, then "manage" I think its called and "Browse local files".
Upload the DayZLauncher.exe.config file here so we can see what's wrong. Just Drag&Drop it into the textbox.
Then delete that file and verify your game files in Steam.

Fixed a couple years ago

18:43:31 Error 0 elements provided, 1 expected
18:43:31 File a3\ui_f\scripts\gui\rscdisplaydebriefing.sqf..., line 45

Fixed 1.26

In the end it wasn't json at all.
It was writing to files.
Here is repro code

This is such a pain to reproduce.
https://steamcommunity.com/sharedfiles/filedetails/?id=2905487932
I tried it with this mod.

The broken pattern matching (when pattern is anything other than just "/*") and the wrong read-only flag should be fixed in 1.26
The DIRECTORIES flag not working is separate, that also does not work on windows. We're handling that in a separate ticket to be solved some other time.

At the same time, it sets an attribute with index 4, which, as I understand it, is outside the scope of enum FileAttr where the last index is 3 with type INVALID

Furthermore, workbench publishing should do more for fragmenting the mod internally