Doesn't work with AI land or air vehicles either, IME. They just use their default type-dependent completion radius (which they don't always reach, separate issue) and ignore the command.

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.

I didn't understand what you mean. As far as I know the default end radius is 1-2 meters. In order for the AI group to consider their waypoint completed, they need to be in this radius by default.
But in fact this is not a problem. The problem is that the "Completion Radius" setting will always be ignored by AI units.
I remember the time that it used to work well. Someone broke this function in one of the updates and now they don't want to fix it for 5-6 years already!

As a result, the player cannot activate the necessary action for the AI units, until they actually reach the waypoint.
For example, I need to join an AI squad, that is on the other side of the map (I use waypoint JOIN) to the player and until this AI-squad reaches the waypoint JOIN location, it will not be joined.
But if the "Completion Radius" function worked, then the AI squad would join anywhere on the map!

rev 149887

Fleeing units will still ignore completion radius

In T167056#2353624, @BIS_fnc_KK wrote:

rev 149887

Fleeing units will still ignore completion radius

This problem has nothing to do with Fleeing AI-Units. Put waypoints into empty map, where there are no threats and you will see that the Completion Radius is completely ignored by AI.

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

In T167056#2353704, @BIS_fnc_KK wrote:

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

Fleeing units get new waypoints independent from the original group waypoints? (as if they joined another group temporarily?)

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?

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#2353725, @BIS_fnc_KK wrote:

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

Why do you say "accidentally"? The Completion Radius value is set by the mission designer and is not a accidentally value. This is the exact number.
It seems to me, that Completion Radius should work even for fleeing units also.

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.

Why do you say "accidentally"? The Completion Radius value is set by the mission designer and is not a accidentally value. This is the exact number.
It seems to me, that Completion Radius should work even for fleeing units also.

A fleeing unit's main task should be getting to safely, not trying to follow a parkour of waypoints possibly leading him into danger. That's why fleeing units will purposely ignore waypoints., including Completion radius ones.
Atleast thats how i understand it.

"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.

e: ninja Tenshi strikes again D:

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.

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.

I am immensely happy that this will be fixed, in one form or another. This problem really prevented me from creating quality missions.

A fleeing unit's main task should be getting to safely, not trying to follow a parkour of waypoints possibly leading him into danger. That's why fleeing units will purposely ignore waypoints., including Completion radius ones.

I got it. I can find logic in this. I really hope that in next update for all AI units, except for fleeing unit's, this will work as it should.

In T167056#2353827, @jaj22 wrote:

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.

at least as a fallback

Hi,
I play "Dynamic Bulwarks Mission"
My server is 32bit Linux. Profiling branch.
https://github.com/Omnomios/DynamicBulwarks/tree/develop
In this mission, there is at the beginning of a round a airplane, that drops a box in the players zone. This is definitly broken since Profiling V5, but maybe earlier in V3. The Problem is I cannot say it with 100% because V3 and V4 has another bug that broke the mission entirly. So this is a little bit fuzzy.
Normal behavior is:

• Airplane spawns
• Airpane flys over player zone
• Airplane drops/spawn a box on a parachute inside the player zone
• Airplane exit playerzone and despawn

behavior since V5 (maybe since V3):

• Airplane spawns and imately drops/spawn the box on parachute outside the player zone.
• Airplane flys over player zone and exit player zone and despawns.

-> The box is located outside the player zone and cannot be reached.

Because of that the airplane spawns a ai group and create waypoints I would say it is related to this topic.

Here some additional infos:

• link to the mentioned supply drop function:

https://github.com/Omnomios/DynamicBulwarks/blob/develop/supports/functions/fn_supplyDrop.sqf

Replicated this in the editor. It looks like when you give vehicles non-zero completion radius values, it caps them to a type-dependent minimum. However, this minimum seems to be 10x higher than the normal type completion radius for air vehicles. Tested cases:

B_T_VTOL_01_infantry_F (Blackfish):
Default completion radius 100m
setWaypointCompletionRadius minimum 1000m

B_Heli_Attack_01_dynamicLoadout_F (Blackfoot):
Default completion radius 50m
setWaypointCompletionRadius minimum 500m

Also tried a wheeled APC, which was fine. Can't guarantee that every ground vehicle works though.

@jaj22 how do you check what the actual radius is

@BIS_fnc_KK I'm watching the results in Zeus, although the waypoints were editor-placed. The shorter radii are... very approximate as these helis are quick, but the 1km/500m distances should be pretty accurate. I used a two-waypoint route to make sure that it's not just a visual waypoint removal.

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.

@Tenshi please can you tell me when the player will finally be able to get the bug fix? It's been three months since I created this ticket.
This bug is still hindering the player.

