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.
[2.0.14] Bots jumping / snapping backwards on Aquilo
[2.0.14] Bots jumping / snapping backwards on Aquilo
- Attachments
-
- bots jumping.zip
- (24.51 MiB) Downloaded 102 times
-
- screenrecording-2024-11-06_11.20.36.mp4
- (1.54 MiB) Downloaded 139 times
Re: [2.0.14] Bots jumping / snapping backwards on Aquilo
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
- Filter Inserter

- Posts: 360
- Joined: Thu Jun 01, 2017 12:05 pm
- Contact:
Re: [2.0.14] Bots jumping / snapping backwards on Aquilo
Seems like it, but shouldn't running out of power immediately update the position to avoid such jumps?
Re: [2.0.14] Bots jumping / snapping backwards on Aquilo
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 thoughDarkShadow44 wrote: Wed Nov 20, 2024 4:27 pm Seems like it, but shouldn't running out of power immediately update the position to avoid such jumps?
My mods: Multiple Unit Train Control, RGB Pipes, Shipping Containers, Rocket Log, Smart Artillery Wagons.
Maintainer of Auto Deconstruct, Cargo Ships, Vehicle Wagon, Honk, Shortwave.
Maintainer of Auto Deconstruct, Cargo Ships, Vehicle Wagon, Honk, Shortwave.
Re: [2.0.14] Bots jumping / snapping backwards on Aquilo
The performance optimization should take the remaining power into account?
Re: [2.0.14] Bots jumping / snapping backwards on Aquilo
An easy fix is also to reduce the robo energy drain on Aquilo 
Re: [2.0.14] Bots jumping / snapping backwards on Aquilo
Exactly:robot256 wrote: Sat Nov 23, 2024 5:51 pmThe 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 thoughDarkShadow44 wrote: Wed Nov 20, 2024 4:27 pm Seems like it, but shouldn't running out of power immediately update the position to avoid such jumps?
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.
Re: [2.0.14] Bots jumping / snapping backwards on Aquilo
Any chance this issue gets assigned? The visual teleport is quite noticeable and occurs on all planets when enough robots are charging at the same time, not just on Aquilo.
If the naive prediction is just to project the position forward using speed and a number of ticks, it would only be a single boolean check to determine if the robot will reach that position at full speed - comparing the robot's remaining energy against the energy required to move (usage per tick * number of ticks * surface energy multiplier). It would actually be fairly trivial to calculate the exact tick in which it runs out of power - unless there are complexities I don't know about!
If the naive prediction is just to project the position forward using speed and a number of ticks, it would only be a single boolean check to determine if the robot will reach that position at full speed - comparing the robot's remaining energy against the energy required to move (usage per tick * number of ticks * surface energy multiplier). It would actually be fairly trivial to calculate the exact tick in which it runs out of power - unless there are complexities I don't know about!




