There have been some indirect fixes that could have affected this bug, please check if it still is happening after Revision: 152411

Install the latest .NET Framework.

As usecase was requested:

With EF CDLC release

These config entries are only read on Transport vehicles.
On people, they do have the entry in engine, but its always initialized to false, and never read from config.

Please fix this if possible because I can’t drive cars I fix.

Okay, thx for the infos. For now i think dedmen has to much to do with his current work. Maybe I'll bring it up nicely next year.

How does createVehicle work?

I find it really difficult to create a discussion here. For me, a feedback tracker is about information or possibilities to improve something and to discuss this with officials or to give information for improvements.
Maybe it is better to discuss something like this in the arma discord, here I am interested in official statements.

Speaking as third party observer with a little bit of developer experience and some knowledge of how games/software works, there is little point in changing the current system of createVehicle with regards to initialization.
If you need certain assets to be loaded consistently fast in run-time conditions, then you should prespawn those as "dummy objects" and immediately delete them once you initially enter run-time conditions.
It is justified (and sane) as the developer of the game to leave the existing system as it is, because your case is easily a much more niche use-case than the cases most people use Arma for.

any chance to add this?

How does createVehicle work?

+1. Still an issue. Above fix does not always work.

You may want to ask on the arma discord as reminder if your update was missed

most likely nothing can be done here - creating a new entity is complex (loading the model and texture data, allocating memory (RAM+VRAM), initializing the simulation, loading sounds, etc)

Copy, thx

i was able to crash the game with the modparams command by inserting a really log string as the modclass parameter...i wonder if the modlist i was using had an obfuscated modclass that could have caused a buffer overflow or something in an unusual way?

Switch to the stable branch until a fix is released on the performance branch.

Fixed in profiling branch v9, and next dev branch.

Any new info on this? Was the minidump useful?

@BIS_fnc_KK The issue happens also in vanilla, not mods. After the briefing at the start of the mission, you get into the offroad and drive down the road. Suddenly a big lag happens and the error is printed to the rpt.

Basically a can of worms but I think it can be improved

Tested again on both stable and v8 profiling, it doesn't work for me on either.

I will take another look

Cannot reproduce.
Running 2.18 (post hotfix) 2.18.152302
Both working and "broken" buttons work for me.

This can probably be fixed easily by updating BIS_fnc_setUnitInsignia to use the new string-based selection targeting for setObjectTextureGlobal, instead of searching for and then hard-saving the current uniform's insignia index.

Best reproduction example is:

1. spawn class B_Plane_Fighter_01_F in Eden any world in fly with AI pilot
2. start mission and move your camera avay jet from a ~2km
3. then move closer to jet and listen that no any sound played (even super close to jet)
4. wait ~20 sec and sound will appear instantly

Indeed, the siren on police boats has a place. How nice that it is very easy to implement, we need next actions:

1. in CfgVehicles → Boat_Civil_01_base_F → Sounds add this code see Pastebin
2. in CfgVehicles → Boat_Civil_01_base_F → UserActions add this code see Pastebin

Look at the result - https://youtu.be/Z3Sr42D0J1g, same as @madpat3 requested via video

In T186146#2698129, @BIS_fnc_KK wrote:

Does this happen in 2.18 vanilla?

Does this happen in 2.18 vanilla?

2.18 prof v6 and later

Retested with current profiling branch version: 2.18.152307

Retested with current profiling branch version: 2.18.152307

I don't quite understand why the memory LOD is so far off the visual LOD, but maybe as a workaround you could offer another parameter to set what LOD to use.
It would make more sense to use a visual LOD by default in my opinion, attachTo is a visual thing, but I can understand that you probably don't want to break existing code.

setUnitLoadout will now fail if unit is switching weapon
isSwitchingWeapon command added

I cannot reproduce this bug. Does the repro in description run with a mod?

This happens with the AAV9 from Expeditionary Forces CDLC as well, seems like the AI is unable to use tracked vehicles in water, they can only go forward.

Confirmed this still happens as of 2.18 stable and profiling

This has been fixed in the 2.18 update, it can be closed

This has been resolved as of the latest 2.18 stable, it can be closed

I don't think so, I would expect {mapGridPosition [8500,4700]} to return "085047", not "084046", because 8500m mod 100m = 0m and 8500m / 100m = 85, thus {mapGridPosition [8500,4700]} should return "085047".

Is the grid position not matching map grid square?

utils 4 produces this error as well @BIS_fnc_KK

Bump

It would be nice to get this fixed cause I do see quite a few mods using some of the fields that dont work thinking they do.