-
Notifications
You must be signed in to change notification settings - Fork 33
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
[Bug] Mod list fails to appear if mod loading fails too early #42
Comments
I think this is by design, to prevent other mods' code from running when the game is in an errored state. In the log you sent, the reason for the mod loading failure is still shown, even though the mods list is not fully populated. |
Yeah but usually having a mod list is good for detecting & alerting people of common problems from wrongly versioned mods etc, an example of this is how I've got a bot that will alert users if they've got incompatible versions of mods etc |
This was raised in Discord a few minutes ago. My preliminary thoughts, based on my knowledge of the design of FML and not having looked at the code yet: When FML encounters a mod loading error in the early stages of the mod loading process (such as during the phase where dependencies are verified), the mod sorter shifts to a 'fail-safe' mode where it passes only the system mods -- Minecraft and NeoForge -- to the rest of the mod loading process. The idea behind that decision (as I understand it) is to allow solely NeoForge and Minecraft to continue loading (and no other mods), in the hopes of reaching a stable enough state later to display a friendly error screen to the player in the game window. (See MinecraftForge/MinecraftForge#7993 (comment) and the subsequent works MinecraftForge/MinecraftForge#8049 and MinecraftForge/MinecraftForge#8238 for more details on this behavior, and on the system mods concept.) What I assume happens here is that the crash report extender uses the information from the mod list which, in the aforementioned 'fail-safe' mode, only contains the system mods. That would cause the crash report to only have the two system mods. This isn't a very large problem, since the |
…Release Classes (#42) Seen a couple of people encounter this in mod dev (when adding dependencies): SJH considers a Jar to be `Multi-Release` based on the `Manifest` <https://github.com/McModLauncher/securejarhandler/blob/96a7b6a8fe1f1117e01dfd94c640757154372a68/src/main/java/cpw/mods/jarhandling/impl/Jar.java#L124> If it is then it resolves a path to `/META-INF/versions` <https://github.com/McModLauncher/securejarhandler/blob/96a7b6a8fe1f1117e01dfd94c640757154372a68/src/main/java/cpw/mods/jarhandling/impl/Jar.java#L126> And tries to walk it <https://github.com/McModLauncher/securejarhandler/blob/96a7b6a8fe1f1117e01dfd94c640757154372a68/src/main/java/cpw/mods/jarhandling/impl/Jar.java#L127> This works for most Jars, however it does not consider the case where a Jar is erroneously marked as `Multi-Release`, with `/META-INF/versions` **not** existing. If this is the case, `Files.walk` will throw a `UnionFileSystem$NoSuchFileException` which is then wrapped and rethrown as a `UncheckedIOException` <https://github.com/McModLauncher/securejarhandler/blob/96a7b6a8fe1f1117e01dfd94c640757154372a68/src/main/java/cpw/mods/jarhandling/impl/Jar.java#L138> Attached Example Stacktrace, <https://gist.github.com/AterAnimAvis/35ded98d52a78c2f257d59173c86366c> --- Current implementation of a fix is from a bit of spitballing [in Discord](https://discord.com/channels/313125603924639766/922237746460893234/1129415771567689738)
If mod loading fails early then the crash log will not include the mod list and will only include Minecraft & forge.
Example of this type of log: https://gist.github.com/NeoCamelot/5e5d94426d3d872bbb04256484740323
The text was updated successfully, but these errors were encountered: