Skip to content
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

Feedback on 982b53b. #30

Closed
10 of 15 tasks
Viech opened this issue Feb 25, 2015 · 5 comments
Closed
10 of 15 tasks

Feedback on 982b53b. #30

Viech opened this issue Feb 25, 2015 · 5 comments

Comments

@Viech
Copy link
Member

Viech commented Feb 25, 2015

  • There needs to be a guaranteed-to-be-writable default install location for every OS. For Linux (and maybe also Mac) it should be somewhere in ~ (check the Posix/XDG/etc. standards, maybe ~/.local/share is the correct location but I'm not sure), for Windows use whatever steam uses for downloaded games, etc. That default needs to be displayed in the first-start install-selection textbox.
  • Changing the install location in the menu doesn't trigger any direct reaction, only after restarting the updater there is a reaction.
  • The reaction to changing the install location via the menu currently is that the old install location is abandoned and the game is re-downloaded to the new location. The desired behaviour for changing an installation directory should definitely include asking the user whether they want to move the old installation over. If the option can be changed during a running/paused update this means that the updater has to behave accordingly.
  • There currently is no error for when the selected download directory is not writable. For windows, installing to the system's location for programs may be desired by users, which requires admin privileges. Only allow/implement this if the launcher can maintain these privileges over multiple executions and reboots, so that it doesn't re-request privileges every startup (I'd say it's still fine for actual updates only).
  • You could actually circumvent all the points above by just dictating the install location, which is what some other launchers do iirc. It would be sufficient as an option if you could change the install directory via a command line parameter only (which is stored to configuration just like now though). In that case it's fine if it's also the user's obligation to move any content before re-executing the launcher with a new install location.
  • The launcher should have an uninstall option, in case the isntallation isn't properly registered with the OS which would handle the de-installation instead (which it isn't, atleast not for Linux). This is probably as easy as deleting all downloaded data after asking for confirmation.
  • The launcher doesn't need a Quit button. What it does need is a Play button which also replaces the Update button. To be precise, the Update button as such isn't needed either as launching the launcher means that you want to (update and) play the game in as few clicks as possible. Thus, all that is needed is a Play button that is greyed out while an update is being downloaded or looked for.
  • If you insist on a pause button, integrate it into the Play button, too. It would have three states: Play (greyed out), Pause/Resume (during update), Play (launches game). Looking at other launchers, I don't see many pause buttons for the same reason as above: Either you want to update and launch the game or you don't.
  • When the updater fails to look for a new update (e.g. no internet connection), the Play button should become available anyway after a few seconds. This should print a warning as the text of the download bar ("Failed to update").
  • Use the download bar to print the subset of the log messages that is interesting to the user: "Looking for update" (while downloading the .torrent and then doing a fast-verification), "Verifying installation" (in case of a necessary or requested non-fast-verification), "Downloading (n%)", "Up to date", "Failed to update". The log should be printed to the console only, if at all (maybe add a --debug switch). We can use the space you currently print the log to later for news and changelogs.
  • The menu should offer the in-depth verification (re-checksuming) of the installation, similiar to how it's done in torrent clients.
  • The menu could offer a download and upload speed limit setting. A drop down menu with "unlimited" and a few options (a range/selection of powers of two) is sufficient.
  • The launcher should create desktop icons on all operating systems for both the launcher (see next point) and Unvanquished itself. Atleast do the latter for now.
  • The latest version of the launcher needs to be shipped inside the binary packages of the torrent (prefered) or the launcher needs to copy itself to the installation directory for the last point to be possible (not prefered, as the launcher is never updated that way but maybe worth an intermediate solution). Some launchers would even re-launch themselves after replacing their own binary. We need a self-updatig launcher in the long run for stability, so it's best to figure out a good strategy now.
  • If the launcher is shipped as part of the torrent as explained above, the (default) install location should be the directory it is launched from. Detect this, for example by looking for the binaries or at a prioritized config file that would be part of the torrent, too. This allows users who downlaoded the torrent or zip once (or got it on a flashdrive) to update it, which is an extremely cool feature for very little effort!
@DolceTriade
Copy link
Member

Default install dir

This is the directory it is launched from. I will prepopulate it in the install box.

Changing the install location in the menu doesn't trigger any direct reaction, only after restarting the updater there is a reaction.

I haven't seen this in my tests. Could you explain how to reproduce this further, perhaps in a separate issue?

Changing install location and moving content

You cannot change the install location mid download. The prompting to move the stuff for them seems like something that I wouldn't target for the initial alpha release.

Feedback when not writable

There is feedback (a very generic error message), but it could be better. I will fix this.

Admin prompt on windows

I get an admin prompt on windows to run the app. I haven't tried writing to a system location (ie, Program Files). I will fix it if it errors out.

