API Request: Option to leverage TOP block probing without extending PNCR base class
mc-ganduron opened this issue ยท 4 comments
I have some mod blocks I'm working on that provide PNCR capabilities. As a rule, I keep dependencies to a minimum, so I'm not currently extending PNCR's base classes. Naturally this may change in the future, but I'd like to use The One Probe to see the air/heat details of my blocks as they are coded now. I'm unable to do this because the probe is configured to test exclusively for BlockPneumaticCraft
blocks:
The probe logic itself does not rely on BlockPneumaticCraft
:
I'd like to propose a lighter option to leverage the probe block output so that extending BlockPneumaticCraft
is not a requirement. If that sounds reasonable to you, I'll offer up two options...
Option 1: Create a tag interface to mark probe-able blocks. BlockPneumaticCraft
would extend this interface, and the TOPInit
code tests for this interface. Mod blocks would extend the interface to enable probe features. Example TOPInit
code:
if (blockState.getBlock() instanceof IPneumaticCraftProbeBlock) {
TOPInfoProvider.handleBlock(mode, probeInfo, player, world, blockState, data);
}
Option 2: Create a data tag to mark probe-able blocks. TOPInit
would continue to test for BlockPneumaticCraft
classes, and (failing that) also test if the block isIn
the new data tag. Example TOPInit
code:
Block block = blockState.getBlock();
if (block instanceof BlockPneumaticCraft || block.isIn(PneumaticCraftTags.Blocks.PROBE_TARGET)) {
TOPInfoProvider.handleBlock(mode, probeInfo, player, world, blockState, data);
}
There are trade-offs in both cases, and there may be other good options as well. Let me know what you think.
Also, while you're free to extend BlockPneumaticCraft
in future, be aware of course that it's not an API class and could change at any time (whereas I try to keep the API stable as much as possible). So if you do find yourself needing to do that, let me know and maybe we can work out an API enhancement of some kind to keep it clean...
Yep definitely a reasonable request. TBH, there's probably no good reason not to have both options, e.g.:
Block block = blockState.getBlock();
if (block instanceof IPneumaticCraftProbeable || block.isIn(PneumaticCraftTags.Blocks.PROBE_TARGET)) {
TOPInfoProvider.handleBlock(mode, probeInfo, player, world, blockState, data);
}
And I'd probably name the interface something like IPneumaticCraftProbeable
since it could also be applied to entities, in theory...
TBH, there's probably no good reason not to have both options...
Awesome, thanks.
... be aware of course that it's not an API class ... So if you do find yourself needing to do that, let me know ...
I'm glad to hear that. I'm dipping into PNCR's common
package for a few things I can't get from the API, but I need to see how much of that I actually rely on. I'll post a new issue for this after I get it sorted.