GMO Heaven
- GMOHeaven
- gmoheaven
- America/Denver
- Yes
- No
MCPE-39025
Explanation:
Within the GUI for the structure block are the toggleable options:
Include Entities (which apparently means mobs)
Include Players
Toggling these does have an effect on what the preview model within the structure block GUI shows. (see image StructureBlockSetup)
However, upon exporting, the .glb file will not properly contain all entities and players. (see image StructureBlockResult).
Repro Steps:
Create a new world on Windows 10.
Create a cage for a skeleton. Place a skeleton inside.
Nearby, create a cage for a sheep. Place a sheep inside.
Stand near both cages and place a structure block.
Ensure an item is in the player's hand. (see image ReproSetupBlocks)
Using the structure block GUI, select the area that includes both cages and the player.
Using the structure block GUI, enable toggles for include entities and include players.
*Notice that the toggle updates the sample model within the GUI to include players/mobs.
Optionally, toggle the show blocks option to off.
Give the structure a name, then export. (see image ReproSetupGUI)Open the newly created .glb file. (I used 3D Viewer and Paint 3D)
Notice the lack of players and mobs, unlike the model in the Structure Block GUI.
Notice the presence of the item model that was visible in the player's hand as well as that of the bow in the skeleton's hand.
(see image ReproResult, also file TestSetupModel.glb)
My conclusion is that this must be unintended as there are options enabling the very thing that is not functioning. I suspect the issue resides in the process of generating the model. This impacts the ability of a player to create (very cool) 3d models using their player model and that of mobs.
Explanation:
Within the GUI for the structure block are the toggleable options:
Include Entities (which apparently means mobs)
Include Players
Toggling these does have an effect on what the preview model within the structure block GUI shows. (see image StructureBlockSetup)
However, upon exporting, the .glb file will not properly contain all entities and players. (see image StructureBlockResult).
Repro Steps:
Create a new world on Windows 10.
Create a cage for a skeleton. Place a skeleton inside.
Nearby, create a cage for a sheep. Place a sheep inside.
Stand near both cages and place a structure block.
Ensure an item is in the player's hand. (see image ReproSetupBlocks)
Using the structure block GUI, select the area that includes both cages and the player.
Using the structure block GUI, enable toggles for include entities and include players.
*Notice that the toggle updates the sample model within the GUI to include players/mobs.
Optionally, toggle the show blocks option to off.
Give the structure a name, then export. (see image ReproSetupGUI)
Open the newly created .glb file. (I used 3D Viewer and Paint 3D)
Notice the lack of players and mobs, unlike the model in the Structure Block GUI.
Notice the presence of the item model that was visible in the player's hand as well as that of the bow in the skeleton's hand.
(see image ReproResult, also file TestSetupModel.glb)
Edit: Also see attached test world if desired: StructureBlockBugTest.mcworld
My conclusion is that this must be unintended as there are options enabling the very thing that is not functioning. I suspect the issue resides in the process of generating the model. This impacts the ability of a player to create (very cool) 3d models using their player model and that of mobs.
Structure Blocks donot Export3d Player/Mob ModelsStructure Blocks do Not Export All Entities
Explanation:
Within the GUI for the structure block are the toggleable options:
Include Entities (which apparently means mobs)
Include Players
Toggling these does have an effect on what the preview model within the structure block GUI shows. (see image StructureBlockSetup)
However, upon exporting, the .glb file will not properly contain all entities and players. (see image StructureBlockResult).
Repro Steps:
Create a new world on Windows 10.
Create a cage for a skeleton. Place a skeleton inside.
Nearby, create a cage for a sheep. Place a sheep inside.
Stand near both cages and place a structure block.
Ensure an item is in the player's hand. (see image ReproSetupBlocks)
Using the structure block GUI, select the area that includes both cages and the player.
Using the structure block GUI, enable toggles for include entities and include players.
*Notice that the toggle updates the sample model within the GUI to include players/mobs.
Optionally, toggle the show blocks option to off.
Give the structure a name, then export. (see image ReproSetupGUI)
Open the newly created .glb file. (I used 3D Viewer and Paint 3D)
Notice the lack of players and mobs, unlike the model in the Structure Block GUI.
Notice the presence of the item model that was visible in the player's hand as well as that of the bow in the skeleton's hand.
(see image ReproResult, also file TestSetupModel.glb)
Edit: Also see attached test world if desired: StructureBlockBugTest.mcworld
My conclusion is that this must be unintended as there are options enabling the very thing that is not functioning. I suspect the issue resides in the process of generating the model. This impacts the ability of a player to create (very cool) 3d models using their player model and that of mobs.
Explanation:
Within the GUI for the structure block are the toggleable options:
- Include Entities (which apparently means mobs)
- Include Players
Toggling these does have an effect on what the preview model within the structure block GUI shows. (see image StructureBlockSetup)
However, upon exporting, the .glb file will not properly contain all entities and players. (see image StructureBlockResult).
Repro Steps (now simplified):
- Create a new world on Windows 10.
- Create a cage for a skeleton. Place a skeleton inside.
- Type /give @s structure_block
- Place the structure block and select an area that includes the skeleton.
- Using the structure block GUI, enable toggles for include entities and include players.
- Notice that the toggle updates the sample model within the GUI to include players/mobs.
- Give the structure a name, then export. (see image ReproSetupGUI)
- Open the newly created .glb file. (I used 3D Viewer and Paint 3D)
- Notice the lack of players and mobs, unlike the model in the Structure Block GUI.
- Notice the presence of the item model that was visible in the player's hand as well as that of the bow in the skeleton's hand.
(see image ReproResult, also file TestSetupModel.glb)
Edit: Also see attached test world if desired: StructureBlockBugTest.mcworld
My conclusion is that this must be unintended as there are options enabling the very thing that is not functioning. I suspect the issue resides in the process of generating the model. This impacts the ability of a player to create (very cool) 3d models using their player model and that of mobs.
Structure Blocksdo Not Export All EntitiesStructure Blocks Do Not Export All Entities
Description:
When signing out of a game at world height (standing on a block at y= 255, player height = 256), signing back in to the game results in a variety of unpredictable behaviors.
The most frequent possibility is that the player will appear somewhere below the block they signed out on, slightly offset in x or z coordinate value (this is not what is described in https://bugs.mojang.com/browse/MCPE-38374).
The next most common result is respawning in at y = -40 (below bedrock) and instantly dying if in survival.
The least common behavior is actually respawning where you signed off, which would be the expected result.
Steps to Reproduce:
1) Create a new creative world.
2) Place a block at y=255 and stand in the middle of it.
3) Leave the game and come back.
4) Notice the variety of strange results.
5) For more fun, fill a 16x16 area around the player's perch down to y=2 with solid blocks. Move around and retry. Certain positions seemed more likely to result in strange behavior than others.
Severity:
Moderately severe by my estimate. While it's unlikely that most players build to world height, those that do can encounter severe progress loss. It also indicates a slightly unpredictable implementation, which could indicate further issues not yet discovered.
Unlisted Video Example (7:27): https://youtu.be/r8Ups0My1uw
The end of the video contains two below bedrock spawns, and they can occur even with air blocks below the block(s) at 255.
This appears to be fixed in 1.10. Though seeing as I haven't found the change log with this fix mentioned, I'll leave it up temporarily.
Description:
When signing out of a game at world height (standing on a block at y= 255, player height = 256), signing back in to the game results in a variety of unpredictable behaviors.
The most frequent possibility is that the player will appear somewhere below the block they signed out on, slightly offset in x or z coordinate value (this is not what is described in https://bugs.mojang.com/browse/MCPE-38374).
The next most common result is respawning in at y = -40 (below bedrock) and instantly dying if in survival.
The least common behavior is actually respawning where you signed off, which would be the expected result.
Steps to Reproduce:
1) Create a new creative world.
2) Place a block at y=255 and stand in the middle of it.
3) Leave the game and come back.
4) Notice the variety of strange results.
5) For more fun, fill a 16x16 area around the player's perch down to y=2 with solid blocks. Move around and retry. Certain positions seemed more likely to result in strange behavior than others.
Severity:
Moderately severe by my estimate. While it's unlikely that most players build to world height, those that do can encounter severe progress loss. It also indicates a slightly unpredictable implementation, which could indicate further issues not yet discovered.
Unlisted Video Example (7:27): https://youtu.be/r8Ups0My1uw
The end of the video contains two below bedrock spawns, and they can occur even with air blocks below the block(s) at 255.
This appears to be fixed in 1.10. Though seeing as I haven't found the change log with this fix mentioned, I'll leave it up temporarily.
Description:When signing out of a game at world height (standing on a block at y= 255, player height = 256), signing back in to the game results in a variety of unpredictable behaviors.
The most frequent possibility is that the player will appear somewhere below the block they signed out on, slightly offset in x or z coordinate value (this is not what is described in https://bugs.mojang.com/browse/MCPE-38374).
The next most common result is respawning in at y = -40 (below bedrock) and instantly dying if in survival.
The least common behavior is actually respawning where you signed off, which would be the expected result.
Steps to Reproduce:
1) Create a new creative world.
2) Place a block at y=255 and stand in the middle of it.
3) Leave the game and come back.
4) Notice the variety of strange results.
5) For more fun, fill a 16x16 area around the player's perch down to y=2 with solid blocks. Move around and retry. Certain positions seemed more likely to result in strange behavior than others.
Severity:
Moderately severe by my estimate. While it's unlikely that most players build to world height, those that do can encounter severe progress loss. It also indicates a slightly unpredictable implementation, which could indicate further issues not yet discovered.
Unlisted Video Example (7:27): https://youtu.be/r8Ups0My1uw
The end of the video contains two below bedrock spawns, and they can occur even with air blocks below the block(s) at 255.
This appears to be fixed in 1.10. Though seeing as I haven't found the change log with this fix mentioned, I'll leave it up temporarily.
From the changelog:
- Player position is now accurately saved when exiting and rejoining a world
Description:
When signing out of a game at world height (standing on a block at y= 255, player height = 256), signing back in to the game results in a variety of unpredictable behaviors.
The most frequent possibility is that the player will appear somewhere below the block they signed out on, slightly offset in x or z coordinate value (this is not what is described in https://bugs.mojang.com/browse/MCPE-38374).
The next most common result is respawning in at y = -40 (below bedrock) and instantly dying if in survival.
The least common behavior is actually respawning where you signed off, which would be the expected result.
Steps to Reproduce:
1) Create a new creative world.
2) Place a block at y=255 and stand in the middle of it.
3) Leave the game and come back.
4) Notice the variety of strange results.
5) For more fun, fill a 16x16 area around the player's perch down to y=2 with solid blocks. Move around and retry. Certain positions seemed more likely to result in strange behavior than others.
Severity:
Moderately severe by my estimate. While it's unlikely that most players build to world height, those that do can encounter severe progress loss. It also indicates a slightly unpredictable implementation, which could indicate further issues not yet discovered.
Unlisted Video Example (7:27): https://youtu.be/r8Ups0My1uw
The end of the video contains two below bedrock spawns, and they can occur even with air blocks below the block(s) at 255.
I have this problem currently on Windows 10. v.1.6.1
An important note when the developer who reads this gets to bug fixing is that kelp only grows into horizontally flowing water (thereby forming source blocks) when it is allowed to grow naturally into the last water source below the horizontally flowing water. This is hard to explain, but I will post pictures showing how to set this up (reproduceable) and what I mean.
Steps to reproduce:
1) Place a three high pillar of stone in the middle of a flat platform
2) Place a water source on the top of the pillar using a bucket. Water should flow on all sides.
3) Place kelp two blocks high on one side of the pillar. It could be manually placed one higher, but do not!
4) Place kelp three blocks high on the opposite side of the pillar. Notice that it cannot be placed any higher on this side.
5) Wait for the two block high kelp to grow. First it will grow into the downward flowing water, forming a water source at this location (as intended, I believe). This is now the same height as the second kelp you placed.
5) Wait further for the first kelp placed to grow into the horizontally flowing water adjacent to the original water source. Notice that a source block will be created at this location.
6) (Optional) Notice that further waiting does not result in the second placed kelp growing into the
If horizontally flowing water blocks are intended to be turned into source blocks (highly unlikely), then the behavior should be the same regardless if the player places the previous kelp block or if it naturally grows to that point.
Also, it is impossible to manually place kelp into horizontally flowing water. This would also have to be updated in the (unlikely) case that source creation is working as intended.
Why is this an awful bug? This bug is particularly annoying if you want to have a waterfall go into a water body full of kelp (a cosmetic building choice). The kelp will slowly create source blocks higher and higher, effectively raising the water level as high as the highest drop of the waterfall. This snowballs into potentially flooding massive areas of your world.
Edit: I am currently unable to upload pictures due to a browser error. Will do so as soon as possible.
Edit 2: Pictures currently uploaded. I added glass to make it clearer to see what is going on, but the setup is otherwise functionally identical.
Edit 3: Edited Edit 2 to include word "functionally". My editing habit is getting out of hand...
I have the same issue on both Xbox One and Windows 10. Screenshots are from Windows 10. v.1.6.1 for Windows 10.
Steps to recreate (a little more clearly)
1) Place a stair block two blocks in the air.
2) Surround the three open sides of the stair block with glass (to see what's going on). Leave the full back and bottom of the stair block open to the air.
3) Use a water bucket to waterlog the stair block. No water should be flowing at this point (as intended).
4) Ensure no blocks are immediately below the stair block.
5) Break the stair block.
6) Observe that the water behaves as if it were still contained within a stair block. It does not flow downward or out the back.
See screenshots showing stair block surrounded by glass for visual example.
I can confirm this is an issue on Xbox splitscreen. It can be pretty soul destroying working on underwater builds.
Also, this post indicates it's an issue on Switch too:
https://www.reddit.com/r/Minecraft/comments/a8gynj/trying_to_play_multiplayer_but_cant_see/
Addressing concerns:
First: I'm aware that anyone can edit the wiki. I'm also aware that developers are occasionally the ones who edit the wiki (for example on Bedrock spawning mechanics). In this case, the information on the wiki is so specific that it seems either an intent to deceive by creating false information (unlikely, I believe), or was placed by someone with intimate knowledge of the code.
Second: The problem of strongholds generating extremely far away from spawn should be considered a bug regardless of what the wiki says. This is a problem already addressed in the Java edition due to the incredible inconvenience and annoyance distant strongholds create. I'd be shocked to discover that no such attempt has been made on Bedrock to ensure close-to-spawn strongholds exist. I think this is indicative of a problem in generation of strongholds. In short: Fewer strongholds are actually generating than the developers must intend.
Third: This is not an issue on every seed! I tried to look for a pattern in which seeds have these issues, but I failed. In my (n≈12) testing, about 1/4 of the seeds failed to generate a close stronghold. This is frequent enough to merit concern, however. For example, here is a Reddit post showing two distinct users with the same issue: https://www.reddit.com/r/Minecraft/comments/abzig6/infinite_worlds_leading_to_a_few_minor_problems/
The frustration players experience with this bug is clear.
I can confirm that this bug occurs on Realms and Xbox One. Both are on 1.8 currently.
The attached images (Setup.png, Result.png) are taken in Windows 10 Edition via LAN with the Xbox world.
Repro Steps:
1) Find an ocean monument (/locate monument)
2) Go to it and use fill command to replace the top four layers (60 - 63 inclusive) with a solid block of choice. Fill in one block extra to the sides as well (for a total dimension of 60 x 4 x 60)
3) Use fill command to replace top 3 layers (61 - 63 inclusive) with air. Leave the extra border of solid blocks around the side to keep water from flowing in. Air space dimensions 58 x 3 x 58.
4) Go to a y value of at least 90 and observe the spawning guardians in air. If you can't get any to spawn, set a command block to constantly kill all entities which are not guardians. ( /kill @e[type=!guardian] ). Alternatively, toggle peaceful mode on and off till you have spawning.
I've seen multiple separate instances of what looks like this bug on Reddit. These are all apparently coming since 1.9 was released this morning.
https://www.reddit.com/r/Minecraft/comments/ann501/help_with_broken_end_city_portal/
https://www.reddit.com/r/Minecraft/comments/ann501/help_with_broken_end_city_portal/efunghw
https://www.reddit.com/r/Minecraft/comments/anlctn/my_end_gateway_put_me_in_an_invisible_barrier/
Edit: More added below!
https://www.reddit.com/r/Minecraft/comments/annd7k/stuck_in_end_gateway/
Have you received the 1.9 update for Nintendo Switch yet? It was released a few hours after the other editions, so that might explain why the realm is on a different version (1.9).
@Kyle morley
While it's a reasonable guess that the value for height is stored as an 8-bit int, this is not the case. Looking at the save file shows the data type used is actually a float. And it is capped at 512, not 256. There is a reasonable amount of decimal precision regardless of value. If it were stored as an integer type, it would potentially have issues if a player were to attempt to sign out while standing on a bottom-half slab.
Also, before spawning back in, the value stored in the save file will be correct, but can still result in spawning in at -40. Notice in the video that the player doesn't spawn in at -1 and fall to -40, but they instantly spawn in at -40.
Regardless of cause/implementation, this is a severe bug in the regard that it can result in progress loss. It can occur while doing something well within the bounds of the game. There is literally an achievement for reaching the top of the world while using scaffolding!
This seems like a good post for the feedback site, not the bug tracker.
The implementation is different on Bedrock from Java, but that does not mean it is a bug. In the same regard, the fact that Guardians spawn in just 25 spots is not a bug. Or strongholds generating more commonly beneath wells. These are just differences.
The more I think about it, the more I like the idea of implementing this change, but still, this discussion should probably happen on the feedback site.
This is an example of a difference between Java and Bedrock implementation. I believe it currently works as intended.
If you think this should be changed, check out the feedback site.
Still an issue in public release of 1.10.0
This seems to be an issue still in 1.10.
A converted zombie spawned from a spawn egg or naturally will agro the player. However, once it turns into a drowned, it becomes passive. I have video of this if necessary.
Tested on Windows 10. Inspired by this Switch owner's Reddit post: https://www.reddit.com/r/Minecraft/comments/b3xk7r/neutral_drowns/
Confirmed fixed in 1.11 release. N=20 with looting and without and got an average of 1.8 shells/shulker with Looting III, and 0.7 shells/shulker without Looting.
Confirmed fixed in release 1.11. And without breaking other things, so great work by the devs here.
This is no longer an issue as far as I can test in release 1.11.
Fixed in release 1.11 by my testing.
Also the changelog states, "Drowned converted from zombies will now attack players"
Link for the lazy: https://feedback.minecraft.net/hc/en-us/articles/360026977492
Fixed in 1.11 release.
https://bugs.mojang.com/browse/MCPE-37006?focusedCommentId=538178&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-538178
A similar situation on Reddit: https://www.reddit.com/r/Minecraft/comments/bikd9f/can_anyone_explain_why_this_happens_were_using/
I separately confirmed this (entirely unmotivated by, and prior to the release of SilentWisperer's video). It is unmentioned in changelogs, so I suspect it is indeed a bug. While maybe not the worst bug, it seems strange to limit easy mode players in this way.