Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
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.
{
"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"
}
]
}
@bitbrain

This comment has been minimized.

Show comment Hide comment
@bitbrain

bitbrain May 22, 2013

Looks great!

Looks great!

@lukasbach

This comment has been minimized.

Show comment Hide comment
@lukasbach

lukasbach May 22, 2013

Awesome :D
Hey dinnerbone, is there a possibility to color the name from command blocks? (Or will there be ever a possibility?)

Awesome :D
Hey dinnerbone, is there a possibility to color the name from command blocks? (Or will there be ever a possibility?)

@wlritchi

This comment has been minimized.

Show comment Hide comment
@wlritchi

wlritchi May 22, 2013

What's the official position on servers "firewalling" chat messages? I assume size limits will be enforced, but will/should there be any other restrictions?

What's the official position on servers "firewalling" chat messages? I assume size limits will be enforced, but will/should there be any other restrictions?

@Fishrock123

This comment has been minimized.

Show comment Hide comment
@Fishrock123

Fishrock123 May 22, 2013

.json 👍

.json 👍

@HarrisonC

This comment has been minimized.

Show comment Hide comment
@HarrisonC

HarrisonC May 22, 2013

Nice Work

Nice Work

@ZeroErrors

This comment has been minimized.

Show comment Hide comment
@ZeroErrors

ZeroErrors May 22, 2013

This looks like a much better way.

Does the time command need a usage for the translate, commands.time.usage, with the time and if it was added, subtracted or set?

This looks like a much better way.

Does the time command need a usage for the translate, commands.time.usage, with the time and if it was added, subtracted or set?

@tehbeard

This comment has been minimized.

Show comment Hide comment
@tehbeard

tehbeard May 22, 2013

Nice, but what would happen if a "translation" is not available on a client?

Nice, but what would happen if a "translation" is not available on a client?

@lukasbach

This comment has been minimized.

Show comment Hide comment
@lukasbach

lukasbach May 23, 2013

@tehbeard probably use the english version from the text

@tehbeard probably use the english version from the text

@grum

This comment has been minimized.

Show comment Hide comment
@grum

grum May 23, 2013

Or give an error that it was unable to find the key in the translation data (if en_US is also not available).

grum commented May 23, 2013

Or give an error that it was unable to find the key in the translation data (if en_US is also not available).

@dequis

This comment has been minimized.

Show comment Hide comment
@dequis

dequis May 23, 2013

Is there going to be a vanilla API (not the mod api, just a function in the vanilla code) to translate legacy § coded strings to this json format? Looks like a pain in the ass to force every plugin/mod to build all these objects to get simple formatting working.

Of course this is going to be great when flexibility is needed and will get rid of all the ugly bugs with § (I never got around to understand them to submit a proper bug report, though).

Also, will the client notify the server about the preferred language? Server side only mods could benefit from that, since they can't use client side translation data.

dequis commented May 23, 2013

Is there going to be a vanilla API (not the mod api, just a function in the vanilla code) to translate legacy § coded strings to this json format? Looks like a pain in the ass to force every plugin/mod to build all these objects to get simple formatting working.

Of course this is going to be great when flexibility is needed and will get rid of all the ugly bugs with § (I never got around to understand them to submit a proper bug report, though).

Also, will the client notify the server about the preferred language? Server side only mods could benefit from that, since they can't use client side translation data.

@jgierer12

This comment has been minimized.

Show comment Hide comment
@jgierer12

jgierer12 May 23, 2013

@questcube You can already do this (with an NBT editor)

@questcube You can already do this (with an NBT editor)

@kblackcn

This comment has been minimized.

Show comment Hide comment
@kblackcn

kblackcn May 23, 2013

So cool!

So cool!

@dries007

This comment has been minimized.

Show comment Hide comment
@dries007

dries007 May 23, 2013

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

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

@Mrkol

This comment has been minimized.

Show comment Hide comment
@Mrkol

Mrkol May 23, 2013

Wow, looks alot simpler than it is right now!

P.S.
JSON is the new minecraft trend!

Mrkol commented May 23, 2013

Wow, looks alot simpler than it is right now!

P.S.
JSON is the new minecraft trend!

@md-5

This comment has been minimized.

Show comment Hide comment
@md-5

md-5 May 24, 2013

Wow, looks alot simpler than it is right now!

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

md-5 commented May 24, 2013

Wow, looks alot simpler than it is right now!

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

@SirCmpwn

This comment has been minimized.

Show comment Hide comment
@SirCmpwn

SirCmpwn May 24, 2013

  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.

  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.

@md-5

This comment has been minimized.

Show comment Hide comment
@md-5

md-5 May 24, 2013

Also line 45 should be chat.type.text

md-5 commented May 24, 2013

Also line 45 should be chat.type.text