Update 2.10 did not have this fix :( I don't know when 2.12 will be...

@mickeymen
It should be on the current version of development branch

Game version: 2.11.150030
Branch: development

any game version that ends with a number higher than 149887 should have it. The main build will take longer to be updated.

Quoted The main build will take longer to be updated.

Yes, and I wanted to know from you when the update of the stable assembly? You do not know?
I don't use dev, I have a stable build

@Tenshi
By way of explanation:
This ticket is not yet complete. In the performance build, this ticket was introduced with version v3. It turned out that this bugfix caused a new problem: The completion radius for at least one aircraft does not seem to work properly (for an explanation see comments by jaj22 and me here in the ticket).
In my opinion, this should be solved before this ticket is included in the stable version.

Created a test mission to demonstrate the new bug with aircraft/heli completion radius. Instructions: Run it, hit zeus and map. Watch.

In T167056#2383362, @mickeymen wrote:

Quoted The main build will take longer to be updated.

Yes, and I wanted to know from you when the update of the stable assembly? You do not know?
I don't use dev, I have a stable build

I'm just QA, so i honestly don't know when 2.12 will be finished and released.
However we have the other branches if you want to play a game where it's fixed, or test whether the fix works the way you expect it to.

In T167056#2383505, @jaj22 wrote:

Created a test mission to demonstrate the new bug with aircraft/heli completion radius. Instructions: Run it, hit zeus and map. Watch.

completionRadTest.VR.zip3 KBDownload

Thank you for the repro mission, however it is unclear to me what the issue you are experiencing.
On my end i see all the planes & heli's complete both waypoints.

@Tenshi
If you expand the older posts, you will find this post from jaj22:
"
Replicated this in the editor. It looks like when you give vehicles non-zero completion radius values, it caps them to a type-dependent minimum. However, this minimum seems to be 10x higher than the normal type completion radius for air vehicles. Tested cases:

B_T_VTOL_01_infantry_F (Blackfish):
Default completion radius 100m
setWaypointCompletionRadius minimum 1000m

B_Heli_Attack_01_dynamicLoadout_F (Blackfoot):
Default completion radius 50m
setWaypointCompletionRadius minimum 500m

Also tried a wheeled APC, which was fine. Can't guarantee that every ground vehicle works though.
"

Tested on performance build v7, linux 32bit but should be at least on all perf and dev builds be a thing.

TL;DR: Setting a small non-zero completion radius massively increases the completion radius for air vehicles.

Does not apply to stable.

In T167056#2383734, @Wetzer wrote:

Replicated this in the editor. It looks like when you give vehicles non-zero completion radius values, it caps them to a type-dependent minimum. However, this minimum seems to be 10x higher than the normal type completion radius for air vehicles.

In T167056#2383764, @jaj22 wrote:

TL;DR: Setting a small non-zero completion radius massively increases the completion radius for air vehicles.

Guys, I tried to understand the meaning of the problem. Yet I don't understand full value of this problem.
If you're not happy with a 100m end radius instead of 0m, why can't you make the end radius a very small number?
You say that the problem occurs ONLY if the end radius = 0 m?

For example, what happens if you set the end radius > 0, for example within a 1- 5 meter?, It won't cause the aircraft to move closer to the actual waypoint?
Logically this should solve the problem if it only occurs at zero completion radius

@mickeymen Is this a language problem? "non-zero" means "not zero". The behaviour for zero completion radius is fine. The behaviour for non-zero completion radius is not.

@mickeymen
I appreaciate your effort to find a solution. But to set the value for the completion radius to a value lower than a computated specific value for each type of vehicle would "override" this lower value by the "computated specific value". And here is the problem specially for that specific air vehicle:
The computated value is 10x higher as forseen by the value in the config. this means in numbers:
The minimum completion radius forseen for this air vehicle is 100m. This means, that all values between >0m and 1000m would be overriden by 1000m (the faulty computated minimum value for these air vehicle of 100m).
Caused by the bug it is 10x higher, so it is 1000m.
In other words: All values from 100m(this is after the introduced behavior of this ticket the minimum compl. rad for this vehicle) to 1000m are not reachable to set. And THAT is a problem. Not for me, but for some scripters and for all the missions out there, that maybe are abandon and have no support anymore to react to this.

I am not very happy by this ticket in the case of handling the minimum value at all. I understand the attempt to set a minimum value if no special "optional" value is set and i think that's a good addition.
But i have strong concerns for the rule to ignore a consciously taken decision by the mission creator and "override" his value by the minimum value. I see here two points:

1. The created mission would behave "unpretictable" for mission creators that are not aware of this specific rule. In first place they expect that the vehicle would complete the waypoint in the new and deviated given radius.
2. It takes away the freedom of the mission designer in the name of a "general security" that cannot be predicted for every use case.

@jaj22
@Wetzer

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

Yes, now I understand.
You are talking about a problem when the completion radius > 0.
In this case, the air vehicle will increase the given number by 10 times.

This is definitely a problem that needs to be fixed, together with my problem

Thanks for the thorough investigation

The final completion radius is the radius you set for waypoint completion or the precision of the vehicle whichever is bigger. For the AI in player group it is additionally multiplied by 5, for AI not in player group it was not checked at all (hence ticket). I made AI not in player group follow rules of AI in player group. This is why 200m precision became 1000m completion radius. Going to change it to default handling, so 200 precision will be 200 radius, etc. Lets see how it plays

rev 150093

In T167056#2385061, @BIS_fnc_KK wrote:

For the AI in player group it is additionally multiplied by 5,

Why does it multiply at all? Could you remove this multiplier?

After all, the GAME itself offers to set its own value! Let the player install it himself. it turns out that the player sets one value, and the game will deceive him.
I believe that no multiplier is needed, not for infantry, not for vehicles!
Let the mission creator independently set the values he needs for each waypoint.
It would also be possible to create a script command that could implement a random completion radius if the player wishes

Thanks for game support...

Could you remove this multiplier?

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

@BIS_fnc_KK
After some testing, I would appreciate the ability to influence the safety range. Maybe as an optional parameter to switch off safety distance.
As new, optional parameter it would not break the default setup and give the chance for existing missions to "react" to the new cirmustances with minimum effort.
An advantage of this would be, that the multplier can be introduced again for Non-PLaer AI groups

In T167056#2385760, @Wetzer wrote:

@BIS_fnc_KK
After some testing, I would appreciate the ability to influence the safety range. Maybe as an optional parameter to switch off safety distance.
As new, optional parameter it would not break the default setup and give the chance for existing missions to "react" to the new cirmustances with minimum effort.
An advantage of this would be, that the multplier can be introduced again for Non-PLaer AI groups

What do you mean? The detection radius cannot be less than vehicle precision, because of the path planning, it will plan path in chunks of the size of vehicle precision so it cannot be less. If you you think the precision is too rough, make a mod and change it, since it is config value it cannot be changed on per vehicle basis.

What do you mean? The detection radius cannot be less than vehicle precision, because of the path planning, it will plan path in chunks of the size of vehicle precision so it cannot be less. If you you think the precision is too rough, make a mod and change it, since it is config value it cannot be changed on per vehicle basis.

The idea is not to change vehicle precision itself. the idea is to make it changeable if the value is taken into account for path planning at all. The default would be "yes". When mission creator decides by additional optional parameter of completion radius to switch off precision value, the path planning would take into account only the given completion radius of the specific waypoint.

In T167056#2385841, @Wetzer wrote:

What do you mean? The detection radius cannot be less than vehicle precision, because of the path planning, it will plan path in chunks of the size of vehicle precision so it cannot be less. If you you think the precision is too rough, make a mod and change it, since it is config value it cannot be changed on per vehicle basis.

The idea is not to change vehicle precision itself. the idea is to make it changeable if the value is taken into account for path planning at all. The default would be "yes". When mission creator decides by additional optional parameter of completion radius to switch off precision value, the path planning would take into account only the given completion radius of the specific waypoint.

What you are suggesting is rewriting half the engine, it is not doable

What you are suggesting is rewriting half the engine, it is not doable

Half of the engine is to figure out the path planning? No wonder why it is so slow. :D

From my side it looks only like only of an if statement around precision value in the function/method for the calculation of the completion radius (and some fluff for the overload of the completion function).
In my opinion this solution would be only the second best solution. First would be to allow to override the completion radius by the mission creator. And if the mission creator set the value to 5m for an air plane, everyone would know, why the ai would'nt reach the completion for this waypoint.

As mentioned before, the advantage would also to reintroduce the multiplier for the non-player ai groups(as i understand is now switched off for these groups) because there would be an option to switch off this calculation by the suggested optional parameter (in case the mission creator would actively discard/reduce this safety measure).

In T167056#2385111, @BIS_fnc_KK wrote:

Could you remove this multiplier?

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

@BIS_fnc_KK If the Completion Radius should have a multiplier and cannot be removed, then please add a multipliers description to this, if the player hover over the field where the value is entered.
This will help players to choose the required/suitable value and not be deceived by the game.

Historic day!

In the main branch, It was fixed today!
I've been waiting for this for about 6 years!

On the BIS forum, I had to prove to the developers that this error exists, even when I created repro missions, no one believed me!
Only after I created at least 3 tickets, here on the feedback forum for this bug, it was resolved. Hallelujah!!!

BIS you are a bit late, but a magician...