Basic selection and updating of the selected server has been added. There are a few subtle mechanics which need to be added still, such as keybind shortcuts (enter to submit, etc). In addition, functionality still needs to be added to generate the list of servers from the manifest file.
Fixed a minor issue with the login view.
Updated play button styles.
Updated dependencies.
The temporary span which displayed the selected server has been changed to a button. Clicking this button will open the server selection view. The server selection view is still pending full implementation.
Added warning message when console is opened, this is in preparation for alpha.
Added a new background image. Restored random backgrounds on launch (for now).
Changed the overlay dismiss/cancel buttons from anchors to buttons.
Moved server selection styles to launcher.css, as they are nearly finished.
Moved overlay convenience functions to overlay.js.
Moved launch area (landing.ejs) convenience functions to landing.js.
Various cleanups and documentation also added.
Moved landing.ejs specific scripts to a dedicated file. General cleanup for other script files. Need to examine the remaining code in actionbinder.js to determine the most logical place for it.
The player count on the landing page is now functional. If the server cannot be reached, the label and value will change to SERVER and OFFLINE, respectively. This behavior can be modified.
Temp folder is deleted when minecraft is closed. If the Node.js process ends abruptly, the folder will not delete. As a dirty way to counter this, the directory we extract native files to is cleaned in the preloader. Maybe we'll come up with a more elegant solution in the future.
You will be given an option to install Java manually. Selecting this will bring you to a final prompt which gives some useful information about installing Java and where you can find help. You have two options on this prompt. The first is to simply aknowledge it, which will dismiss it. The second is to go back to the first prompt.
The darwin frame is the same as the original, however the button behavior is corrected. The win32 frame uses the traditional buttons found on windows. Also added a small logo image to the windows frame. Each frame is dynamically loaded on startup via ejs.
Also disabled the server selection test UI.
When a user attemps to launch, the configured Java executable will be validated. If it is invalid, we will look for a valid installation. If no valid installation is found, the user will be prompted with an option to install Java. An option to decline needs to be added. If they choose to install, it will download, extract, and update the executable in the config. The game will then be launched.
Also added progress tracking for asset validations, as they can potentially take a bit longer. Showing progress assures the user that the program isn't stuck or broken.
Fixed an issue with concurrency when there are no downloads queued on launch. Added support for static function execution in AssetExec. Fixed a binding issue in uicore.js caused by delayed div loading. For now the solution is just hard coding in the value, will probably switch these two a css file later on. Included the launcher's x64 runtime directory in Java scans.
Separate views are stored in an ejs file. When the app starts, each file will be loaded, with the DOM elements hidden. Based on the state of the application, a specific view will be fadded in. Switching between views will use this principle.
Moved contents of index.ejs to landing.ejs to make it compatible with the new format. As a result, index.ejs is deprecated and will be removed once it is no longer needed for reference.
Mojang fallback cannot be implemented due to limitations of decompressing large lzma files in node.js. This can probably be worked around by packaging with some command line binary, but it honestly it not worth it.
Static utility functions have been moved. Functions which handle Java downloads will be moved next. AssetGuard is becoming a lengthy file, to cope with this I've added region comments so that specific sections can be collapsed and expanded when needed.
Possible paths are pulled from the registry and JAVA_HOME. These are sorted by version and whether they point to a JRE or JDK. Each path will be validated using an experimental option which yields the arch of the binary. The first one to be validated will be selected and returned.
