TheMuffinPony
- TheMuffinPony
- themuffinpony
- America/New_York
- Yes
- No
Itemsin Villager GUI glitchItem tag in Villager GUI glitch
If you are in spectator mode (/gamemode <3|spectator> [Name/Selector]) and you sprint while on or in a block, you see particles.
==============
What I expected: Particles would be invisible.
What Happened: Particles are visible.
==============
REPRODUCTION:
==============
1) Go into Spectator Mode ('/gamemode 3')
2) Go into/onto a block
3) Hold CTRL/your Sprint key
4) See your particles
Best seen if you are being supported on a block (i.e. not flying) and then switching
==========
Possible duplications:
MC-94535- Flying and holdingsprint showsparticles
(doesn't mention spectator mode/must be on a block)If you are in spectator mode (/gamemode <3|spectator> [Name/Selector]) and you sprint while on or in a block, you see particles.
==============
What I expected: Particles would be invisible.
What Happened: Particles are visible.
==============
REPRODUCTION:
==============
1) Go into Spectator Mode ('/gamemode 3')
2) Go into/onto a block
3) Hold CTRL/your Sprint key
4) See your particles
Best seen if you are being supported on a block (i.e. not flying) and then switching
==========
Possible duplications:
MC-94535- Flying and holding CTRL really close to the ground, emits walking particles
(doesn't mention spectator mode/must be on a block)
macOS Sierra (v 10.12.3 [16D32]), running launcher V2.0.805 and Minecraft Server 17w06a provided by minecraft.net, RAM: 12 GB client, 8 GB server
Minecraft Realms
Doing
/tellraw (selector) []{/code} will kick them with a big longmessage:Internal Exception: io.netty.handler.codec.DecoderException: com.google.JsonSyntaxException:
{/code}
com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 1
This works with any other array of square brackets, ex.[[]]{/code}Now, this can be exploited by using a Repeating Command Block to do
/tellraw @a []{/code}, effectively denying anyone from joining a server/realm/world. This doesn't work with curly brackets, as it says "Invalid json: ". The only good use for this is to give Realm owners a limited version of/kick
{/code}to kick spamming players from the server.
Doing
/tellraw (selector) []will kick them with a big long message:
Internal Exception: io.netty.handler.codec.DecoderException: com.google.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 1This works with any other array of square brackets, ex.
[[]]Now, this can be exploited by using a Repeating Command Block to do
/tellraw @a [], effectively denying anyone from joining a server/realm/world.
This doesn't work with curly brackets, as it says "Invalid json: ".
The only good use for this is to give Realm owners a limited version of
/kickto kick spamming players from the server.
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** THIS COULD POSSIBLY AFFECT 1.11.2!!! ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
Okay.
Reproduction: Using the server console, enter this command.Console Command/say § § § § § § § § § § § § § § § § § § § § § § § § § § § § § § etc.
![]()
![]()
This text must be executed from the server console!
![]()
![]()
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** THIS COULD POSSIBLY AFFECT 1.11.2!!! ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
Okay.
Reproduction: Using the server console, enter this command.Console Command/say § § § § § § § § § § § § § § § § § § § § § § § § § § § § § § etc.
![]()
![]()
This text must be executed from the server console!
![]()
![]()
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** THIS COULD POSSIBLY AFFECT 1.11.2!!! ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
How to reproduce
Use the following command in a command block and right click the created sign
/setblock ~ ~1 ~ standing_sign default replace {Text1:"{\"text\":\"Click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/say \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** It does NOT work by using the \u00A7 JSON escape character! Please use method below. ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
How to reproduce
Run this in a command block then use (default right click) the created sign above./setblock ~ ~1 ~ standing_sign default replace {Text1:"{\"text\":\"Click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/say \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}As noted above, do NOT use JSON escape codes; they must be sent as section signs to the client. As mentioned, use the sign above (as the \u00A7 is actually converted into a section sign).
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** It does NOT work by using the \u00A7 JSON escape character! Please use method below. ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
How to reproduce
Run this in a command block then use (default right click) the created sign above./setblock ~ ~1 ~ standing_sign default replace {Text1:"{\"text\":\"Click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/say \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}As noted above, do NOT use JSON escape codes; they must be sent as section signs to the client. As mentioned, use the sign above (as the \u00A7 is actually converted into a section sign).
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** It does NOT work by using the \u00A7 JSON escape character! Please use method below. ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
How to reproduce
Run this in a command block then use (default right click) the created sign above./setblock ~ ~1 ~ standing_sign default replace {Text1:"{\"text\":\"Click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/say \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7 \u00A7\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}As noted above, do NOT use JSON escape codes; they must be sent as section signs (not escape codes) to the client. Instead, use the sign above (as the \u00A7 is actually converted into a section sign and sent as a section sign to the client, instead of \u00A7).
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** It does NOT work by using the \u00A7 JSON escape character! Please use method below. ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
How to reproduce
Run this in a command block then use (default right click) the created sign above./setblock ~ ~1 ~ standing_sign default replace {Text1:"{\"text\":\"Click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/say \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}As noted above, do NOT use JSON escape codes; they must be sent as section signs (not escape codes) to the client. Instead, use the sign above (as the \u00A7 is actually converted into a section sign and sent as a section sign to the client, instead of \u00A7).
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** It does NOT work by using the \u00A7 JSON escape character! Please use method below. ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
How to reproduce
Run this in a command block then use (default right click) the created sign above./setblock ~ ~1 ~ standing_sign default replace {Text1:"{\"text\":\"Click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/say \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}As noted above, do NOT use JSON escape codes; they must be sent as section signs (not escape codes) to the client. Instead, use the sign above (as the \u00A7 is actually converted into a section sign and sent as a section sign to the client, instead of \u00A7).
Code analysis by @Marcono1234
Section sign with invalid formatting character afterwards can exceed chat window boundaries
*** It does NOT work by using the \u00A7 JSON escape character! Please use method below. ***
I am a decent command blocker, and I do use section signs whenever I can't use JSON text and would like/need color. I mainly do this in applications such as custom item names, scoreboard team prefixes, etc. To do so, I use the Server Console to give me a Command Block with section signs, because the Server Command prompt allows section signs.
However, running an excessive amount of section signs with no valid formatting character after them can lead to some weird glitches; such as this one exceeding maximum chat window boundaries. If you would like any more information, feel free to comment below!
Launcher and server output[@] § § § § § etc.
How to reproduce
Run this in a command block then use (default right click) the created sign above./setblock ~ ~1 ~ standing_sign default replace {Text1:"{\"text\":\"Click\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"/say \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7 \\u00A7\"}}",Text2:"[\"\"]",Text3:"[\"\"]",Text4:"[\"\"]"}As noted above, do NOT use JSON escape codes; they must be sent as section signs (not escape codes) to the client. Instead, use the sign above (as the \u00A7 is actually converted into a section sign and sent as a section sign to the client, instead of \u00A7).
Code analysis by @Marcono1234
It looks like the method FontRenderer.getCharWidth(char) is causing problems because it returns -1 for the section sign. But I am not sure if this is even worth fixing since as far as I know the goal is to switch everything to text components at some point.
The "r"s come from the "§r" which is appended to every text component, however "§§r" is then processed as invalid formatting resetting style and "r".
Using /recipe give * should give the executing player all recipes, but instead returns "Player '*' cannot be found". Furthermore, doing /recipe give <a selector/name> will give an internal error.
Leaving a command blank in a chain command block results in "Unknown command."
Hey there, I've seen a bug with prefixing names using scoreboard teams. DISCLAIMER: This uses very slight modding, but the issue doesn't relate to modding
The bug
Quick background info
You can use a program like NBTExplorer to change a team's prefix. Normally, this is just for scoreboard teams option <team> color <color> to put, say, §a when setting color to green so that players' names on that team are green.
However, when changing the prefix using a program like NBTExplorer so that it is over 16 characters, it is over the limit and you can not join a server/Realm. The bug here is that if you join a singleplayer world, there is no limit compared to multiplayer worlds and it does not kick you, which is a big pain for testing.
Other info
What I expected
When it went over the limit in a singleplayer world, it would kick me/throw an error in the launcher log/etc.
What actually happened
I could use it just fine over the limit in a singleplayer world, but multiplayer worlds/servers will give me an error. This is a big pain for testing.
How it could be fixed
Simply add the limit to singleplayer or expand it to, say, 4096*.
* I was making prefixes for someone's server world and needed to test it in singleplayer when it worked fine. I gave it to him and he installed it on his server, only to have an error given. This was a big pain for both me and most likely him.
The bug
- If a Realm Owner does something that causes a player to be kicked (due to being uninvited, world option changes etc), it will always say Kicked by an operator. even though "Operators" (in Realms terms) nor the owner can use /kick
.
What I expected
- When a player was kicked off of a realm, it would show why (ex. "You have been removed from the Realm whitelist.").
What
happened
No matter how you try to kick a player off (more on that below), it will say "Kicked by an operator."
Reproduction
- You will need 2 players, one of which must own a Realm. I will refer to them as Owner and Observer.
Close and open theRealm while the Observer is online. The Observer sees a kick screen that says "Kicked by an operator".- C
hange a setting in the Realm config menu (ex. Enable Command Blocks, Difficulty). Once again, the Observerwillsee a kickmessagesaying"Kicked by an operator".Switch worlds. Unsurprisingly, the Observer gets kicked with themessage "Kicked by an operator".- Remove the Observer from the invited players list. You know what it will say
A fix
- Add kick messages which are localized, ex. disconnect.realms.setting=
Setting(s)have been changed that requireaRealmRestart.Sidenote
This seems a little like a suggestion, but it is a bug because neither Operators nor Owners can kick players (they are granted OP level 2 and the Owner has extra permissions through the Configure GUI), thus the message is false.
The bug
- If a Realm Owner does something that causes a player to be kicked (due to being uninvited, world option changes, etc.), it will always say Kicked by an operator. even though "Operators" (in Realms terms) nor the owner can use /kick even using the Configure panel (without uninviting and re-inviting the player, similar to running /ban and then /pardon on the same player in a short time frame).
Reason for the bug
- When the player does an action, the Realms program runs /kick <playername> for each player (since /kick @a isn't a possibility) on the console (or some custom external java function called by the Realms 'system' that 'runs' the realm), but does not specify a reason.
What I expected
- When a player was kicked off of a realm, it would show why (ex. "You have been removed from the Realm whitelist.").
What happened
- No matter how you try to kick a player off (more on that below), it will say "Kicked by an operator."
Reproduction
- You will need 2 players, one of which must own a Realm. I will refer to them as Owner and Observer (not to be confused with the block).
- Close and open the Realm while the Observer is online. The Observer sees a kick screen that says "Kicked by an operator".
- Change a setting in the Realm config menu (ex. Enable Command Blocks, Difficulty). Once again, the Observer will see a kick message saying "Kicked by an operator".
- Switch worlds. Unsurprisingly, the Observer gets kicked with the message "Kicked by an operator".
- Remove the Observer from the invited players list. "Kicked by an operator". What else would you expect?
A fix
- Add kick messages which are localized, ex. disconnect.realms.setting=Realm settings have been changed that require the Realm to restart.
- This would require a little tinkering with the server source code (since as of 1.12.1, all kick messages can only be entered as plain text) to allow usage of external JSON kick messages (which would also be useful for regular server administration).
Sidenote
This seems a little like a suggestion, but it is also a bug because neither Operators nor Owners can kick players (all players are granted OP level 2 which only includes singleplayer commands (not /ban, /kick, etc, and the Owner has extra permissions through the Configure GUI which cannot kick players without uninviting/reinviting them), thus the message is false.
Edits
- Changed a few things primarily for clarity. Also added edit and reason for bug sections.







Attachment: http://i.imgur.com/lo5FouI.png
{Lore:["This","Lore","is","VERY","long","to","help","fix","bugs","and","with","this","lore","We","can","fix","bugs","because","of","this","very","long","lore","that","is",":?:","lines","long","so","we","can","fix","MC","-","92527","with","this","very","very","very","very","very","long","lore","so","let","'s","go","fix","it","!"]}Command:
/give @p diamond_sword 1 0 {display:
}
Okay... how do I delete this
Edited
MC-94535text and selected gamemodeYes
Question: Can you revamp the command so that it is /fill <coordinates> <name> [dataValue|state] replace [<blockToReplace> [dataValue|-1|state|*]] [fillBlockDataTag]?
(It is easy to detect a <code>{</code> vs a different character for starting an item technical name in my opinion)
So, if you wanted to replace wood planks with chests (with a bow inside) between 0, 0, 0 and 1, 1, 1, you would do {{/fill 0 0 0 1 1 1 chest 0 replace planks * {Items:[0:
{Slot:0,Item:"minecraft:bow",Count:1b,Damage:0s}]} }}.
However, if you wanted to fill chests regardless of planks, you would remove the planks *.
Wow. This is basically the equiv. of the 15w34c memory allocation crash (in my opinion as a server manager). This REALLY needs to be fixed IMMEDIATELY. Can confirm for macOS .jar.
Why is this a security issue? Couldn't you just have some sort of verification thing? I'm surprised on what the server depends on (stuff like giving skin urls) and what the client depends on (sending inventory to server repeatedly).
Appears to be fixed in 1.12
Can confirm for 1.12...
Appears to be fixed as of 1.13