Late to the party, but it is really obvious that the selection doesn't exist when the return value is simply [0,0,0]. As Leopard20 said, it is really hard to justify this log spam in my opinion.

a variable counterpart for "getOrDefaultCall" would be fantastic

Sorry for the late answer. It works now fine, thanks.

ScriptError inside a config file indeed.
It happened so early in the game start that the world didn't exist yet. And eventhandlers are stored in the world, and we added a ScriptError eventhandler

from my experience, the mods that this has occurred with are:
lago melee system
bullet in chamber
project infinite inspect weapons
i believe it has something to do with the cfgmods parser because it fails at that step during the startup process
diag shows following error unique to this:
d:\bis\source\dev\futura\el\evaluator\expresscompiler.cpp(4384)(func: GameState::CompileConstants) [AssertNoDlg] MainThread=8712 globals
i haven't been able to pinpoint exactly what is causing it or the correct commonality between the above mods. and there are many more that are causing this but it is taking me way too long to track them all down.

dev, don’t think it made it to rc

In T169734#2405319, @BIS_fnc_KK wrote:

Any workaround?

both
veh setDamage 0
and
veh setHitpointDamage ["hitEngine", 0]

should now work

Attached the compressed mdmp and bidmp of one of the crashes.

Any workaround?

both
veh setDamage 0
and
veh setHitpointDamage ["hitEngine", 0]

vehicle engineon true; does not work, isEngineOn turns false after that.

will be fixed in 2.14

"Drowned" mission EH added in rev 150299

And no matter how many player's corpses there are on the map, any explosion near player's corpses will broadcast this effects on the screen current player
It will not necessarily be a mine - any explosion

4 year later, Still being yelled at over AR fire that were moving cuz my Oval-then circle-then oval radar is turned off.

I thought that players would work as a kind of virtual camera on server side in this case, but that clears it up.

dedicated server is remote machine, there is no camera on it. Not sure if it ever fired on dedicated server.

I don't understand how this applies to my case.

"Special multiplayer behaviour: When added to a remote unit or vehicle, this EH will only fire if said entity is within range of the camera. That range is determined by the fired ammo's highest visibleFire and audibleFire config value. In case of units, muzzle attachment coefficients are applied too."

The only solution I have is to replace by a scripted function checking vehicles every few secs:

This would be possible to ammend with

rev 150292

As noted also with T170145, having non simulated groups being returned also would be useful, so maybe only exclude them with additional optional parameter?

That command would be really useful to save alot of time, even outside perframe execution. If you have a good amount of units/groups around a certain place, it takes a good chunk of time.

No, it happens not anymore since i started T159875, as around this time the behaviour seemed to have changed, which i noticed because my workarounds for this issue which worked well for some time suddenly did not work properly anymore.

rev 150290 "building_exterior" for enableAudioFeature

works as expected - can be closed

this seems no longer to be true from our testing/usage. is it still for you @Ron4Swat ?

This is so amazing. Arma for life!

next dev

playsoundUI can do it

To be able to play cfgsounds, through script with volume control that respects a global mixer volume

I guess this can be resolved as we now have allObjects?

playSound doesnt have direct volume control property. What exactly do you need?

Well, after a week of testing I couldn't reproduce this "bug". Seems I was confused by the fact that when I logged in as admin global channel was available.
Again, thanks for the explanation, @BIS_fnc_KK (makes sense to update BIKI), and sorry for the false alarm.

They are the same sound files, should be fixed in the dev after next