SearchNearby Endless Loop #1544

[mrzachhigginsofficial]

When merged this pull request will:

• Performance and reliability adjustments for SearchNearby function
• Set a max timeout for each unit move order (positions *15 and no more than 2 minutes).
• Set a time start variable "CBASearchTime" on each unit.
• Added a quarter-second pause between unit iterations.
• If the timeout is exceeded before the unit is ready, the unit will receive a new command for the next position. Command time is updated to reflect timeout for the next move command.

[mrzachhigginsofficial]

Proposed PR for issue #1544

[commy2]

Added a quarter-second pause between unit iterations.

Why?

Set a time start variable "CBASearchTime" on each unit.

Should not be a hard coded string in a local variable, but a QGVAR, i.e. QGVAR(SearchTimeout)

Not sure about using time. It uses the SQF NUMBER type single precision float, i.e. this change will make the script fail after roughly 11.5 days uptime.

[commy2]

Why not below use getVariable default instead?

[mrzachhigginsofficial]

The units would eventually skip every building as the start time would never be updated. Perhaps the variable name is confusing.

[mrzachhigginsofficial]

Perhaps QGVAR(StartSearchTime) would make more sense.

[mrzachhigginsofficial]

Updated in aa63e9a

[commy2]

If lazy eval is used here, may as well inline the whole local variable.

[mrzachhigginsofficial]

As such?

if (unitReady _x || {(_x getVariable _timetag) + _timeout < time}) then {...}

[commy2]

Timeout should probably be a function parameter instead. Then it is opt in (default it would be off to keep the current behaviour), and tweakable. I would not make it dependent on group size at all.

[mrzachhigginsofficial]

Timeout should probably be a function parameter instead. Then it is opt in (default it would be off to keep the current behaviour), and tweakable. I would not make it dependent on group size at all.

This is not dependent on group size but is dependent on the number of positions in the chosen building. Unit timeouts are evaluated the same whether there are 2 or 100.

private _positions = _building buildingPos -1;
...
private _timeout = (count _positions * 15) min 120;

[mrzachhigginsofficial]

Regarding parameterizing the function, I agree and propose the following parameters:

_timeoutcoef
_maxtimeout

private _positions = _building buildingPos -1;
_timeout =  (count _positions * _timeoutcoef) min _maxtimeout;

[mrzachhigginsofficial]

@commy2 - I need to test that latest commit some more. Please review and let me know if it resolves any of your concerns (especially the opt-out).

[mrzachhigginsofficial]

I'm closing this PR for now. The more I dig into this, the more I see more opportunities for these units to get stuck.

Another example in fnc_searchNearby.sqf

    private _wp = _group addWaypoint [getPosASL _leader, -1, currentWaypoint _group];
    private _cond = "({unitReady _x || !(alive _x)} count thisList) == count thisList";
    private _comp = format ["this setFormation '%1'; this setBehaviour '%2'; deleteWaypoint [group this, currentWaypoint (group this)];", formation _group, behaviour _leader];
    _wp setWaypointStatements [_cond, _comp];

Once again, if the units are never ready, this "regroup" waypoint will never complete. I will open a new PR once I have a more comprehensive solution. @commy2 brings up a good point that this should be parameterized as to not change existing functionality, so I will keep that in mind. It is unfortunate so much reliance is put on the AI sim working as intended (especially since it's virtually impossible to account for every scenario).