Skip to content
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

Open
IThundxr opened this issue Nov 27, 2023 · 3 comments
Open

[Bug] Mod list fails to appear if mod loading fails too early #42

IThundxr opened this issue Nov 27, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@IThundxr
Copy link

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

@IThundxr IThundxr changed the title [BUG] Mod list fails to appear during early crashed [Bug] Mod list fails to appear during early crashed Nov 27, 2023
@IThundxr IThundxr changed the title [Bug] Mod list fails to appear during early crashed [Bug] Mod list fails to appear if mod loading fails too early Nov 27, 2023
@sciwhiz12 sciwhiz12 added the bug Something isn't working label Nov 27, 2023
@embeddedt
Copy link
Member

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.

@IThundxr
Copy link
Author

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

@sciwhiz12
Copy link
Member

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 debug.log file contains the logging from the mod locators which can be sufficient to determine what mods would be loaded. However, it should still be fixed for the sake of those who only have access to the crash report (such as the user not having provided it earlier, or not having some required option enabled for generation of the debug.log file).

shartte pushed a commit that referenced this issue Dec 22, 2024
…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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants