I am going to move this to Duplicates due to https://forums.factorio.com/97568 but it could also go to Not a bug (because there is no explicit guarantee that rounding of coordinates for MapPosition and build position function are equal) or Wont fix (because changes here have a really high possibilit...

This topic is not as simple to call it a bug based on what you are describing. It is simillar to https://forums.factorio.com/97568 because there are actually 2 layers of rounding: first layer of rounding happens when values from lua are converted to MapPosition (where coordinates are fixed points wi...

Car's control (CarPrototype::tank_driving = false) and Tank's control (CarPrototype::tank_driving = true) are 2 different control schemes and they cannot be merged because they are inherently different. Tanks are able to rotate in place without moving. That means rotation is as following: - when v >...

The "good inserter syncing" was an artifact of the inserter to underground belt being slower by 1 tick: when inserter needs 43 ticks to dump 8 items onto a blue underground belt that gives you a throughput of 22.325 items/second and there will be a tiny gap after each burst of 16 items. Th...

I think this may be slightly more digestable image: 104104-c.png Here in case of the undergrounds going south or east, you may see that inserter that is trying to insert closer to the open end of the underground belt is actually inserting item in the middle, where the inserter that is trying to inse...

Issue is heavily based on how the item insertion specification function was implemented compared to insertion function for other transport belt connectables: other entities (except of linked belt which was also affected) are using transport belt connectable's center position so if inserter tries to ...

Thanks for the report. Issue is now fixed for 1.1.73. Insertion of items on underground belts that are facing south or east will now behave consistently with other directions, which means at stack size of 8 you will get gaps consistently at all directions.

Ok i see where the issue is, the item insertion specification is incorrect for underground belts that are going South or East.

I see no issues here. All inserters here are dropping items on the right transport line, which is on the west side when belt goes south.

-- edit:

Hm... i think most likely i misread the bug report. Let me reanalize it

1.1.70 is current stable version and 1.1.71 is current experimental version. The best solution for you would be to simply use 1.1.71 where this provided save file simply loads fine. If you are using steam you should be able to select experimental branch in the beta settings. Why did you switch game ...

There is no point in this discussion before 1.2 release since by that time there may be other ways of managing trains that do not require disabling train stops. Locking topic.

I did a quick attempt at trying to fix this save file (it was basically to discard all military targets data and rebuild them from scratch) and it seems to load correctly, but i had to go through a load-save cycle and it is possible some of the mods may be at wrong versions. I will have to investiga...

Thanks for the report. I am not seeing any crashes here so this is not a bug. Poor performance cannot be considered as a bug unless it would be a regression. Here it is one of those "player does weird things, gets weird results" things. Under the profiler i see the code spends 85% trying t...

From the internal logic of loading save files, on_configuration_changed will be raised for all mods any time any part of the game version is changed, this includes main, major, minor and developer part of the save file format version field. This is because on_configuration_changed will raise every t...

Signals will automatically try to connect to rails when they are created. Only things you need to take care of is for the position to be exactly on a tile center, direction to be correct and to not have signals on an adjacent tile in the direction of a signal.

Your signals have incorrect direction.

Thanks for the report. This issue was already fixed for 1.2 in a lot more generic and clean way so i had to decide if i even want to fix this in 1.1.x as well, but given a temporary fix has only 4 lines of code it is now also fixed for 1.1.71.

Yes, that would be fully expected. If there are two stops (same) name with a limit of 1 each, two trains will go. If one station gets disabled one train will go and the other will stop dead where it is - usually on the main track. That is the issue. I do not care about this case anymore. Train stop...

Thanks for the report. Issue is now fixed for 1.1.70. I was able to reproduce the issue using a UnitGroup with a BuildBase command set since the biter that was a member of this unit group had a distraction that allowed it to go away of the group while not preventing the UnitGroup from finishing its ...

Looking into the desync report i only see differences related to Rampant's units.

Could you provide a save file in which the issue is happening?