Your windows profile/user name could not be found
As a workaround you can use the -name= start parameter, to set your name manually

Correction: sometimes I can see contents of both weapon holders when accessing corpse: e.g. when I shoot solder in the torso from behind, but not when shooting in the head from behind. So perhaps it is to do with how far from the character the weapons fall.

also put yourself as the commander of this gunner nearby. When the game starts your gunner will say "no ammo" but will never leave his static weapon!
Expected Behavior: The gunner of any static weapon without ammo must exit and remain nearby.

what repro do you need?
just place any static machine gun with gunner in the map and deprive it of ammo in the object properties

repro please

Is it possible to add a setting to make the laser less opaque I think they would look better if more solid lines, and to have the dot show in day (like show flare in day for reflector class).

Yes, it is now all working, thank you developers for your hard work!

Historic day!

already 2.12 and fixing it turns out to be a problem

That seems related to T166710, which was just fixed in 2.12, so it's probably worth checking again.

Nvm, I am dumb and I realize the mistakes in trying to represent the large value misled me

Can confirm, the problem still occurs in v2.10.

Example:

_group addEventHandler ["UnitKilled", {
	params ["_group", "_unit"];
	if(units _group findIf {alive _x} < 0) then {
		// Everyone is dead
	};
}];

In T170658#2413276, @Xeno wrote:

Samatra, there is already a killed EH.

This is about an event handler only firing when all units in a group are dead.. Needed for AI groups in Co-op missions for example.

Currently you have to constantly iterate over all units of a group to check if all units are down.

So virtually like the empty group EH which only fires when all units in a group are deleted.

Samatra, there is already a killed EH.

I'd suggest "UnitKilled" event handler instead. There you can check if everyone is dead as well doing something on individual unit death.

Hello, now I noticed that this problem has been generally fixed and now Koreans, Laotians and South Vietnamese use "MUTE". I don’t know if the creation of this topic played any role in this, but nevertheless, thanks for the work done.
But, an important nuance. I have noticed that when assigning a fighter from the above factions as a "player", he will use the standard voice protocol with American English. The problem is observed only with these factions. OPFOR factions do not experience this problem.

In T165080#2413236, @BIS_fnc_KK wrote:

Cant tell what is scripted and what is vanilla on that video. Can you make an Eden repro showing the problem?

Cant tell what is scripted and what is vanilla on that video. Can you make an Eden repro showing the problem?

0xC0000005 - ACCESS_VIOLATION
Can also be STATUS_ACCESS_VIOLATION.

In T165080#2413212, @BIS_fnc_KK wrote:

It cannot be just fixed as it may break missions where people used workarounds

It cannot be just fixed as it may break missions where people used workarounds. It has to be a new map control or something

In T165080#2413210, @BIS_fnc_KK wrote:

is this the same issue? https://feedback.bistudio.com/T169976

is this the same issue? https://feedback.bistudio.com/T169976

I think that drawEllipse/drawRectangle shapes not being rotated along with the map is a bug. These are map shapes, no display shapes and their coordinates and dimensions should be relative to the map. I'll have a fix in the mission but this should be addressed on engine level if you ask me.

also true if unit is UAV pilot(gunner) or remote controlling one

https://community.bistudio.com/wiki/soundParams
https://community.bistudio.com/wiki/stopSound

any chance for canVehicleCargo?

I have a workaround for crates. I use a trigger to assign ownership of the crate to a nearby player. I'm not sure if this reproduces johnb43's workaround, by changing locality. Here's the snippet of code in the trigger: {crate setOwner owner _x} forEach thislist;

resort to hacky approaches like storing indexes as position Z coordinate

You can just store them as hashmaps now

If you have something that changes from 0 to 120000 gradually and you set it to cut off at 266, everything from 267 to 120000 would return 266, which in your formula is 0 due to linearConversion.

Not at all. In my case it will return values from 1 to 0. 1 for raw values from 3 to 0, and 0 for values from 150 and higher. There will be no jumps in return values at all. Take a closer look at the example above.
But it doesn't matter at all, it is just a use case. I guess I gave that as an example for nothing :)

Because you use hard limits. If you have something that changes from 0 to 120000 gradually and you set it to cut off at 266, everything from 267 to 120000 would return 266, which in your formula is 0 due to linearConversion.

max and min would create hard limit that would seem like a jump

No, it is not supposed there could be such jumps. I tested in a sequence of thousands iterations, and linearconversion works perfectly on both dedicated and local machines, the result is absolutely predictable for specified values.
But let's forget about the linearConversion. The main question - why the getLighting param jumps?

max and min would create hard limit that would seem like a jump, this is why you have linearConversion that does interpolation smoothly. Get rid of max and min and you wont see instant jumps to 0

rev 150318 https://community.bistudio.com/wiki/inAreaArrayIndexes

In T170544#2411210, @BIS_fnc_KK wrote:

as wiki shows second element can go up to 28526.2, if you limit it to 166 it is expected it will seem as instant jump

as wiki shows second element can go up to 28526.2, if you limit it to 166 it is expected it will seem as instant jump

won’t fix