[0.11.7] game.createentity wrongly interprets grid

[Kikkers]

Hi.

My mod seems to have some issues with all entities that use game.createentity. What seems to happen is that the entity created is aligned to the grid with a [+0.5, +0.5] offset, which places them in an unexpected position. Modifying the input position does not help, as it snaps to the grid (the wrong grid). Only setting the "placeable-off-grid" flag in the prototype seems to avoid this behavior.

Link to the problem in question in the mod thread: https://forums.factorio.com/forum/vie ... 132#p59119

[kovarex]

As I replied in the topic, I don't understand what is wrong.

The position {0.5, 0.5} is the center of the tile, so logically, the entity (when it is 1X1 entity) is moved to this point when it is not offgrid entity.

[Kikkers]

Oh, it seems I missed a rather important detail:

I normally remove the collision_box field from the prototype unless I notice it's needed, assuming the field is automatically set to a zero-size box.
It seems that setting collision_box to any value manually (even to the default zero-size box) changes the way how an entity is snapped on the grid.


You can use the mod to recreate this:

• Place one Electric switch, you will notice two graphics offsetted (they should overlap).
• Find and edit the pole-entity.lua file in the mod, add
  collision_box = {{0, 0}, {0, 0}},
  to the "smart-pole-deco-vertical" prototype
• Repeat first step, graphics overlap, problem solved

So the bug I'm trying to point to is (yet again) more subtle than I first expected:
Explicitly setting a default value has a different behavior than setting nothing.

[kovarex]

I tried this in the main game with inserter.

Setting the collision box as zero, or not setting it at all had the same effect (the inserter was marked as having tile size 0X0, so it was created in the boundaries of the tiles).

[Kikkers]

Strange. Must be a combination of some factors then.

[kovarex]

Oh, it seems I missed a rather important detail:

I normally remove the collision_box field from the prototype unless I notice it's needed, assuming the field is automatically set to a zero-size box.
It seems that setting collision_box to any value manually (even to the default zero-size box) changes the way how an entity is snapped on the grid.


You can use the mod to recreate this:

• Place one Electric switch, you will notice two graphics offsetted (they should overlap).
• Find and edit the pole-entity.lua file in the mod, add
  collision_box = {{0, 0}, {0, 0}},
  to the "smart-pole-deco-vertical" prototype
• Repeat first step, graphics overlap, problem solved

So the bug I'm trying to point to is (yet again) more subtle than I first expected:
Explicitly setting a default value has a different behavior than setting nothing.

I tried it (I guess that the electric switch is related) and there was no difference, the preview showed one item, and when build, there were two entities the second one moved a little.
I don't think that the zero collision box specified is any different from the not-specified collision box, I believe the problem is somewhere else.

I also tried to set the tile_width property to 1, and it was aligned again.

The tile_width, tile_height are by default calculated from the collision mask (ceiled values of width/height of the collision mask), these are used to calculate the snap to grid logic.
When the width/height is even, that coordinate is snapped to the edges of the tile, when it is odd, it is snapped to the center.

When the tile_width/tile_height is specified explicitly, it overwrites the computation from the collision mask.

[Kikkers]

It still seems to be something else. I'm trying everything on the smart accumulator (an accumulator with a smart chest in about the same tile, the smart chest part is shifted), and neither setting tile_width or collision_box seems to do anything. Grandted, the way I'm doing some of the stuff in this mod is borderline hacking.

I am getting the impression that we'd be better off if I just patched the mod. It might be too specific, it doesn't seem that other mods have similar issues. And there doesn't seem anything that I can't fix from my end anyway.