Adam Ekstrom
- 93castle
- 93castle
- America/Denver
- Yes
- No
MC-36910
Minecart spawners now show a full-size pig model instead of the little 1/4 scale spinning voodoo doll thing. This new pig model look doesn't spin, and sticks outside of the minecart spawner, just sitting there, without moving. Please fix this. Minecart spawners make the game crash in 14w03a and 14w03b. In 14w04a, they don't make it crash, but still have that static full size pig model. The minecart spawner is supposed to spawn fallingsand entities, and it does so successfully, but it just looks weird with that full size pig model. I labeled the attached pictures with red text that specifies which snapshot was used to take that screenshot.
I haven't tested out the minecart spawners that are spawning things besides falling sand entities, but I know that it occurs for fallingsand minecart spawners.
Steps to reproduce:
{FallHurtAmount:2.0,EntityId:FallingSand,Data:7,Tile:17,Time:-80,TileID:17,Block:minecraft:log,FallHurtMax:40}
1. Go into snapshot 14w04a.
2. Spawn a spawner minecart with the /summon command:
/summon MinecartSpawner ~0 ~0 ~2 {Delay:120,SpawnData:,EntityId:FallingSand}
3. Observe the full size pig model sticking out of the spawner minecart.
Minecart spawners now show a full-size pig model instead of the little 1/4 scale spinning voodoo doll thing. This new pig model look doesn't spin, and sticks outside of the minecart spawner, just sitting there, without moving. Please fix this. Minecart spawners make the game crash in 14w03a and 14w03b. In 14w04a, they don't make it crash, but still have that static full size pig model. The minecart spawner is supposed to spawn fallingsand entities, and it does so successfully, but it just looks weird with that full size pig model. I labeled the attached pictures with red text on the images themselves that specifies which snapshot was used to take that screenshot.
I haven't tested out the minecart spawners that are spawning things besides falling sand entities, but I know that it occurs for fallingsand minecart spawners.
Steps to reproduce:
{FallHurtAmount:2.0,EntityId:FallingSand,Data:7,Tile:17,Time:-80,TileID:17,Block:minecraft:log,FallHurtMax:40}
1. Go into snapshot 14w04a.
2. Spawn a spawner minecart with the /summon command:
/summon MinecartSpawner ~0 ~0 ~2 {Delay:120,SpawnData:,EntityId:FallingSand}
3. Observe the full size pig model sticking out of the spawner minecart.
/give command successful output isnowmixed up compared to previously.
What I EXPECTED to happen was...:
-In ANY snapshot for 1.8, starting as early as snapshot 14w02a, the first 1.8 snapshot, the command will work properly. When a command block with this command in it:testfor @p[r=1]
is powered, it can detect a player less than one block away from the command block (especially noticeable by checking the comparator next to the command block.) This is how it works if you try it in 1.7.4, but not in the snapshots for 1.8.
What actually happened was...:
The command block, when given this command:
testfor @p[r=1]
and then powered doesn't detect a player if there is one close enough, and returns this result:"The entity UUID provided is in an invalid format"
This problem happens using almost any command, and any argument. The exact same commands worked in the older versions, but this bug impairs players' ability to use commands in the snapshots. Nowadays, I can hardly do anything involving arguments due to this bug. The only thing I found that works is if I just write the coordinates, followed by the radius, without actually labeling the arguments, like so:
testfor @p[682,10,43,r=1]
And sometimes even that won't work either. Relative coordinates don't often don't work at all, except for sometimes with the execute command. The same result happens every time I try to specify arguments: the last output in the command block is "The entity UUID provided is in an invalid format," even though I have it perfectly written, and I've checked it for accuracy.
This happens almost every time, and with almost every command. It makes command block work almost impossible. Please fix this bug soon, Mojang. Commands are made to be useful, not to refuse to work just because of some bug that prevents them from doing so. Please, I really like the snapshots, but almost nothing is do-able in them while this bug is present.
Steps to Reproduce:
1. Place a command block
2. Place a redstone comparitor facing out from the command block
3. In the command block, type the following:testfor @p[r=1]
4. Get a button from creative mode, hold your crouch key down (the default is left shift) and right click the command block to place the button on it.
5. Push the button on the command block.
6. Right click the command block while in creative, and look at the "Previous Output field." The previous output will be listed as the time the command was activated, and then this error message:"The entity UUID provided is in an invalid format."
7. Repeat steps 1-6 in Minecraft 1.7.4, and the comparator will output successfully if a player is within one block of the command block, though as a side note the previous output will not indicate its success, only the comparator will. The previous output will most likely be the time and then: "That player cannot be found," even though it obviously DID find the player if the comparator lit up when the player was within one block of the command block.
As above mentioned, here is an example command, one that is extremely simple and correct, but doesn't work because of this bug:
testfor @p[r=1]
This bug only appears in command blocks, not in the chat.
Try it for yourself. Run the example command in the snapshots. You'll see that I'm right.
Here are more examples, all of which have been double-checked for accuracy, but none of them work right now in the snapshots for 1.8 because of this bug of command arguments being mistaken for UUIDs:
testfor @p[x=-535,y=4,z=-250,r=2] ~-0.2 ~-1 ~0
scoreboard players set @p[score_necromancy_min=3,score_necromancy=3] checkpoint 4
testfor @p[score_bloodlustmem=0]
[Note: Both of the objectives mentioned above, necromancy and bloodlustmem are dummy objectives.]
Several other users already posted similar bug reports for this kind of issue. Their error reports were either ignored, or marked as "Works as intended." I don't know how making it so almost no command block stuff can be done could possibly be considered "Works as intended." This bug has been around since the start of the 1.8 snapshots, and nothing has been changed to improve this since then. Personally, I consider this to be the worst bug currently in the game, because it cripples adventure map/challenge map making.
What I EXPECTED to happen was...:
-In ANY snapshot for 1.8, starting as early as snapshot 14w02a, the first 1.8 snapshot, the command will work properly. When a command block with this command in it:testfor @p[r=1]
is powered, it can detect a player less than one block away from the command block (especially noticeable by checking the comparator next to the command block.) This is how it works if you try it in 1.7.4, but not in the snapshots for 1.8.
What actually happened was...:
The command block, when given this command:
testfor @p[r=1]
and then powered doesn't detect a player if there is one close enough, and returns this result:"The entity UUID provided is in an invalid format"
This problem happens using almost any command, and any argument. The exact same commands worked in the older versions, but this bug impairs players' ability to use commands in the snapshots. Nowadays, I can hardly do anything involving arguments due to this bug. The only thing I found that works is if I just write the coordinates, followed by the radius, without actually labeling the arguments, like so:
testfor @p[682,10,43,r=1]
And sometimes even that won't work either. Relative coordinates don't often don't work at all, except for sometimes with the execute command. The same result happens every time I try to specify arguments: the last output in the command block is "The entity UUID provided is in an invalid format," even though I have it perfectly written, and I've checked it for accuracy.
This happens almost every time, and with almost every command. It makes command block work almost impossible. Please fix this bug soon, Mojang. Commands are made to be useful, not to refuse to work just because of some bug that prevents them from doing so. Please, I really like the snapshots, but almost nothing is do-able in them while this bug is present.
Steps to Reproduce:
1. Place a command block
2. Place a redstone comparitor facing out from the command block
3. In the command block, type the following:testfor @p[r=1]
4. Get a button from creative mode, hold your crouch key down (the default is left shift) and right click the command block to place the button on it.
5. Push the button on the command block.
6. Right click the command block while in creative, and look at the "Previous Output field." The previous output will be listed as the time the command was activated, and then this error message:"The entity UUID provided is in an invalid format."
7. Repeat steps 1-6 in Minecraft 1.7.4, and the comparator will output successfully if a player is within one block of the command block, though as a side note the previous output will not indicate its success, only the comparator will. The previous output will most likely be the time and then: "That player cannot be found," even though it obviously DID find the player if the comparator lit up when the player was within one block of the command block.
As above mentioned, here is an example command, one that is extremely simple and correct, but doesn't work because of this bug:
testfor @p[r=1]
This bug only appears in command blocks, not in the chat.
Try it for yourself. Run the example command in the snapshots. You'll see that I'm right.
Here are three more examples, all of which have been double-checked for accuracy, but none of them work right now in the snapshots for 1.8 because of this bug of command arguments being mistaken for UUIDs:
testfor @p[x=-535,y=4,z=-250,r=2] ~-0.2 ~-1 ~0
scoreboard players set @p[score_necromancy_min=3,score_necromancy=3] checkpoint 4
testfor @p[score_bloodlustmem=0]
[Note: Both of the objectives mentioned above, necromancy and bloodlustmem are dummy objectives. To test them, you'll have to make the dummy objectives of the same name in your worldsave before running these commands.]
Several other users already posted similar bug reports for this kind of issue. Their error reports were either ignored, or marked as "Works as intended." I don't know how making it so almost no command block stuff can be done could possibly be considered "Works as intended." This bug has been around since the start of the 1.8 snapshots, and nothing has been changed to improve this since then. Personally, I consider this to be the worst bug currently in the game, because it cripples adventure map/challenge map making.
I've noticed this issue too, and it still needs fixing. It's rather ineffective to not be able to see Friendly Invisibles unless Friendly fire is set to true. It kinda defeats the purpose.
Confirmed in Minecraft 1.5.1 and above. Before than as well, I am guessing. Mining Fatigue, even when raised to level 10 or above is useless in trying to prevent people from breaking any block with the material "rock" with their bare hands. If they use the correct tool, the mining fatigue correctly prevents the block from breaking, but it fails to stop people using their bare hands from breaking "rock" blocks. I tried other materials such as "wood" and "soil" types, but the only one I could break with my bare hands while under Mining Fatigue ten or higher was all "rock" materials. However, when you break a "rock" block while under high levels of Mining Fatigue, the block does not give its drop when it breaks, even when you are in Survival Mode.
I can confirm this bug. I ran into the same problem myself in 13w24b. I converted six 1.5 texture packs from the 1.5 version by using the Texture Ender, and then tried to load them in 13w24b, expecting them to load as normal. They didn't load at all, but they did make a few things like grass and torches look weird. I tried to select the resource pack on the selection screen, but it just lagged like it used to when loading the old texturepacks, but then the the default was still shown as selected (had the white box around it.) The resource packs really don't seem to be as ready to be released as Mojang thought. This bug makes me hesitate to play this snapshot. Default textures get sooooo boring to look at, and in 13w24b, that's the only textures that will load because of this bug! I've tested this in 13w24a as well. It loads resource packs fine (other than the fact that the menu for them is labeled "Texture packs" rather than "Resource packs", but that doesn't affect their loading), but 13w24b doesn't load them at all!!!
I can confirm this bug. I ran into the same problem myself in 13w24b. I converted six 1.5 texture packs from the 1.5 version by using the Texture Ender, and then tried to load them in 13w24b, expecting them to load as normal. They didn't load at all, but they did make a few things like grass and torches look weird. I tried to select the resource pack on the selection screen, but it just lagged like it used to when loading the old texturepacks, but then the the default was still shown as selected (had the white box around it.) The resource packs really don't seem to be as ready to be released as Mojang thought. This bug makes me hesitate to play this snapshot. Default textures get sooooo boring to look at, and in 13w24b, that's the only textures that will load because of this bug! I've tested this in 13w24a as well. It loads resource packs fine (other than the fact that the menu for them is labeled "Texture packs" rather than "Resource packs", but that doesn't affect their loading), but 13w24b doesn't load them at all!!!
Confirmed for 13w24b. It's annoying to have your most recently played worldsaves at the bottom of the list!
Confirmed.
Confirmed for 13w42b snapshot. This bug happens far less often when I use 1.6.4 than when I use any of the 1.7 snapshots. It crashes any time when I try to trade with a villager in 1.7 snapshots. This cripples the snapshots, in my opinion, because I use trading so often.
This is the crash report that was made when I most recently attempted to trade with villagers in 1.7. It may or may not detail the actual bug of trades with villagers failing. I am not sure because the crash report is steeped in programming language of which I have little to no comprehension.
Sorry. I searched for a duplicate of this issue before creating it, but I must have used the wrong keywords, instead of the ones for the duplicate of this. I know that over 50% of issues are resolved as duplicates, but I wasn't able to find it, as I said.
Why is it intended to stop background music when gamemodes are changed? It makes sense to pause the music when the game is paused, but I can't think of a reason why gamemode changing would need music ending as part of it. I'm not trying to be mad or rude, I was just curious as to the motivation for saying that this works as intended in that regard.
To Dakotah Intriglia:
Many of the people who commented on this issue here suggested the exact same solution as you did, myself included. Unfortunately, Mojang usually has a "we'll do it in our own sweet time" attitude.
Still present in 1.8's snapshot # 14w02c I don't know to add that to the "affects versions:" list.
Actually, I can't reproduce it myself, and I'm the one who posted this bug. It must have just been a temporary glitch. Now when I try it, the "Blocks" volume can turn off Fire's sounds. Huh. Sorry for the false alarm, it seems.
Confirmed for 14w04a!!!!! It's rather annoying.
This bug is a pain! Confirmed in 14w04b. The maps are invisible in item frames.
This is what Item frames look like that have maps in them in 14w04b. It renders them without the actual map being visible.
Thank you! I was able to fix that part of the resource pack, and now it works perfectly!
These are the screenshots I took. The ones that don't have the messed up hitbox visible are the ones that were in between the flashes of abnormality in the pattern of the glitch. That pattern is:
normal...messed up... normal... messed up..., etc.
I have the same problem using almost any command, and any arguement. They worked in the older versions, but this bug impairs players' ability to use commands in the snapshots. I can hardly do anything involving arguments. The only thing I found that works is if I just write the coordinates, followed by the radius, without actually labeling the arguments, like so:
@p[682,10,43,r=1]
And sometimes even that won't work either. Relative coordinates don't work at all. The same result happens every time I try to specify arguments, the last output in the command block is "The entity UUID provided is in an invalid format," even though I have it perfectly written, and I've checked it for accuracy. This happens almost every time, and with almost every command. It makes command block work almost impossible. Please fix this bug soon, Mojang.
Reply to FVbico's comment:
Are you in one of the snapshots between 14w02a and 14w26c? Also, if you can't confirm it, please record your attempt and post it as a Youtube video, and put the link to it in the comments for this bug report, so I can see what I might be doing wrong if you are doing it the right way. Thank you!!!
I suppose it's possible that Mojang changed the argument format in the snapshots, and that resulted in me doing it wrong, but until I see what you were doing, I won't know for sure.
I would be grateful if anyone else CAN confirm this bug. It sure seems to be the result of a bug, not user error. I checked the commands, and they work for me in 1.7.4, but they don't work in the 14w02a snapshot or above, up to and including snapshot 14w26c, the most current snapshot as of today, June 30th.
Thanks for posting the screenshots, FVbico. That'll do in place of a Youtube video, sure. Thank you.
To Anon Ymus: Yes, I am aware of the fact that the radius centers on the command block. Well, what am I doing wrong then, if I am doing it wrong? Please help. I have no trouble with it in 1.7.4, but it won't work in the 1.8 snapshots. Why would that be?