Closed UnknownShadow200 closed 2 years ago
This is because the classic client also trims leading whitespace.
The trimming normally gets cancelled out, because of the implicit &S
that p.Message inserts before majority of messages sent to the player - which ends up creating an invisible &e
before the leading whitespace.
However, in the case of &a
, the implicit &e
is removed so you end up with leading whitespace
Worked example (normal)
1) Call p.Message with Test
2) p.Message adds implicit &S
- string is now &S Test
3) Linewrapper.CleanupColors processes string - &S
is converted to &e
4) Player is sent &e Test
Worked example (problem)
1) Call p.Message with &aTest
2) p.Message adds implicit &S
- string is now &S &aTest
3) Linewrapper.CleanupColors processes string - &S
is converted to &e
, then &e
is removed since there are no 'visible' (non-space) characters between it and the next color code of &a
4) Player is sent &aTest
So solution is to change Linewrapper.CleanupColor to replace previous color with next color, instead of removing previous color and then appending next color. (for the above problematic example, this change would mean &a Test
would be produced instead)
Need to test to ensure this doesn't break anything though..
Also, if default system color (&S
) is changed to &f
instead, then the trimming will no longer be cancelled out. Not sure if that's worth fixing too though
(Sidenote: Due to an oversight, Linewrapper.CleanupColor when given the input &S &fTest
actually produces &fTest
instead of the optimal Test
. But since this is actually desired behaviour, the oversight will remain)
Note: It's still technically not completely optimal, because "&f &aT"
produces " &aT"
instead of expected "&a T"