AvgZing
- TheRoyalBlock
- theroyalblock
- Europe/Stockholm
- Yes
- No
MCPE-24497
REALMS-7232
TxrBk2.jpg
Since there are so many pictures, and I want them in a specific order, I have uploaded them to a github repository and will link them below.
In Minecraft Windows 10 Edition, version 1.2 beta number 3, creative mode, numerous blocks are missing from the inventory. With these same blocks, if you enter them in a /give command, it comes up with a syntax error. Interestingly enough, it is still possible to get these blocks. How, you ask? You find the block that was already placed. For example, if this is an old world from a previous version and you already placed dispensers, you can find that dispenser, middle click it, and it will be added to your inventory. If it is not already in the world, you're helpless, sorry!
Murtag has already stated that he is unable to reproduce this, but the screenshots should act as proof that this is an unfortunate error. I will soon restart my minecraft (at the moment others are playing on the world) and will edit the post afterwards.Example 1: Dispensers
Dispensers cannot be found in the inventory
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/3h.jpg)
I then attempt to get a dispenser by using the /give command
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/4h.jpg)
And I end up getting a syntax error
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/5h.jpg)Example 2: Rails
As I attempt to find regular, powered, activator, or detector rails, I look through the inventory.
I come across rails.
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/4i.png)
I then expand the rails, but, to my disappointment, I find only regular rails.
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/5i.png)
I search for rails, and again, find regular rails again. SIDE NOTE: This pic has the build info as well, as requested by Murtag.
(Pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/7i.jpg)Example 3: Anvils!
This strays from the original topic a little bit, but is still a small inventory error.
As I decide to look for the different types of anvils in the inventory (adds a visual aspect), I find anvils, 3 of them! One of them is an expandable menu, and there are two more. All three of them have the same exact "anvil" tag, and the exact same item image. They are also all slightly transparent. How strange!
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/4j.jpg)
Here's another pic, this time with the stuff circled. You see the arrow inwards, showing that the menu is not expanded. You also see the two other anvils, with the anvil tag and transparency.
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/5j.jpg)
We now expand the anvil menu, and see that we have another anvil, exactly the same!
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/6j.jpg)I hope this helped!
P.S: Here's a picture with the build number included, as that seems to have been cropped out in the other images! https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/build.jpg
An edit will be added as soon as I get a chance to restart Minecraft (people are still playing on my world.
EDIT: I closed and reopened minecraft, the issue was not fixed. I reinstalled it, and it worked again. Still a valid issue, though.
Since there are so many pictures, and I want them in a specific order, I have uploaded them to a github repository and will link them below.
In Minecraft Windows 10 Edition, version 1.2 beta number 3, creative mode, numerous blocks are missing from the inventory. With these same blocks, if you enter them in a /give command, it comes up with a syntax error. Interestingly enough, it is still possible to get these blocks. How, you ask? You find the block that was already placed. For example, if this is an old world from a previous version and you already placed dispensers, you can find that dispenser, middle click it, and it will be added to your inventory. If it is not already in the world, you're helpless, sorry!
Murtag has already stated that he is unable to reproduce this, but the screenshots should act as proof that this is an unfortunate error. I will soon restart my minecraft (at the moment others are playing on the world) and will edit the post afterwards.Example 1: Dispensers
Dispensers cannot be found in the inventory
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/3h.jpg)
I then attempt to get a dispenser by using the /give command
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/4h.jpg)
And I end up getting a syntax error
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/5h.jpg)Example 2: Rails
As I attempt to find regular, powered, activator, or detector rails, I look through the inventory.
I come across rails.
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/4i.png)
I then expand the rails, but, to my disappointment, I find only regular rails.
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/5i.png)
I search for rails, and again, find regular rails again. SIDE NOTE: This pic has the build info as well, as requested by Murtag.
(Pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/7i.jpg)Example 3: Anvils!
This strays from the original topic a little bit, but is still a small inventory error.
As I decide to look for the different types of anvils in the inventory (adds a visual aspect), I find anvils, 3 of them! One of them is an expandable menu, and there are two more. All three of them have the same exact "anvil" tag, and the exact same item image. They are also all slightly transparent. How strange!
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/4j.jpg)
Here's another pic, this time with the stuff circled. You see the arrow inwards, showing that the menu is not expanded. You also see the two other anvils, with the anvil tag and transparency.
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/5j.jpg)
We now expand the anvil menu, and see that we have another anvil, exactly the same!
(pic: https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/6j.jpg)I hope this helped!
P.S: Here's a picture with the build number included, as that seems to have been cropped out in the other images! https://github.com/TheRoyalBlock/Minecraft-Bug-Report-Photos/raw/master/build.jpg
An edit will be added as soon as I get a chance to restart Minecraft (people are still playing on my world.
EDIT: I closed and reopened minecraft, the issue was not fixed. I reinstalled it, and it worked again. Still a valid issue, though.
EDIT 2: After playing for about 25 more minutes, the items disappeared again.
Double whammyFloating rails and too many mobs
Floating rails and too many mobsToo many mobs
Realms have already been laggy on a simulation distance of 4. Unless the entire game has been optimized AND realm specs have been raised (neither of which have happened), realms should not be raised to any simulation distance other than 4 or 6 (which is ideal). Simulation distance 10 loads 4 times as many chunks (see @Amuhn Ra's breakdown) per player. Realms simply aren't built to handle anywhere near this: I have no idea what testing you did, but this does not seem thought out to me.
On top of that, this not only added a lot more lag to both realms AND clients (devices stuttering, mobs "teleporting", mob caps filling up nearly instantly, etc), but it also broke the majority of farms on the platform as virtually all farms are built for sim 6 or sim 4.
Players typically don't even play on sim 10 on their local worlds: I don't understand why it's being forced on realms.
Especially on realms with addons or realms with many players, it's impossible to play: almost half of my players have protested this change and started playing on other servers rather than our realm, simply because it's such a massively negative change. Some other realm owners I know switched immediately from realms to servers. Please, revert this change, or switch it to simulation 6, or open it up to player changing.
On Realms (and likely, BDS), resource and behavior packs behave differently than in other singleplayer and multiplayer worlds.
For reference, check out FoxyNoTail's Mob Heads, Mini Blocks, or Armor Stands packs from the following link. https://foxynotail.com/addons/
They will work on Windows 10 and Mobile, but will fail (crash on world-join) on Xbox (On Realms/BDS). In singleplayer or multiplayer, the packs work perfectly fine.
Additionally, other packs (such as various one-player-sleep packs) do not work on realms/BDS, but work well in singleplayer/multiplayer. I don't have a pack available to demonstrate this at the moment.
Have discussed this with CornerHard in the past. Seemed to work with your internal testing, but failed when put in practice on an actual realm.
On Realms (and likely, BDS), resource and behavior packs behave differently than in other singleplayer and multiplayer worlds.
For reference, check out FoxyNoTail's Mob Heads, Mini Blocks,orArmor Stands packs from the following link.https://foxynotail.com/addons/They will work on Windows 10 and Mobile, but will fail (crash on world-join) on Xbox (On Realms/BDS). In singleplayer or multiplayer, the packs work perfectly fine.
Additionally, otherpacks(such asvariousone-player-sleep packs) do not work on realms/BDS, but work well in singleplayer/multiplayer. I don't have a pack available to demonstrate this at the moment.
Havediscussed this with CornerHardin the past. Seemed to work with yourinternal testing, butfailed when putin practice onan actualrealm.On Realms (and likely, BDS), resource and behavior packs behave differently than in other singleplayer and multiplayer worlds.
Steps to Reproduce:
1. Download Mob Heads, Mini Blocks, or Armor Stands resource pack from https://foxynotail.com/addons/
2. Add pack to a realm
3. Join realm using an Xbox, downloading the resources
Observed Results:
Joining freezes on the building terrain step, forcing the console user to close the game and restart, then clear the cache and join the realm without downloading resources.
Expected Results:
User should be able to join the realm like normal.
The issue at the root of this is a difference in behavior between Realms (and possibly BDS) and local worlds' handling of packs. Other users have reported similar differences in behavior with packs such as DrAv's One Player Sleep pack, where it worked locally but failed when uploaded. Something about this difference causes the packs listed above to fail on realms, causing a crash for Xbox users.
I have briefly discussed this issue with CornerHard. It worked on his internal tester, but continued to fail in practice on my realm.
The Bug:
- When updating a realm to a new version (ex: 1.18.2 to 1.18.10), you cannot update via the main menu – you must update by editing the realm.
Steps to reproduce:
- Log in to realm owner account
- Join realm from main menu
- Realm gives "Need to update" message
- Edit the realm and press play from there
- Realm updates successfully
Additional information:
This has persisted throughout multiple communities for an extended time, and is not a new issue.
The Bug:
- When updating a realm to a new version (ex: 1.18.2 to 1.18.10), you cannot update via the main menu when there are players online – you must update by editing the realm.
Steps to reproduce:
- Log in to realm owner account
- Join realm from main menu while players are online
- Realm gives "Need to update" message
- Edit the realm (effectively kicking all players) and press play from there
- Realm updates successfully
In the new world create UI, resource packs cannot be activated if they're already active as a global resource.
Video description: Various other packs activate successfully, but the pack as a global resource does not. Also seen in the video: MCPE-152260
In the new world create UI, resource packs cannot be activated if they're already active as a global resource.
Video description: Various other packs activate successfully, but the pack as a global resource does not. Also seen in the video: MCPE-152260,
MCPE-152263
Steps to reproduce:Run a realm with custom resource and behavior packs on the active world
Invite members
Press the back buttonObserved results:
Realm says "Applying Packs
Steps to reproduce:
Run a realm with custom resource and behavior packs on the active world
Invite members
Press the back buttonObserved results:
Realm says "Applying Packs" and restarts the realmExpected results:
Realm invites members with no impact on gameplay.Other information:
After inviting members, can force close the app. They will still be invited, but it will not try to apply packs and restart the realm.
Steps to reproduce:
Run a realm with custom resource and behavior packs on the active world
Invite members
Press the back buttonObserved results:
Realm says "Applying Packs" and restarts the realmExpected results:
Realm invites members with no impact on gameplay.Other information:
After inviting members, can force close the app. They will still be invited, but it will not try to apply packs and restart the realm.
This may apply to other realms screens, but is most noticeably impactful when simply making changes to the members.
Steps to reproduce:
Run a realm with custom resource and behavior packs on the active world (Demo pack attached)
Invite members
Press the back buttonObserved results:
Realm says "Applying Packs" and restarts the realmExpected results:
Realm invites members with no impact on gameplay.Other information:
After inviting members, can force close the app. They will still be invited, but it will not try to apply packs and restart the realm.
This may apply to other realms screens, but is most noticeably impactful when simply making changes to the members.
Steps to Reproduce:
1. Set BDS render distance to any amount, or be aware that Realm render distance is 10 chunks
2. Join the world with a render distance higher than that of the host server (Higher than 10 on Realms, higher than what was set in BDS)
3. Observe noticeable ingame lag, and major lag on CPU/server resources
Observed Results:
Lag/server resource use drastically increases as more players join with a render distance higher than the host.Lag/server resource use drastically decreases when players lower their render distances to match, or below that of the host.Expected Results:
Lag/server resource use are not affected by client-side render distance.Steps to Reproduce:
1. Set BDS render distance to any amount, or be aware that Realm render distance is 10 chunks
2. Join the world with a client render distance higher than that of the host server (Higher than 10 on Realms, or higher than what was set in BDS)
3. Observe noticeable ingame lag, and major lag on host CPU/server resources
Observed Results:
Server lag/server resource use drastically increases as more players join with a client render distance higher than the host. Server lag/server resource use drastically decreases when players lower their render distances to match, or below that of the host.
FollowingREALMS-2980: This can also be tested through in-game means by setting a repeating command block to add a value to a scoreboard each tick. It will be noticeably slower than 20 ticks per second when the server is lagging.
Expected Results:
Server lag/server resource use are not affected by client-side render distance.
Steps to Reproduce:
1. Set BDS render distance to any amount, or be aware that Realm render distance is 10 chunks
2. Join the world with a client render distance higher than that of the host server (Higher than 10 on Realms, or higher than what was set in BDS)
3. Observe noticeable ingame lag, and major lag on host CPU/server resources
Observed Results:
Server lag/server resource use drastically increases as more players join with a client render distance higher than the host. Server lag/server resource use drastically decreases when players lower their render distances to match, or below that of the host.
FollowingREALMS-2980: This can also be tested through in-game means by setting a repeating command block to add a value to a scoreboard each tick. It will be noticeably slower than 20 ticks per second when the server is lagging.
Expected Results:
Server lag/server resource use are not affected by client-side render distance.Steps to Reproduce:
1. Set BDS render distance to any amount, or be aware that Realm render distance is 10 chunks
2. Join the world with a client render distance higher than that of the host server (Higher than 10 on Realms, or higher than what was set in BDS)
3. Observe noticeable ingame lag, and major lag on host CPU/server resourcesObserved Results:
Server lag/server resource use drastically increases as more players join with a client render distance higher than the host. Server lag/server resource use drastically decreases when players lower their render distances to match, or below that of the host.
FollowingREALMS-2980: This can also be tested through in-game means by setting a repeating command block to add a value to a scoreboard each tick. It will be noticeably slower than 20 ticks per second when the server is lagging.Expected Results:
Server lag/server resource use are not affected by client-side render distance.
Steps to Reproduce
Summon a baby villager in a chamber with the only escape being under half slabsExpected Results
Baby stays inside chamber, maybe tries to jump against the walls a bitObserved Results
Baby runs right under half slabsOther Information
This only seems to happen with some baby villagers – it took me a few tries to get one that would do this. This is most noticeable in villager breeders and open trading halls. It does not need to be double slabs as shown in the video. When running from a mob (ex: zombie), they don't seem to try to escape through the slabs. Unsure if this happens with baby zombies.Steps to Reproduce
Summon a baby villager in a chamber with the only escape being under half slabsExpected Results
Baby stays inside chamber, maybe tries to jump against the walls a bitObserved Results
Baby runs right under half slabsOther Information
- This only seems to happen with some baby villagers – it took me a few tries to get one that would do this. This is most noticeable in villager breeders and open trading halls.
- It does not need to be double slabs as shown in the video.
- When running from a mob (ex: zombie), they don't seem to try to escape through the slabs. Cannot push them under either. Seems it must be of their own volition.
- Unsure if this happens with baby zombies.
- Attached world download logs in facing a baby villager surrounded by slabs. That villager should be able to run out from under the slabs if it decides to do so.
This was originally reported in
MCPE-151295but was marked as resolved due to it only being a realms issue (Could not reproduce in singleplayer)
Yes, this is still an issue.
AvgZing: When you say "villagers are sometimes assigned a new random number", what number are you looking at? A villager's identifying number is its UniqueID, which is stored in its entity definition inside the chunk it's in. As far as the game logic is concerned, that number is the villager. It can't change, not even when you save and reload the world. For it to change would be like you swapping bodies, names, and minds with somebody else. Would you still be you? No, you'd be him and he'd be you. But villagers don't swap bodies and identities, so their UniqueIDs should never change.
In the DWELLERS list, the items in the first actors list represent the associations of villagers and the village. The ID of each actor is the UniqueID of the villager entity. Since the UniqueID can't change, the actor IDs can't change either...but the order they're listed can and does change for a bunch of reasons. So it's possible your statement was based on noticing that the ID number at a particular position in the list changed. If that's what you saw, I think you'll find if you look at all the actor ID numbers that they may be shuffled, but they don't change.
Another possibility is that one or more chunks in the village were pruned. Server administrators sometimes do that to reduce the world size after members have explored a lot. Depending on whether they also delete the old village data, pruning chunks in a village could cause a lot of seemingly random problems. However, pruning is something that happens outside the game and it isn't supported, so any problems it causes are not reportable as bugs.
AvgZing: See the comment immediately above yours and the Fix Version field.
![[Mod] EVGENSYPERPRO](../../../data/avatars/users/92853.png){kind=small}
AvgZing: Beacon is a complete block, without any holes in the textures. Accordingly, I consider this a mistake. Also the glass block doesn't get waterlogged (unless you think it should be waterlogged because of the glass)...
AvgZing: vanilla-parity means that the function works differently in the java version.
Resolved, my texture packs were outdated
JL576875 said that the anvil textures bug is already reported, feel free to ignore that part then.
Cookiebuild3r, while I appreciate your effort to help, please look at the pictures. I clearly did that already.
Mega_Spud, Of course I did that! As an IT guy, I knew where to look and got everything deleted, even the registry keys (thanks regedit!)
Thank you for editing, I was planning on doing just that, but you beat me to it!
Hi There Bemoty,
It doesn't seem to have been fixed, here's another screenshot
Sorry, the previous screenshot was unclear. Here's another
While there are fewer creepers than before, there is still a very large amount, considering it's peaceful mode... Perhaps the limit needs to be lowered?
I connected to a server. I then left the server. I then closed Minecraft. Two days later I reopened it and joined my local world then got these pictures. I have not been able to reproduce it recently, however, because it's a rare problem...
In other words, not related to servers.
I can confirm this, although not for farms. In a villager breeder in survival Realms, many of our villagers frequently despawn. So far, we've unfortunately lost a mending librarian, respiration librarian, 2 clerics, and a weapon smith.
Ian,
Unfortunately, the technique that you mentioned is impractical for Villager Breeders which require AFK time to grow and breed the villagers.
You must contact Matt Gartzke on twitter and he'll get this resolved.
I can still reproduce this on 1.2.11.x. I cannot reproduce it on my laptop, but it is very visible on my desktop PC. 5 seconds per letter. Very painful to type with, unfortunately.
Read the changelogs. This was a feature modified for Update Aquatic: Underwater descent speed slowed. This is, unfortunately, working as intended. The easiest way to get around this is by turning on experimental gameplay and swimming to the floor.
This means that the server has not updated to the latest version yet.
Also reproduced on Win10. When the word "for" is on the second or third line of a sign, it goes to a one-line mess. Additionally, when it becomes a one-line thing, the word "This" is hashed out to "####". I've tried to fix this with enters, with automatic spacing, with different colors or formattings, no avail. So far I just have to avoid using "for" in lines 2 or 3.
Confirmed on 1.12.0.24 on Windows 10 update 1903. The skin only changes when the app is completely restarted. If the client remains open, the skin will never reset, even when crashing out of a realm due to AFK.
Confirmed on Windows 10 v1.12.0.28. Lags in all gamemodes. Testing on realms is needed
WAI. That's a Java feature
On bedrock edition, when chunks are unloading and reloading, the villagers are sometimes assigned a new random number. This will sometimes disconnect them from everything and force them to reconnect. However, reconnecting to their job sites or beds can sometimes go wrong and instead of connecting to their previous bed and workstation, they connect to another one-- sometimes thousands of blocks away. This seems to be due to a malfunction in the villagers' "Detection radius" value.
I've heard about this on other devices in the past. Often times the issue is just that they did not properly uninstall the game. Other times it's because their phone simply has issues with the game and needs a factory reset
1.13.0.18 seems to have this fixed, spawning only creepers and spiders as intended.
Still affects 1.13.0.18
Affects 1.13.0.18, can be solved by putting carpet on top of the magma blocks
Update: Fixed in 1.13
Still affects 1.13. Similar unlinking issue affecting Java 1.14.4, but without the village expansion
Still affects some devices. Apparent solution is to turn on fancy bubbles, which could cause lag. Not a reliable solution.
Since this has been mainly discussed on the Techrock discord rather than on the bug tracker, I figured I'd update with my (minimal) knowledge. In addition to the issues above:
I've seen patrols in extremely limited amounts around villages: I've only seen 1-2 in my entire play time since V&P (far more hours than I'd like to admit ;3), so the issue may just be light-related but there's a chance that the spawning-timer implementation as listed on the Wiki is bugged as well, in and of itself.
As previously stated, restarts are the only way to fix the broken chunks. Very occasionally, it can be fixed by leaving the area and returning, but this doesn't always work
Just got another rollback, 3 or 4 minutes ago, rolled back around 10 minutes of progress. Not as much as usual, but still a rollback...
Thank you for trying to fix, though!
Also note
MCPE-82191IonicEcko, while the distribution matches it, the biome size itself does not. There's another issue pertaining to this which I'll look for later.
This seems like a cause for a potential memory leak if what Kris Beauchamp said is the case.
Can confirm. No fog parity with Java right now.
As previously mentioned, also affects soul sand valleys. This is a MAJOR fundamental bug with the update and needs fixing ASAP. Unfortunately, however, it still affects today's beta.
Confirmed. Fossils are currently incredibly rare.
Decision needs reconsidering with running iPad MC on MacOS without touchscreens.
As this was fixed in 1.16, can someone test
MCPE-50175to ensure that this fix did not bring back that bug?Caleb, that's untrue. That's been shared around a lot, but the fact that it worked in the past (but was then broken) shows that that's untrue.
As stated in
MCPE-69159, the issue seems to be incorrect generation location of the ceilings (around y125) rather than completely missing.Still affects 1.16.1
Still affects 1.16.1
WAI on Realms, only a BDS issue
Fixed in 1.16.20.52
Still affects 1.16.20.53
Still affects 1.16.20.53
Affects 1.16.20.54
Affects 1.16.20.54
Affects 1.16.100.50
Affects 1.16.100.50
Affects 1.16.2 and 1.16.100.51
Affects 1.16.2 and 1.16.100.51
Issue invalid: Your admin needs to update their game to 1.16.2, and then update the server using the new Bedrock Dedicated Server files for 1.16.2 on the Minecraft website.
Affects version 1.16.100.51
1.16.100 is still not Java parity: villagers lose their discounts after a certain time.
Realms have already been laggy on a simulation distance of 4. Unless the entire game has been optimized AND realm specs have been raised (neither of which have happened), realms should not be raised to any simulation distance other than 4 or 6 (which is ideal). Simulation distance 10 loads 4 times as many chunks (see @Amuhn Ra's breakdown) per player. Realms simply aren't built to handle anywhere near this: I have no idea what testing you did, but this does not seem thought out to me.
On top of that, this not only added a lot more lag to both realms AND clients (devices stuttering, mobs "teleporting", mob caps filling up nearly instantly, etc), but it also broke the majority of farms on the platform as virtually all farms are built for sim 6 or sim 4.
Players typically don't even play on sim 10 on their local worlds: I don't understand why it's being forced on realms.
Especially on realms with addons or realms with many players, it's impossible to play: almost half of my players have protested this change and started playing on other servers rather than our realm, simply because it's such a massively negative change. Some other realm owners I know switched immediately from realms to servers. Please, revert this change, or switch it to simulation 6, or open it up to player changing.
I believe this is intentional: as with render distance, simulation distance scales to device performance.
I'm facing the opposite: All rendering is being done by the GPU, none by the CPU.
It seems that render dragon abandoned the distribution of rendering between CPU and GPU and just went "if your GPU can do it, it will, and if your GPU can't, then your CPU will", but those metrics are useless because some GPUs are good but not that good, and no CPUs are even close to that good.
It seems that render dragon abandoned the distribution of rendering between CPU and GPU and just went "if your GPU can do it, it will, and if your GPU can't, then your CPU will", but those metrics are useless because some GPUs are good but not that good, and no CPUs are even close to that good. See:
MCPE-97408While I can't speak for mobile, I know a related issue is
MCPE-97408. It seems that render dragon abandoned the distribution of rendering between CPU and GPU and just went "if your GPU can do it, it will, and if your GPU can't, then your CPU will", but those metrics are useless because some GPUs are good but not that good, and no CPUs are even close to that good. Because of this, I get lag on even just the title screen on my laptop with an Ryzen 3500U (+Vega 8 Graphics, which can run 48 chunks-pre-RD with 80% GPU and now runs at 100% GPU regardless of render)Tested on multiple windows 10 laptops, mobile, and xbox.
Experienced in multiple different worlds.
The coordinates provided were example coordinates. It occurs regardless of nether portal positioning. No matter what the coordinates, world, or device, nether portals will occasionally delink from their originally connected one and instead generate a brand new one at game-determined coordinates (just as it would if the original portal is broken, except that it is not broken, it is intact and should be treated as such by the game.)
This is not the issue.
I would understand if it, instead of going to the 'wrong' coordinates (0,0) created the portal at the 'right' coordinates (56, 56) and consistently went there. But that is not how this is working.
When the portal at 56, 56 is created, it does not link there permanently. In fact, most times, it still takes you to 0, 0, the wrong coordinates. But occasionally, it will take you to 56, 56. (or any other coordinates, 56, 56 is just an example).
That is the inconsistency that I am reporting: it does not send the player to the "new portal as close as possible to the calculated coordinates".
I'd also like to note that the information provided in
MCPE-39609is contradicted by the world NBT data: portals do actually have a set 'list' of 'target portal coordinates' that they're linked with, if you open the world up in MCCToolchest or UME, you will see this. Presumably, the issue is that the NBT data is either incorrectly overwritten, wrongly prioritized, or incorrectly called.Steps to Reproduce:
1. Create a nether portal in the overworld
2. Create a nether portal in the nether at coordinates (Overworld/8), as one does when making a nether portal
3. Enter the nether portal repeatedly
Observed Results:
A 2nd nether portal will be generated in the overworld, quite nearby to the portal created in step 1. When entering Overworld Portal #2, you will still arrive at the Nether-Side Portal. When entering the Nether Portal, you will come out at Overworld Portal #1 (as created in step #1), but occasionally you will come out at the 2nd nether portal.
Expected Results:
By the nether portal coordinate system, the Nether-Side Nether Portal should remain linked to Overworld Portal #1, because the coordinates are correct (divided by 8). It should not generate a 2nd Overworld Portal
Overworld Portal 1 and the nether portal should be consistently linked, without randomly, occasionally generating (or linking) to a 2nd Overworld portal.
There are no bedrock tweaks packs enabled. It has been tested on a realm with only the problematic pack and nothing else, and the issues were still present. As FoxyNoTail's packs are also affected, it's not an issue relating solely to the One Player Sleep pack. No matter the cause, there should still not exist this discrepancy between realms/BDS and singleplayer/multiplayer. It is reproducable when the impacted player is the only one online/connecting, as well as when there are other, non-impacted players online.
I have updated the ticket as you requested. To address the "single issue" aspect, this is all with the same root cause of the difference in behavior, with the crash being a result of that difference.
The issue may be marked as closed. Though it is unusual that it runs at 100% GPU consistently, it scales back the processes as more tasks need to use it. Essentially, optimizing performance constantly. Though it harms battery life, it's not an issue.
Yes, this is still an issue. The /give command will still only give a certain amount of items, rather than the amount as requested, and will display a discrepancy in chat.
This remains an issue. The ticket has been updated.
This bug's been around for as long as we've had rain, but it's now more significant with mountains encouraging higher builds and deeper caves for the rain to affect. Has anyone tested the exact limits of this in the current update and in the caves and cliffs betas? What's the height that blocks need to be placed at to begin raining inside, and did it adjust with the new betas or is it still in the mid 200s - and if it is, does it rain underground under mountains?
Here's a video that begins to cover and explain this with a demonstration. More testing has gone on since then, but there's some proof for now. https://youtu.be/rMERsHtWW0I?t=485
Unsure if this was fixed in the beta. I know that eating animations for custom food were fixed, so maybe this was too.
Perhaps I worded it wrong. The bug is that updating a realm from the main menu fails when players are online, but succeeds when the realm is empty.
An ideal test case would have lots of players spaced out far in the world with a large render discrepancy, while monitoring real-world resource use as the discrepancy is changed.
Fixed in 1.18.10.
Added 1.18.10 to the affected versions.
The intended behavior is to drop the remaining items on the ground, similar to if you broke a chest. This is most helpful if filling a doublechest or similar.
See
REALMS-9869, which has reproduction steps, an ADO, and more evidence.REALMS-2980lacks the ADO and some proof, but provides a fantastic video demonstrating how to test this via in-game means, and adds another confirmation of this issue.Relates to MCPE-16892?
This can be closed, the issue was that mob griefing was off.
This issue persists.
Confirmed on my own realm. This was originally reported in
MCPE-151295but was marked as resolved due to it only being a realms issue (Could not reproduce in singleplayer)Still affects 1.18.30
This may relate to REALMS-10109. In that issue, the order of operations in behavior packs on realms is different from singleplayer – it's possible that this is what's causing the issue on xbox for these packs as well, particularly if interactions with bedrocktweaks packs are exacerbating the issue.
Affects 1.18.30
Steps to Reproduce:
1. Download the addon linked to this report, or any addon with an item (custom or modified vanilla) whose maximum stack size is below 64
2. Add the addon as a behavior and resource pack to a realms world
3. Move it around the creative or survival inventory, shift clicking and pulling stacks out of inventories, and merging them
Observed Results:
Stacks flicker with a full stack size before the excess disappears. When merging 2 stacks already in the inventory, the excess disappears. The overall experience is glitchy and results in voided items or errors.
Expected Results:
Stacks smoothly merge or are prevented from merging, and are moved around the inventory while preserving their maximum stack size.
Relates to MCPE-42473
This relates to MCPE-154475.
Theory: single-stacked items who give themselves as a product/remain in the crafting table have different behavior than multi-stacked items.
Additional information: If a crafting recipe requires 1 prismatic shard (for example) and outputs 1 cake and 1 prismatic shard, the intended behavior is for the prismatic shard to remain in the crafting table, but instead said prismatic shard moves to the inventory. HOWEVER, if you put 2 prismatic shards in the crafting table, crafting the cake will result in the prismatic shard remaining in the crafting table, as intended. Very odd inconsistency.
My world experienced this back in 1.14, but only one time – so it was not reproduceable enough to create a big report. Terrible as corruption is, I'm glad this is getting more widespread attention.
In that situation, ONLY mobile players had issues. Their game would lock up and they would be unable to move/load in, until we killed them to move them to another area. After deleting the chunks through a world editor, the issue was resolved.
Client side memory leak, maybe? Possibly caused by pendingticks?
The placefeature command no longer exists in the game. It was likely added accidentally and removed prior to 1.18.30's release. This issue can be closed until the feature is added officially.
It should be solidly waterlogged (ex: waterlogging it fills the interior with water), and water shouldn't flow out. However as seen with stairs, trapdoors, leaves and other partial blocks, solid waterlogging doesn't exist on bedrock as it does on java – water will flow out of any waterlogged block. Still WAI imo, since there is water-fillable space in the block.
Presumably when all players log out, as that's the condition required for a restart of the realm.
This can be confirmed by multiple people on
REALMS-10112Happens to vanilla realms as well.
Yes @Marco Bergsma that's right. It's ONLY the gamerules that are NOT in the world settings. Great deduction!
That other issue seems like a separate command-functionality based issue. This issue in this case is that the realm is only saving world settings. Intended behavior is that "permanent settings" were meant to be set through the realm menu, , for EXAMPLE, the /difficulty command used to only last until restart. This issue is a problem because these ingame-command-gamerules cannot be permanently set through the menu.
RE: Umija5895M
If you set your simulation distance to 4, load a new world, and run "/fill ~-40 ~ ~-40 ~40 ~ ~40" the command fails. There are very specific areas – not limited to chunks, but specific blocks – where the command succeeds.
40 blocks is within simulation distance 4, no matter where you are in a chunk, proving that the issue with /fill is dissociated from simulation distance.
All blocks within the command must be in a Saved Chunk, and chunks only save when they're interacted with – not just when simulated.
I don't believe this bug should be labeled Vanilla Parity – this is a feature that used to work and now fails, not something in need of a parity update.
Seems to be working for me @D3vinRil3y, have you tried changing the hover note and structure name that you're using to a different one after each edit?
Yes
Just tested once again in 1.19.80: maps still inflate world size.
The in-game world size counter is slightly inaccurate, more of an estimation. Here are accurate steps to reproduce:
Expected Result: There is one map created at the default scale, with a very minor file size increase.
Observed Result: There are 5 maps created at all scales, without even viewing the map. The file size is increased permanently and to a greater effect than it would be otherwise. (See "Map Bug.png" attached to the report, showing 1 map in-game with 5 maps in the world NBT).
When a map is generated, it remains in the files forever; hence why maps continue to increment in numbers in-game overtime. This is intended and destroying the maps will not do anything. What is unintended is the auto-generation of all scales for every map created.
This is continuing to impact 1.20 on realms. Wonder if this relates to
MCPE-74493Confirmed as well. Bonemeal doesn't work underwater.
Thanks. Search function hates me sometimes.
Can confirm.
Observed behavior: TNT underwater does no damage to players.
Expected behavior: When TNT is dispensed underwater, it damages players around it unless their feet are behind blocks – just like above the water.
Notes: This is inconsistent with the behavior from Java Edition which was marked Works As Intended in
MC-26279, and can serve as a correction toMCPE-21611which was from prior to Buzzy Bees+ parity initiatives.This is a bedrock realms-only issue. Does not impact any other modes of gameplay (BDS is untested)
I have tested on two realms – one with addons, and one that's completely vanilla. Both experienced this issue.
Still affects 1.20.50.
RandomTickSpeed does not impact the deepslate redstone ore either.
Was this fixed along with
MCPE-169988?This is an updated version of
MCPE-163810Really not sure how this is WAI. How is it "intended" to have any player animations or animation-based UI changes break custom skins and capes entirely? Can this be reopened or the decision explained?
This still occurs in the latest stable release and is replicable using the attached pack.