-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store the updatable updater as any asset, the downloaded one just being a chainloader #50
Comments
Note that I'm not very happy with the Windows' updater asking for privilege elevation at startup because it's default installation directory is in |
Here is a flow diagram of what I think how the updater must behave: You can click on the picture to see SVG in full size, you can find dia source there. Note that I did this diagram before @DolceTriade answered to my question about “when does the udpater updates itself”. I'm not against redoing the diagram to adapt to the current behavior which is: the updater silently updates itself at startup, “when the splash screen is showing prior to the main screen showing”, except I'm not sure we can fix the chicken and egg problem from needing the main screen to configure the home path hence the engine dir. In this diagram the Note that this flow requires some command lines to be implemented, some command line I would like to see implemented in any way. This is also thought in a way the updater is the launcher, and act as the game binary, the engine just being a component spawned by the launcher, so the launcher is expected to be started by protocol handlers and start menu entries, being at least able to pass proto://addr urls to engine. |
It looks like that “updating at splash time” is only meaningful when self-replacing is expected to work on randomly downloaded updaters, but as soon as the self-replacement occurs on the updater stored in I also think that to be able to properly store the downloaded updater, we may store in the json file depicted in #46 the path to updater binary in distributed zip so the |
Nice flowchart :) Instead of assuming some hard-coded path for One perverse consequence of the diagrammed flow is that if you download a new version of the updater and run it, but there is an old version already installed, the new version would launch the old version. Perhaps we could do this instead: If the running updater's binary is not located in the selected installation directory (or one has never been selected), it prompts the user to select an installation directory and moves itself to the selected directory. |
Oh yes, nice catch! I would avoid implementing more windows. Many we can just check if installed updater is older than the one running it, if yes then display the usual main window and when people clicks on download button, the updater is copied if downloadable is not newer, downloaded if copy fail, or the updater continue the process if either copy and download fail (basically an updater started from a zip on windows while being disconnected from the Internet). |
Sorry if I was not clear, the hard-coded path for |
Yeah, I am not suggesting any new UI. What I meant was that if the updater's directory is different from the one in settings, it should act like a new install, and give the user the chance to change options before doing further actions. |
Updater in installation directory is implemented now, although not exactly as in the flowchart. Copying to the installation directory occurs during the game installation step. Self-updates are always in-place, regardless of where the updater is stored. When the updater relaunches itself, it is always from the same path. |
Original comment from #49 (comment)
For the next sentences I'll assume Linux (we would adapt for other OS):
Basically what I think is that the updater would install itself as
~/.local/share/unvanquished/base/updater
at first launch and then run it and close the parent, and of course that path would be the updater to update in priority, and every time the original updater is started, whatever it is stored, it would start the one in~/.local/share/unvanquished/base
before doing anything else. Autogenerated shortcuts would point to the updater in that path, not the randomly downloaded one.We may also try to replace the binary that is stored in the wild, but even if we fail to, that would not be a problem, starting an old updater will load the newer one even before trying to update.
That would fix the started-from-zip issue (#49) at the same time.
The text was updated successfully, but these errors were encountered: