samasaurus6
- samasaurus6
- samasaurus6
- Europe/London
- Yes
- No
MC-14769![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
I made a model for potions and used the white stained glass texture for the bottle part and an opaque "potion overlay" texture on the inside of the bottle.
The problem is that, even though the overlay is opaque and the stained glass is translucent, the overlay cannot be seen from the outside.
You can see as I go close up to it, the overlay is definitely working properly with a potion of poison used as the example below.
[EDIT 1]: Short video of the problem: http://i.gyazo.com/96ef13fdfd943706f1801e7943d238cf.mp4
When gliding with the Elytra, the rotation of the rendered player head does not match with the position of the cursor. (Direction that player is looking, essentially)
This is problematic for two reasons really. Firstly it looks very strange if looking straight up or straight down while gliding.
And secondly (also arguably more importantly) this completely ruins any use the Elytra has in map-making with block models. The block models in the head slot of the player will over-rotate instead of looking where the player is actually facing. Example: https://i.gyazo.com/7404fe66590678393da985c54cbfc0b0.mp4
I propose that the player head should only rotate 180 degrees as that is the maximum pitch you can change with your cursor. It would also be beneficial for the player head to rotate with the body too.
I hope you can fix this.
When gliding with the Elytra, the rotation of the rendered player head does not match with the position of the cursor. (Direction that player is looking, essentially)
This is problematic for two reasons really. Firstly it looks very strange if looking straight up or straight down while gliding.
And secondly (also arguably more importantly) this completely ruins any use the Elytra has in map-making with block models. The block models in the head slot of the player will over-rotate instead of looking where the player is actually facing. Example: https://i.gyazo.com/7404fe66590678393da985c54cbfc0b0.mp4
I propose that the player head should only rotate 180 degrees as that is the maximum pitch you can change with your cursor. It would also be beneficial for the player head to rotate with the body too.
[EDIT] Here's a video I made which better illustrates why this is such an issue: https://www.youtube.com/watch?v=ZcklKh9hZuI
I hope you can fix this.
samasaurus6 that one is already marked as affected.
Confirmed for 14w33a
Still affecting me in 1.8-pre1
I made a post on Reddit which shows this in action: http://www.reddit.com/r/Minecraft/comments/2yoc3d/psa_do_not_have_more_than_63_clocking_blocks_in_a/
With the help of redstonehelper, I now understand what causes this. It happens when you have more than 63 clocking blocks in a single chunk. Clocking blocks are command blocks next to a fill clock and the fill clock itself. When you go over that limit, rather than sending block updates, Minecraft will just send the WHOLE chunk. This is what causes both the increase in network usage and the chunk updates. Usually when you change blocks in a chunk, just the block data for those blocks is sent, but if you happen to be changing more than 64 EVERY tick, then the whole chunk data is sent.
So this isn't really a bug as such, but more a hard limit on how chunks are updated and such. I doubt Mojang will change the way chunks are handled just to benefit larger clocks. The solution is simple, just make sure you have less than 63 clocking blocks in any one chunk. Place clocks on chunk borders to easily spread the clocking blocks across multiple chunks.
Ahh hey Panguino,
Yeah the video you made about it doesn't seem to actually correspond with how it works in 1.8.3 which is where I did my tests. As long as the clocks are in the spawn chunks, crossing chunk borders has no effect on lag or chunk updates and as long as there are less than 63 clocking blocks in each chunk, everything is fine; they do not add together. A possible explanation for our different results may be (just guessing here) due to how chunk handling was initially multithreaded and to my knowledge in 1.8.3 it no longer is.
Resource pack with the 3D models attached. Ignore the splash potion models. I have not done them yet. The potion can be seen from the inside but not the outside.
Confirmed for 1.8.5 and 1.8.6.
Given that
MC-86936was created minutes before my bug report, contains less information on why the bug is caused and is already (yet, wrongly) closed, I see no reason why this should be counted as a duplicate.Seems that oak stairs and cobblestone stairs disappear when the world is reloaded.
Linked to this bug
MC-87194@FVbico Count tag doesn't make it work.
@mrpingouin1 Yes it certainly seems that way, but is there any reason why they've limited it back to just splash_potion or lingering_potion? I saw a lot of pretty cool ideas come out of it and it can't have caused any problems right? I guess all I'm after is an explanation why it couldn't be kept the way it was in 15w45a :/
Can confirm, but wanted to add detail. It crashes when an item is removed or moved from your inventory in survival. This can happen in multiple ways. Throwing a potion. Dropping an item, placing the last block in a stack of blocks etc.
Confirmed for 1.9.3-pre3.
I don't see pre-3 on the list... It was only just released.
Confirmed for Release 1.9.3... sigh Was really hoping this would be fixed already...
Can Confirm. Also experienced this lag before. Reckoned it was due to model complexity, but even just using BUILT-IN models for the predicate overrides, there is major lag. Getting an FPS drop from 900FPS to 170FPS just from holding an inventory full of hoes...
Seems like all models for the predicates are "loaded" despite only one being seen at a time.
This is the best case scenario too. Map-makers rely on predicates to add models to maps without being limited to just the in-game items. Combine the predicate lag with complex models and you get some very resource heavy maps...
sigh Confirmed for 1.10... Can this please be fixed already? It should honestly be a higher priority than a lot of these other bugs that have been getting fixed. This actually affects survival gameplay as well!!!
Can confirm custom biomes no longer generate in this beta.