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. 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...
Confirmed for Release 1.9.3... sigh Was really hoping this would be fixed already...
I don't see pre-3 on the list... It was only just released.
Confirmed for 1.9.3-pre3.
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.
@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 :/
Seems that oak stairs and cobblestone stairs disappear when the world is reloaded.
Given that MC-86936 was 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.
Confirmed for 1.8.5 and 1.8.6.
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.
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.
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.
Still affecting me in 1.8-pre1
Confirmed for 14w33a
Can confirm custom biomes no longer generate in this beta.