Open EphDoering opened 10 months ago
I can confirm I've never been able to get it to work (at least, not programatically -- you can manually run Factorio in update mode if you tell the updater to leave the files, but you will still face the problem of Factorio auto-starting after each update). It's either something relating to the windowing/rendering system (SDL2/Allegro), or just a specific (intended) behavior that is ellided in the headless version. I suspect (but can't confirm) the same would happen with a graphical Linux build. My theory is that Factorio with a UI has this particular behavior because the player who just launched the update wants to get back to the game -- not to have to launch it again.
Using the updater for non-headless updates is really not an intended use case (graphical Factorio already has a perfectly fine self-updater), so I have no particular ideas to help. I once had the idea that on a completely offline machine one could fake the Factorio website by providing a simple web service with the appropriate JSON endpoints, in which case you would want to also have the binaries handy. But realistically, the updater is only intended to work with headless Factorio.
Oh, interesting. Thanks for your insight! I think I got around the GUI launching issue by requesting the download with the isTarget=false parameter from /updater/get-download rather than /get-download-link, but I also downloaded all the updates first, then updated in one command. That allowed for only one UAC prompt. I wonder if the final gui launch control and/or the are-there-more-updates control are easily editable within the update zip.
In any case, I think Factorio has to use the updater slave on windows because on windows you can't overwrite a running executable, so I think it creates a temporary executable updater slave and then executes that to overwrite the main executable. On linux you can rename/ copy over a running executable without any issues so they might not use an update slave on linux at all.
Indeed, I just tested out my update script on the Linux GUI version and it doesn't use the update slave so it worked without the race condition issue. It also didn't start up the GUI afterwards, but I guess the command line version with --apply-update should never have to start the GUI back up since when doing an update from the GUI on Linux the GUI never even has to shut down.
Anyway, the checksums of the win64 updates downloaded with isTarget as true and false were identical, so I guess I'm as lost as I was to start.
I think Factorio has to use the updater slave on windows because on windows you can't overwrite a running executable
I think you must be right, that makes perfect sense.
the checksums of the win64 updates downloaded with isTarget as true and false were identical
Wasn't expecting that, what does the parameter even do then? Maybe it's actually just for analytics? I would've expected at least a config file to be different.
On windows when you run Factorio with the updater, it seems to relaunch itself:
When that happens for me, my subprocess.check_output call returns, while the updater slave continues to try to do it's work. Unfortunately, when the cleanup happens after the main Factorio process exits, it then makes the update unavailable to the updater slave.
I was wondering if you'd experienced this issue yourself?