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

Add new Lidded API, deprecating existing bukkit Lidded API. Adds PlayerLiddedOpenEvent #11814

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

456dev
Copy link
Contributor

@456dev 456dev commented Dec 25, 2024

replaces #11379, pre hard-fork pr

minimal changes from previous pr, mostly some variable renames + //paper comments, to be in-line with the new guidelines.

  • Additionally, I need to double check the implementation of PlayerLiddedOpenEvent for shulker boxes, particularly if players can leak.

previous description below:

Featuring

  • 5 LidModes, 3 of which were not possible before
  • The ability to get if the lid actually should be open, if a player is in the container
  • The ability to get if the lid is open, from api or the player itself

This also deprecates Bukkits api because of the confusing and outright incorrect javadocs (so those now accurately represent the behaviour)

Testable with the included testplugin commands.

I'm not 100% sure if the PaperLidded interface is the best way of doing this, but it is working
Also, let me know if the naming needs to change.

  • see if anything important is skipped in the check method scheduled every 5 ticks on chests

- adds `/test_lidded_new <blockpos> query` to get the api's view of the block
- adds `/test_lidded_new <blockpos> set <lidmode>` to change it.
- adds `/test_lidded_old <blockpos> <is_open | close | toggle>` to use the implementation of the old api on top of the new api.
- adds `LiddedTestListener` to test `PlayerLiddedOpenEvent`, which makes any lidded blocks open quietly (ie cancel the event), if done while holding any wool in your main hand.

since it's not the easiest thing to test in-game without some api consumer/activator

a seconds player might be useful to inspect state while it is open/closed with multiple people.
@456dev 456dev requested a review from a team as a code owner December 25, 2024 02:01
@456dev
Copy link
Contributor Author

456dev commented Dec 25, 2024

Fixed #11364 with new api

/**
* @deprecated Incomplete api. Use {@link io.papermc.paper.block.Lidded} instead.
*/
@Deprecated // Paper - Deprecate Bukkit's Lidded API
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: remove this lone // paper comment

Suggested change
@Deprecated // Paper - Deprecate Bukkit's Lidded API
@Deprecated

* Cancelling this event prevents the player from being considered in other {@link Lidded} methods:
* they will not contribute to the {@link Lidded#getTrueLidState()} and {@link Lidded#getEffectiveLidState()}.
* <p>
* This event is called twice for double chests, once for each half.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: fix global implementation for double chests.

iirc as well as this double-fire behaviour, modifying the state of the non-dominant half doesnt play a sound, but still keeps the animation open seperately.

LidState getEffectiveLidState();

/**
* Gets how the lid would be without any lidded mode, based on players interacting with the block.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: replace with smth like

Suggested change
* Gets how the lid would be without any lidded mode, based on players interacting with the block.
* Gets how the lid would be with {@link LidMode.DEFAULT}
* I.E. based on players interacting with the block.


import org.jspecify.annotations.NullMarked;

@NullMarked
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually needed, since its a very simple enum?

@kennytv kennytv added the type: feature Request for a new Feature. label Dec 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Request for a new Feature.
Projects
Status: Awaiting review
Development

Successfully merging this pull request may close these issues.

2 participants