PneumaticCraft: Repressurized

PneumaticCraft: Repressurized

50M Downloads

API Jar: Unobfuscated names conflicting with official names when building a mod

mc-ganduron opened this issue ยท 6 comments

commented

Is it possible to obfuscate the API jar as part of PNCR's build process? I'm running into problems with its unobfuscated names...

I'm using the official deobfuscated Minecraft names for my mod. PNCR's runtime jar (vs. the API jar) is fully obf'd and thus gets fully deobf'd as part of building my mod. As such, PNCR's naming choice doesn't affect anything when compiling against the runtime jar. Building against the API jar, though, is different. The API jar isn't using the official names but also isn't fully obfuscated. I think one or the other "isn't" would be okay, but both together cause problems when compiling my mod.

As an example (no surprises, just for reference), here is part of PneumaticCraftRecipe from the runtime jar vs from the API jar...

Runtime jar:

  public boolean func_194133_a(int width, int height) // ...

API jar:

  public boolean canFit(int width, int height) // ...

The official name for canFit is canCraftInDimensions. Extending (say) PressureChamberRecipe and compiling against the API produces an error because there's no plain canCraftInDimensions or obf'd func_194133_a. The derived class now needs to define it:

error: [xxx] is not abstract and does not override abstract method canCraftInDimensions(int,int) in IRecipe

I can fall back to compiling against the runtime jar or just implement the functions since they're only stubs, no problem in either case. However, it seems like a better approach would be to use an obfuscated API jar.

Let me know what you think.


As an aside, this naming stuff gets pretty funny. Naturally the obfuscator can only obf names it knows, and it only knows what Mojang uses. This means that, although PneumaticCraftRecipe::getCraftingResult(DummyIInventory) is a valid implementation of IRecipe<...>::getCraftingResult(...), the DummyIInventory argument keeps the method from obf'ing -- it's a different signature. Now there's a phantom getCraftingResult method when deobf'd into official names, and no implementation of (officially-named) IRecipe<...>::assemble(...). ๐Ÿ˜‘

commented

This is a good incentive to properly overhaul the PNC build system, which has been creaking along since 1.12. I have been intending to redo it, including switching over to Mojang mappings, and an obfuscated API jar will be part of that.

Not a trivial change, but something I need to stop putting off, so I'll let you know how it's going over the next few days...

commented

Actually turned out to be easier than I thought: https://github.com/TeamPneumatic/pnc-repressurized/tree/1.16.5 - see commit 8923233

Note:

  • New 1.16.5 git branch, due to the size of the changes
  • Not building this with Jenkins yet
  • Not heavily tested yet, but it does build and start up OK
  • Mappings changes were mostly smooth with only a few clashing names - watch out in particular for numeric text fields in GUI's, and drone speed calculations - they should work but some method names had to be changed there due to vanilla clashes

You're welcome to have a play with it (and please let me know if you spot any problems), but you will need to clone & build it yourself for now. Also, one other change I want to make is to get the API code properly into its own sourceset (i.e. move it under src/api/java/... instead of pulling it in from src/main/java/.../api). That will be coming soon hopefully. Once that's done & I've tested more, I'll add this branch to the Jenkins build list.

commented

API is now in its own sourceset as well (which was useful to do since I caught a few places where the API was calling into the main JAR, oops).

commented

Thanks for spotting that!

commented

That's great, thanks a lot for doing that. Like housecleaning, it only looks like it will take forever.

No issue compiling against the new API jar. I hit a snag running against the new runtime jar:

Stacktrace:

	at java.lang.Class.getDeclaredMethod(Class.java:2130) ~[?:1.8.0_51] {}

-- MOD pneumaticcraft --
Details:
	Caused by 0: net.minecraftforge.fml.common.ObfuscationReflectionHelper$UnableToFindMethodException: java.lang.NoSuchMethodException: net.minecraft.world.spawner.AbstractSpawner.isNearPlayer()
		at net.minecraftforge.fml.common.ObfuscationReflectionHelper.findMethod(ObfuscationReflectionHelper.java:166) ~[?:?] {re:classloading}
		at me.desht.pneumaticcraft.common.util.Reflections.init(Reflections.java:29) ~[?:2.13.4-CUSTOM] {re:classloading}
		at me.desht.pneumaticcraft.PneumaticCraftRepressurized.<init>(PneumaticCraftRepressurized.java:79) ~[?:2.13.4-CUSTOM] {re:classloading}

Caused by Reflections:

public static void init() {
msbl_isActivated = ObfuscationReflectionHelper.findMethod(AbstractSpawner.class, "isNearPlayer");

Swapping this line back to its previous version fixed the error.

No problems after a few minutes of mod testing. If anything shows up, I'll let you know.

commented

Closing this, I think these issues are all resolved now?