Hello! Thank you for the feedback. First of all, enclosed is your fixed save. Second - your enclosed .log file seems odd - are you sure it is log file corresponding with crash-on-load of your save? I got very different log. Also, the loading the save resulted in crash in both 1.1.32 and 1.1.33, so i...

Thank you for reporting this. In the saves from the desync, you are already in the tank, leaving and reentering did not cause desync for me. Could you confirm that after server+factorio restart you still get desynced? If you could provide some additional saves before the desync, it might help. So fa...

Thank you for feedback. The save you have provided works fine for me. Could you specify What you did (and what happened) between the time of saving and the crash? And does it happen persistently or only once?

Thank you for the feedback. Issue should be fixed as of 1.1.33. The reason was issue with cloneArea function used by some mods where ghosts placed on top of existing entities (like your save, where there where pipes marked to be deconstructed under the pole ghost) would be not cloned. In case of gho...

Senpai1337 wrote: ↑

Tue Apr 13, 2021 3:12 pm

...

Thanks for the clarification.

Do you happen to have a save or up-to-date server up, where this could be replicated?

So far i have been unable to replroduce the desync in either setting. Until someone provides save or other way for me to reproduce the desync, I am moving this to pending.

Chukles wrote: ↑

Sun Apr 04, 2021 9:46 pm

...
Edit: Upon further testing, we discovered that it does not desync when we go through power recovery in our smaller, nuclear powered north base.

What do you mean by that?

I have rewired that factory, however desync did not occurr. When you will be able to, please, get me a save of a state that would crash the next morning.

Moving this to pending until save game is provided

It was directed to whomever has useful save

Would you please include last successful save before the desync occurred?

Upon further investigation, it turned out Rseding was correct - the status is there, because it would like more iron plates at the moment. Moving the thread to "not a bug".

Without further exploration i guess this might be distantly related with 96457 that I am working on. I noticed that the logic for showing inserter status message expects that the inserter is stopped "for a good reason", if it is just not woken up yet, the messages get wonky.

Hello! Thank you for your feedback. So far I have just superficially looked over the issue and here are some points. a) As the error suggests, it is caused by having copper connections in ElectricPole in "wrong order", specifically actual connection after nulls. This is (for numerous reaso...

Thank you for the feedback.

This was not the case in 1.1.8, so it is probably result from the recent refactor ... anyway, we are looking into it.

Hello! Thank you for the feedback. I have loaded and run you save for several minutes and I couldn't reproduce any issue with saving. The crash seems related to electric networks, are you aware of any action you took since last succesfull save that could produce an unusual state of poles/electricSwi...

Also, from you description it seems that your (hosting) friend's save attempt was successful? If yes, could you also include that save file? Also, as kovarex said, the crash is caused by attempting to save an inconsistent state, so if your friend's save was successful, the inconsistency must have oc...

Thank you for the feedback. The linked issue has been fixed (as of 1.1.13), so hopefully the cause of your issue has also been fixed. If you experience this again after 1.1.13 is out, please let us know. In the meantime, i am marking this as resolved.

The log file seems similar to 94524.

the log file is ok, what i would like is the save file (for example last autosave that did not crash).