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
NoiseChunkGenerator should be in net.minecraft.world.gen #2057
Comments
Hmm, seems the package visibility index from enigma has stopped working for long |
I doubt that the index works but the command line interface broke. Need to check. |
I did start looking at improving and fixing the mappings validator. Would be nice to try and get rid of these issues. But we cannot guarantee it |
Turns out check mappings was never broke. It was this that broke: And this check mappings never worked since the intermediary update 2 years ago! |
Look at the current results:
|
Ouch, thats quite a lot there. We could just take the stance of not caring in favor of better mappings? Worth discussing |
Imo we will just fix it. But I will probably patch this task to work like javadoc (our javadoc does not fail if the doclint errors). So we can probably catch that illegal state exception thrown and just print the error message, or only fail when we are not on ci |
Related snippet:
|
Looking back, some stuff probably had better be exposed than left package private or protected. From #128 (comment):
If classes like |
IMO we should keep the package-private friends together in the same packages. It might result in worse mappings in some places, but they're also more correct behaviour-wise. |
A few interesting things stand out. For example, in that message above it says ThrownEntity must be in same package as ProjectileEntity, yet I don't see why; ThrownEntity though uses one protected method from ProjectileEntity in its lambda construction (which javac afaik usually generates a bridge method for) even if jdk's lambda meta factory can totally handle that. Just putting a reminder for myself to check if package visibility index from enigma needs an update. |
Turns out that brainfart enough, ProjectileEntity's constructor is package private. That's why... |
as required by visibility Fixes FabricMC#2057 Signed-off-by: liach <liach@users.noreply.github.com>
I would argue the opposite, given we fix the behaviour either way there's no advantage to worse mappings just because Mojang happen to use a particular package structure. Not least that you don't even need Loader's make everything public at dev runtime hack anymore, Tiny Remapper can do it directly in the places where it is needed. |
I agree with Chocohead, I'm not in favor of moving classes around just to respect Mojang's package structure. We need to fix the issues elsewhere in the toolchain |
Hmm, so we need to declare that we want to fix access instead at https://github.com/FabricMC/fabric-loom/blob/57c9a8f3209121f22e84b8b01b64f1093256f1d3/src/main/java/net/fabricmc/loom/configuration/providers/minecraft/MinecraftMappedProvider.java#L129-L136 and Lines 826 to 830 in 629b96e
The loom refactor proposal is good that we can actually utilize split loom to reduce duplicate code between yarn and loom |
Needs a loom pr as well. The loom pr can properly fix the problem in dev env. Signed-off-by: liach <liach@users.noreply.github.com>
Properly fix FabricMC/yarn#2057 Signed-off-by: liach <liach@users.noreply.github.com>
Closing this now. For people wondering, the solution is always to run the named (yarn) mapped jar/bytecode through fabric loader. This includes calling data generators from your mods' dev env! |
While I think the package for
NoiseChunkGenerator
is currently better, running Minecraft in a development environment causes this crash.The text was updated successfully, but these errors were encountered: