The Car-Inserter interaction is non-homogenous (locational) and non-isotropic (rotational)

This subforum contains all the issues which we already resolved.
mathe172
Burner Inserter
Burner Inserter
Posts: 11
Joined: Fri Jun 02, 2017 3:35 pm
Contact:

The Car-Inserter interaction is non-homogenous (locational) and non-isotropic (rotational)

Post by mathe172 »

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:

Code: Select all

/c dir = defines.direction.north
/c pos={x=0,y=0}

/c for i=1,10 do for j=-1,1,2 do game.player.surface.create_entity{name="car",direction=dir,force="player", position={x=pos.x+3*i,y=pos.y+j*(22+i)/256.}} end end
(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):
Image

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

Similarly, for

Code: Select all

/c dir = defines.direction.south
we get:
Image

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

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

North pointing cars:
Image

South pointing cars:
Image

Going to {0, 100000}:

North pointing cars:
Image

South pointing cars:
Image

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.
User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3717
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: The Car-Inserter interaction is non-homogenous (locational) and non-isotropic (rotational)

Post by DaveMcW »

mathe172 wrote: Sun Oct 07, 2018 4:17 pmThe 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.
Rseding91
Factorio Staff
Factorio Staff
Posts: 14318
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: The Car-Inserter interaction is non-homogenous (locational) and non-isotropic (rotational)

Post by Rseding91 »

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.
If you want to get ahold of me I'm almost always on Discord.
mathe172
Burner Inserter
Burner Inserter
Posts: 11
Joined: Fri Jun 02, 2017 3:35 pm
Contact:

Re: The Car-Inserter interaction is non-homogenous (locational) and non-isotropic (rotational)

Post by mathe172 »

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 😜)
posila
Factorio Staff
Factorio Staff
Posts: 5357
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: The Car-Inserter interaction is non-homogenous (locational) and non-isotropic (rotational)

Post by posila »

Thanks for the report.

Fixed for 0.17

(Thanks Allaizn for fixing it for us. :))
User avatar
MasterBuilder
Filter Inserter
Filter Inserter
Posts: 353
Joined: Sun Nov 23, 2014 1:22 am
Contact:

Re: The Car-Inserter interaction is non-homogenous (locational) and non-isotropic (rotational)

Post by MasterBuilder »

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")
Give a man fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life.
Post Reply

Return to “Resolved Problems and Bugs”