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"
    }
  ]
}

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 '='