In T82591#2605667, @Wulf wrote:

Fixed in Dev build 151825.

In T168103#2518935, @Vestarr wrote:

It would save me a lot of trouble with my project, and it's kinda holding me back with my mod. I currently have to attach a custom Draw3D handler to render that IR laser without a dot using drawLaser command under specific conditions just for that one case. I wish I could just tell it that beamThickness must be 0 and dotSize must be 0.15 and have the same results as we have with colored laser attachments, except in IR.

BIS please respond!

In T126046#2602464, @NikkoJT wrote:

I think you need to read a bit more carefully.

KK added a revision number (i.e. the change number for the problem being fixed) and changed the task status to Feedback, as in "waiting for feedback on whether the fix worked".

@Bis! 9 years have passed, Instead of fixing it, you only change the status of this problem, 9 years later! Looool!
Mod makers fixed this themselves a long time ago!

The Grenade Window Breaker mod works for both hand and UGL grenades...

@Bis! 9 years have passed, Instead of fixing it, you only change the status of this problem, 9 years later! Looool!

I think during combat injured AI after getting order 'get treat from medic' must take prone position and medic on healing start needs proning too. All animations will applied by auto, just force the wounded man to prone after the medic has received the order to treat him, the medic himself will also prone before treating him, or he will run as usual, go prone a few meters away and crawl to the wounded man…
In any case, AI should not be frozen like it is happens now

If the commander orders a medic to treat a wounded AI, then that wounded AI stops like a statue and will wait stands at full height without moving! During combat, this makes his behavior unnatural.

@NikkoJT thank you for clarification

I didn't understand much of what you said. In your screenshot, I also see red units with blue icons.
A red soldier should not have a blue icon.
Also, the icon of an animated character should not remain after the death or exit from the animation of this animated character.
Can't it be fixed?

I propose the addition of a getter function that allows server administrators to retrieve all handles created via the "spawn" SQF command. This function would provide a list of SCRIPT handles that could be used to terminate the scripts, along with relevant information such as the script name, execution status, and any associated variables, etc.

it was some kind of AI bot

I understand your frustration with the "Seek and Destroy" waypoint in Arma3. It's disappointing when a feature doesn't work as expected, and it can impact the overall gaming experience, especially in a tactical game like Arma3 and click here to read more about the game developers take note of this feedback and work on improving the "Seek and Destroy" feature to make it more distinct and effective. Addressing these concerns would undoubtedly enhance the gameplay and offer a more immersive and engaging experience for players.

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.