Paul Chote

The check at https://github.com/OpenRA/OpenRA/blob/bleed/OpenRA.Mods.Common/Activities/Move/MoveAdjacentTo.cs#L129 is the ain bottleneck, which isn't affected by the `check` value. 4a609bbee81f4a82bd85ea8244857f02145649c8 also hurt a lot, but there is no clear simple mitigation we can apply....

Of course, and we already do for many things. But there is a big difference between deciding that something like this issue needs to be tested and designing an implementation...

IMO this is a good demonstration of the trap of speculative generality - a lot of time and effort to try and solve every behaviour that may be needed, but...

Gameplay simulation code must not use floats - this causes desyncs!

@sorcerer86pt's video shows that this appears to be missing a key detail from the ornithopter strike: they should circle by ~270 degrees, such that the second strike is at right...

> which is unrealistic at this point due to engine limitations. No it isn't. It would be straightforward to create a new fly-type activity that allows the aircraft to follow...

I agree with your solution.

OpenRA.Utility(1,1): Error: Actor type `truk` consumes conditions that are not granted: loaded OpenRA.Utility(1,1): Error: Actor type `fix` consumes conditions that are not granted: build-incomplete, being-demolished OpenRA.Utility(1,1): Warning: Actor type `hind`...

This will complicate fixing #16557. Can you please elaborate on your motivations for this feature (I guess this is for OpenHV) so we can better consider the tradeoffs for/against it?

Would keeping a constant tick rate but setting a randomized start frame solve the problem?