-
Notifications
You must be signed in to change notification settings - Fork 269
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
Non-"intermediary" AccessWideners are Unsupported when no Intermediary is Present in Production #966
Comments
Loader expects AWs to be in the target namespace:
Knot presumes this is fabric-loader/src/main/java/net/fabricmc/loader/impl/launch/knot/Knot.java Lines 258 to 260 in a2c5248
Loader only remaps AWs when in dev, and even then only from
|
Soooo... call it what it is. Cause development isn't always "named" and production isn't always intermediary. It seems like that is the only necessary distinction here. |
if you remap the entire game to mojmap in production, and then try to load mods that are mapped to intermediary (the production output state), that will never work. there is a reason floader remaps the game to intermediary and loom remaps mods to intermediary at build time. if you are deviating from that to force some other mapping, you need to go all the way and remap everything not just the base game |
I think this is a valid issue, currently both loom and loader cheat a bit when intermediaries arent present as use |
Player has removed most of the hardcoding in his Loader Extension branch already: sfPlayer1@2e6e4ec |
When launching a Minecraft instance with no intermediaries (intended) with Fabric, and loading a mod mapped to the
official
namespace (AccessWidener included), the game will fail to launch.This is the case for my mod that was built with Unimined.
Loom apparently just marks all AccessWideners as "intermediary" whether they actually use intermediary or not.
Log
https://mclo.gs/5KfaIN3
The text was updated successfully, but these errors were encountered: