Most of the stuff you mentioned makes a lot of sense, however i am not sure i am willing to change current behavior. Current behavior is kind of a mash-up of something that can be implemented explicitly using 2 combinators: first doing [each]>0, output [each] (input count), and second combinator con...

Already exists. https://lua-api.factorio.com/latest/cla ... le_effects

No. For a feature that base game would never use but would have to pay the performance cost i am not accepting that. For an item to have durability it would need to have a data attached to it. So far modules have data attached to them but i already made them work without any item data so i am even m...

Thanks for the report. Issue is now fixed for 1.1.107.

This is minor enough and possibly mod breaking enough that i decided to fix this for 2.0.

This is fixed for 2.0.

Thanks for the report. Issue is now fixed for 1.1.107. There is a shortcut in the story that was supposed to trigger when instead of setting quickbar you would place the mining drill but it was actually triggering when there was a stone furnace already on the surface. It went one step too far forwar...

Thanks for the report. Issue is now fixed for 1.1.107

Ref 112709

This is suspicious, i managed to reproduce that exact issue by using standalone 1.1.100 that was updated using built in updater to 1.1.104, and at that point when i enabled experimental updates it failed to update to 1.1.106. By using fresh, standalone 1.1.104, enabling experimental updates it corre...

Thanks for the report however that is Not a bug. Signals are directional entities, they only connect to rails at specific side based on the signal direction. Since you are pasting signal with the West direction, it only binds to the rails above it (or when rotating a blueprint, on other sides). What...

Thanks for the report. Issue is now fixed for 2.0.

Thanks for the report. Issue here was that the underground building logic assumed that if belts between underground belt ends were straight they should get removed but that logic was slightly wrong as it could remove straight belts with side connections as well as showing what is reported here (on f...

Thanks for the report. I am considering this to be a Not a bug. If the grid position values would be required to be relative to the top left corner of all visible entities then if visible entities would change the grid position values would have to be adjusted. In this example when you selected blue...

Thanks for the report. I am not going to fix that issue in 1.1.x because pump logic is quite tricky to not cause performance problems. One of the operations in pump that is relatively expensive due to entity searches is search of fluid wagons so pump tries as much to not do those searches if not nec...

I am not considering this to be important to fix. Having this relative grid position be allowed to be out of core entity snapping would only have a cosmetic effect and tiny effects on the cursor position but it would not add any new behaviors or would not remove any existing behaviors. I will mark t...

Thanks for the report. Issue will be fixed in 2.0. Core of the issue is that blueprints in library are different objects than blueprints in inventory. When setting up that blueprint in library first a blueprint item is created but then it is cloned to blueprint record in the library. Common part of ...

Moving to translations.

Thanks for the report. I was able to reproduce the issue by watching the replay as well as reproduce it from scratch. It looks that replay considers first player as a local player so when first player left the game, blueprint library was disconnected from local player shelf and this caused another p...

Implemented for 1.1.106