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.