mojira.dev

Mr Smeo

Assigned

No issues.

Reported

MCPE-21368 all previously unnamed maps have been migrated to be named "Map 0" Cannot Reproduce MCPE-21242 Anvil GUI Item counts jumbled. cosmetic Cannot Reproduce MCPE-21232 At night the stars rise from north and set to south, rotating on x-axis (Wrong Direction) Fixed MCPE-21205 Taking suffocation damage on Chested Donkey in a 3 block high space Duplicate MCPE-21203 Horse saddle duplicate appears back on horse when horse is leashed.. Cannot Reproduce MCPE-21126 List Of Enchantments clipped in chest / Anvil GUI Cannot Reproduce MCPE-21031 Villagers accept Charcoal as Coal while trading Fixed MCPE-20957 Cannot add more than one instance of a class of bucket to hot bar Fixed MCPE-20812 Crash on "Save and Exit" Duplicate MCPE-20404 Chested Donkey Inventory GUI does not show item descriptions when transferring items back and forth Cannot Reproduce MCPE-20387 Hotbar and Inventory slot contents shifting in Horse GUI. Duplicate MCPE-20243 Inventory Items Disappear While Trading with Villager Duplicate MCPE-19249 Endermites occasionally spin around for a few seconds when not chasing a target Fixed MCPE-18868 Blocks and Items deleted from End spawn room when gamer leaves End and returns. Works As Intended MCPE-18863 Arrows "dancing" when shot at a closed gate Fixed MCPE-18711 Iron Golems immune to knockback enchantment Works As Intended MCPE-18485 Hotbar Section Missing From Horse Inventory UI. Duplicate

Comments

Sadly have to report I had this show up again in 1.1.0.9, specifically, I lost a sword in inventory slot1 when trying to top up a furnace input slot.
This was an old furnace, is it possible that could be the cause as I've tested this in 1.1.0.9 previously and it seemed to be working ok but that was probably with a furnace created in 1.1.0.9?
Could furnaces generated in earlier versions still be affected?
If so, would breaking/placing update it or would one need to destroy and remake all old furnaces?

Adding Android 6.0 MCPE 1.1.0.9 (and before) as also still being affected.

@Gregory Schultz,

Correct I am beta testing, sign up yourself and you will get access to 1.1.0.9 on the play store.
Regarding the duplicate hotbar entries, MCPE-20458, this also looks fixed in 1.1.0.x I have not observed this for a while.
1.1.0.9 is a massively improved build in lots of ways so I suspect @Mojang will be rolling this up into a mainline release soon but that is speculation I dont have any inside info on that.

Have tested this on 1.1.0.9 and it looks good.
On the "Top up input slot on furnace:" step the UI stops counting when the input slot is maxed at 64 so there is no buffer/return to inventory occurring during the transfer.
Another great fix in 1.1.0.9 🙂 Thanks Devs.

Update 2:
I had a crash in game and rollback (leaving to auto report/upload)
This gave me the chance to test opening this chest rather than destroying it, this worked also so great 🙂
Pictures added just for the sheer pleasure of seeing this fixed 👍 😃

The (Ex) Chest of Doom:

[media]

Et Voila!:

[media]

+my tuppence worth.
Crashing chest since long time ago (see MCPE-21375 & MCPE-18516 for details).
Crashes if interacted with in any way including via opening, destruction, hoppers, etc.
This specific chest contains 64 Air in slot1 (programatically slot0), others have explicitly mentioned Air in a chest slot making the game crash also, so that is one cause of chest crashes clearly identified.

Maybe delete that slots contents while loading the chunk in a similar method used to update unnamed maps to be called Map 0?

Update: (Android 6.0)
Awesome!! Fixed in 1.1.0.9, I was able to destroy this chest with an axe without the crash. Many thanks Devs!

Duplicates MCPE-17783

@Mojang Mods/Helpers
It might be helpful if you update the Guidlines to advise reporters to search and check that a still open issue is not a duplicate before adding a comment to it just as you advise searching before adding a new issue.
I have fallen into this trap a few times now (blush), adding comments to a ticket that has been recently added or updated but has not yet been caught and closed by admin as a duplicate, only to see it resolved as a dupe some time after commenting on it.

Duplicates MCPE-11477,
no need to add my previous comment to that ticket as it does not add anything new.

@Eric, yes not fixed in mainline yet but is now fixed in 1.1.x beta builds.
The fix should be with you soon on next IoS release I would think.

+1 Me too.
I quite like it, clouds were a bit flilmy before. They look great in a thunderstorm at sunset 🙂
Obviously a bug though, pity.

+1 on 1.0.0.5 on torch and sign.
A sign with a torch above it have detached on several game starts now and were on the ground.
Checked using maps, the torch and sign are confirmed to be in a different chunk to the block they are attached to. Bordering North (torch/sign) South (Sandstone Block).

Standing next to them after a save/start, while the chunks were loading around me I heard the "pop" of the detached torch and sign being placed in my inventory.

Confirmed, only for me a white sheep dropped grey wool.

