Allow plain NBT string in ClientboundSystemChatPacket

[kangarko]

Currently the constructor for ClientboundSystemChatPacket takes in a Component or a BaseComponent and performs expensive calculations.

At the end of the day, the system chat message is sent as a String.

I am proposing one extra constructor with plain String to allow developers sending json messages without performance hits.

I am writing my own component parser and currently it has to be converted into JSON String, then CraftChatMessage.fromJSON, then back to String, wasting performance.

[lynxplay]

IDK what version you are looking at, but 1.21 uses a StreamCodec to write the Component into the FriendlyByteBuf.
Paper specifically also has logic in these codecs, so I don't see how we'd expose a string here without rewriting how the packet is serialized, which is a rather large diff for 0 gain on our side.

Not to mention that this is obviously internals.

[electronicboy]

The string tag only works for simple text, i.e. no formatting, etc, otherwise, it's an NBT compound tag, which needs to be encoded anyway, using the same codec system.

There is 0 gain for supporting NBT here, and we generally do not change the internals to support plugins unless there is a good, strong-standing reason to do so. Messing with packet classes for plugins is generally a no-go for long-term maintenance reasons.

[masmc05]

Makes sense.

So you recommend passing CraftChatMessage.fromJSON(String) into the constructor and using it that way? Or what's the best way to send json component messages when I have a string with formatting events at my disposal?

Thanks.

https://docs.papermc.io/paper/dev/component-api/introduction#gsoncomponentserializer

[kangarko]

Not what I asked for. I am having a JSON String instead from my own parser.

[electronicboy]

the best option is generally going to be to not have your own intermediatary layer producing a json string but to deal with the actual underlying components so you can skip the intermediary conversions, but, if you want to go around on a trip, that is going to be your best option, yes. (assuming you desire to keep support with upstream, otherwise, you can use adventure with less of the internals)

[masmc05]

Yeah, you can parse this json string using GsonComponentSerializer to an adventure component, paper in all its methods supports not converting this component to nms component without a reason. So in the system chat packet adventure component is directly passed into the codec and send in binary, without (most probably) converting to nms

[kangarko]

Thank you. I wrote our parser before Adventure came to life. We use javascript conditions and permissions to send different component parts per-receiver and per-sender. I will look into if Adventure can support the edge cases we have in ChatControl.