Skip to content

R5.41.0#7011

Merged
dktapps merged 67 commits into
stablefrom
r5.41.0
Feb 15, 2026
Merged

R5.41.0#7011
dktapps merged 67 commits into
stablefrom
r5.41.0

Conversation

@dktapps
Copy link
Copy Markdown
Member

@dktapps dktapps commented Feb 15, 2026

DO NOT SQUASH MERGE!!

wraith and others added 30 commits December 7, 2025 11:31
when there's no residue, plugins would expect to see an empty array when getting the residue. The old code would have given an array with 1 element containing a null item, which would've been confusing.
Allow overriding the residue item in PlayerItemConsumeEvent
This is a new take on RegistryTrait.
While this is a major change internally, outwardly it should work exactly the same for the vast majority of plugins.
However, any plugins that were using reflection to mess with Vanilla* (e.g. to override blocks) will break due to internal design changes.

Compared to RegistryTrait, this has various advantages:

- Performance
  - simple (non-cloning) registry accessors such as VanillaEffects are over 300% faster
  - cloning registry accessors like VanillaItems are 30-40% faster
  - registry accessors are now regular functions instead of using __callStatic(), meaning that JIT and Opcache optimizations can improve their performance even further

- Robustness
  - while the member values of registries can still be tampered with via reflection, their types are now strictly enforced, which forces plugins to use a class that matches the original type if they want to e.g. hack in a custom class for a block
  - plugins cannot add new registry cases via reflection, making it clear that these are not meant to be modified

- Separation of gencode from source code: this makes it clearer to contributors which files are not to be touched

- Doxygen can now understand VanillaBlocks et al and generate proper docs entries, since it didn't understand the @method tags used previously

How it works:
- A class extending RegistrySource is declared
- Members are declared in setup() as before, using register() or registerDelayed() depending on the needs of the code
- build/generate-registry-interface.php src generated
- Generated classes with many functions and initialization logic are placed in the generated/ folder
- When first accessed, the generated class invokes YourRegistrySource->setup() to get the values to assign to its internal members

The main downside to this change is that the generated registry accessor class cannot have custom code added to it. This pattern was never used by PocketMine-MP, but grepPlugins reveals that plugin developers sometimes add custom utility functions to RegistryTrait-using classes, which is not possible with this new system. However, this seems like a small price to pay for the major improvements this system enables. Such functions can always be moved to a separate utility class. This might be revisited in the future if there's a demand for custom functions on the generated output class.

This change also opens the potential for allowing proper overrides of blocks and items, since the gencode is able to enforce class types and ensure type compatibility with code using these functions. I'm not sure if this is something we'll actually allow, but it's a lot less work to safely allow it with this design than with the legacy RegistryTrait. RegistryTrait would have had to do manual type verification, while this design just works like normal code.

There are some minor caveats with this approach, however. Since the accessor functions don't necessarily exist during setup() (as it may be called during codegen), anything that wants to access something via a generated registry interface must use registerDelayed() instead of register(). This is seen in a few places in VanillaItems where items need to reference VanillaBlocks. In this case, the type of the generated registry accessor is based on the return type of the closure given to registerDelayed(), instead of being taken directly from the value. This allows the gencode script to operate without fully initializing the registry, which would cause a circular dependency problem.

TLDR: New registry system, much fast, big improve, many robust, very wow!
this is about 10% faster than calling a function which just clones the member anyway.
this required a hack for all-sided logs, since bamboo doesn't have any such block
@dktapps dktapps requested a review from a team as a code owner February 15, 2026 20:29
pmmp-admin-bot[bot]
pmmp-admin-bot Bot previously approved these changes Feb 15, 2026
pmmp-admin-bot[bot]
pmmp-admin-bot Bot previously approved these changes Feb 15, 2026
pmmp-admin-bot[bot]
pmmp-admin-bot Bot previously approved these changes Feb 15, 2026
@dktapps dktapps merged commit bb8ae4a into stable Feb 15, 2026
52 checks passed
@dktapps dktapps deleted the r5.41.0 branch February 15, 2026 21:26
@github-actions
Copy link
Copy Markdown
Contributor

@pmmp/server-developers Draft release 5.41.0 has been created for commit bb8ae4a. Please review and publish it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants