New chat system for Minecraft. The server won't translate any text for the client, and there'll be a proper stack based colouring/formatting system, so no more leaking colours, english-only messages, or out of date translations.

gistfile1.json

{
  "color": "yellow",
  "translate": "multiplayer.player.joined",
  "using": [
    "Dinnerbone"
  ]
}

{
  "color": "gray",
  "italic": true,
  "text": [
    "[",
    "Dinnerbone",
    ": ",
    {
      "translate": "commands.give.success",
      "using": [
        "Stone",
        "1",
        "1",
        "Dinnerbone"
      ]
    },
    "]"
  ]
}

{
  "translate": "death.attack.outOfWorld",
  "using": [
    "Dinnerbone"
  ]
}

{
  "translate": "death.attack.explosion.player",
  "using": [
    "Dinnerbone",
    "Creeper"
  ]
}

{
  "translate": "chat.type.chat",
  "using": [
    "Dinnerbone",
    "Hello, world!"
  ]
}

{
  "translate": "chat.type.emote",
  "using": [
    "Dinnerbone",
    "dances"
  ]
}

{
  "color": "red",
  "translate": "commands.generic.usage",
  "using": [
    {
      "translate": "commands.time.usage"
    }
  ]
}

So cool!

From a modders point of view: oh god no....

Wow, looks alot simpler than it is right now!

P.S.
JSON is the new minecraft trend!

Wow, looks alot simpler than it is right now!

What exactly are you smoking? Have you ever tried to make a custom server.

