-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
Comments
So I've been looking at the implementation of this, and it revealed a slight flaw in the current patch file structure: 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. 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. |
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.
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:
versions.js
for every patch after stack configurationThe text was updated successfully, but these errors were encountered: