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:

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

In T167449#2354732, @Leopard20 wrote:

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

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;
	};
}]

rev 149916

Reproed, [] broken

I have implemented a workaround to the affected script: https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/9cc182c6aff0dfa2f9f28925ce9d9ac9d2f60339

The versions I indicated are correct; their bug report is what's incorrect. My ATM locator script they referenced uses allMissionObjects for editor ATMs, but nearestObjects for terrain ATMs. Here's the script with the workaround: https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/9cc182c6aff0dfa2f9f28925ce9d9ac9d2f60339

I’m not sure the versions are correct, here is screenshot in 2.08 https://feedback.bistudio.com/T167429#2354350

I was able to work around this bug by using nearestTerrainObjects [[10655.9,12201.3,1.49722], ["HIDE"], 5] instead.

In T167429#2354331, @AryxRayx wrote:

Self placed Land_Atm_01_F and a Land_Atm_02_F work.

But It doesnt work on Original map placed ATM's (Land_Atm_01_F/Land_Atm_02_F), for example those on Altis. (As if they dont exist anymore)

Atm_01 at [3777.37,13517.8]
Atm_02 at [3281.66,12963.2]

I tested in 2.08 on Altis, the return is [] Could you give me Altis position of ATM so I could verify that’s the case?

Self placed Land_Atm_01_F and a Land_Atm_02_F work.

Please provide exact steps how to reproduce this as well. If I place Land_Atm_01_F or Land_Atm_02_F both get detected. Are you sure you didn place Land_Atm_01_malden_F for example

In T126021#2354042, @LSValmont wrote:

This still happens even in Reforger so don't get your hopes up =p

PS: It is even worst in Reforger btw

what map is this?

rev 149910

Hey @sadovsf this still isn't fixed :(

I believe this is old news, but:
Fixed on Dev 2.11.149907

Update has substantially improved the strobing effect for thermals on my UHD 630 machine! Just played earlier today and the improvements were noted. I typically use the ENVG-II optics as well as the Nightstalker rifle scope in game. The rapid strobing effect has ceased - there's still a flashing that looks like lightning flashing, or perhaps a camera flash at a sporting event, but the thermals behind it are stable and consistent, so it's still an improvement several times over what I was experiencing before, which made the thermals useless to me. Now I can consistently use them, and just ignore the flashing.

I’m going to talk to OP

nils for out of bounds _index might not be really needed as there is

vehicle magazinesTurret [turretPath, includeEmpty]

to get empty magazines so you can find the count yourself.

Maybe its time to finally fix this command. Lets be honest, 99% of usages of this command are to get currently loaded magazine. Who needs *random* magazine ammo count? Lets make this command prioritize loaded magazines.

This still happens even in Reforger so don't get your hopes up =p

Ok this could to be perhaps related to the Ai not forgetting their old generated path? When teleported around the Ai will still try to device a path that uses their previous path point which is now very far away and that makes the process use a lot more resources. A solution could be that the setPos command always resets the Ai path which after being moved has to generate a completely new one (path) without considering their previous paths.

rev 149907

You too ;D

Still assigned to "None", still present in the same way in 2.10.
5 years anniversary of the post.

And me?

Always a pleasure to give you weird bugs to fix <3

next dev or prof v4

I think I also found the issue with nested ifdef's because of you :D
When it finds a if or ifdef with a false condition, it then proceeds to skip all data until the next #endif
But, that also means it skips if's and ifdefs, causing it to misscount the #endif

https://community.bistudio.com/wiki/Arma_3:_Unusual_process_exit#0xC0000135_-_STATUS_DLL_NOT_FOUND
Please try the steps in the link above and let us now if that fixes the issue.

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.

Wont fix, it could change how dialogs handling key presses now, and break something

In T167185#2351280, @sharp1337 wrote:

If this is confirm to happen on all missions and not only in your particular mission setup then I hope devs can look into it and resolve it.

My mission setup was nothing special, opening editor, placing a single soldier (player), and creating units at runtime (exactly like in the video). I'm able to reproduce this on any map, Altis, Stratis, even VR.

Fine with the fleeing restriction personally, and I look forward to testing the update. I would have thought that allowFleeing 0 was appropriate for any use case where you wanted to be stricter about following waypoints.

"rev 149887" is a revision number, a change number. There have been 149,886 logged changes to the Arma 3 code before this one - see how this other fix, committed right before this one, is 149886. The current dev branch contains revisions up to 149863, so 149887 will probably be included in the next dev branch update (this week?). It will probably come to stable in the next release, but it's not guaranteed - the next stable release is likely to be the thermals hotfix, and it's possible that's already locked down for QA, which would push this change out to 2.12.

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 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?

no, fleeing units should not accidentally complete waypoints when they run for cover

In T167056#2353704, @BIS_fnc_KK wrote:

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

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

In T167056#2353624, @BIS_fnc_KK wrote:

rev 149887

Fleeing units will still ignore completion radius