[SOLVED] How to use Byte Buddy with obfuscation?

[Anon10W1z]

My Byte Buddy code works perfectly in the development environment, but for the compiled mod it doesn't seem to work.

String blockClassName = deobfuscated ? Block.class.getName() : "atr";
installMethodInterceptor(blockClassName, named(onBlockAddedName).or(named(onNeighborBlockChangeName)).or(named(updateTickName)).or(named(tickRateName)), CppBlockInterceptor.class);
String commandBaseClassName = deobfuscated ? CommandBase.class.getName() : "z";
installMethodInterceptor(commandBaseClassName, returns(Item.class).or(returns(Block.class)), CppCommandInterceptor.class);

private static void installMethodInterceptor(String methodContainerName, ElementMatcher<? super MethodDescription> methodMatcher, Class methodInterceptor) {
try {
	Class methodContainer = Class.forName(methodContainerName);
	new ByteBuddy().redefine(methodContainer).method(methodMatcher).intercept(MethodDelegation.to(methodInterceptor)).make().load(methodContainer.getClassLoader(), ClassReloadingStrategy.fromInstalledAgent());
} catch (Exception e) {
	e.printStackTrace();
}
}

And this fails with a ClassNotFoundException for the obfuscated class names. Shouldn't they have been obfuscated since it's not in a development environment?

[Anon10W1z]

What what what... What is that even supposed to do? Also...  if you need crazy things like this to accomplish your base edits, you are most likely doing too much of them.

About class names: FML deobfuscates class names at runtime, so you do not need the obfuscated versions.

I'm trying to make dirt and clay fall like sand, and change the getItemByText and getBlockByText methods in CommandBase to allow using items and blocks by ID in commands.

[Anon10W1z]

I'm trying to make dirt and clay fall like sand

That is a thing that takes ~5-10 minutes using pure ASM. No need to throw a huge library at it.

change the getItemByText and getBlockByText methods in CommandBase to allow using items and blocks by ID in commands.

This is a horrible idea but can be done without any base edits.

Alright then I'll ditch Byte Buddy

[Draco18s]

Warning about pure ASM:

While this is possible, be aware that Clay almost certainly does not have its own updateTick and onNeighborChanged methods, meaning that requesting them will cause a null return.  These functions are instead handled by the Block superclass, which if you ASM those methods, will be called for all blocks.  You will want to insert an static function call which lets you discriminate between blocks without having to write huge chunks of code in bytecode.  That call can also fire Forge events.

 

This repo is out of date, massively, and doesn't compile/run properly, but it shows what I mean by inserting a static function call.

https://github.com/Draco18s/HarderStuff/blob/master/main/java/com/draco18s/cropcore/asm/CropPatcher.java#L85-99

 

I later had issues with the event call, and ended up calling the event constructor with Reflection.  If you do that, just let your static function throw the exceptions; the try...catch block weirdly lags the simulation (Forge tps says "20 ticks per second" but it visibly takes closer to 20 seconds per tick*).

 

*I'd love a good explanation as to why.

[Anon10W1z]

Warning about pure ASM:

While this is possible, be aware that Clay almost certainly does not have its own updateTick and onNeighborChanged methods, meaning that requesting them will cause a null return.  These functions are instead handled by the Block superclass, which if you ASM those methods, will be called for all blocks.  You will want to insert an static function call which lets you discriminate between blocks without having to write huge chunks of code in bytecode.  That call can also fire Forge events.

 

This repo is out of date, massively, and doesn't compile/run properly, but it shows what I mean by inserting a static function call.

https://github.com/Draco18s/HarderStuff/blob/master/main/java/com/draco18s/cropcore/asm/CropPatcher.java#L85-99

 

I later had issues with the event call, and ended up calling the event constructor with Reflection.  If you do that, just let your static function throw the exceptions; the try...catch block weirdly lags the simulation (Forge tps says "20 ticks per second" but it visibly takes closer to 20 seconds per tick*).

 

*I'd love a good explanation as to why.

I already had that covered, but thanks for the advice anyways.