feat: add custom block registry for third-party plugin integration

[Th0rgal]

Summary

Hi!

I'm the maintainer of Oraxen and I propose this integration that would make it easier for custom block plugins to work with mcMMO.

This PR adds a new CustomBlockRegistry that allows plugins like Oraxen (but also others like ItemsAdder) to register their custom blocks so that players can earn mcMMO skill XP when breaking them.

What's included:

• CustomBlockRegistry: A registry where plugins can register their custom blocks with skill type and XP values
• McMMOCustomBlockBreakEvent: An event that fires when a registered custom block is broken, allowing plugins to modify XP dynamically
• ExperienceAPI additions: Simple methods for plugin developers to register and unregister their custom blocks

How it works

Plugin developers can register their custom blocks in their onEnable:

// Register a custom ore to give Mining XP
ExperienceAPI.registerCustomBlock("myplugin", "mythril_ore", "MINING", 150);

// Or using the combined format
ExperienceAPI.registerCustomBlock("myplugin:diamond_ore_variant", "MINING", 200);

And clean up in onDisable:

ExperienceAPI.unregisterAllCustomBlocks("myplugin");

Why this matters

Currently, custom block plugins have no clean way to integrate with mcMMO. Players who use both Oraxen and mcMMO often ask why breaking custom ores doesn't give them Mining XP. This PR solves that problem!

Companion PR

I've also submitted a companion PR to Oraxen that uses these new APIs: oraxen/oraxen#1703

Backwards compatibility

This is purely additive and doesn't change any existing behavior. All existing blocks and XP handling continues to work exactly as before.

Test plan

• Build mcMMO and verify it compiles
• Test registering a custom block via the API
• Test that XP is awarded when the custom block is broken
• Test unregistering blocks
• Test that existing vanilla block XP still works normally

Thanks for considering this! I'm happy to make any adjustments based on your feedback. Looking forward to better integration between our plugins!

[nossr50]

I'm not opposed to adding an API for an easy "it just works" experience for users of mcMMO and other plugins, however, I think config should be involved in this process.

If a plugin is registering a custom block, it should make an entry into the relevant config and users should be able to override that entry (for example, setting the XP values to whatever they want).

So, if a plugin were to register a custom block for a user, it should create relevant experience.yml values if it's the "first contact" of this custom block/etc.

Perhaps experience related to custom things could simply go in its own config to keep things segregated, it doesn't really matter much, or rather I haven't given it sufficient thought.

I haven't had time to sit and think about all the things in this PR, this is just my initial thoughts after skimming the files changed.

I'm reminded of #5205 and #5205, it is likely the work related to those issues would also bring about support for custom blocks/entities/etc.

[Th0rgal]

I'm not opposed to adding an API for an easy "it just works" experience for users of mcMMO and other plugins, however, I think config should be involved in this process.

If a plugin is registering a custom block, it should make an entry into the relevant config and users should be able to override that entry (for example, setting the XP values to whatever they want).

So, if a plugin were to register a custom block for a user, it should create relevant experience.yml values if it's the "first contact" of this custom block/etc.

Perhaps experience related to custom things could simply go in its own config to keep things segregated, it doesn't really matter much, or rather I haven't given it sufficient thought.

I haven't had time to sit and think about all the things in this PR, this is just my initial thoughts after skimming the files changed.

I'm reminded of #5205 and #5205, it is likely the work related to those issues would also bring about support for custom blocks/entities/etc.

Thanks for the feedback! I updated the pr to use a config-backed approach. You are right, that should be better.
Changes made:

• Added custom-blocks.yml config file for user customization
• Plugin registrations now create config entries on "first contact" only
• Config values always take priority over API-registered values (users can override XP)
• Added enabled: false option to disable specific blocks
• Custom blocks persist across restarts

The config is now the source of truth but the API stays simple for plugin developers.

[Th0rgal]

Little bump @nossr50

[nossr50]

Alright I've taken some time to look over the implementation, and I have a few thoughts...

The way the changes in this PR are structured, it doesn't really seem like mcMMO is automatically rewarding XP for custom block breaks anywhere, it seems like it would solely rely on calls outside of mcMMO to invoke stuff such as addXpFromCustomBlock, this is not really how I would have gone about it.

I also am not sure there is much value in coupling the custom blocks to plugin names, I'm thinking that aspect could probably be removed entirely, I can see why you did it since there's a call to unregister all blocks owned by a specific plugin, but I'm not sure that would see much use.

It'd be simpler for the user to be able to add custom blocks to the custom_blocks.yml with just block name and no need for plugin name, and I don't think we would be losing out on much.

I'm also considering I may just do my own implementation of all this, since custom item support and custom block support may as well go hand-in-hand.

[Th0rgal]

Got it @nossr50 , thanks for the reply. Let me know what you prefer, I'm open to updating this pr if this helps