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

Non-"intermediary" AccessWideners are Unsupported when no Intermediary is Present in Production #966

Open
halotroop2288 opened this issue Aug 18, 2024 · 5 comments
Labels

Comments

@halotroop2288
Copy link

halotroop2288 commented Aug 18, 2024

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.

Namespace (official) does not match current runtime namespace (intermediary)

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

wagyourtail added a commit to unimined/unimined that referenced this issue Aug 18, 2024
@halotroop2288 halotroop2288 changed the title Non-"intermediary" AccessWideners are Unsupported when no Intermediary is Present Non-"intermediary" AccessWideners are Unsupported when no Intermediary is Present in Production Aug 18, 2024
@Chocohead
Copy link
Contributor

Chocohead commented Aug 18, 2024

Loader expects AWs to be in the target namespace:

accessWidenerReader.read(reader, FabricLauncherBase.getLauncher().getTargetNamespace());

Knot presumes this is named in dev or intermediary out of dev:

public String getTargetNamespace() {
// TODO: Won't work outside of Yarn
return IS_DEVELOPMENT ? "named" : "intermediary";

Loader only remaps AWs when in dev, and even then only from intermediary to the target namespace (i.e. Yarn).


official as a namespace is effectively a Minecraft specific invention; if you search for it, the only references are in MinecraftGameProvider and an old overload in GameProviderHelper, all in the context of remapping the original game jar. Regardless to whether your GameProvider remaps the game jar, the target namespace is taken as intermediary (out of dev).

@halotroop2288
Copy link
Author

halotroop2288 commented Aug 19, 2024

Soooo... call it what it is. dev or production

Cause development isn't always "named" and production isn't always intermediary. It seems like that is the only necessary distinction here.

@Linguardium
Copy link

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

@modmuss50
Copy link
Member

I think this is a valid issue, currently both loom and loader cheat a bit when intermediaries arent present as use intermediary as the namespace, this is mostly becuase the work to support this hasnt been done. All of the loader APIs should support this just fine.

@modmuss50 modmuss50 added the bug label Aug 19, 2024
@NebelNidas
Copy link
Member

Player has removed most of the hardcoding in his Loader Extension branch already: sfPlayer1@2e6e4ec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants