Skip to content

Add API around client-side only Signs#9786

Closed
Sytm wants to merge 1 commit into
PaperMC:masterfrom
Sytm:client-side-sign
Closed

Add API around client-side only Signs#9786
Sytm wants to merge 1 commit into
PaperMC:masterfrom
Sytm:client-side-sign

Conversation

@Sytm
Copy link
Copy Markdown
Contributor

@Sytm Sytm commented Oct 2, 2023

Signs are commonly used as multi-line text input, so this should be part of the API.

Anvils are also frequently used for that, but they only offer single-line text (although they are already part of the Paper API)

@Sytm Sytm requested a review from a team as a code owner October 2, 2023 14:22
Copy link
Copy Markdown
Contributor

@lynxplay lynxplay left a comment

Choose a reason for hiding this comment

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

Given that there is a PlayerUseUnknownEntityEvent, I think this is better left like it initially was, only called for unknown signs to not interfere with "normal" API usage.

@Sytm
Copy link
Copy Markdown
Contributor Author

Sytm commented Oct 11, 2023

My reasoning for doing it this way has been that while the unknown entities are known to be actually unknown because of the continually increasing entity id, there could be already a sign placed at the location where the local sign should be opened, so when he closes the sign editor the sign change handling would be passed to the real api which shoots it down before the event is called because the player wasn't allowed to do so.

This wouldn't require searching for a free space around the player to send him a sign and unify the possible handling of them with one event instead of maybe two (if it were to actually work)

@Sytm
Copy link
Copy Markdown
Contributor Author

Sytm commented May 30, 2024

So what's the current stance on this PR? I'd still like to see it added in this form, but I haven't gotten an answer on my previous comment

@Owen1212055
Copy link
Copy Markdown
Member

Hmm, I agree something like this is certainly useful. But the current event name is defo a bit misleading as we definitely want to make sure there is a distinction as people might blindly listen to this event.

I agree that it might be useful to have an "unknown" one and then a normal one.

@Sytm
Copy link
Copy Markdown
Contributor Author

Sytm commented Jun 7, 2024

I have changed the name of the event to differentiate it more from the normal event.

I am still not sold on the concept to only call this event when there isn't an actual sign to edit, because of the points I already mentioned above.

@Sytm Sytm closed this Jan 4, 2025
@Sytm Sytm deleted the client-side-sign branch January 4, 2025 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Closed

Development

Successfully merging this pull request may close these issues.

4 participants