[2.0.14] Bots jumping / snapping backwards on Aquilo

[morganc]

When robots divert to charge at roboport on Aquilo they are jumping backwards. See video attachment.
Seems to be purely visual gameplay is working perfectly otherwise.
Worker robot speed 6 researched.
Using Factorio 2.0.16 experimental / Steam / Linux.

[Loewchen]

Looks like this is just the point they are all running out of power so the position is corrected retroactively, see https://factorio.com/blog/post/fff-421.

[DarkShadow44]

Seems like it, but shouldn't running out of power immediately update the position to avoid such jumps?

[robot256]

Seems like it, but shouldn't running out of power immediately update the position to avoid such jumps?

The performance optimization means that it doesn't actually check the power level at every point. Seems like it's not checking for how much power is left until after it tries to subtract how much it would have used and sees it was too much. They might have done it that way to avoid an extra step of predicting whether it will run out of power before the next update point. It does seem like it might be worth the tradeoff to make the visuals better though

[morganc]

The performance optimization should take the remaining power into account?

[morganc]

An easy fix is also to reduce the robo energy drain on Aquilo

[kovarex]

Seems like it, but shouldn't running out of power immediately update the position to avoid such jumps?

The performance optimization means that it doesn't actually check the power level at every point. Seems like it's not checking for how much power is left until after it tries to subtract how much it would have used and sees it was too much. They might have done it that way to avoid an extra step of predicting whether it will run out of power before the next update point. It does seem like it might be worth the tradeoff to make the visuals better though

Exactly:
It just takes the current speed (based on it being currently out of power or not), and using it as predictor for the next step (which is X amount of ticks). But when the next step is done, it actually calculates how far can it get based on the power, so the "naive" prediction is not precise.

The prediction logic could be improved in the future, but it is not a critical bug to make it a priority.