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

Fast bootstrapping of patches #36

Open
nmlgc opened this issue Oct 17, 2014 · 1 comment
Open

Fast bootstrapping of patches #36

nmlgc opened this issue Oct 17, 2014 · 1 comment

Comments

@nmlgc
Copy link
Contributor

nmlgc commented Oct 17, 2014

This would only download the most necessary data of each patch (game version data in particular) on initial patch selection, with the rest being only downloaded when needed (e.g. once a particular game has been located on a user's system).

In particular, this means:

  1. Only pull versions.js for every patch after stack configuration
  2. Use that to start searching for games
  3. Download any global patch data during the search process
  4. Create shortcuts
  5. Download/update the rest of each game's data individually after the user started a game through a shortcut, using a blocking downloader.
@nmlgc
Copy link
Contributor Author

nmlgc commented Nov 7, 2014

So I've been looking at the implementation of this, and it revealed a slight flaw in the current patch file structure: <game>.js and <game>.<build>.js are stored in the root directory of a patch. The patches themselves don't include a simple list of the games they support (and really, why should they), so determining the global and game-specific parts of a patch becomes slightly less trivial, as there is no way around building such a list internally by parsing through files.js.

If we are about to break backwards compatibility anyway, we should move these files into the subdirectories of the respective games (so that e.g. th14.v1.00b.js becomes th14/th14.v1.00b.js) for even faster bootstrapping. Then, global files are easily identified by the lack of a slash in their filename.

For now, I'll be implementing this feature as if that were the case. In a typical setup where only a single game is to be patched, this would still download 40-ish JSON files too many.

nmlgc added a commit that referenced this issue Nov 8, 2014
And that would be all of fast bootstrapping (#36) we can reasonably implement
without a GUI.

... except that it's not yet as fast as it could be, due to a slight flaw in
the current patch file structure: "<game>.js" and "<game>.<build>.js" are
stored in the root directory of a patch. The patches themselves don't include
a simple list of the games they support (and really, why should they), so
determining the global and game-specific parts of a patch becomes slightly
less trivial, as there is no way around building such a list internally by
parsing through files.js.

If we are about to break backwards compatibility anyway, we should move these
files into the subdirectories of the respective games (so that e.g.
"th14.v1.00b.js" becomes "th14/th14.v1.00b.js") for even faster bootstrapping.
Then, global files are easily identified by the lack of a slash in their
filename.

This implementation already pretends that this is the case. In a typical setup
where only a single game is to be patched, this would still download 40-ish
JSON files too many.
@nmlgc nmlgc removed their assignment Mar 16, 2019
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

1 participant