- Game/jvm arguments are now passed one-at-a-time, never grouped
- Added support for legacy version manifests by adding in the missing
arguments
- Correctly pull arguments from old manifests
- Some slightly hacky handling for old library stanzas
- Short-circuit if library URL has empty path to prevent accidentally
downloading HTML pages as jars
- Add launcherShortname prop, passed to --versionType
- Fix game arguments being missing from version manifest due to new format
- Update Runner to use more substitutions & support new argument model
- Move loader/installer libraries to their own section to avoid runtime conflicts
- Implement some basic feature matching for arguments
oh lord okay
- Update to new launchermeta endpoint for version manifests
- Fix library handling (libraries now seem to give us the URL most of the time)
- Write entire new system for handling the forge installer process
- Fix asset handling, mostly (still TODO is remove all traces of assetSource, it's given to us by launchermeta now)
If for any reason the document associated with a LimitLinesDocumentListener
ended up not getting shorter when its first line was removed (this is,
of course, impossible), sklauncher would wedge in a busy loop that
completely killed the GUI thread forever.
Solution, part #1: Don't do a while loop, just remove multiple lines
if you need to.
But wait, why are we having this problem at all? It turns out that there
are problems when the document's length changes, which can manifest as
tons of BadLocationExceptions going uncaught in the AWT thread which is
trying to refresh the window. Why? Probably because the insert into the
document isn't happening in the Swing run queue, but concurrently with
it. So use an invokeLater to do the actual insertion.
With these two changes, and a console set to 125 lines, I got no failures.
Previously, if I set the console to 125 lines, it would die catastrophically
before Minecraft was done starting up.
Also performance may be noticably better. It's pretty common for things
to dump 20+ lines into the buffer at once. If you have a 10,000 line buffer,
and you then delete the first line of it 20 times, that's actually a whole
lot of allocation and shuffling going on.
This converts the project into a multi-module Gradle build.
By default, Git does not show history past a rename, so use git log
--follow to see further history.
