After the recent Factorio upgrade to 1.0.0 I get the following error:

The mod Autodrive (0.2.7) caused a non-recoverable error.
Please report this error to the mod author.

Error while running event autodrive::on_configuration_changed
LuaEntity API call when LuaEntity was invalid.
stack traceback:
autodrive/control.lua:362: in function 'gui_car_publish'
autodrive/control.lua:3154: in function <autodrive/control.lua:3132>
stack traceback:
[C]: in function 'index'
__autodrive/control.lua:362: in function 'gui_car_publish'
autodrive/control.lua:3154: in function <autodrive/control.lua:3132>

I'll have a look. Incidentally, I'm just working on Autodrive again anyway. It's time for the long-delayed update… :-)

I think I've already fixed that before your report. It doesn't seem to be a problem of Factorio 1.0, the crash happened because a mod providing a vehicle has been removed.

Anyway, check out version 0.2.8, please!

The latest version 0.2.8 desyncs multiplayer client right after joining. That is:
- server loads the game ok, and the server player appears
- server sets the game to pause (to decrease sync data)
- client joins ok and appears on the screen
- server cancels pause
- desync happens
This persisted when swapping client and server.

I have tried this few times. Then I rolled back to 0.2.7, and the desync is gone. When swapping client and server the desync is gone too.

I don't know how to debug this =(

The latest version 0.2.8 desyncs multiplayer client right after joining.

Wouldn't you know it: the only thing I didn't test this time was multiplayer mode … :-(

I don't know how to debug this =(

I've a pretty good idea what causes this. A fix should be ready by tomorrow at the latest.

Please try 0.1.29/0.2.9!

The game no longer crashes, but instead the mod now suggests me to install GCKI each time I load a save. But I do have GCKI installed....

Oh, what the… The plan was it would do that at most 3 times per game and player! Some more stupid mistake?

I suppose your version of GCKI is >0.17.14, too. I wonder what's happening there. I'll send you a small mod on the forum that will activate heavy logging. Could you add this, load the game again, and send me the log file?

I believe, we are stressing different things. The message seems to have disappeared after 3 times. But it should had not appeared at all, since I do have GCKI installed already. But I shall post the debug log at the forum within half an hour

Please try 0.1.30/0.2.10! :-)

I just experienced a desync caused by this mod on loading. It seems to be related to the AUTODRIVE-misc.no_GCKI message as seen in this desync comparison:

Sorry, this is more or less gibberish to me -- I haven't been able to make sense of any desync reports yet. I see that the Autodrive string is mentioned in the upper pane at the bottom of the picture, and Picker Dollies at the other. Yes, that looks different, so it could be a desync, but how, why, and where I couldn't tell.

In the upper part of the picture, I've found references to some other mods: Helmod, Vehicle Snap, Wind Power. Apart from that, the screenshot unfortunately doesn't help me at all. A saved game that I could use to reproduce the desync would be far better! Could well be related to interaction with a mod I didn't have installed during testing.

However, I can show you something else:

$ find . -type f -exec grep -Hn "no_GCKI" {} \;
./control.lua.original:112:      log({"AUTODRIVE-misc.no_GCKI"})
./control.lua.original:113:      game.print({"AUTODRIVE-misc.no_GCKI"}, {r = 1, a=.1})
./locale/en/messages.cfg:55:no_GCKI=The mod "Gizmos Car Keys (improved)" (GCKI) complements "Autodrive". It's recommended (but not necessary) to use both mods!
./locale/ru/autodrive.cfg:46:no_GCKI=Мод "Автопилот" хорошо сочетается с модом "Gizmos Car Keys (improved)" (GCKI). Рекомендуется (но не требуется) использовать эти моды совместно.
./control.lua:119:    --~ vdebug({"AUTODRIVE-misc.no_GCKI"})
./control.lua:120:    --~ player.print({"AUTODRIVE-misc.no_GCKI"}, {r = 1, a=.1})
./control.lua:180:    vdebug({"AUTODRIVE-misc.no_GCKI"})
./control.lua:181:    player.print({"AUTODRIVE-misc.no_GCKI"}, {r = 1, a=.1})

You can neglect control.lua.original -- that's just a backup that's never run. The two lines below that are just the definitions of {"AUTODRIVE-misc.no_GCKI"} in the English and the Russian locale. That's no code that gets executed. The code in control.lua will get executed. But the first 2 lines (119, 120) are commented out. This leaves us with just two lines where the string is used (lines 180,181). I don't see anything obviously wrong there. Or could it be that "player.print" would cause desyncs? You could comment out lines 180/181 and see if that changes anything. If it does, that would indicate that Autodrive may be in some way involved -- if not, I'm tempted to say there's another mod that causes the desync.

Sorry, I know this isn't really helpful, but that's all I can tell you at the moment …

Well I'm a modder too and can tell you that player.print desyncs in multiplayer if not all players receive the same message. Either iterate through all players or use game.print which broadcasts it to all players.

The desync reports are quite hard to understand I don't follow them myself fully either however I know enough that it can give me an indication and judging by the removal of the mod causing the save to no longer desync I'm quite positive that my judgement is spot on.

