[QoL] Improve update checking speed; fix minor bugs

[ahmouse15]

Cache file hashes to speedup update checking dee859c04b1b9e4bd0a5b851b830cdad9c881e04

This stores local TTR file hashes on disk, rather than being re-calculated at every login. This vastly improves TTR update check times when no update is needed, from around ~5 seconds to less than a second on my laptop; especially useful when opening multiple toons in a row. The only downside I could think of is that if files are somehow corrupted or deleted outside of the launcher, it won't automatically be fixed until another TTR update modifies that file. Let me know what you think about this.

Initialize ConfigHandler before Accounts 2c69b1bebdaf470a340e7536e00b741eda10c2fd

While building the previous commit, I ran into a small bug with out of order operations, where on first launch the attempt to create config/accounts.json happens before the config directory is created. This fixes it by initializing configHandler - which creates the directory - before its needed.

Check if Java version is greater than 17 rather than equal to 17 c052e883bc98c99bc942b14717b5d43202d416c0

The Linux java check only checked if the version was equal to 17 instead of greater than or equal to. Most distros use Java 17 so it worked, but I tried on a rolling release (Java 21) and ran into this.

On a side note, have you thought about implementing delta patching?

And also, thank you for adding me to the new About page!

[hyperdefined]

I've wanted to speed up the updater for a long time now, I just wasn't sure on how to do it properly (it was also written like 4+ years ago). I like this approach, but how do we tell the launcher to update the local cache? From what I see, there isn't a trigger to update the cache.

Maybe instead, we check updates once per launch? It will check on one toon, then will not check afterwards until the program restarts. Also, maybe load all the hashes first from the site, then compare instead of one by one?

The config issue was probably from https://github.com/hyperdefined/CustomLauncherRewrite/commit/663349bf84648a124c6d71440274917dc3ea317b.

I like changing the run.sh script to include 17 and above. I might update to a later LTS version soon. I really want to also redo the Linux part, since having that run.sh is kind of annoying, just not sure how else I could do it.

[ahmouse15]

Every time an update happens the cache is simply overwritten with the new hashes (while preserving files that didn't change), which are either taken from the patch manifest during the update, or manually generated if it hasn't been cached yet (which should only ever happen once). Besides that, there's no method to update the cache.

For what it's worth, storing hashes is what modern game launchers do, just a bit more sophisticated than what I've done. I'm mostly testing this for work on another launcher I'll be working on in the next few months (open source launcher for EA games). I do agree that checking updates once per session is sufficient to solve the multiple toons problem, however doing that alone without caching wouldn't benefit actual update checking time (which caching takes ~5 seconds off), so it just depends on whether you want the absolute fastest update time vs less things to maintain.

I'm no expert, but if you did want the absolute fastest update time, here are some other things I can think of:

• [ ] Fetching all hashes at once
• [ ] Caching of hashes
• [ ] Delta updates
• [ ] Multithreading (as simple as one download thread and one extracting thread could double performance)

I'm willing to implement any of those if you'd like, since I'll probably end up reusing part of it in the near future anyways.

Lastly, to replace run.sh, this clever solution allows you to combine a shell script with a jar to create a single Linux executable.

Also, do let me know if ever you don't want me to keep adding random things, since this is your project and I understand not wanting the codebase to end up too "foreign"

[hyperdefined]

I appreciate the help you've given so far, I'm just not that sophisticated on what the best practices are to achieve this. multithreading the updates would be a lot faster to start. I would have to see how the caching system work, I'm not against it at all.

Don't worry about the code being too foreign to me, I am more than happy to learn how it works.

[ahmouse15]

I'm going to scrap this implementation for now, and instead open an issue to discuss download improvements and properly keep track of changes. For now, checking for updates once per session would make multitoon logins much smoother, so I'll work on a PR for that shortly.