Factorio Forums

While trying to find the exact numbers of the mechanics of car loading and unloading using inserters, we have encountered some unexpected inconsistencies.

The test:
We execute the following commands: (The 1/256 comes from the fact that the whole games seems to calculate positions in multiples of 1/256.)
We then build the following setup around the cars (all inserters extracting from the cars):


As can be seen, the inserters can extract starting from the 3rd car (i.e. shifted by +-25/256).

Similarly, for we get:


Note that now inserters only start working at the 4th car.

Going to {0,1000}, things get even weirder:

North pointing cars:


South pointing cars:


Going to {0, 100000}:

North pointing cars:


South pointing cars:


The strange thing is that on one hand, the 1/256 position precision suggests the use of fixed-point numbers, while the behavior seems to originate in floating-point precision loss.

mathe172 wrote: ↑

Sun Oct 07, 2018 4:17 pm

The strange thing is that on one hand, the 1/256 position precision suggests the use of fixed-point numbers, while the behavior seems to originate in floating-point precision loss.

That's because the map uses fixed point, while inserters use floating point.

Inserter-car interactions are known to be bad for performance. It's not surprising they are buggy too. Just be happy the devs don't nerf your 2x3 super-chests further.

Thanks for the report. If one of the other devs wants to look into it they're free to do so but I don't consider this worth working on.

There's no special logic when it comes to inserters interacting with cars over an assembling machine or chest. Simply those entities are always built on grid-aligned positions and you're free to place cars on non-grid aligned positions.

Thank you very much for your reply!

We totally understand that this is a low priority issue. However, we were wondering whether you could provide an explanation why this happens.

Our guesses as to what might be going on:

• The bounding box of the car (+-1,+-0.7) is rounded to 1/256 precision (towards 0), i.e. (+-256/256,+-179/256)
• The rotation matrix corresponding to the orientation of the car is applied to the bounding box as floats.
• The result is rounded to 1/256 precision again. Since sin(pi)!=0 (not exactly at least), but sin(0)==0 (entries of the rotation matrix), this could explain why cars oriented towards north have a different size than others (this is something else we noticed - cars pointing not north (i.e. south, east, west) are smaller than those pointing north by 1/256 in all directions)
• Translations are applied together with the rotation as affine transformations using floats. Since the 23 bit precision of floats is not enough for 10^5 (17 bits) + 1/256 precision (8 bits), precision is lost leading to "smaller" cars

In case we're more or less correct with our guesses, couldn't the translational part just be applied with the 1/256 precision, i.e. rounding the result after the rotational part? Given that the translation vector is already a multiple of 1/256 and the result is rounded, this shouldn't have any drawbacks and just provide extra precision for coordinates far away from the origin.

Of course, without seeing the code, these are just educated (hopefully at least) guesses. We would appreciate it very much if you could outline the reasons for these inaccuracies, as we strongly depend on understanding the exact mechanics behind the interaction. (Map will be posted once we're done )

Thanks for the report.

Fixed for 0.17

(Thanks Allaizn for fixing it for us. )

For those looking, I think this is the bug report by Allaizn that posila is referencing.
(Title: "Cars and Tanks have a slightly smaller collision box when not facing north")