Confirmed in current stable, singleplayer and localhost MP, both with provided mission and a trivial custom one where I simply remote control a unit, release it and then spawn an enemy unit in front of it. After being remote controlled, the unit aims but does not shoot at enemies.

Seems to fix an issue I thought was unrelated, where hideObjectGlobal didn't always work on *localhost* when executed during the init process. Time will tell, because the replication wasn't 100% reliable anyway. Tested on 2.18 RC.

Works on Windows at least:
stable: S.O.G. Prairie Fire | vn | false | false
profiling: S.O.G. Prairie Fire | vn | false | true

The fix on dev seems to work, whatever it is. Tested with 1, 10, 1000 and 1e6. Also checked for bias in the last value, seems fine.

Much faster repro by abusing isNil. Typically generates the fail case well within a minute:

[] spawn { 
    private _attempt = 0; 
    private _nohit = true;
    while {_noHit} do { 
        systemChat str _attempt;
        isNil {   
            for "_i" from 1 to 100000 do {
                if (floor random 1000 == 1000) exitWith { 
                    systemChat "hit";
                    _noHit = false;
                };
            };
        };
        _attempt = _attempt + 100000;
    }; 
};

The floor doesn't make a difference to the result (FP won't report a normalized value as equal unless the bits match) but was added on request.

Maybe wouldn't be necessary if there was a reasonably fast way to subtract large arrays. But there isn't. Would like a bulk hashmap deletion method at least.

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

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

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

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

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:

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.

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.

Same issue: Mi-2 AI crew won't fire any weapons except the door guns, and seem to have trouble flying in general. Armed UH-1s are fine.

Added a couple of trivial example missions with Altis and CamLaoNam bridges. Just start the mission and watch. Quad bike swerves violently to the right, about 2/3 of the way across each bridge.

@Tenshi Initial testing with the 32-bit version on the profiling branch suggests that the resolution was successful.

Managed to get a couple more mdmp files from the 32-bit client:

Apparently I need an .mdmp file but it's not generating them locally for some reason. Will try to get one from another machine.