Allow getting/setting the sign's editor uuid

[SoSeDiK]

No description provided.

[lynxplay]

While the code generally looks good, could you elaborate a bit on what the usecase for such a setter is?
At least a setter for anything that isn't just null?

Having a bit of a hard time thinking of a usecase that would have a developer set the allowed uuid but not open the sign editor, given this value is terribly fleeting and is reset when the set uuid player is too far gone.

//edit: Additionally, what is the usecase for the uuid getter too? There is no point in time where the uuid getter would yield a non null value when the player one does as a disconnected player would clear the uuid.

[SoSeDiK]

setter

It's quite niche, but is used exactly for that: either to reset the current editor, or to set one without immediately opening the sign screen

getter

Player instance is obtained from uuid, and in some cases only the uuid is needed (e.g. if you just care whether the sign is being edited, or want to get value from Map by uuid). Getting Player isn't that bad for those cases, but since there's setter, getter doesn't hurt

[lynxplay]

or to set one without immediately opening the sign screen.

I am still unsure on what that would useful for. Any way to open said sign via the API would override the allowed editor, so would the player interacting with it. Which kinda only leaves packets, at which point, why have this in the API.

[SoSeDiK]

open said sign via the API would override the allowed editor

Correct, and is expected. Plugins should check whether there's already an editor if they want to avoid overrides.

so would the player interacting with it

I just checked, and other players can't interact with the sign (open it / dye) if there's an editor set, and said editor is within range.

---

Setting the allowed player softly "notifies" other plugins that this sign is occupied without the need to actually open the sign on the same tick, or at all (e.g. you might want to open chest menu instead, and on inventory close, set the editor back no null).

The other way to handle the given example would be to cancel all interact events while you handle your own sign editing, but in my case I do not want to cancel literally all interacts since not all interactions interfere with editor, and other plugins can't know who's occupying the sign.

---

You brought up a good point about the range reset, though. While all my sign interactions are handled within the range, I think a note about this could be added to javadocs? Or even a way to toggle the range check? (but not whether the player's online one)