Aircraft - Drone "Follow Unit" Waypoint Action

[mrschick]

When merged this pull request will:

• Add a "Follow Unit" Waypoint Action to Drones, to emulate the vanilla "Follow Unit" behaviour from the UAV Terminal, which is unfortunately only available on other drones unless "friendly map content" is enabled;
  • Follow action is available when pointing at a man/vehicle (currently via cursorTarget) and creates a persistent "follow" type waypoint;
    • Works from UAVs;
    • Works from UGVs;
  • Follow action permits selecting a min distance to follow to, just like the vanilla interface (unclear how that logic works);
• Fix the "recharge" action being shown on destroyed drones;

[mrschick]

Looks like UGV Follow code is broken and a known issue. I guess an all-round solution will require some sort of follow-mode PFH that updates a move/hold waypoint, which should also allow scripting a "min distance to follow" behaviour, though a native scripting method would be preferable.

[mrschick]

Ended up implementing the selectable follow distance via a simple distance check in the PFH, should be pretty efficient already but could be optimized further.
I guess the interaction to set follow distance could be more user friendly too.

Feedback appreciated.

[mrschick]

I guess the current implementation of a separate "Follow Distance" interaction (just like for Loiter Altitude) is best.
It still needs a stringtable entry for localization, Loiter Altitude uses the vanilla $STR_3den_waypoint_attribute_loiteraltitude_displayname, so far I haven't found anything similar for Follow Distance. I doubt there is though, so it will probably need to be added.

[mrschick]

I think this is pretty much complete.
Maybe some Air vehicles should also be followable, might be useful when tracking other small drones with a drone 🤔

[johnb432]

Looks like UGV Follow code is broken and a known issue. [...]

I want to see that ticket be included in the code, explaining why a PFH even needs to be added.

[johnb432]

I think this is pretty much complete. Maybe some Air vehicles should also be followable, might be useful when tracking other small drones with a drone 🤔

I really don't know: I don't use drones at all and frankly I don't care for them. We need other opinions here.

[LinkIsGrim]

I'll test later this week. Code looks good at a glance post-changes, but I haven't looked too hard.

[PabstMirror]

I could see someone saying this is too strong because the drone will continue to follow even if it doesn't have line of sight
e.g. vehicle in forest or human inside of a building
but there is always a way to disable with getVariable [QGVAR(droneWaypoints)
and I think most use of this will be perfectly fine

[mrschick]

The vanilla following was similarly OP, it would get stuck sometimes if the drone's turret wasn't looking at the target, but once you'd lock it with Ctrl+T and "revealed it" with T, the AI would know about it even when in buildings and follow with few interruptions.
Also I think most use-cases (especially with UGV) will be following of the drone operator, which the drone should always know where to find due to the terminal's DL.

[LinkIsGrim]

LGTM

[johnb432]

@mrschick I can't push any changes on your branch.
I believe it's because you don't allow contributors to commit to PR branches directly. If you enable it, it allows us to merge master when we want to test and makes it easier to commit small changes.

I want to merge the master branch, along side with some minor changes (code cleanup, header fix) and I don't want to have to do this via the website, so please allow me to push changes.

[mrschick]

@johnb432 Unfortunately maintainer edits cannot be enabled for organization PRs.
https://github.com/orgs/community/discussions/5634

[mrschick]

Running git merge --squash master to merge while keeping linear history caused the PR to show with 731 files modified. Fixed by rebasing and force pushing.
I guess the "best" way would be running git merge master to not break any history, but it makes commit history messy IMO.