Sign update

[TheLimeGlass]

Description

• Updated ExprSignText to modern standards.
• Added Skript's ChatFormat support with Adventure API.
• Added support for multiple signs.
• Did all the versioning for 1.20 where there can now be two sides to a sign.
• Added changers as Njol's comment from 9 years stated to do.

Notes:

• This class is a large review due to versioning, adventure api AND 1.20 changes. o7
• BlockState#update(boolean, boolean) is 1.13+ so no need for try/catch anymore, also made the force boolean true because the user is modifying the value.
• I have an aliases update for 1.20 covering many sign features Aliases for 1.20 skript-aliases#88

---

Target Minecraft Versions: any
Requirements: Paper is optional
Related Issues: #4576 #5778

[TheLimeGlass]

Changed to a functional interface to support:

Sign::getLines
Sign::getLine
Sign::setLine
Sign::line
SignChangeEvent::getLines
SignChangeEvent::getLine
SignChangeEvent::setLine
SignChangeEvent::line
SignSide::getLines
SignSide::getLine
SignSide::setLine
SignSide::line

Tests failing is not related to this pull request. Fix at #6433

[APickledWalrus]

What is the point of these static methods? Why not just call setLineMethod.setLine(line, value) directly? Rather than all of these interfaces, I think it would be better just to have a Spigot and Adventure implementations of an interface with set/get methods. The Adventure implementation can handle the string->component conversions.

[TheLimeGlass]

It's required to be static, because that's how FunctionalInterface works. One method must be static.

Adventure doesn't exist on Spigot, so you can't rely on Adventure to handle the string to component conversions as the method doesn't exist.

It's a functional interface because AdventureSetSignLine has to be a separate class due to the classes not existing and needing to be statically initialized.

[APickledWalrus]

There should be no problem to call the interface methods directly? There's no requirement for there be a static method.

If the Adventure implementation is used only on Paper, I don't see why it would be an issue to handle the component parsing in the interface implantation rather than the syntax's change method. I think the implementation right now is somewhat over complicated for what we need

[TheLimeGlass]

I don't agree with it being more complex. It's making it simpler to read. You have to deal with all the provided methods I posted #5797 (comment)

[APickledWalrus]

I think it's unnecessary for the Adventure interface to be something we're specifically checking for in change. There should just be an implementation for Adventure of SetSignLine that handles the component conversion (that way adventure doesn't need passed/handled as it's own parameter). Additionally, I'm still not seeing why these static methods are necessary. If you have the interface object, why can't you just call the method it has directly?