Force install location and allow changing it via command line only

Maybe once we're stable. During alpha, I think it is a bad idea for users to not be clear where the game is installed.

Uninstaller

Yep, TODO

Launcher part of the updater

TODO. I wasn't targeting it for the initial release. I wanted to get the download and updater part down first.

Merge buttons

Good idea.

Download bar to print messages

While the updater is still in development, I think seeing a download history is good so the user can help me debug issues. In the future, I think this is a good idea. The top area will instead be for news and such.

Re-checksuming

The updater does this if you press updater. I could add a menu option for this, but it would basically do the same thing as updating.

Rate limiting

Fairly simple, but I wanted to keep the options minimal. If you want to rate limit, pause it and start it again later. If it becomes a heavily requested feature, I can add it however.

Actually install (ie, desktop entries/start menu/registry/register handlers on linux/etc)

TODO, definitely not for this release, but will be there in future releases.

Shipping with the torrent

Yes, but not until its a little further along.

yo dawg I heard you want to update your updater so you can update while you update

Yeah. Problem is on Windows, you cannot overwrite a running application, so I think the best solution would be an updater updater...

@Viech
Copy link
Member Author

Viech commented Feb 25, 2015

Default install dir

This is the directory it is launched from. I will prepopulate it in the install box.

No, installations shouldn't go to where you download files to, they should go to the locations that are standardized for user-privilege installations, i.e. to ~/.local/share/Unvanquished/ under linux or wherever steam and unprivileged game launchers install games under windows. If you run any launcher for a game released on linux it won't drop the game to ~/Downloads/ either. This is simply nonstandard and purpose-defeating behaviour for a launcher that manages your game installation, not a small area of your messed up, purged-once-in-a-while downloads folder.

Changing the install location in the menu doesn't trigger any direct reaction, only after restarting the updater there is a reaction.

I haven't seen this in my tests. Could you explain how to reproduce this further, perhaps in a separate issue?

I will when I get around to that.

Feedback when not writable

There is feedback (a very generic error message), but it could be better. I will fix this.

The generic error message doesn't catch an existing non-writable folder under linux. Try with /root.

Re-checksuming

The updater does this if you press updater. I could add a menu option for this, but it would basically do the same thing as updating.

There are two types of verification for torrents. One is fast and probably looks at file modification timers to not re-checksum the entire download again (I don't know the exact method though, timers is juts a guess). That's the one you correctly use whenever the launcher checks for updates. The other is a complete re-checksuming of the entire download to look for broken files, which can take a long time. I'm not sure when this is necessary (i.e. what errors aren't catched by the fast approach) but every torrent client offers this option and I wouldn't be surprised if existing launchers offer this too for similiar reasons. I know that steam has this option.

yo dawg I heard you want to update your updater so you can update while you update

Yeah. Problem is on Windows, you cannot overwrite a running application, so I think the best solution would be an updater updater...

Can you maybe fork and disown a process that does this, then starts the new binary? I think there must be some way to achieve that "your application has updated and needs to be restarted now" effect. I mean, if not on Windows where else?

Rate limiting

Fairly simple, but I wanted to keep the options minimal. If you want to rate limit, pause it and start it again later. If it becomes a heavily requested feature, I can add it however.

I'm fine with both a pause button and a rate limit. I'm pretty sure most proprietary launchers don't even bother to implement either. If a user is on a really low bandwith link, a pause button doesn't do anything for them as they just want to be able to watch videos/play games/etc. during their mutliple hour download. It's merely the "Can you stop downloading, I'm ingame for another ten minutes!" situation where a pause button makes any sense but even then a rate limit does the trick as well. Both are kind of optional in my opionion but the limit is certainly more powerful.

@Viech
Copy link
Member Author

Viech commented Jun 7, 2015

Unticked

Changing the install location in the menu doesn't trigger any direct reaction, only after restarting the updater there is a reaction.

as it isn't actually implemented. Note that changing the download location doesn't even trigger a re-download on next launch, you would need to hit the verify button. (Quick verification on startup by timestamp or so doesn't seem to be implemented yet?)

@Viech
Copy link
Member Author

Viech commented Jun 7, 2015

It doesn't even continue an unfinished download anymore. It just tells you the game was up to date…

@slipher
Copy link
Contributor

slipher commented Apr 23, 2024

The menu could offer a download and upload speed limit setting. A drop down menu with "unlimited" and a few options (a range/selection of powers of two) is sufficient.

I don't recall ever seeing this in any other installer, so I think we are doing well enough by having a "Pause" button. This should be sufficient if you are in a video call or something and need to stop the updater to free up bandwidth.

Other remaining items have been moved to dedicated issues.

@slipher slipher closed this as completed Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants