new lines are white about velocity HOT 21 CLOSED

@PurpleIsEverything That's fine - I often store messages like that too. However, the color coded messages need to be deserialized using the appropriate method on the ComponentSerializers.LEGACY instance, not using LegacyChatColorUtils.

@astei No reason why plugin authors should be performing any sort of legacy text manipulation - the Velocity API accepts Components in all places. Soooo I still stand by my opinion that the class has no place being in the API at all 😄

from velocity.

By that, he means that in general, you should be working in the JSON world, and only use legacy text in limited situations (backwards compatibility, reading from configuration, ...) That is, only deserialize and serialize legacy text, never manipulate it.

from velocity.

ComponentSerializers.LEGACY does what most people need with components, especially since it takes in a custom format code. I will open a PR to remove the translate method.

I am keeping LegacyChatColorUtils#removeFormatting(): ComponentSerializers.PLAIN.serialize(ComponentSerializers.LEGACY.deserialize("")) isn't particularly concise and does more work than it needs to.

from velocity.

@DoNotSpamPls ComponentSerializers.LEGACY.deserialize(String, char) does what you need, just pass in '&'.

from velocity.

It is probably sending the message as 2 separate messages, which means that the second message doesn't have any color codes in front of it. An easy fix would to be to add color codes after the linebreak.

from velocity.

He's probably talking about the automatic line breaks when the message gets longer than 1 line. I fixed that by using the legacy ComponentSerializer (or whatever that is called). But yeah, it's a bit of an issue.

from velocity.

try use
ComponentSerializers.LEGACY.deserialize(message, '&');

from velocity.

This isn't an issue in Velocity, AFAIK. If there is a bug, it is in KyoriPowered/text.

from velocity.

@BukkitTNT Can you show the code you're using to send the message?

from velocity.

@lucko while I'm not mr. BukkitTNT, with this code you can see the bug for yourself, this is the result:

The raw TextComponent.builder() does not have this issue, so the issue I opened above is really invalid, it seems to be a bug with the LegacyChatColorsUtil.translate() thing

from velocity.

Your code doesn't compile.

Line 35:

@NonNull String message = ComponentSerializers.LEGACY.deserialize(builder.substring( 0, builder.length() - 1 ));

is not valid.

The deserialize method does not return a string.

from velocity.

LegacyChatColorUtils shouldn't really be in the Velocity API. It has no valid use in plugins.

The correct/improved version of the code you gave is as follows.

https://gist.github.com/lucko/cbef3c9e383201163371f68d6f4ea244

from velocity.

@lucko I really do agree with you here, but I'm loathe to make any more breaking API changes. I have two in the works already.

I do however find removeFormatting to be useful enough that it ought to stay.

from velocity.

Better to make breakages now as opposed to later.

I'd argue that any current usages of that class are by mistake - you're doing plugin authors a favour by removing it.

from velocity.

@lucko whoops, I meant to remove the ComponentSerializers part entirely, and just leave the LegacyChatColorUtils above.

from velocity.

You shouldn't be using LegacyChatColorUtils. I've posted the correct usage above.

As I said in the Kyori/text issue:

The 'white text after line break' issue usually occurs when legacy formatting codes are used inside the "text" component instead of using the color attribute.

which is exactly what you're doing. 😉

from velocity.

I personally very rarely hard-core chat messages so I do make use of the & color code deserialization.

from velocity.

@PurpleIsEverything lucko has a point though, there is zero need to use the LegacyChatColorUtils, because the legacy deserializer from Kyori/text can already handle that 😃

from velocity.

Sounds good to me too.

from velocity.

@lucko as a plugin author, I use the legacy deserializer to parse messages from the config that use the & color code, since having JSON monstrosities in the config isn't really very user-friendly. I'd much rather give them the option to just type "&e&lHello world!" and me parsing it from there 😛

from velocity.

Yes, I'm using that, I'm just talking about lucko's opinion that no reason why plugin authors should be performing any sort of legacy text manipulation. Otherwise I'm fine with the removal of the utility found in Velocity

from velocity.