Étienne B.
- EBhero
- ebhero
- America/New_York
- Yes
- No
9 issues
Key
Summary
Status
Reporter
Assignee
Created
MC-46697![[Mojang] MNilsson](../../../data/avatars/users/18951.svg){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Added Attachments:
Added Attachments:
Étienne B. turn particles on in the video settings
Étienne B.Étienne B. turn particles on in the video settings
Well, its look like the bug is fixed when i test it!
So now you can update the status to "resolved".
Thanks for caring about it
It's still on the 1.8.1 Prerelease 3, sadly
It seems that it does that too on single player:
Filling 100*100 platform cause game crash
Confirmed for 1.8.8
It's still concern the current Minecraft version 1.8.8
The bug happen on stained glass
An image worth 1000 words. So I've created a .gif!
I've built a wall of withe stained glass with a floor of orange stained glass. It can be clearly seen that there is a "glitch" between the withe and the orange stained clay
Ok I think I found it!
I've recreated this is by doing the following:
1-put a normal command bloxk, then switch it to "Always active"
2-Do ctrl- mouse wheel to have a copy of the block in the inventory
3-Put the new block on the ground
4-Switch the block to "repeat" and put a random command in it (ex: say test)
By doing this, you'll notice that the command block doesn't spam "test" in the chat as it should do!
Comfirmed for 15w50a
It happens most of the time when you are on a server with loads of plugins OR if you have a really slow computer. You should do multiple tests to see when it happens.
Does it happens only on servers or in a solo world?
Ok I think I know what's happening:
When changing command block options (well, for now on: impulse to repeat mode), they don't consider their new options until they are redstone updated.
Also, if you do this and the command block is set to "Always active", you need to put it to "needs redstone", press done and set it back again to "Always active" to consider his new state.
Strange enough, the bug happens also in the main hand. Well, at least for me.
O.O
...I never existed... ...You saw nothing at all...
Comfirmed for 15w51b
Added better examples. An important notice is that the light cuts
exactly at a chunk limit. We can also notice that the light cuts on the wall(The dark side of the wall is at Y=15 and the bright side is at Y=16).
Reproduced at night time, by adding/removing a torch near a chunk limit, in a dark area.
Also, most of the time the light updates instantly, but it do take some time in other tests. It doesn't uptade at the same speed if we place it on a wall or on the ground.
All the screenshots as been taken in 15w51b.
More testing should be useful.
An easy way to notice it in 15w41b:
{OnGround:1b}-Load a world (Solo) and make sure you are the only player on it
-Place a command block with "/testfor @a
-Set the command block to "Repeat" and "Always Active"
-Place a comparator next to the command block so it can test the result
This setup is made for testing the player's tag OnGround.
Now, you need to jump without moving horizontally. The comparator should not turn on, even though you are on the ground.
So is there anyway to solve the problem?
Sad enough, loads of Minecraft maps using playsounds will be broken... We'll need to load an older Minecraft version to fix it...
I confirm
A simple splution is to put this command inside a repeating command block:
{Motion:[0.0,0.0,0.0]}/entitydata @e
Confirmed for 1.10.2
Comfirmed in 1.10.2
Comfirmed for 16w40a
{id:"minecraft:zombie",IsBaby:0b,IsVillager:0b,HandItems:[],ArmorItems:[]}The new command is:
/give @p spawn_egg 1 0 {EntityTag:
}
When starting sprinting with speed 2, instead of going straight to speed-affected sprinting FOV, it pops into normal sprint FOV then back up with the extra FOV. It gets quite dizzying unless you have dynamic FOV set to off.
It does the same when you stop sprinting: Extra sprint FOV -> normal FOV -> speed 2 normal FOV in a matter of frames.