Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 5.23.0 #6561

Merged
merged 60 commits into from
Dec 5, 2024
Merged

Release 5.23.0 #6561

merged 60 commits into from
Dec 5, 2024

Conversation

dktapps
Copy link
Member

@dktapps dktapps commented Dec 5, 2024

This includes all changes from minor-next as of December 5th

!!!! DO NOT squash merge this PR !!!!

ipad54 and others added 30 commits November 10, 2024 15:07
not supporting this has caused problems every time this function has been used in reality so far (#6092 and #6333).
Co-authored-by: ipad54 <[email protected]>
Co-authored-by: Dylan T. <[email protected]>
…ks/VanillaItems (#6498)

Use reflection to locate BlockTypeIds and ItemTypeIds for VanillaBlocks/VanillaItems

Since BlockTypeIds and ItemTypeIds are derived from VanillaBlocks and VanillaItems respectively anyway (they only exist to allow identifying blocks/items without having to create instances of them), this hack is probably OK, and reduces the chances of mistakes.
Previously it was explored to have these IDs generated by auto-incrementing in VanillaBlocks/Items and have the constants generated that way, but this proved to be too problematic because of unstable diffs no matter how we chose to sort the elements. See #6313 for previous research on the subject.

This is obviously not a desirable hack to keep long-term. In the future it will probably make sense to redesign VanillaBlocks like so:

enum VanillaBlocks { ... }
VanillaBlocks::STONE (the type ID)
VanillaBlocks::STONE->new() (to create a block)

However, more research is needed on this, as I'd prefer not to make block creation any more verbose.
This will be useful for future block additions
…item and block (#4683)

This allows, for example, banning the usage of spawn eggs, without preventing opening of doors, without the need for item ID whitelists.

It also allows customizing the behaviour of item and block interactions when sneaking - it's now possible to force spawn eggs to work when sneaking, or force containers to open.

Finally, this also allows preventing any interaction at all without preventing block placement (by setting both to false). Since cancelling the event will typically prevent placement too (which might not be desired).

Side note: Blocks are now always synced when right-clicking on a block.
This differs from the previous behaviour, where the blocks were only synced when the action "failed".
However, since this change introduces a situation where the action may succeed but have different results than the client expects, it's best to just always sync blocks in this situation.

Fixes #3267
Support for more advanced stuff like NBT copying wasn't added in this PR, as the NBT used by PM is currently an inconsistent mess and doesn't play nice with vanilla. In the interests of avoiding this mess propagating, it's been left for another time.

Adds PlayerEntityPickEvent a la PlayerBlockPickEvent
and Entity->getPickedItem().
… to the main server process (#5273)

Support for this was introduced in PHP 8.0, though not mentioned in any changelog: php/php-src#5777

This simplifies the subprocess handling considerably. However, there is a potential for problems if PHP generates any E_* errors, since these get written to STDOUT as well.
To avoid error messages being treated as a command, a hash is attached to each IPC message, seeded with an incrementing counter. This prevents error messages causing command replays or unintended commands.

Unfortunately, PHP doesn't support binding pipes other than stdin/stdout/stderr on Windows for the child process, so we have to use stdout for this. In the future, if it becomes possible, a dedicated pipe for the purpose should be introduced. We'd need something like php://fd/<number> to work on Windows.
this is dodgy and we shouldn't rely on it long term.

relates to #6524
@dktapps dktapps requested a review from a team as a code owner December 5, 2024 14:30
pmmp-admin-bot[bot]
pmmp-admin-bot bot previously approved these changes Dec 5, 2024
@dktapps dktapps added Category: API Related to the plugin API Category: Gameplay Related to Minecraft gameplay experience Category: Core Related to internal functionality Type: Enhancement Contributes features or other improvements to PocketMine-MP Type: Release (!!!) Pull request will trigger a release when merged labels Dec 5, 2024
pmmp-admin-bot[bot]
pmmp-admin-bot bot previously approved these changes Dec 5, 2024
plugins shouldn't be using these, but since it's not marked as internal, we can't be sure.
@dktapps dktapps merged commit ea8f971 into stable Dec 5, 2024
32 checks passed
@dktapps dktapps deleted the r5.23.0 branch December 5, 2024 15:51
Copy link

github-actions bot commented Dec 5, 2024

Draft release 5.23.0 has been created for commit ea8f971. Please review and publish it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: API Related to the plugin API Category: Core Related to internal functionality Category: Gameplay Related to Minecraft gameplay experience Type: Enhancement Contributes features or other improvements to PocketMine-MP Type: Release (!!!) Pull request will trigger a release when merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants