Mike Dueck
- TrashCaster
- trashcaster
- America/Los_Angeles
- Yes
- No
MC-75678![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
If you use /blockdata to replace the name of a container while it is open, it will not update the name in the GUI.
Rename a mob (I used a villager) to lets say, Bob.
Try to remove the name by using
{CustomName:""}It won't change the name.
The only way to correct this is to kill the mob, and spawn in a new one, which is very inconvenient if you've spent a while trying to fuss with other tags to make your mob display right.Rename a mob (I used a villager) to lets say, Bob.
Try to remove the name by using
{CustomName:""}It won't change the name.
Edit:
I've been told that setting the name to " " will remove the name, but not the nameplate.
This should be corrected regardless, since I assume it is not working as intended.White-space trimming should be turned off, and rendering the name plate should check for both CustomName tag existing, and it not being blank.
The only way to correct this is to kill the mob, and spawn in a new one, which is very inconvenient if you've spent a while trying to fuss with other tags to make your mob display right.
No it isn't. When you do "replaceitem" it says 99, and when you try to test for 106, it doesn't work.
I treated with and without quotes. Nothing works. I tried with the JSON book generator, and that doesn't work. Do not pay "solutions" until you test them.
Put a shield in your off hand, and food in your main hand.
When you are hungry, eat the food. (I tested with cooked beef and a white shield, if that matters)
You will eat the food, and your shield will come up to block.This doesn't happen with inverse slot arrangement, mind you.
Edit: This appears to only be happening in third person, and it's more of a "partial block". Your arm doesn't go up all the way to block.
As the title says, arrows will stick into the player even when the shield blocks them.
Spawn a skeleton in (put something on his head so he doesn't burn up if you test during the daytime).
Get yourself a shield, and block his arrows.
Sometimes an arrow will actually stick into the shield, but usually it sticks into the player.
Edit:
Along with this, when you switch the hand of where your shield is (off hand or main hand) the arrow will stick to the shield accordingly, but it will never flip the direction the arrow faces to accommodate that.
As noted by others, still exists int 15w33c. This also occurs with fishing. (I just so happened to get one on a plain rod on my server
)
To test with the rod, just do:
/give @p fishing_rod 1 0 {ench:[{id:61,lvl:100s}]} /enchant @p lure 3
Expectation: Armor stand would just chill in the back.
Reality: https://www.youtube.com/watch?v=a617KVNG-LINo, I did not have a teleport command running to rotate it or anything. Yes, this world was created in the version used.
Steps to reproduce are available in the video.
Doing a 1 line command that checks for multiple entities (by chaining "as") does not work in command blocks. It does however work when it's done in chat.
The command I used was
/execute as @e[type=item,nbt={Item:{id:"minecraft:flint"}}] as @e[type=item,nbt={Item:{id:"minecraft:feather"}}] as @e[type=item,nbt={Item:{id:"minecraft:stick"}}] run say "Propagated between Flint, Feather, and Stick"Video is here
https://youtu.be/PRT8NMhGawo
Edit: Despite the video showing a conditional command block (which is default, by the way), it doesn't work with an unconditional block either
@Mike Dueck: Christie N used that example as a metaphor. He wanted to say if something changes in the background the foreground hasn't to change necessarily too.
Anyway, this is not a bug, but a feature request, please see: Minecraft Suggestions on Reddit.
Any selectors SHOULD work with spectating players because how will people be able to make adventure maps or pvp maps with alternating spectator/survival without being able to target specific players?
If you want to exclude spectators from being selected, use @a[m=!3]
I love the story for this.
We need more bug reports like this.
What Luke means is if a player hasn't joined yet, their score wont register as being 0, and therefore will not be picked up by the command blocks. If they joined and were set to -1 first, then 0, it works as intended.
LTDR/Too rambly:
The game's default default score doesn't register players properly, and therefore can't be tracked unless added manually with quirky work arounds.
/scoreboard objectives add playerID dummy
/scoreboard objectives add nextPlayerID dummy
/scoreboard players set DUMMYPLAYER nextPlayerID 1
Place a command block:
Fill it with: /scoreboard players operation @p[score_playerID=0] playerID += DUMMYPLAYER nextPlayerID
Place a comparator out of that command block.
Place a command block after the comparator:
Fill it with: /scoreboard players add DUMMY_PLAYER nextPlayerID 1
The problem lies in the fact that the selector "@p[score_playerID=0]" never selects a player to use the operation on. By default, any score is initialized as 0.
What should happen is, it will take the nearest player's "playerID score" and add the "nextPlayerID score" to it, as long as it's 0. Afterwards it adds 1 to the "nextPlayerID score" so it is always unique per cycle.
This doesn't work because of the selector fail.
This is a useful feature. I don't know why anyone would want this removed.
Invisible block interaction using testforblck ~~ ~ air
Then spam create it where you want these "barriers".
FallingSand isn't a block. It's an entity. The reason they don't rotate is because rotating the block model on the entity wasn't implemented. This isn't technically a "bug", as Mojang never intended to allow FallingSand entities to rotate. While it would be nice to see it in game, it's more of a "requested feature".
It's nothing to do with textures.
Does not work as it should. Intention means nothing when necessity is a factor.
That's not the point.
You have a modified client, therefore your bug reports will be invalid, as they can pertain to an issue with the mod, and not the game.
Try removing your mods, test the same thing, and make a report on that. Otherwise the moderators have full rights to deny your report.
Are you using any mods? Perhaps MCPatcher?
Wait, boolean tags are actually booleans now?
They aren't using Optifine. Optifine adds more Video Settings.
Carl Nathans
No it doesn't.
It leaves a blank box above the entity's head because the space is there.
No.
Try to do it. Seriously. Don't assume or guess. Actually TRY it.
1) Give the mob a name.
2) Try to remove the name using ANY tactic.
3) The nameplate is still there.
You cannot get rid of the custom name.
That's what the glitch is though. I'll update the description to prevent future misinterpretations.
This is because blocks need an update. When they are generated, they don't update on their own. Much like "primed falling sand" needs a block update before it falls.
This is not a bug. This is a way to prevent the client from freezing by scheduling block updates for every generated block in a chunk.
Everyone keeps saying this is a feature. But the twitchy movement leads me to believe this is a bug.
Either the AI needs to be tweaked to make this "attack" more immersive, or it's a bug needs to be fixed.
I don't mind the Ender Dragon stopping in the middle to do extra attacks, but it sits IN the portal, rather than fly above it, or sit near it. It just looks awful.
Squids are immune to it on land for sure, I just tested.
Why are the numbers inconsistent?
This was Mojang's workaround to hacked inventories spawning command blocks with /op in them.
So technically, this is "works as intended". But really, who are we kidding. Mojang could simply disallow the /op command from command blocks, and even just clear the NBT of all spawned in items from creative menu. Rework the packet system a bit to create a server-side of the creative menu, and only allow items to be added/used from the server, just like it is in survival. No more functioning inventory hacks.
You do not need to put quotes in the JSON, Mojang set it to lenient, which means keys don't require quotes. I found the solution as per your last advice, you do need all 3 (author, title, and pages) for the book to work.
So the following,
{text:\"Hi\"}/give @p written_book 1 0 {HideFlags:32,title:"Book",author:"Author",pages:["
"]}
will work.
Moderators, feel free to close this. I apologize for this. It is true though, that the JSON generator no longer works, however. So Mojang must have changed their book parser without mention in the changelog.
Confirmed even for 15w33b
There is additional details to mine. Can we change mine to just the added part then?
This is still the case, even in 15w34a. Over one year. Wow.
/title @a title
{"text":"Chapter I", "bold":"true"}works.
You forgot to quote "true"
Works as intended. This is a new mechanic where the fishing bobber becomes fully attached to the mob. If it is within the hitbox of the mob, it attaches.
@dodo comododo
It's in the video. Hence why I wrote "steps to reproduce are in the video".
@Kumasasa
Thanks for adding it to the ticket.
@Kumasasa
Could you maybe change the post to say:
"Steps to reproduce are in the video, but also below".
I can't edit anything on mobile.
I'd like to mention that the solution to this is actually simple.
The reason why it doesn't "update" is because the constructor of the GUI only saves the current name as a string variable. If the entity/tile entity instance were stored instead, then a simple getCustomName call in the draw method would fix it. I guess this was a performance concern. But it isn't going to make a huge impact anyhow. It's only allocating a reference in memory, not a whole new object.
That's what the object variables are already doing.
Like Marcono1234 said, no NBT tag is used, so the server can't save it to the world. And I haven't tested multiplayer, so maybe some one can test multiplayer and see if others can see a "just sheared" snow golem to test for synchronization.
This will indicate if it is just client side, or if the data just is lost.
If I may ask, why is this marked as "won't fix"?
What is making you guys not want to fix it?
I have stated the fix. It's really simple. I understand performance may be a concern, but you only draw one screen at a time, and for it to fetch a single string every tick (as opposed to the current way of fetching the string upon opening the GUI, and only that one time) is not going to make any more impact than it does fetching a list of items every tick.
The way I see it, the signs should all have text colors matching that of the item texture. Additionally, I would like to see the option to either recolor sign colors within the GUI, or have some kind of file in a resource pack to determine the sign text colors per sign-type.
The outer layer of your skin IS completely black. You need to have transparent pixels in those spots. Black does not get hidden.
Did you even attempt to replicate it? I just tried it conditional and not, it still behaves the same. This is not invalid.