megashub

1200 entites are simply too much

The scene in that screenshot isn't exactly excessive-looking. The houses and castle have decorated interiors and exteriors with windows. It's a populated village with 30ish villagers and iron golems. It has a simple redstone street lighting system. ... and that's really it.

If there all that is what makes up 1200 entities, then that still sounds bug-like. If, however, the caves underneath these chunks are full of egg-bearing zombies, and THAT's what's inflating that entity count, then that's still a bug, but not one that's specific to the FPS optimizations that Mojang just released.

1. Will update and retest. Didn't know 1.7 compatibility issues had been resolved.
2. True. But in MC 1.7.10 I don't have this problem.
3. That is contributed to by lots of zombies holding eggs below ground. But beyond that, the ticket description does say highly developed areas. Because the zombies aren't visible in that screenshot, they shouldn't be rendered. But even without them, the performance loss when compared to 1.7.10 is bug worthy.

I'm happy to provide a comparison screenshot if that would help.

So the only thing Mojang cares about is Effect, and not Cause?

Oh, right. Derp. Because SP is now the same as MP under the hood. Sorry, forgot about that.

FWIW: My server has seen this problem from well before 1.7.2, and it's a bare metal server which I wouldn't consider slow.

FWIW, MCPE-6713 indicates Android-hosted worlds creates instability for iPhone guest players. Did not think to test the reverse (iPhone-hosted with Android guest). That issue description contains other details regarding signal strength and distance which appear to negate the concerns of a bad connection. Both phones are top-end handsets, as well, so client hardware/OS version limitations are not a likely cause either.

Mod: Please update the affected versions to include 0.8.0 beta build 5 & 0.8.0 beta build 8 and 0.8.1 as they were specified in MCPE-6353 and MCPE-6624 as well.

Mod, please update affected versions to include 0.8.1

This appears to be fixed for me on 0.8.1a. I'm running a Nexus 5 4.4.2.

note the duplicated bow in the hotbar after the left-most item broke and all of the hotbar items shifted over to the left one.

Confirmed this still happens in 0.8.0 beta build 8.

I've narrowed down the behavior to when an item breaks, the hotbar moves all of the items over to the left one box, and auto-fills in the right-most box with another item from your inventory. If your inventory doesn't have many items in it, it will display a copy of the same item already in your hotbar.

Expected behavior: I expected either analgous behavior to the PC version (ie. the box containing the broken item remains empty after it breaks), or, if the auto-shifting/auto-filling behavior is intended for PE, then I expected the right-most box to remain empty if your inventory doesn't contain enough items to autofill the hotbar.

Having two of the same item in the hotbar just to keep it populated seems unnecessary, as is just confusing to see two of the same item.

See screenshot for example.

This appears to be resolved in 0.8.0 beta build 8.

I believe MCPE-5882 and MCPE-5884 effectively duplicate this issue.

I have a similar problem. I can't change the name, but I can add characters. Once I add characters, I cannot remove those either.

So, really, it just sounds like backspace is not working.

I am using a Nexus 5, Android 4.4, Kernel 3.4.0-g9eb14ba (Build KRT16M).

Edit: I would recommend editing the Summary of this issue to exclude the phone model, as it appears to be handset agnostic. Probably a bug in the app and/or compatibility with specific Android OS versions.

My wife and I have experienced this on both Mac and PC. For our own sanity, we've had to mute the music entirely because of it.

Still present in 1.7.2.

I know this is a resolved issue, but the title needs to be updated for accuracy: "Trap Doors close automatically when on or adjacent to trip wire hooks"

Can this issue please be updated to include 1.6.2 and Survival mode as well?

Hi Tails,

Thanks! 🙂

Question: It's linked as a duplicate, but is it? Also, this is marked as resolved, but is it's own separate problem. ...right? confused

I would like to add my voice to this problem. We've tested this thoroughly on our survival multiplayer server, and would be happy to demo this for anyone at Mojang, at any time.

The symptoms are the same, and the action is automatic. It happens automatically anywhere from a few seconds to a minute or two after opening the trap doors. If an unhooked tripwire hook is present on the block, and that same block has a trap door on it, that trap door will auto-close.

It's a bigger problem too, because I've been able to isolate that all trapdoors which are adjacent to the hook itself (but not diagonal), will also auto-close at the same time.

For the record, our server is running 1.6.2.