@Dinnerbone

This comment has been minimized.

Show comment Hide comment
@Dinnerbone

Dinnerbone May 24, 2013

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.
Owner

Dinnerbone commented May 24, 2013

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.
@wrincewind

This comment has been minimized.

Show comment Hide comment
@wrincewind

wrincewind May 24, 2013

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?

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?

@rogermb

This comment has been minimized.

Show comment Hide comment
@rogermb

rogermb May 24, 2013

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

rogermb commented May 24, 2013

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

@dequis

This comment has been minimized.

Show comment Hide comment
@dequis

dequis May 25, 2013

@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.

dequis commented May 25, 2013

@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.

@dries007

This comment has been minimized.

Show comment Hide comment
@dries007

dries007 May 25, 2013

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?

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?

@md-5

This comment has been minimized.

Show comment Hide comment
@md-5

md-5 May 25, 2013

@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.

md-5 commented May 25, 2013

@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.

@SirCmpwn

This comment has been minimized.

Show comment Hide comment
@SirCmpwn

SirCmpwn May 25, 2013

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.

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.

@md-5

This comment has been minimized.

Show comment Hide comment
@md-5

md-5 May 26, 2013

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

md-5 commented May 26, 2013

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

@Afforess

This comment has been minimized.

Show comment Hide comment
@Afforess

Afforess May 26, 2013

Like it. Nice work!

Like it. Nice work!

@Claycorp

This comment has been minimized.

Show comment Hide comment
@Claycorp

Claycorp May 27, 2013

@Dinnerbone
I don't really know anything about JSON or java but one thing i do know is about servers. I've ran my fair share of servers small to large modded vanilla bukkit you name it... I know when something falls out of popularity for something better or different. I can guarantee you that changing something by a tenfold is an issue compressed or not servers are not cheap, internet is not cheap. People who run servers don't want to pay more for just because your fixing something that isn't broken beyond fixing. There's far to few issues with what is currently in place for a full rework of the chat system.

Also whats so much better about this? I don't see any point in this at all its not adding anything that is better than what exists, plus everyone who has any mods server wrappers or whatever that uses the current text will need to change it breaking many mods that people like.

Until some GOOD and USEFUL points are CLEARLY pointed out and explained on HOW and WHY this is BETTER (beyond some pathetic translations) route to take i see no point and look at it as a step backwards not forwards.

@Dinnerbone
I don't really know anything about JSON or java but one thing i do know is about servers. I've ran my fair share of servers small to large modded vanilla bukkit you name it... I know when something falls out of popularity for something better or different. I can guarantee you that changing something by a tenfold is an issue compressed or not servers are not cheap, internet is not cheap. People who run servers don't want to pay more for just because your fixing something that isn't broken beyond fixing. There's far to few issues with what is currently in place for a full rework of the chat system.

Also whats so much better about this? I don't see any point in this at all its not adding anything that is better than what exists, plus everyone who has any mods server wrappers or whatever that uses the current text will need to change it breaking many mods that people like.

Until some GOOD and USEFUL points are CLEARLY pointed out and explained on HOW and WHY this is BETTER (beyond some pathetic translations) route to take i see no point and look at it as a step backwards not forwards.

@SnoFox

This comment has been minimized.

Show comment Hide comment
@SnoFox

SnoFox Jun 6, 2013

@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.

SnoFox commented Jun 6, 2013

@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.
@coelho

This comment has been minimized.

Show comment Hide comment
@coelho

coelho Jun 11, 2013

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.

coelho commented Jun 11, 2013

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.

@Hoolean

This comment has been minimized.

Show comment Hide comment
@Hoolean

Hoolean Jun 25, 2013

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

Hoolean commented Jun 25, 2013

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

@oloflarsson

This comment has been minimized.

Show comment Hide comment
@oloflarsson

oloflarsson Jun 30, 2013

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.

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.

@coelho

This comment has been minimized.

Show comment Hide comment
@coelho

coelho Jul 1, 2013

@oloflarsson

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

It's not.

coelho commented Jul 1, 2013

@oloflarsson

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

It's not.

@Dav1dde

This comment has been minimized.

Show comment Hide comment
@Dav1dde

Dav1dde Jul 1, 2013

@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).

Dav1dde commented Jul 1, 2013

@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).

@arjunyg

This comment has been minimized.

Show comment Hide comment
@arjunyg

arjunyg Jul 23, 2013

@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....)

arjunyg commented Jul 23, 2013

@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....)

@tigerw

This comment has been minimized.

Show comment Hide comment
@tigerw

tigerw Sep 14, 2013

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.

tigerw commented Sep 14, 2013

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.

@wernovox

This comment has been minimized.

Show comment Hide comment
@wernovox

wernovox Feb 14, 2016

Shit '='

Shit '='

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment