Mod Integration Development: What's the correct way to register additional item details?

[benjaminiserman]

Hey all—I'm currently trying to enrich the item details for my AbyssalContract item. What I have is fully working, but I'm pretty sure I'm committing a faux pas by referencing ComputerCraftAPIService from a dependent mod. Could anyone point me towards the recommended way to do this? I can't find it for the life of me.

Code sample: link

[SirEdvin]

Recommended way it by doing something like this.
You basically create a separate class that holds all integration logic and then dynamically load it from your main mod class if the dependent mod is present.
You would still need to have CC:T in a building environment, but in minecraft your mod would work with it just fine.

[benjaminiserman]

Ah that's different from what I was asking, but I am curious—is that meaningfully different from the way I'm currently doing it?

[SirEdvin]

Probably. In raw java it should raise a ClassNotFound exception, because you reference the class, that requires CC:T classes, so it would try to load CC:T classes and fail, but for minecraft I am not 100% sure.

But in any case you can just test it with loading your mod without CC:T in the pack.

[SquidDev]

This should be fine. Java is pretty lazy about loading classes, and for static method calls, won't load it unless the method is called. For instance, the following runs fine, despite us deleting Foo entirely:

ᐅ cat Example.java && javac Example.java && rm Foo.class && echo "=========" && java Example
class Foo { static void bar() { } }

class Example {
  public static void main(String[] args) {
    if(args.length == 1) Foo.bar();
    System.out.println("Done");
  }
}
=========
Done

[SirEdvin]

As usual, your Java knowledge is just amazing :)

I am just make everything fool-proof, since I don't trust java a lot :)

[SquidDev]

I am just make everything fool-proof, since I don't trust java a lot :)

Yeah. It's hard to know what's defined by the spec, and what's just OpenJDK behaviour. Typically I would go through a bouncer method, for example, having aComputerCraftCompat.register()¹, which then does the registration. In this case, this might actually make things a bit simpler, because you can then just do:

fun register() {
  VanillaDetailRegistries.ITEM_STACK.addProvider {details, itemStack -> 
    if (itemStack.item is ContractItem) {
      val contract = LoadedContracts[itemStack] as? AbyssalContract ?: return
      details.putAll(contract.details.map { (key, value) -> Pair(key, value ?: mapOf<String, Any>()) })
    }
  }
}

Footnotes

1. I have some vague recollection of there being cases where ModItemDetailProvider would be loaded (which in turn tries to load DetailProvider), even if the method body itself isn't. But this was from comments I read 5+ years ago when Forge was rewriting ModLauncher, so a) could have entirely misunderstood or b) might not even be true any more. Honestly, if it works on OpenJDK, ship it. ↩

[SquidDev]

What I have is fully working, but I'm pretty sure I'm committing a faux pas by referencing ComputerCraftAPIService from a dependent mod.

Yes, anything in the impl is a no-no :p. You want to do VanillaDetailRegistries.ITEM_STACK.addProvider(ModItemDetailProvider()) instead.

[SquidDev]

Have also fleshed out the docs at https://tweaked.cc/mc-1.20.x/javadoc/dan200/computercraft/api/detail/package-summary.html. Let me know if there's anything which that doesn't explain!

[benjaminiserman]

Ahh I missed this on the README. My bad! Thanks for the help :)