Chris54721
- Chris54721
- chris54721
- Europe/Stockholm
- Yes
- No
MC-37110
When standing on a Slime Block (by walking on it, doesn't happen when you stop bouncing) the screen flickers vertically.
Sorry if there are no screens, but it's really hard to capture the glitch in a screenshot.
Also affects 14w02b (not present on version list)When standing on a Slime Block (by walking on it, doesn't happen when you stop bouncing) the screen flickers vertically.
Sorry if there are no screens, but it's really hard to capture the glitch in a screenshot.
Looking at F3 info, it looks like you jump a little bit ('g' changes between true and false) so this is not a rendering issue.
Also affects 14w02b (not present on version list)
When standing on a Slime Block (by walking on it, doesn't happen when you stop bouncing) the screen flickers vertically.
Sorry if there are no screens, but it's really hard to capture the glitch in a screenshot.
Looking at F3 info, it looks like you jump a little bit ('g' changes between true and false) so this is not a rendering issue.
Also affects 14w02b (not present on version list)When standing on a Slime Block (by walking on it, doesn't happen when you stop bouncing) the screen flickers vertically.
Sorry if there are no screens, but it's really hard to capture the glitch in a screenshot.
Looking at F3 info, it looks like you jump a little bit ('g' changes between true and false) so this is not a rendering issue.
This also happens when you place another block 2 blocks above the Slime Block (above your head) and you try jumping.
Windows 8.1
Java 1.7.0_45Windows 8.1
Confirmed with both Java 7u51 and 8
When standing on a Slime Block (by walking on it, doesn't happen when you stop bouncing) the screen flickers vertically.
Sorry if there are no screens, but it's really hard to capture the glitch in a screenshot.
Looking at F3 info, it looks like you jump a little bit ('g' changes between true and false) so this is not a rendering issue.
This also happens when you place another block 2 blocks above the Slime Block (above your head) and you try jumping.
When standing on a Slime Block (by walking on it, doesn't happen when you stop bouncing) the screen flickers vertically.
This also happens when you place another block 2 blocks above the Slime Block (above your head) and you try jumping.Video demonstrating the bug (thanks Anton Kudin!) http://cl.ly/WMXw/vid.mov
Flicker when standing on Slime Block(causing g to change fast between true and false)
When standing on a Slime Block (by walking on it, doesn't happen when you stop bouncing) the screen flickers vertically.
This also happens when you place another block 2 blocks above the Slime Block (above your head) and you try jumping.
This is not a rendering bug but a physics engine bug, as in older snapshots (before the F3 menu update) the 'g' value changed quickly between true and false.Video demonstrating the bug (thanks Anton Kudin!) http://cl.ly/WMXw/vid.mov
When looking at the Anvil in your inventory, there is a small
whiteline on the side of the top part of the block.This doesn't happen in the hotbar.
When looking at the Anvil in your inventory, there is a small transparent line on the side of the top part of the block.
This doesn't happen in the hotbar.
When looking at the Anvil in your inventory, there is a small transparent line on the side of the top part of the block.
This doesn't happen in the hotbar.
This only happens with Anisotropic Filter + Mipmap to max level
1. Open any chest
2. Wait for the opening sound to stop playing
3. Close the chestThe opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.The bug does not happen if the chest inventory is modified.
1. Open any chest
2. Wait for the opening sound to stop playing
3. Close the chestThe opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.The bug does not happen if the chest inventory is modified.
Chest opening sound plays again when closing if mouse is not moved
1. Open any chest
2. Wait for the opening sound to stop playing
3. Close the chest
The opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.1. Open any chest
2. Wait for the opening sound to stop playing without moving the mouse
3. Close the chestIf the mouse cursor was not moved, the opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.
1. Open any chest
2. Wait for the opening sound to stop playing without moving the mouse
3. Close the chestIf the mouse cursor was not moved, the opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.
Does not affect Double Chests.
1. Open any chest
2. Wait for the opening sound to stop playing without moving the mouse
3. Close the chestIf the mouse cursor was not moved, the opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.
Does not affect Double Chests.Seems like the issue does not happen everytime you try reproducing it; it's a bit random.
1. Open any chest
2. Wait for the opening sound to stop playing without moving the mouse
3. Close the chestIf the mouse cursor was not moved, the opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.
Does not affect Double Chests.Seems like the issue does not happen everytime you try reproducing it; it's a bit random.
1. Open any chest
2. Wait for the opening sound to stop playing without moving the mouse
3. Close the chestIf the mouse cursor was not moved, the opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.Seems like the issue does not happen everytime you try reproducing it; it's a bit random.
1. Open any chest
2. Wait for the opening sound to stop playing without moving the mouse
3. Close the chestIf the mouse cursor was not moved, the opening sound will be played again before playing the closing sound.
Also affects Trapped Chests.
Does not happen if the MC window loses focus before closing the chest.Seems like the issue does not happen everytime you try reproducing it; it's a bit random.
When using the new /particle command, it outputs a success message (Playing effect <name> for <times> times) even if the specified particle name doesn't exist.
When using the new /particle command, it outputs a success message (Playing effect <name> for <times> times) even if the specified particle name doesn't exist.
When used in command blocks, the comparator returns a true output (so it emits a redstone signal)
/gamemodedoesn't workwhenviewingan entity's camera/gamemode causes strange behavior when looking through an entity's camera
You can'tchangeyour gamemode(and get back to the normal camera) when you're in spectator mode and you're looking through an entity's camera.
I know the spectator mode is not finished yet, but I wanted to report this just in case.If you try changing your gamemode when looking through an entity's camera, it will cause a strange behavior.
For example, try looking through a creeper's camera, then do /gamemode creative. You'll remain into the entity's camera and only the held item will be rendered (in a strange way) until you press SHIFT.
If you do the same with /gamemode survival, the held item and the XP bar (not the levels number) will be rendered until you blow up and when you respawn the creeper.json filter won't be removed unless you use the Super Secret Settings button.
Steps to reproduce
1. Destroy the End Crystals
2. Build a pillar directly on top of the exit portal (x=0, z=0) until you reach y=128 (the coordinates of the topmost block should be x=0, y=128, z=0; higher pillars should work as well)
3. Stand on top of the pillar, and wait for the Ender Dragon to reach you
4. A couple of seconds after the Dragon stops above the pillar, the game should crash.
This doesn't always happen, and it may require to create a different world if it doesn't on your first attempt.By analyzing the log from a Forge instance, I was able to find out the bug is related to the Ender Dragon pathfinding code. After the server (or client if in singleplayer) crashes the first time, it will crash again everytime the End is loaded, unless you delete the DIM1 folder.
Steps to reproduce
- Destroy the End Crystals
- Build a pillar directly on top of the exit portal (x=0, z=0) until you reach y=128 (the coordinates of the topmost block should be x=0, y=128, z=0; higher pillars should work as well)
- Stand on top of the pillar, and wait for the Ender Dragon to reach you
- A couple of seconds after the Dragon stops above the pillar, the game should crash.
This doesn't always happen, and it may require to create a different world if it doesn't on your first attempt.By analyzing the log from a Forge instance, I was able to find out the bug is related to the Ender Dragon pathfinding code. After the server (or client if in singleplayer) crashes the first time, it will crash again everytime the End is loaded, unless you delete the DIM1 folder.
Steps to reproduce
- Destroy the End Crystals
- Build a pillar directly on top of the exit portal (x=0, z=0) until you reach y=128 (the coordinates of the topmost block should be x=0, y=128, z=0; higher pillars should work as well)
- Stand on top of the pillar, and wait for the Ender Dragon to reach you
- A couple of seconds after the Dragon stops above the pillar, the game should crash.
This doesn't always happen, and it may requiretocreatea different world if it doesn't on your first attempt.By analyzing the log from a Forge instance, I was able to find out the bug is related to the Ender Dragon pathfinding code. After the server (or client if in singleplayer) crashes the first time, it will crash again everytime the End is loaded, unless you delete the DIM1 folder.
Steps to reproduce
- Destroy the End Crystals
- Build a pillar directly on top of the exit portal (x=0, z=0) until you reach y=128 (the coordinates of the topmost block should be x=0, y=128, z=0; higher pillars should work as well)
- Stand on top of the pillar, and wait for the Ender Dragon to reach you
- A couple of seconds after the Dragon stops above the pillar, the game should crash.
This doesn't always happen, and it may require creating a different world if it doesn't work on your first attempt.By analyzing the log from a Forge instance, I was able to find out the bug is related to the Ender Dragon pathfinding code. After the server (or client if in singleplayer) crashes the first time, it will crash again everytime the End is loaded, unless you delete the DIM1 folder.
Still bugged in public release 1.7.2
In Minecraft 1.7 numeric IDs are deprecated and will be removed in the future, so in this case you should replace the item id (387) with minecraft:written_book
/tellraw @a {"text": "-", "extra": [{"text": "[Regeln]",color:gold,"clickEvent": {"action": "run_command", "value":"/give @p[score_p=1,score_p_min=1] minecraft:written_book 1 1" {author:\"Marcono1234\",title:\"Regeln\",pages:[\"Sei nett\",\"Sei nett\",\"Sei nett\"]}"}}]}Try with this, I added " after 'minecraft:written_book 1 1'
Also, the ping time increased a lot in 1.7.2 with the new networking system.
Looking at F3 info, it looks like you jump a little bit ('g' changes between true and false) so this is not a rendering issue.
This only happens with Anisotropic Filter + Mipmap to max level
Graphics drivers are already updated to the latest version using the official NVIDIA tool. I'm using a GTX 770.
Yup, looks also bugged in 1.7... It seems that this happens since I updated the graphics drivers.
Do you have VSync enabled?
VSync synchronizes the frame rate to your monitor's one, so it avoids rendering glitches. Basically if it's enabled, it means that you have a 60Hz monitor, and you really won't be able to see more than 60 FPS. I suggest you to keep it enabled, because there's no difference between what you can see when it's enabled and what you can see when it's disabled.
Have you tried enabling and disabling it again? Sometimes it's a bit buggy
I usually get the FPS drop in every snapshot. The allocated memory stays to 100MB max and my FPS are above 200 on max settings
I searched for those keywords and found that result before opening the issue, but it doesn't look like the same bug... That bug is affecting jukeboxes and records, this one is affecting chests.
Confirmed with latest snapshot (14w02c)
That's not right...the command is working, it's only outputting a wrong value.
For what I understood:
/particle <particleName> <x center> <y center> <z center> <x radius> <y radius> <z radius> <particle speed> <particle count> <entity the particle should follow>
particleName: name of the particle, type "/particle " then hit tab to see all the available values
x, y and z center: the block that will be the center of the particle generation
x, y and z radius: how many blocks the generation should be expanded in the various directions
particleSpeed: the speed of the particle, determines how long it takes to despawn
particleCount: how many particles should be spawned in the selected area (they are spawned at random positions inside it)
entity...: if you choose an entity, it will drop particles as it moves
That's what I meant...there is a really strange behavior. You can try, for example, going into spectator mode and look through a creeper's camera: if you do /gamemode survival you'll die, but the green pixelated filter will remain.
I'm also talking about survival mode here, maybe you could merge the two issues.
Still present in latest snapshot 14w07a.
Yeap same for me.
Confirmed. The dark anvil texture bug applies to every type of anvil, the slightly damaged one is also rotated.
Just checked, still present in 14w11b...
Still there in 14w25b (probably affects every version from 14w02a)
Still there in latest snapshot; added the video to the issue.
Still there in the first 3 prereleases.
1.8 released, bug still present ~9 months after reporting.
I don't get "Pinging..." anymore, but I assume that's intentional. The icon is fine.
Still there in 1.8.2-pre7
Still a bug in 16w06a