Ai falls under floor of first level on maps of Livonia, CUP, Western Sahara, everywhere in buildings where there is an elevated ground floor.
By the way, how will the AI go through the walls on any maps! I'm so tired of this crap. Tis issue looks like a real shame(

The Scale - is what has always distinguished the Arma3 series, from other miitary genre games .

Flares are useless (launcher)

Good day!

In T165786#2325757, @Tenshi wrote:

Thank you for reporting the issue.
We will see what we can do

In T171294#2425174, @Leopard20 wrote:

This needs new animation files which most likely won't happen at this stage of development.

Great idea! I would love to see this in the Arma3 editor

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

Historic day!

In T167056#2385111, @BIS_fnc_KK wrote:

Could you remove this multiplier?

No, too late to change it now, it can break backward compatibility

In T167056#2385061, @BIS_fnc_KK wrote:

Guys it was my fault, I was not attentive and misunderstood you in a hurry, also english is not my native language/ In general, I missed

In T167056#2383734, @Wetzer wrote:

Quoted The main build will take longer to be updated.

In T167056#2353822, @Tenshi wrote:

Yes, but until no understand version "rev 149887" - you mean current dev version? Does this mean that this will be fixed in the next stable release?

What he means is that on version 2.XX.149887 this should be fixed, so if your on any branch that has that or equal revision it should have the fix.
i think Dev gets updated as one of the first branches.

In T167449#2354863, @LSValmont wrote:

In T167449#2354732, @Leopard20 wrote:

You can fix it yourself by setting the effective commander as the driver himself:

this addEventHandler ["GetIn", {
	params ["_veh"];
	if (!isNull driver _veh) then {
		_veh setEffectiveCommander driver _veh;
	};
}]

This would help advanced mission makers yes but entry level mission makers with just some EDEN experience and little scripting experience will not be able to enjoy this fix (actually a workaround).

To be honest one of the reasons why unmodded arma content is so uncommon/unthinkable for mission makers is that BI demands their players to come up with their own workarounds too much. I bet you learned scripting and eventually over the years became of of the most knowledgeable modders out there due to your own dissatisfaction with the state of the game in many regards. It shouldn't have to be that way in most cases, that players need to learn advanced scripting/modding just to make their missions more fun or less buggy specially when the feature is/was already present and it is just currently broken and/or incomplete for any reason.

In T167449#2354732, @Leopard20 wrote:

You can fix it yourself by setting the effective commander as the driver himself:

What he means is that on version 2.XX.149887 this should be fixed, so if your on any branch that has that or equal revision it should have the fix.
i think Dev gets updated as one of the first branches.

In T167056#2353704, @BIS_fnc_KK wrote:

It is fixed in rev 149887 but not for fleeing units, clearer now?

Yes, but until no understand version "rev 149887" - you mean current dev version? Does this mean that this will be fixed in the next stable release?

In T167056#2353624, @BIS_fnc_KK wrote:

rev 149887

Fleeing units will still ignore completion radius

In T167056#2353571, @jaj22 wrote:

They just use their default type-dependent completion radius (which they don't always reach, separate issue) and ignore the command.

In T166035#2331729, @Dwarden wrote:

vanilla units without any mods video would be welcomed

@Cyruz I suggested a good solution above. By default, this disappears, just like it would in real life. But in the properties of the object there should be a checkbox - "do not delete in case of destruction of buildings".
Or do you think that each user will have the skills of scripting knowledge?

In T63050#2330713, @Cyruz wrote:

If an object was placed floating, I'd rather it was kept floating. Admins/mission makers can script the rest, deleting stuff is undesired.

That bug is not related to vanilla animations.

BIS, thank you too, because you don't forget about A3

That bug is not related to vanilla animations

thank you for for clarification

In T63050#2322629, @NikkoJT wrote:

However, the idea of such a system is still flawed.

In T63050#2322623, @NikkoJT wrote:

Some static objects, such as sandbag walls, don't have physics simulation at all - they're always fixed in place. You could place one in midair to begin with and it would stay there. The only possible solution for these objects would be to delete them when the building is destroyed, and it wouldn't be safe for the engine to do that automatically (it could accidentally delete something the missionmaker doesn't want it to). The best way to handle those is for the missionmaker to use an event handler or trigger to delete them when the building is destroyed.

In T63050#2307214, @BIS_fnc_KK wrote:

Should be fixed in 149354

In T73168#2306607, @BIS_fnc_KK wrote:

Leaving ragdoll simulation on the dead bodies is costly, however Im going to add scripted solution to be able to temporary enable ragdoll on dead bodies

In T63050#2307214, @BIS_fnc_KK wrote:

Should be fixed in 149354

ok i got it

Is it even possible to make a ragdoll without a time limit? So that each corpse always responds to external influences (weapon inpacts, environment morphing)
If the ragdoll had no time limit, then this problem wouldn't exist.

I'm not using the dev version, I hope in the next stable build, this will no longer be.

In T164782#2307183, @BIS_fnc_KK wrote:

Should be fixed in 149354

Hey BIS!