Problem with mass drivers and their mineral packets :
I have a system with two colonies equipped with mass drivers and automines. The sender is on a planet with a 13b km orbital distance. The receiver is on the moon of a planet with a 11b km orbital distance. The two colonies are way over 10b km apart right now. Every 5 days, all of the system bodies get their position updated, and a new packet is sent from one colony to another.
I have the habit to use 3-hours time increments. The mineral packets don't move, even after zooming in on them. There's no movement tail whatsoever. Their indicated speed is between 1700 and 2500 km/s.
When I use a 8-hours time increment, the mineral packets move as normal. The movement tail shows and is way longer than the distance between 2 packets.
I see the same behavior in another system with numerous colonies. The receiver is a planet close to the primary. The buggy sender is on the moon of a planet 7b km away, this time equipped with a civilian mining complex. Packets are therefore sent at 1000 km/s. I have two other colonies in that system, on moons of a planet 11b km away. The packets move at over 3000 km/s and are not affected by the bug.
Any idea why this would be? Is it the moon part? The packet speed part? Distance from primary or receiver? Or even system bodies data? My current solution is to either not use mass drivers, or not use 3-hours or less time increments. I'll backup my database in case it might help solving the issue.
Edit : In another system, I'm mining far away comets and sending the minerals with an excess of mass drivers. Packets move at 15,000 km/s or more and aren't affected by the bug. One packet (probably the first) moves at less than 2000 km/s and is affected by the bug, not moving during 3-hours and even 8-hours increments. I stopped all mass drivers and am now using 1-day increments.
Edit 2 : Same bug in Sol system, where far-flung comets are sending immobile packets to Earth even with 1-day increments. Moons are not the problem. I suspect a rounding error somewhere, maybe when ETA is way bigger than the increment used. (The packet moves barely 1E-15 of the way, why move it at all?)