If you still need a save that demonstrates the desync then ask again though I believe the culprit has been found ;)

Well I'm a modder too and can tell you that player.print desyncs in multiplayer if not all players receive the same message. Either iterate through all players or use game.print which broadcasts it to all players.

Yep, you're right … I tested that nagging function pretty thoroughly, and if I remember correctly I also did it in a local MP environment (with Factorio running from 2 accounts on the same computer, so it wouldn't have been anything like a real game). I wonder why it didn't trigger there … Also, I believe there was a reason that I used "player.print" instead of "game.print". Could be related to preventing on_load from choking on trying to access "game", then changing something later on …

The desync reports are quite hard to understand I don't follow them myself fully either however I know enough that it can give me an indication and judging by the removal of the mod causing the save to no longer desync I'm quite positive that my judgement is spot on.

Could you recommend some guide for how to use and interpret desync reports? I guess they must be useful, but so far I haven't seen any documentation yet, so I've always ignored them and tried other ways to identify the cause of desyncs. :-)

If you still need a save that demonstrates the desync then ask again though I believe the culprit has been found ;)

I don't think I still need a save file … But I won't be able to fix that right away (already working on a fix for another mod at the moment, and I should really finish that before turning to something else). So, for now, could the people who use Autodrive in multiplayer mode please fix the bug locally? Commenting out line 181 of control.lua (put 2 dashes at the beginning: "--") or deleting it should be all it takes!

I don't know if there is a guide to desync reports really ... However there is https://wiki.factorio.com/Desynchronization and https://wiki.factorio.com/Tutorial:Modding_tutorial/Gangsir#Multiplayer_and_desyncs that talk about it.

Desync reports are essentially two saves where the server (or host) and client differ in a checksum of the game state. What I use to see the data differences is WinMerge (which is free and open source) and allows you to do a folder comparison even with binary files. As with a lot of opensource stuff the UI is a bit clunky but it works good enough to see the differences between the saves.

This is just the tools though seeing the differences is what you are after (I don't of the top of my head know a linux tool that does binary diffs across entire folders).

Once you can see the differences you can start finding what the actual differences are. this can be a nightmare as one tiny change ripples through the game and causes many things the differ over time. However in this specific case it was reasonably easy to spot as the heuristics report already shows major differences in the chat lines.

Usually though I find differences in script.dat file which is the storage location of all serialized mod data. I tend to search for identifiable variable names in the differences and then look through the mods to see if I find something that is known to be wrong (see second link above). This is a hit and miss method though and can be hard to actually pinpoint what is the cause and what is an effect.

Desync reports are very annoying and are easier if the saves are small. For instance the world that exposed this desync for me is too large to do a full binary comparison in winmerge but I managed to pinpoint it nonetheless with the smaller files.

As a complete side note ... stop putting nagware in your mods :P

I don't know if there is a guide to desync reports really ... However there is https://wiki.factorio.com/Desynchronization and https://wiki.factorio.com/Tutorial:Modding_tutorial/Gangsir#Multiplayer_and_desyncs that talk about it.

Desync reports are essentially two saves where the server (or host) and client differ in a checksum of the game state. What I use to see the data differences is WinMerge (which is free and open source) and allows you to do a folder comparison even with binary files. As with a lot of opensource stuff the UI is a bit clunky but it works good enough to see the differences between the saves.

Thanks for the links! I've read through Gangsir's tutorial several times in the past, of course, but must have skipped parts of the desyncing stuff because it still was a bit over my head in the beginning, but as a late-comer to the party, I hadn't seen the old FFF yet. It seems I should turn to use heavy mode for testing. :-)

This is just the tools though seeing the differences is what you are after (I don't of the top of my head know a linux tool that does binary diffs across entire folders).

I do use Linux, guess I'll need to start looking for a tool which does that. :-)

As a complete side note ... stop putting nagware in your mods :P

I would, if there was an easy way. I think I've already explained somewhere about the history: I've made GCKI and used it together with Autodrive in my game. As there were some things that interfered with my mod, I looked at Autodrive's code and made some adjustments in mine, so it made sense to add an Autodrive dependency to GCKI. After I've sent some patches to dorfl, I became collaborator on Autodrive, so I could fix things from both ends, and finally dorfl transferred Autodrive to me, and I've added a lot of code to both mods to ensure that they add to each other. Of course, they can still be used separately (if GCKI is used with AAI Programmable Vehicles, using Autodrive in addition is pointless -- and some users of Autodrive think that using GCKI would be cheaty), so merging the mods doesn't make much sense. A dependency to direct attention to the other mod doesn't work either because that would introduce a circular dependency. So printing a short message on loading a game seemed like a good idea. That wouldn't be necessary, however, if the game had a more complex dependency system, with fields like "Provides" (I could use that for "minime" with its new character selector: setting the "Provide" field would allow other mods to fulfill a meta-dependency on "New Character", for example) or "Recommends" (just links to supported-but-not-required mods instead of a real dependency that should be loaded first). But I doubt we'll get this anytime soon, or even at all …