Quilt issue: quilt_loader missing
Opened this issue · 9 comments
There seem to be an issue with the Quilt loader. Here is my config: https://github.com/sweenu/nixfiles/blob/d6fba43e8177dd67d9ba7ddb769fa934d8ebb4a2/hosts/najdorf/minecraft/default.nix
And here is the crash report: crash-2024-03-20_24.14.02.7060-quilt_loader.txt
I thought at first that it might be the modpack even though I have no problem using it client side. But then I tried removing all mods and keeping only the Quilt API mod and the error persisted. So I'm thinking that it might be an issue with the package.
Hmm. This one is odd, considering it... clearly is loading Quilt, but isn't providing the Quilt loader mod itself.
There is a chance that this is an issue I've had in the back of my mind finally manifesting, but it may take me a bit to know for sure.
(Basically, how libraries are unpacked currently is both inefficient and has weird implications for the classpath, and is something I've run into while trying to run some servers locally.)
Just tried the exact same setup but with fabric and it works fine. So I'm going to stay with that for now.
You've used the quilt loader yourself without issues? Are you able to reproduce my error?
I was looking into how the official quilt-server-launcher.jar is built and run, and the jar seems to be very simple; it just loads the jars from libraries/ into the classpath. The only file in it is META-INF/MANIFEST.MF, with the following contents:
Manifest-Version: 1.0
Main-Class: org.quiltmc.loader.impl.launch.server.QuiltServerLauncher
Class-Path: libraries/org/ow2/asm/asm-commons/9.6/asm-commons-9.6.jar li
braries/org/quiltmc/quilt-loader/0.24.0/quilt-loader-0.24.0.jar librari
es/org/ow2/asm/asm-util/9.6/asm-util-9.6.jar libraries/org/ow2/asm/asm/
9.6/asm-9.6.jar libraries/org/ow2/asm/asm-analysis/9.6/asm-analysis-9.6
.jar libraries/net/fabricmc/sponge-mixin/0.12.5+mixin.0.8.5/sponge-mixi
n-0.12.5+mixin.0.8.5.jar libraries/net/fabricmc/access-widener/2.1.0/ac
cess-widener-2.1.0.jar libraries/org/quiltmc/quilt-config/1.2.0/quilt-c
onfig-1.2.0.jar libraries/net/fabricmc/intermediary/1.20.4/intermediary
-1.20.4.jar libraries/net/fabricmc/tiny-remapper/0.10.1/tiny-remapper-0
.10.1.jar libraries/net/fabricmc/intermediary/1.20.4/intermediary-1.20.
4.jar libraries/org/ow2/asm/asm-tree/9.6/asm-tree-9.6.jar libraries/net
/fabricmc/tiny-mappings-parser/0.3.0+build.17/tiny-mappings-parser-0.3.
0+build.17.jar libraries/org/quiltmc/quilt-json5/1.0.4+final/quilt-json
5-1.0.4+final.jar
The classpath seems to be loaded relative to quilt-server-launch.jar, even if it's called from a different directory (I'm not really familiar with the internals of Java, but I tested it and it seems to work). Could we write a derivation that creates a directory containing a minimal quilt-server-launch.jar, as well as symlinks to the required libraries in a subdirectory, or is there some reason you'd prefer to pack everything into a single jar? I think this might work better, since it would work the same way as the "official" Quilt jar. Doing it this way could also allow for sharing the library files between different server versions. Any thoughts on this approach?
I should have written it down so I could express it concisely, but that was exactly what I was hoping to figure out how to do properly in fixing this. The same goes for the Fabric derivation. Even better, create the minimal server launch jar with absolute paths in the class path, then there's no need for the symlink tree at all.
It works :)
Still need to clean it up a tiny bit, but I should be able to push this today once I fix the update scripts.
The main other thing I want to do with this later is figure out if I can have Nix handle all of the libraries, because Fabric/Quilt/etc unpack a lot of libraries to libraries/... on first launch that I would like to avoid. I would also like to avoid it copying to versions/.../server-....jar if possible, but I'd need to look into how to do that.
Please see if fa037f4 fixes your issue. It theoretically should, and in my brief testing I didn't see it, however I haven't tried running it properly in production yet to know for sure.
(If I was doing this in a slightly smarter way I would have pushed to the develop branch, but it's too late now)
I just tested it with my modpack and everything seems to work perfectly!
Cool! Fixed and improved! And I've figured out a way to not deal with libraries and versions too, it just needs more tinkering :)
Reopening due to #65 :(