An Update on BCBG

I know I said I'd have the mod done in a week, a week ago. I've gotten sort of sidetracked with some side-projects, and it's taken a while.

Also, I've now officially doubled the amount of classes in the launcher. Jeez.

The launcher can now load stubs named with MCP class names (ie, in 1.8 GuiMainMenu_Stub.class will patch sf.class).I've also worked out how I'll handle needing to reference methods/fields in the original class but not wanting to override them: with a @nopatch annotation (not ideal but subclasses dun work).

For example, before:

public void patchMe(){
    nonPatchyThings();
    return 1 + 1;
}
//need nonPatchyThings declared even though you won't use it, so it will be patched even though it shouldn't be!

After:

public void patchMe(){
    nonPatchyThings();
    return 1+1;
}
@nopatch
public void nonPatchyThins(){} //won't get patched but will compile without errors, will use actual version at runtime 

I'm also working on the installer that was promised. The manual patch API might get pushed back to a different release because it's a pain.

Evolution of the Stub Mechanism

Originally my plan for BCBG was to only provide Patch classes. However, I noticed transitioning a base class to a patch class was often needlessly difficult if the modifications weren't complicated. I started designing an extension to the Patch interface that would allow passing in a byte[] as class data to strip methods from, and realized "Hey, I could do this automatically!". I quickly created a very hacky interface to scan for one method and move it to another class. Then I rewrote that into a nicer interface, and made it scan all methods and fields.

The way the current mechanism works is through a "cache" system. I parse through the stub class and cache all the events ASM emits, then replay them on the target class.

The BCBG event chain - the CachingClassAdapter stores the CallCache/CachingMethodAdapter/CachingFieldAdapters to emit later


The old Patch classes are neatly worked in as pre/post Stub operations. The system is very fast, mainly thanks to ASM's optimization. Two Stubs complete in less than a second, depending on their complexity.

Next blog post I'll talk about the Patch class design and how that works in with Stub classes.