Increase helicopter autotravel speed

[johannes-graner]

Summary

Features "Increase helicopter autotravel speed"

Purpose of change

Helicopter autotravel was restricted to the same 19 kph (3 tiles / second) as land or water vehicles, even though the main reason for restricting the speed (obstacle avoidance) largely does not apply to flying vehicles since at sufficient z-levels, there are very few obstacles to collide with.
For non-flying vehicles, the relatively low speed is fine, but for helicopters this leads to unmanageable fuel consumption, which makes it practically impossible to use autotravel while flying.

Describe the solution

The autotravel speed is increased for helicopters to 102 kph (16 tiles / second, 55 knots) without addressing any potential pathfinding issues. This specific maximum speed was chosen due to being close to the maximum efficiency speed for helicopters (50 - 70 knots), while being low enough to have manageable speed oscillations when turning.

Describe alternatives you've considered

Manually flying at high speeds, but this becomes tedious when traversing large distances (100s of OMTs). Additionally, each turn takes quite a long time to process at those speeds, so the wall time to manually fly 100 OMTs at 360 kph can be longer than autotraveling at 19 kph.

Addressing obstacle avoidance at high speeds, but this would be really difficult.

Testing

Autotraveled in a helicopter at high enough z-levels to avoid any obstacles. Autotraveled in a car to make sure that nothing changed for regular autotravel.

Additional context

No z-level changes are possible while autotraveling with a helicopter. Resuming a route from another z-level doesn't work, but that would be unchanged by this PR. It's very possible to crash the helicopter when not going high enough before beginning autotravel, due to the obstacle avoidance not really being built for such high speeds (Turns out this is not actually the case).

When autotravelling in a straight line (N, E, S, W), a stable speed is maintained, but when the omt path is diagonal, the speed oscillates mainly between 102 and 51 kph. Could be looked into, but it's way less annoying than ground vehicles before #70780 and the fuel consumption is already enormous for helicopters, so the constant ac-/deceleration is less of a problem here.

[RenechCDDA]

So this makes absolutely no attempt to prevent e.g. flying directly into a radio tower you knew was there? It completely ignores the sees check and doesn't replace it with anything.

[IdleSol]

I have a question. What will happen if we call the function responsible for autotravel several times during one turn?

I.e. the move started, called the first time and traveled 3 squares, then called the second time and traveled another 3 squares and so on. After N repetitions, complete the turn. Will the final speed be 3N? Without the problems of pathfinding and collisions with obstacles?

Or do we take the speed of the transport and break it down into multiples of 3 tiles per second. And we get the number N. In a loop from 1 to N, we call the auto-travel function. At the end of the cycle, end the move.

[johannes-graner]

So this makes absolutely no attempt to prevent e.g. flying directly into a radio tower you knew was there? It completely ignores the sees check and doesn't replace it with anything.

There are two avoidance checks, one to brake and stop autotravel ("you're about to run into X"), and one that slows down and tries to find a new path without stopping autotravel (e.g. a tree appears in the way but can be pathed around).

The first check is still in place, and works as intended as long as a constant speed is maintained. The regular autotravel does not take acceleration into account, which is the reason it's limited to 19 kph (3 tps).

The reason for removing the second check is that for some reason it completely prevents autotraveling in the air at speeds higher than the minimum 6 kph (1 tps) when the direction is anything but horizontal (E, W). I suspect this is due to the call to data.adjust_z that adjusts the vehicle z-position to ground level, but I was not able adjust that function to make it work.

However, once you're a few z-levels up, there are so few tall obstacles that it's very easy to avoid them by making sure the path does not travel through any such OMTs. Or even easier, go straight to z=9 where I have not seen any obstacles other than fairly rare wind turbines that are even possible to run into.

[johannes-graner]

I have a question. What will happen if we call the function responsible for autotravel several times during one turn?

I.e. the move started, called the first time and traveled 3 squares, then called the second time and traveled another 3 squares and so on. After N repetitions, complete the turn. Will the final speed be 3N? Without the problems of pathfinding and collisions with obstacles?

Or do we take the speed of the transport and break it down into multiples of 3 tiles per second. And we get the number N. In a loop from 1 to N, we call the auto-travel function. At the end of the cycle, end the move.

I'm not sure that would work without introducing "cheating" by allowing adjustments to speed and direction multiple times per turn, which is not available during regular driving. To my understanding, a turn is the smallest amount of time for the character to react to their surroundings, so this would result in superhuman reaction times.

It's certainly an interesting idea, but I'm not really up for exploring it since it would likely require substantial changes to the autodrive code.

[kevingranade]

If I'm understanding you correctly, If you fly too fast too close to the ground, you CAN run straight into an obstacle.
If so this is a non-starter. This needs to be a more nuanced thing that allows top speed only when it's actually safe.

[Night-Pryanik]

Make maximum autotravel speed depend on z-level the helicopter is currently flying?

[johannes-graner]

Thanks for the feedback, I'm planning on implementing the suggestion from @Night-Pryanik, possibly with a message as part of travel confirmation if the z-level is too low.

I will also do a bit more testing to ensure that the few very tall obstacles are properly avoided when planning the omt path.

[ampersand55]

What happens if:

1. you fly a helicopter at auto travel speed.
2. debug spawn a wasp 1 tile outside the avoidance check range.
3. autotravel in the direction to put you in collision course with the wasp.

Would you have time to react to the wasp?

[johannes-graner]

I started testing to see how bad the current obstacle avoidance of and was very pleasantly surprised. Autotraveling through a dense city at z=2 works really well with both a nimble 2-seater and a much less nimble Osprey.
Even z=1 works fairly well and all stationary obstacles are either pathed around or autodrive aborts with enough margin to manually get out, i.e. nothing different from normal ground level autodrive.

Regarding@ampersand55: I didn't test this specifically, but flying around wasp infested radio towers works perfectly fine. Autodrive is aborted when creatures are in the way, and helicopters are powerful enough to immediately stop from 102 kph so manually backing out world just as well as when flying manually at those speeds.

In my opinion this works well enough as it is, but if someone disagrees, I am of course open to implementing something akin to what Night-Pryanik suggested.

cdda-heli-speed-low-altitude.mp4

cdda-heli-speed-osprey.mp4

cdda-heli-speed-2seater.mp4