Closed Godwhitelight closed 1 year ago
this is feather fabric but i got the same result on normal fabric as well
I'm not able to reproduce this crash. I'm not familiar with feather fabric; is the rust_launcher
at the top a part of feather fabric, or a different thing? If you are using a custom launcher, it is possible it is doing something wonky with libraries. Based on the crash, this appears to be some sort of incompatibility with the Version
system, which checks the current Minecraft version to determine the correct code to prevent crashes.
My best guess is that the "Mojang Bridge" library isn't right. If I remember correctly, it was removed and shouldn't be loaded for 1.19.4, but the starting JVM with arguments
section of the log lists com/mojang/javabridge
.
If you are using custom JVM arguments, you might be able to remove that item from the list. (Or try without any custom arguments.)
If you're wondering why this library is relevant, it used to contain GameVersion
information, but was later merged in with the normal GameVersion
class in Minecraft itself.
I have tried it with normal Minecraft fabric and I got the same result. the rust_launcher is a part of feather fabric. My guess is the JRE, so what JRE are you using?
Java shouldn't be an issue, since it is bundled with the Minecraft launcher and a different incompatibility error would occur. The bridge library is definitely related, and this isn't affected by the Java version. Can you confirm that you are launching with default JVM arguments? If you can get Minecraft to launch without the bridge library, that should fix it. (Unless that causes a different type of crash.)
Tonight I can compile a "fixed" version of the mod that you can test, but it would only work in 1.19.4.
Here's how the bridge library is related (simplified):
GameVersion
extends Bridge's GameVersion
GameVersion
includes getId
, which is accessible from Minecraft's, since it extendsGameVersion
, but I'm pretty sure it is completely gone)GameVersion
doesn't extend Bridge's (non-existent) GameVersion
GameVersion
includes its own getId
How NBT Editor's Version
determines the Minecraft version:
GameVersion#getId
existsgetId
on Minecraft's GameVersion
getId
on Minecraft's GameVersion
If the bridge library exists when it shouldn't:
GameVersion#getId
existsgetId
on Minecraft's GameVersion
GameVersion
doesn't extend Bridge's GameVersion
, so getId
is incompatiblecan u send a fixed version please?
Here's the "fixed" version. This changes Version
to simply output "1.19.4" instead of getting it normally. Additionally, it prints out some basic debug information to confirm that the bridge library is the issue.
Here is what I get printed out:
[STDOUT]: NBTEDITOR DEBUG:
[STDOUT]: - getReleaseTargetExists: false
[STDOUT]: - getIdExists: false
[STDOUT]: - Bridge_GameVersion: false
[STDOUT]: - SharedConstants extends: <none>
Can you enable the console in the launcher settings and send what you get outputted? I'm guessing you're going to see this:
[STDOUT]: NBTEDITOR DEBUG:
[STDOUT]: - getReleaseTargetExists: false
[STDOUT]: - getIdExists: true
[STDOUT]: - Bridge_GameVersion: true
[STDOUT]: - SharedConstants extends: <none>
If so, then this is the problem - notice getIdExists
is true
while SharedConstants's (Minecraft's) GameVersion
extends nothing.
If this is indeed what you see, can you confirm that you are launching with default JVM arguments? If you can get Minecraft to launch without the bridge library, that should fix it.
Please note that I'm not going to keep this as a permanent solution, so I'm not going to keep releasing "fixed" versions until I understand the root cause and can properly fix it.
ok, it launched.
[20:08:01] [Render thread/INFO]: [STDOUT]: NBTEDITOR DEBUG:
[20:08:01] [Render thread/INFO]: [STDOUT]: - getReleaseTargetExists: false
[20:08:01] [Render thread/INFO]: [STDOUT]: - getIdExists: true
[20:08:01] [Render thread/INFO]: [STDOUT]: - Bridge_GameVersion: true
[20:08:01] [Render thread/INFO]: [STDOUT]: - SharedConstants extends: <none>
While looking into the version system more when debugging a different issue, I discovered a much easier way to get the version information; I can load the id
and sometimes release_target
directly from a version.json
file stored in the game's jar
file. This completely bypasses all the complicated stuff relating to this issue. In theory, this should solve this issue in a much nicer manner, so I'll mark this as completed.
Really cool!
I've just released v1.12.0, which includes the change mentioned in my last comment. If you could confirm that that does fix it, that would be great!
Assuming that the fix worked, I'm going to close the issue now, since it has been a month.