1. Increases network usage tenfold
2. Requires 3rd party servers to have the lang files (those aren't distributable)
3. Far more expensive to decode/encode
4. More RAM usage
5. Adds dependencies
6. Fixes a non-existent problem

Why? The § thing wasn't great, but this seems far worse.

Also line 45 should be chat.type.text

SirCmpwn:

1. Increases this packets size tenfold; not at all total network use. If it becomes an issue we can compress and end up with less than we started.
2. No. That's the point of this change. They needed the langfiles before, now they don't.
3. If chat is such a significant resource hog for your custom server, thread it. You have other issues to worry about though.
4. Insignificant amounts.
5. Ok. Dependencies are bad? We already had json handling.
6. Fixes so many long-existing problems. See 2.

Oh, man this looks good. all this work to the modding API! ...i find it funny that most people are so focused on the little things, and can't see that just about everything in this update is API-flavoured. incidentally, the attribute system looks sweet. hey, maybe putting an item+a potion on an anvil can add the potion's attributes to the item! [for a ton of levels, of course]. gold helmet of speed, anyone?

So how would (e.g. on Bukkit servers) custom plugin messages with multiple colors work?

@Dinnerbone I can't help but feel that if formatting is part of the issue, this is an overkill solution. Yes, § had issues, the main ones that affected me were §r and §f behaving the same way (white resets all formatting), bold/italic/etc not cancelling each other, and the client freaking out if the formatting codes were too complex then deciding to apply everything from the start of the beginning of the line.

All of this is fixable, maybe changing behavior a bit. None of this justifies the increased bandwidth usage, CPU time, and the complexity of sending formatted messages that aren't just what the vanilla server needs to send.

IMO, saying "you can compress/thread it and forget about the issue" seems like a cheap excuse to write code that is inefficient from the beginning. There are huge servers out there that care about the resources, you know. There's people writing filtering proxies to remove unneeded packets, because they care about efficiency. And if you solve the issue by compressing, you'll trade bandwidth for cpu time. And if you thread it, you might end up with big servers dedicating one core exclusively to chat. Hopefully not that much, but i'm just pointing out it might happen.

Yes, § is not trendy or cool or whatever. You know what else isn't trendy? NBT. It's funny how everybody hates that format because it was "made up", but most of minecraft already uses it now, and I think it fits this use case perfectly, but since JSON is what cool kids use, let's ignore the fact that it exists! Yay.

NBT is a really compact representation of data that can be as complex as json. The main advantage of json, IMO, is being human readable, which makes it easy to debug with a any tool, like a packet sniffer. I don't think human readability with a packet sniffer is something we care about, especially not if this is going to be in the middle of the goddamn minecraft protocol, a protocol that is so messy that there's no way to predict the size of each packet, not even from the server code itself.

So if you really want to kill § instead of fixing it, and forget about the fact that sending § formatted messages is a matter of using sprintf()-like templates, and you believe we REALLY need complex data structures, then why the hell not NBT?

(The tweet that links this mentioned allowing cooler web frontends - I'm not quite sure if this was a joke. Any web frontend would require a http server to serve this chat. If this http server is a minecraft mod or plugin, they don't care about the serialization format in the network protocol. If it's not a mod then it has to be a full minecraft bot, for which the difficulty of understanding § is irrelevant next to the rest of the protocol)

Sorry for the long message.

How would you send custom messages from the server to the client with this?
I assume not though chat.type.chat because then you need a player.
Also, multiple colors?

@Dinnerbone
You don't simply thread things, even if threading it takes away from the main tick loop of the server (what if the server is using all available cores already?), this is uneeded CPU cycles being consumed. Take my proxy for example: it has to cater for thousands of users on one server. Now it also needs to decode EVERY chat message sent by EVERY user.

If chat is such a significant resource hog for your custom server, thread it. You have other issues to worry about though.

Almost did a spit-take there. If it's hogging resources, double the resources it consumes?

No. That's the point of this change. They needed the langfiles before, now they don't.

Right, I meant to say custom clients.

Increases this packets size tenfold; not at all total network use. If it becomes an issue we can compress and end up with less than we started.

Adding more compression is a non-insignificant performance hit.

Fixes so many long-existing problems. See 2.

Not really. Lack of lang files wasn't a big deal. There are better ways to do it, too - the server is already aware of the client's desired language, so let it tweak it without client changes. There are other changes you can do without JSON, too, if you want client-side lang decoding. JSON is serious overkill.

Just thought: why isn't this chat format NBT instead of json @dequis :p

Like it. Nice work!

https://gist.github.com/SirCmpwn/c5b3cd93cd424f17edf4

@Dinnerbone, why are you using a data serialization format as opposed to a markup language for fixing chat? We need to be using the right tool for the job. Why not XML, a subset of HTML or even a subset of BB code? These seem like they are better tools for the job.

Regardless if you're going to use JSON or a markup language, you are revamping chat. Should we expect some improvements to chat? Chat is actually fairly terrible with or without JSON and there is a large amount of space to improve it.

• Perhaps adding a container that the server will send website links in, since the Minecraft client can't figure out where those are properly.
• If you're doing away with the subsection character in chat, we shouldn't have to be restricted to 16 colors anymore.
• Most importantly I have to say: I may not be a fan of how you implemented the new chat protocol, but allowing chat to be longer than 100 characters would be also extremely appreciated. Note that a tweet is 140 characters. Making a strong point to a troublesome user is really difficult with less space than a tweet.

This seems so ridiculously inefficient from a server point of view. Do you even realize that there are servers running with up to 4000 players concurrent, that can't afford to be wasting bandwidth (and money) like this?

Not to mention your brackets { and other constructs are using 2 bytes of data instead of 1 due to the use of string16, making it twice as inefficient and showing that it is not correct at all to use json here.

If it ain't broke, don't fix it; and especially don't 'fix' it with something way more inefficient!

This looks like a wonderful change. Keep up the good work @Dinnerbone :)

To those complaining: Please consider that all change is uncomfortable to humans. It's a part of the human nature. You must exercise embracing change. Right now your brains are producing imaginary issues as a way of interpreting your primal reluctance towards change. After using the new system for a couple of weeks you will see none of the issues were real and that in fact the change was an improvement.

@oloflarsson

So you believe that a server using an extra 1gbit pipe on chat online is okay?

It's not.

@coelho
There is hope to get UTF-8, we spoke with Grum and provided a POC implementation, it might make it into Minecraft, there is hope! So at least a bit less bandwith is used (Still JSON overhead is bigger than UTF-8 uses less than UCS-2).

@Dinnerbone
I am currently writing a custom client for mobile devices and I am certainly not looking forward to explaining to a frustrated user why his chat is so slow on 3G data. The protocol if recall correctly went for ~20-50 kbps for a single client (confirmed-ish by some brief not very well controlled tests involving me running around and spamming /say commands to mimick chat on a 1.5.2 client). Then doing the same test on a 1.6 client I got 90-100 kbps, not to mention that actual colored chat from a real server would have 6-8 colors per message, not just 1 like /say. Going on an actual 1.6.2 server with a nice chat going gave me 200 kbps. So while my test might not have been perfectly orchestrated, although I was careful to filter out non-minecraft traffic for my graphs, it seems that the protocol data usage has literally been doubled just from throwing around some JSON structures. People will be spending double/triple an already ridiculous amount of data, which is limited by most cell carriers (in the US at least), just to have chat that is colored Slightly better.

Now the question for Dinnerbone, why do we need JSON? Wouldn't a NBT work just fine?

Thats my take on this.
Thanks for reading,
Arjun

PS: Those entity position updates that everyone was talking about fixing last year never did get fixed did they...? (Probably explains the 100 kbps on the real server test....)

Aw man, I did like my "[INFO] Something" in http://GitHub.com/MC-Server

Now the client will make us colour the whole chat yellow, instead of just the [INFO] bit.

Shit '='