Joe Groocock
- frebib
- frebib
- Europe/Stockholm
- Yes
- No
7 issues
MC-1244![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Changed Description:
The game still targets the selected mob (entity) during the short death animation so does not allow other entities or blocks behind to be hit.
Steps to reproduce.
1. Equip weapon of choice.
2. Kill mob
3. During death animation, try to hit/access things directly behind where the mob was standing - not possibleI would personally prefer to see the hotbox completely disappear just as the death anim starts
Added Description:
When powering a piston the player is pressed up against, the players position doesn't update immediately
Added Environment:
SSP and superflat.
Not directional
Works with Sticky & Non-sticky
Changed Description:
When powering a piston the player is pressed up against, the players position doesn't update immediately
After a second or two, the player will be pushed
Deleted Comment:
co-ordinates?
This is a bug, and a simple fix! Just update the player position and rotation to the sleep viewing angle when player enters the bed!
Isn't this due to the client not receiving mob updates from the emulated server so assuming it has fallen? This bug similarly affects other mobs with wandering through fences and such!
Thanks Jon
PLEASE CLOSE THIS TICKET
Red3yz had this issue in his let's play on the Hermitcraft server. See here: http://www.youtube.com/watch?v=aQ6YlMSNje4
Since support was added for use of these buttons in game, one would assume it is fixed?
Ok, there aren't many bugs that always annoy me in this game, but the obvious graphical ones are just that. Between this and the particle rendering order, I am about done
I for one hope this gets fixed, it looks quite weird considering how it's been for the past 3 years. I hope it is a bug, and not intentional!
I had the same bug happen when opening an iron door with a button. Looks like somebody derped though so probably an easy fix
Must be an issue with iron doors then
Even breaking a block next to one causes the same stack overflow. I bet it's something stupid like the block constantly requests block updates on itself and not the lower part of the door.
Edit:
Updating the lower half of the door doesn't crash the game, only the upper half
Fixed in 14w02b
Can't reproduce by growing with bonemeal in 02b. Fixed?
Not fixed in 02b
This as a feature would be very useful considering they don't despawn properly right now. It's at least a simple measure to control lag until that is fixed
I have seen this happen in 1.7.x versions too. It's not new
Can reproduce
Having the same issue
Can you post the crash log? (minecraft/crash-reports/crash-<DATE>-client.txt)
Doing anything. Placing/breaking blocks, running commands.. everything. There must be something that is taking up significantly more tick time in 14w02b than 1.7.4.
It wasn't quite as bad in 02a for me though
This is a new feature part of the F3 Debug options. Toggle F3 to turn it off
As mine is tagged duplicate, I'll post here what I put:
When traversing chunk boundaries and chunks at the edge of the render distance are loaded and being rendered, a significant amount of chunk updates are performed per frame (I have observed anywhere from 2/300 up to about 600 depending on render distance)
This has been tested on a variety of render distances from 3 up to 16 and appears to affect all of them.
If the player stays within the boundaries of a single chunk then the chunk updates reduce drastically and FPS returns to normal. It only happens when chunks are loaded into render and require updating.
My guess just by the sheer amount of chunk updates is that it updates all chunks loaded or something like that and it's possibly in aid of fixing the "world doesn't load" issues.
For me I average at about 100-120 fps above ground in a normal world but now my fps drops to around 24 on any render distance while I am moving
> 800 villagers.
Maybe that's your issue