I am not considering this to be a bug. Its always possible to insert modules when assembler has other or no recipe set, when modules are already inserted to one machine its possible to make a copy with a blueprint and let construction robots do the rest. Moving to ideas and suggestions.

Thanks for the report. Issue is now fixed for 1.1.77. Core of the problem is related to changing force of a linked-belt. There will be also more logging in case another "transport line groups are not consistent" error would show up.

I guess i will just implement more verbose consistency check for transport lines. In 1.1.77 it will print some extra details to the log file if such issue happens. Using the hint about merge_forces i found that merging force "Bierman_UA" into "neutral" force causes the consistenc...

Core of the problem is due to `bounding_box` you are giving to the request_path. LuaEntity::bounding_box gives you a bounding box which is centered around the entity's position and that is most likely far away from the {0,0} position. The request_path needs a bounding_box which is centered at {0,0} ...

No. 104337

..., but why is the search for selection boxes implemented using collision boxes? Entities are registering on the surface based on their collision boxes because entity collisions is the most common case where entity searches are required. Selection is less common use case so if possible we try to r...

This is related to how entity selection in 1.1.x is implemented. Entity selection is searching for entities using entity searches which are based on collision boxes. Area with entities is based on the cursor position, around which a box with radius of 2 tiles is expanded and it is further expanded t...

Modding Added LoaderPrototype::allow_rail_interaction and allow_container_interaction. Interesting, especially the "rail interaction" part. Any details/docs? Does "containers" also include non-container entities with an inventory, e.g. crafting machines? When did native loaders ...

Its not a function call so it does not store result of the function call. It stores reference to a function itself.

Thanks for the report. I see this issue was already fixed for 1.2.0 and because i am considering this to be minor issue i do not want to fix that in 1.1.x due to possible merge conflicts (that fix would be basically a temporary fix for 1.1.x only).

Thanks for the report. Issue is now fixed for 1.1.75. There was an incorrect surface check when rendering train lights that was filtering for a player's surface instead of the preview-provided surface. Btw when reporting please make bug reports more helpful. I remember there was already similar issu...

I am moving this bug report to "1/0 magic". For 1.1.75 i have added some extra consistency checks related to loading save files with this type of corruption (fluidbox connection pointing to another fluidbox connection that is already connected to something else) but i was unable to reprodu...

Ok i see where the issue comes from. You are quite right with narrowing where the issue is. On the image below, the pipe-to-ground "A" thinks it is connected to pipe "B", however that connection of pipe "B" reports as being connected to chemical plant "C". You...

I will take a look at why this save file reports as consistent while making this bug to appear, however when loading this save file with prototype changed mode (by holding control key while pressing the green "load" button) the fluid systems are rebuilt from scratch and i cannot reproduce ...

This is not a bug. Artillery is not shooting "to discover area" but it is shooting to kill enemies. When a chunk is not yet generated (pollution will generate chunks, radars will generate chunks) or it is at one of the generation stages where it has no entities yet, artillery will not shoo...

It is defined in data stage but then connections are requested in the control stage. Just to make sure there is no confusion here: its not making multiple fluidboxes shared (having single fluid storage), it is just a third type of connection (so there are normal connections, underground connections ...

This is now fixed for 1.2.0. Assembling machine in a blueprint (in gui) and in a blueprint preview (while holding cursor with blueprint over terrain) will only show fluidbox connections which are used by the current recipe.

Implemented for 1.2.0. Its not implemented as linked pipes but as a linked fluidbox connections which means any fluidbox of any entity will have the ability to be defined as linked and connect to other fluidboxes as long as they also have linked connection and belong to a different entity.

Implemented for 1.1.75 as LuaRailPath::is_front, because in the end this is the important bit which prevents setting speed of wrong sign (the train would be going back on the path, extending remaining path instead of consuming it). When is_front = true, speed must be >= 0, and when is_front = false,...

Thanks for the report.

This feature is now implemented for 1.2: ghost pipes will correctly connect to each other.