I found this bug by in RA adding aircraft to THF
CaptureTypes: vehicle, aircraft
and to ^NeutralPlane
CaptureManager:
Capturable:
Types: aircraft
RequiresCondition: !airborne
CaptureNotification:
Notification: UnitStolen
LoseNotification: UnitLost
From the looks of it, the activity does get cancelled. Otherwise, the thief would just keep chasing the helicopter forever instead of parachuting back.
The only flaws I see in that gif is that the activity gets cancelled one or two ticks too late so the thief lerps a bit into the air, necessitating the parachute; and secondly that the thief glitches to the old subcell position after parachuting. The last bit is really a separate issue though.
Come to think of it, this would probably work fine if the thief _didn't_ cancel the activity once it started to move off the grid . Then it would just enter the helicopter as it starts to take off and that would probably look ok.
From the looks of it, the activity does get cancelled.
Apparently it does not get cancelled when the aircraft takes off and flies away before the thief is at the target, which causes the thief to follow the aircraft.
Ah, I see. I was mistaken, Enter doesn't actually cancel at all. The VisualMoveIntoTarget activity simply ends prematurely when the thief can't keep up with the helicopter, which gets the Enter activity in the exiting state and allows it to end.
I guess that makes the solution not so complicated. We can simply let CaptureActor override the TickInner method to allow it to cancel when the target's capturable trait is disabled.
Most helpful comment
It serves as a blocker for educating thieves on aircraft piloting

Here's a fun quirk of this code