I have a chest like that too (android), right in the middle of my archive.
Have tried everything to get rid of it as you have, move/break/open/hoppers etc, touch it and MCPE crashes instantly.
I even tried /setblock 1281 66 85 dirt replace and /fill a 9 block cube around it, instant crash.

When I load the world into MCPEViz and check the logs it can read the contents of the chest ok, the log is below but MCPE just cannot handle it at all without crashing.

I expect you'll have to live with it as I have 😞 I feel your pain!!!

overworld-ParsedTileEntity: [Pos=(1282, 66, 85 @ image 3650, 2693) Sign=[Crashes if / opened / DO NOT TOUCH / ]]
overworld-ParsedTileEntity: [
Pos=(1281, 66, 85 @ image 3649, 2693)
Chest=[
[Block:Dirt Damage=0 Count=64 Slot=1]
[Block:Dirt Damage=0 Count=64 Slot=2]
[Block:Dirt Damage=0 Count=64 Slot=3]
[Block:Dirt Damage=0 Count=64 Slot=4]
[Block:Dirt Damage=0 Count=64 Slot=5]
[Block:Dirt Damage=0 Count=64 Slot=6]
[Block:Dirt Damage=0 Count=64 Slot=7]
[Block:Dirt Damage=0 Count=64 Slot=8]
[Block:Dirt Damage=0 Count=64 Slot=9]
[Block:Dirt Damage=0 Count=64 Slot=10]
[Block:Dirt Damage=0 Count=64 Slot=11]
[Block:Dirt Damage=0 Count=64 Slot=12]
[Block:Dirt Damage=0 Count=64 Slot=13]
[Block:Dirt Damage=0 Count=64 Slot=14]
[Block:Dirt Damage=0 Count=64 Slot=15]
[Block:Dirt Damage=0 Count=63 Slot=16]
[Block:Dirt Damage=0 Count=64 Slot=17]
[Block:Dirt Damage=0 Count=64 Slot=18]
[Block:Dirt Damage=0 Count=64 Slot=19]
[Block:Glass Pane Damage=0 Count=16 Slot=20]
[Block:Grass Block Damage=0 Count=8 Slot=21]
[Block:Grass Path Damage=0 Count=1 Slot=22]
[Item:Coal Damage=0 Count=6 Slot=23]
[Block:Dirt Damage=0 Count=64 Slot=24]
[Block:Sandstone, Smooth Damage=2 Count=51 Slot=25]
[Block:Dirt Damage=0 Count=64 Slot=26]
]
]

MCPEViz shows the contents of slot1 to slot26 but the parse log shows 27 slots and that slot0 contains 64 of id 0 (air) which I think is what MCPE is barfing on.

0x31-te: [Count] 64 0x40 (byte)
0x31-te: [Damage] 0 0x0 (short)
0x31-te: [Slot] 0 0x0 (byte)
0x31-te: [id] 0 0x0 (short)

Full MCPEViz parse log for the chunk attached as ChestOfDoom.txt

Unable to reproduce in 1.1.0.5 also.
I believe this is fixed.

Seems to be fixed in 1.1.0.5
What is more, a horse that was wearing a bugged saddle,
(one that did not show on the horse model in its inventory and was previously caused by this bug)
is now fixed if the horse is saddled/unsaddled again.

Now the confusing part....
I am fairly certain I had just recreated this in 1.1.0.5 so I updated the Affected Versions to include 1.1.0.5.
After I had done that I left the area, when I returned, the chunks had been unloaded and I had to wait a while just outside the area for the chunks to reload.
When I first launched 1.1.0.5 I was in the immediate area of the stables and did some testing there on my open tickets so I can only guess that something was updated/migrated when the chunks containing the stables were reloaded? Or perhaps some background update task had not completed?

Important part is that it does seem fixed now but I would appreciate if someone @Mojang would comment on that to help me understand the update mechanics better and therefore improve my testing approach.

Affects 1.1.0.5

This has reocurred and has become progressively worse through 1.1.0.1, 1.1.0.3 and 1.1.0.4
HTC One M8, I concur with @Aspergerian this is not related to hardware performance.

Another aspect to this.
I just noticed that after removing a saddle from a horse the horse can still be ridden and controlled even when there is no longer a saddle on the horse or shown in the horse model as above.
So the leashing does not explicitly give ridability and control, it just seems to cause the non present saddle to render.

In my case, just after I lost the horse I exited the game and it crashed while saving.
I was placed back at my base where I had left on the journey, I had travelled about a half way across a 1:16 map.

This bit might be a clue to the cause....

I returned to roughly the area where I'd lost the horse and suddenly glitched back onto the horse again, as in it reappeared with me on it!

This used to happen in cases where the game crashed when you were in a boat or on a horse etc, somehow the entity is saved in the chunk I guess and the game tries to reunite you with your ride?
This info might help affected users get their favourite rides back again, go back to the chunk you lost the horse in and you might get it back! or go away from the chunk so it unloads then return.

Also affects 1.1.0.3 for Villager Trading Case.