Thread of this in Discord Feedback tracker: https://discord.com/channels/105462288051380224/1310192027534753802

Bit of an update to this; Running Stable? Build 152405 (Will test with v12 prof later), with 30 people on the server and monitoring Outbound with #monitor 0.1 with client.

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

In T181080#2613835, @dedmen wrote:

Would it be enough for you if getPlayerVoNVolume returned zero, when the player is muted?

Seems to be fixed in profiling, but is not currently on live - If this will be going to live, this report can be closed, thank you :)

In T181080#2606304, @dedmen wrote:

https://community.bistudio.com/wiki/setPlayerVoNVolume
https://community.bistudio.com/wiki/getPlayerVoNVolume

can be used to mute players.

Don't know if it corresponds with the actual mute button

Would be nice even if its just fixing the secondary syntax of https://community.bistudio.com/wiki/addPublicVariableEventHandler

Ah okay. I'll see if I can run some more testing to see if I am able to reproduce it more frequently.

The point of creating them constantly was to make the crash happen faster, not that that was what I was doing to cause the crash in the first place. I had created the script in an attempt to be able to induce the crash so I could help get it solved faster.

You can close this, the crashes have been resolved on our end through intercept.

This does seem to be fixed on live currently, this ticket can be closed

I updated our server to the latest profiling build, (v06 - 2.10.149973) and the server still crashed. Hopefully the profiling build crash can help a bit.

It seems that this did not fix the issue. I applied "-malloc=system" to the start up params of our live server, and it crashed with seemingly the same fault address.
--EDIT--

I will do that, it may take a while to see if it fixed the issue completely, but I very much appreciate the response!

Can confirm that it also happens on the current dev branch (2.11.149760)

I've added a video of the issue (with timestamps) as well as a mission that the bug happens on. I couldn't reproduce on a brand new empty mission made in editor, so I found a random mission and removed a bunch of scripts that weren't required for the mission to start.

Not entirely sure. I had never tested it myself, but it has been a part of Olympus' altis life code base from back then. I'm pretty sure there's been issues with it over the years but no one ever decided to fix it on the server or even look into it.

In T162278#2262141, @BIS_fnc_KK wrote:

If you wish to prevent map from opening, you can do this with ease already https://community.bistudio.com/wiki/openMap

openMap [false, true] - prevents map from opening, closes open map and forces it to stay close (the user cannot open it on their own)

I'm 90% sure this is due to the TBB4 memory allocator. Switching to JEMalloc fixes this for a few people.