Add API around client-side only Signs#9786
Conversation
lynxplay
left a comment
There was a problem hiding this comment.
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.
|
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) |
|
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 |
|
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. |
|
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. |
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)