eSonOfAnder
- e_SonOfAnder
- e_sonofander
- America/Los_Angeles
- Yes
- No
MCPE-61021MCPE-61362MCPE-92752
MC-233399MCPE-156541
WEB-6526
Not sure what is going on, but this ticket is not showing up in the "Open Issues" query from the main page here at all. Is anybody else even seeing this ticket?
Xbox One S controller not working in MCPE1.7Xbox One S controller not working in MCPE on Android
Downloaded the current version of MCPE to my Google Pixel XL, and I am unable to use the Xbox One S controller connected via Bluetooth to properly control the game. Once in a game, the left stick will control movement, but nothing else works. None of the buttons or triggers are recognized, nor is the right stick. The phone recognizes the controller as an input device, and I can use the buttons to control things within the OS (menu navigation and such), so the problem
occurs to bewithinMinecraftitself.Downloaded the current version of MCPE to my Google Pixel XL, and I am unable to use the Xbox One S controller connected via Bluetooth to properly control the game. Once in a game, the left stick will control movement, but nothing else works. None of the buttons or triggers are recognized, nor is the right stick. The phone recognizes the controller as an input device, and I can use the buttons to control things within the OS (menu navigation and such), so the problem appears to be isolated to just Minecraft.
Xbox One Scontroller not working in MCPE on AndroidBluetooth controllers not working in MCPE on Android
Character creator designed skin deleted and replaced with defaultAlex skinCharacter creator designed skin deleted and replaced with a default skin (Alex/Steve)
Minecart with Hopperpulling from a MUCH wider range than it should; does not match existing behavior in non-Bedrock codebaseMinecart with Hopper interacting with other Minecart with Hoppers incorrectly (ONLY with other Minecart with Hoppers)
Please note, this is something of a duplicate of https://bugs.mojang.com/browse/MCPE-60245, but the response there is incomplete, and not applicable.
As described in the linked ticket, a minecart with hopper will pull from another minecart with hopper if it is one level up and to one side, but only in the Bedrock versions of Minecraft. The Java edition of Minecraft does not exhibit this behavior. There is no expectation for this behavior to be the standard; it is illogical, and does NOT match the existing behavior in the rest of the Minecraft codebase. If this were truly "working as intended", it would be this way in both places.
The statement of the minecart with hopper pulling in items from a slightly wider range than the cart itself does NOT explain this behavior for two reasons:
- It is not collecting loose items; it is pulling from another container at a MUCH farther range than it should.
- The size of the minecart is smaller than a block, so your calculations appear to be starting at the wrong place, and are basing it from the outside of the block the minecart is sitting in, and NOT from the width of the minecart itself.
This is not a matter of a feature request; this is getting the behavior corrected to do both what is described in the Wiki (which it does not right now), as well as match the other half of the Minecraft codebase.
Please note, this is something of a duplicate of https://bugs.mojang.com/browse/MCPE-60245, but the response there is incomplete, and not applicable.
As described in the linked ticket, a minecart with hopper will pull from another minecart with hopper if it is one level up and to one side, but only in the Bedrock versions of Minecraft. The Java edition of Minecraft does not exhibit this behavior. There is no expectation for this behavior to be the standard; it is illogical, and does NOT match the existing behavior in the rest of the Minecraft codebase. If this were truly "working as intended", it would be this way in both places.
The statement of the minecart with hopper pulling in items from a slightly wider range than the cart itself does NOT explain this behavior for two reasons:
- It is not collecting loose items; it is pulling from another container at a MUCH farther range than it should.
- The size of the minecart is smaller than a block, so your calculations appear to be starting at the wrong place, and are basing it from the outside of the block the minecart is sitting in, and NOT from the width of the minecart itself.
This is not a matter of a feature request; this is getting the behavior corrected to do both what is described in the Wiki (which it does not right now), as well as match the other half of the Minecraft codebase.
Update screenshows every time the game launcheson XboxUpdate screen behavior incorrect on Xbox
Just.... why... seriously, Mojang, what are you smoking so I can avoid it?
The way the Deep Dark biome generates right now, the entirety of a selection of the "mountain" biomes become Deep Dark once you hit the deepslate Y levels. This
means that Deepslate Emerald Ore will no longer generate under all of these biomesthatthis occurs under. If you are under other types of mountain biomes that do not turn into Deep Dark biome, you will still find Deepslate Emerald Ore generating normally.Known broken:
Stony Peaks
Known working:
Grove
(I will update the above list as I can validate the various biomes.)
Recommendation:
Either:
- Fix Deep Dark generation so that it is not simply a switch for a given biome at a given Y level
the way it is now. (What happened to the whole 3D generation of biomes? Why was that not applied to the Deep Dark biome?)Since the Deep Dark only generates under mountain biomes, allow Deepslate Emerald Ore generationinthem at the appropriate Y levels.
The way the Deep Dark biome generates right now, the entirety of a selection of the "mountain" biomes become Deep Dark once you hit the deepslate Y levels. This was supposed to happen in the same way that Lush Caves and Dripstone Caves generate in 3D blobs, not just "If biome == Stony Peaks || Jagged Peaks && y < 0 set biome = Deep Dark", which is what is happening now. The knock-on effect here is broken rare ore generation for mountain biomes. (Similar to the reported issue affecting Lush Caves / Dripstone Caves, but worse as Deep Dark biomes have no ore generation overrides the way the other two cave biomes do.)
Known broken:
Stony Peaks
Jagged Peaks
Known working:
Grove
(I will update the above list as I can validate the various biomes.)
Recommendation:
Either:
- Fix Deep Dark generation so that it is not simply a switch for a given biome at a given Y level.
- To address the knock-on effect, allow rare ore generation for the original biome that the Deep Dark biome replaced.
Deep Dark biome generationhas broken Deepslate Emerald Ore generationDeep Dark biome generation replaces entirety of specific mountain biomes at Y < 0
![[Mod] GoldenHelmet](../../../data/avatars/users/18951.svg){kind=small}
I can confirm eSonOfAnder’s findings. Farmers (at least those generated in 1.16) will only harvest if they already have something to plant. They do not need to have the specific crop they are going to harvest, just something plantable. I tested potatoes and wheat seeds in a newly generated world, with a different seed from the one provided in the description.
@eSonOfAnder: thanks for providing more information and testing this issue. I've watched the video, tested it myself, and also looked at the vanilla behavior pack. At this point I'm not convinced there is an additional bug here beyond the harvesting bug tracked at MCPE-80084. What I think you've found, instead, are some helpful tips for the design of automatic crop farms. I was able to get farmers to share food when their composters were not next to another villager, and when they had no workstation at all. Putting the composter over the other villager where the farmer cannot reach it just makes the farm more efficient.
It's important to keep in mind that villager behavior is designed around naturally generated villages. In the vanilla behavior pack sharing is a very low-priority behavior--lower than working, harvesting crops, and most other things villagers can do. The radius for targeting other villagers to share with is also very short (3 blocks). This results in farmers in a naturally-generated village sharing food mostly during the afternoon gathering time. That's usually enough to get food distributed to allow the population to grow or recover from an assault. Also, if it weren't coded this way, farmers would end up not refreshing trades and not harvesting consistently, or maybe even not going to bed! A naturally generated village has to balance all of these behaviors. It probably should not surprise that when you want to exploit game mechanics to make highly efficient farms, you may need set things up in ways that look unnatural.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
There are also other examples of non-intuitive recipe triggers, for example you get the boat recipe by jumping in water, the torch recipe when you've crafted a stone pickaxe, and the chest recipe when more than 9 slots in your inventory are filled.
@eSonOfAnder Please be civil here, I have removed your comment. Please only leave comments here if you have something useful to add to the bug report.
Just updated to 1.8.0 and the issue still exists.
Have verified that other games that support Bluetooth controls are working correctly with the same controller connected to the phone.
To clarify, the problem is NOT connecting the controller to the phone; the problem is Minecraft recognizing the controller that is connected. As stated in the description and earlier comments, the controller connects properly, and operates correctly in other games that support Bluetooth controllers.
Controller is on firmware 3.1.1221.0 and shows no updates available.
I purchased and downloaded MCPE from the Amazon App Store, though it appears to be the same version (numerically at least) as what is available from the Google Play Store.
In response to my specific observed behavior, the left stick is the only control that performs anything. No other buttons, triggers, nor the right stick do anything within the game.
I duplicate the exact same behavior on a Samsung Galaxy Tab S2 tablet, running Android 7.0 as well. Left stick moves the character, no button callouts in the UI, cannot assign anything in settings, no response to button, trigger, or right stick within the game.
Can someone please confirm that Bluetooth controller support isn't stripped out of the Amazon App Store version of the game? There are no recent threads on this topic anywhere, hence why I opened this ticket in the first place, but this thread from 1 year ago in the Minecraft subreddit implies that the Amazon version somehow has the Bluetooth controller feature disabled:
https://www.reddit.com/r/MCPE/comments/6bw1o4/problems_with_controller/
Can someone please either confirm or refute this? There does not appear to be any documentation about this anywhere.
Thank you for re-opening. This feels like a very bizarre choice to remove support in the Amazon App Store version, yet it still has all of the Controller settings, which clearly do nothing at this time. At the very least some clear documentation needs to exist, because there is nothing in the Amazon app listing that indicates the game doesn't have the same controller compatibility as the Google Play Store version. The preferable solution is to activate controller support in the Amazon App Store version.
1.10 just released, and confirmed that this issue still exists.
Just confirmed problem still exists in 1.10 that just released.
Attached another debug output log file - most of the time logged in that debug output was me standing still attempting to eat. There was the remainder of a pillager raid with a few pillagers in a village near the spawn of the world, but things were so slow, it was impossible to do anything - move, fight, eat, anything. CPU and RAM usage of the server were low - only about 1 GB of RAM used, and about 30% CPU usage, so it's not a resource availability issue.
Look at the Fix Version field. It is fixed in an upcoming release of the game. Likely to be in the 1.14.1 patch based on Nathan's (Dinnerbone) comments on Twitter. The issue is not closed, but they have resolved the issue internally in the code base; we just have not received it, because the fix hasn't been released / published, yet.
Updated client and server to 1.14.1-pre1, and can see a noticeable improvement, though still not even hitting 20 TPS with only a single client connected. Attached debug capture with myself connected with a Vanilla 1.14.1-pre1 client. Time was spent walking through a cave system that is probably just outside of the spawn chunks of the world, breaking some blocks, placing torches, and encountered a couple of hostile mobs (some silverfish, a couple zombies, and a creeper). There was the sound of a skeleton, but it never appeared in my vision, so may have been on the other side of a wall.
I did encounter some block lag where a block would be broken, re-appear, then disappear again and drop its item. When attacking the silverfish, there were times when the mob would stall for a moment not moving, and also the hitbox was out of place with where the rendered model was showing on the screen, causing some sword swings to miss that I would have expected to hit. One of the zombies did show the clear stutter-step pattern of the server struggling to position it and move it, but that cleared fairly quickly.
Not entirely fixed, but definitely an improvement over 1.14.
profile-results-2019-05-07_20.52.58.txt
Improvements appear to be limited to just having a single player on the server. The instant a second player joined the server, performance went right back down the tube (7 TPS). I was in the same cave system as during the previous debug capture, and noticed that hostile mobs were having severe difficulty with navigation, and were rubber banding, stuttering, and freezing in place. The second player on the server was in a boat, and at one point fell through their boat, through the water, and down into a cave underneath the water about 20 blocks. Pulled another debug log, and attaching it here.
1.14.1-pre1-profile-results-2019-05-07_23.38.21.txt
Looking at the debug log files, the only thing that sticks out is the very high percentage of tick time being spent on AI for the various entities in the loaded chunks, particularly cod, but given that everything is in averaged percentages, it is impossible to tell with that information alone just how much actual time is being spent where. System resource usage on the server is still well below any sort of threshold value - CPU is running around 30%, and RAM is under 1 GB used.
That bit about new world vs upgraded world does not apply to 1.14 at least. Have not tried a newly created 1.14.1-pre1 world. The 1.14 captured debug logs from me earlier are from a fresh 1.14 world, not upgraded from a previous version.
I cannot validate this against the conditions I described above (being tied to upgrading from 1.14 to 1.14.1-pre1.
Please close this ticket.
If, like me, you're on a server hosted by a dedicated hosting provider, we do not have access to the JVM arguments that are being used, and I have had zero luck getting their support people to tell me what they're using.
They have intentionally disabled Controllers in the Amazon App Store version of the game, and to date refuse to enable it for some reason that they have decided not to share with any of their customers that paid for it there. Very disappointing to say the least.
I'd suggest opening a new bug with all of your own pertinent details because it seems like you may be hitting a different situation. The chunk rendering is back to normal on both of my PCs as of the full 1.14.1 release.
My experience, as shown by the multiple debug logs attached previously, definitely do not match Carl's description above - I see this issue on 1.14, 1.14.1-pre1, 1.14.1-pre2, 1.14.1, and now also 1.14.2-pre1. Given that there were no mentions of anything that appeared to be performance related in the release notes, I'm not surprised this prerelease hasn't addressed any of the potential underlying causes for this issue.
Here is the most recent debug output for 1.14.2-pre1: 1.14.2-pre1-profile-results-2019-05-16_19.53.48.txt
Top tick usage is entities, and still seeing AI very high on the list with mobs that exist in large quantities like cod.
Through Minecraft-hosting.pro, I do not see the CPU as being pegged (which is honestly the thing that makes this whole situation more baffling), but still seeing severe issues with 1.14.2-pre2 even with just a single user logged in to the world. The most detailed information I can give you regarding the environment is as follows:
CPU: E3-1240v2 - 3.8GHz
RAM: 4 GB
Storage: SSD (no clarification if this is NVME vs. standard SSD; suspect standard)
Most recent debug log: 1.14.2-pre2-profile-results-2019-05-17_21.19.13.txt
What was going on: Single player in underground cavern doing some minor caving activities including: breaking various stone type blocks, encountering a handful of hostile mobs (zombies, skeletons, creepers), placing torches, creating new torches via 2x2 inventory grid.
Observed behavior: Block lag, mob pathing and movement issues, creeper explosion lag, hitbox detection issues (swing a weapon where an enemy should be based on client rendering, does not hit).
It's gotta be at least partially environmental; as a test, I loaded up the 1.14.2-pre2 server on my local PC:
Core i5-7600
16GB DDR4 RAM
Minecraft world running from standard platter HDD
64-bit Java:
java version "1.8.0_211"
Java(TM) SE Runtime Environment (build 1.8.0_211-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)
Running under Windows 10 Home edition.
With one exception, I have seen none of these same problems in this environment. Shortly after setting it up during a test run with me and a friend both connected via clients on other machines, and both remote on separate networks, we hit one lag spike that kicked us both, but I did not have the debug log running.
[15:59:06] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 40905ms or 818 ticks behind
And then both remote connections were dropped.
Since that time, one or both of us have been on pretty much constantly, and there have been no signs of the "can't keep up" messages that I am seeing on the hosted server whose specs I included earlier. There are a lot of unknowns with my current server host, and since they refuse to interact with me, I can't find answers to them (for example - what OS the machines are running, what specific version of Java beyond just some flavor of 8, what JVM command arguments are being used, etc).
Especially given that the hardware resource monitor on the hosted environment never shows the CPU or RAM usage coming anywhere close to capacity, this doesn't seem like it should be a hardware capability issue. Given the breadth of reports of this issue that I'm seeing across the community, and from responses that I've gotten from multiple other server hosting sites, something is clearly going on.
If there is anything we can provide beyond just these debug logs to try and get to the bottom of this, please let us know because this is extremely painful, and the silence coming from Mojang on this issue is deafening. There has not been a peep of attempting to address these issues in the recent release notes, and this ticket is getting zero responses or updates either.
After doing some digging I found that my server host (Minecraft-hosting.pro - save yourself the headache, and don't use them), not only has a script that disables the default Minecraft autosave feature, but then only issues a manual save once every 24 hours so if your server crashed or reboots between those times, you will lose any progress that has been done between those two points, making it look like chunks have reverted back to earlier states of development.
I have yet to find any documentation that shows how often the Java server saves when autosave is enabled, but it's not very frequent (though this REALLY needs to be documented). Your best bet is to force a save yourself every once in a while (/save-all), and if you have access to the host that the server is running on, set up a cron job to force a save on a timer.
So I cannot correlate the behavior I observed and originally opened this ticket for with a bug in Minecraft.
Amber - unless you are also seeing your server spew out "Unable to keep up" messages at the same time that you are seeing what you're describing, that sounds like a separate bug, and you should open a new bug for it.
Re: CPU Benchmarks - doesn't really help; the Minecraft-hosting.pro servers are running Xeon E3-1240v2 CPUs which are rated at 2028 on their single thread performance benchmark test, but everything from 1.14 through 1.14.2-pre2 is unplayable even with only a single player on the server, so either the min-spec is significantly higher than that, or there is something more going on.
Updated client and server to 1.14.2-pre3 as it added more output for chunk loading/unloading, but doesn't look like that is the specific issue that I am seeing here. Primary culprit still seems to be mob AI based on my profile output results.
1.14.2-pre3-profile-results-2019-05-23_22.42.42.txt
Single player connected to server running Xeon E3-1240v2 w/ 4 GB of RAM. Maneuvering around a cave system underneath the border between a mountain and ocean biome. Breaking occasional stone and ore blocks, and encountering the normal set of underground mobs - skeletons, zombies, creepers, bats.
Experience: Much the same as before, block lag with broken blocks re-appearing and then disappearing again a few moments later. Mobs visually moving very slowly or stuttering as they move, occasionally moving very fast if the server frees up enough to catch up to where it is supposed to be.
It is still extremely distressing that this ticket remains unassigned and Mojang devs are remaining silent.
As an experiment, I recreated the world from my previous tests newly in 1.14.2-pre3 (all of the profile results I've attached are from a world that was created in 1.14 and then upgraded through to 1.14.2-pre3) using the same seed to minimize differences. Created world, allowed the server to stabilize for a moment before logging in, and just proceeded to walk from spawn to where I knew a village was located, near where all of my above testing was done. Almost immediately after connecting, started seeing "Can't keep up" messages in the console, and I can observe some of the same behaviors. I summoned in some basic tools via creative before changing mode to survival and running the remainder of the test.
Debug profile: 1.14.2-pre3-profile-results-2019-05-23_23.22.40.txt
World seed (if this helps at all): 207227789904888
Just tested against 1.14.2-pre4, and still seeing issues. Block lag seemed to be a little bit better, but entity lag (villagers, mobs) was still quite bad. The vast majority of the tick time is still being consumed by mob AI based on the profile results attached here:
1.14.2-pre4-profile-results-2019-05-24_18.58.45.txt
This is again with a single player connected to the server; walking around in the overworld on the surface, breaking some random blocks, and killing a couple of hostile mobs. Same duplicated empty world from my previous comment, and same world seed as all of my previous profile result attachments.
(Is this even useful me posting these debug outputs at each updated snapshot and release showing that I am seeing what appears to be the same issue each time? It is feeling kind of pointless at this point given the lack of response.)
No noticeable improvement with the full release of 1.14.2. Still seeing huge amounts of block and entity lag with just a single player connected to the server. Looking at the debug capture, AI is still the number one culprit.
1.14.2-profile-results-2019-05-27_17.21.26.txt
To be fair, there were no notes about fixes to this in the release notes, but tested it for completeness anyway. Not sure if it would be worth including the actual console log here as well since it does give some more specific examples that get rolled up into the debug profile output. One example that stands out just browsing back through the console output:
[17:20:50] [Server thread/WARN]: Something's taking too long! 'root.tick.levels.mcu-dupe minecraft:overworld.tick.entities.regular.tick.minecraft:spider.ai.newAi.goalSelector.goalUpdate' took aprox 112.972352 ms
So that one specific behavior took over twice as long as a single full tick should take. Due to these issues, I've already canceled my server hosting plan, and my small group has basically disbanded because it became impossible to maintain with this level of performance. I do hope the problems get fixed eventually because it would be fun to play and/or run a MP server again in the future.
It is unclear if the mob despawning issue shown in this video was ever fixed from the initial 1.14 release, and lines up with what some folks have described above:
https://youtu.be/kVlDtWRoWuA
TL;DR - chunks are not unloading correctly based on render and server render distance, and mobs are not despawning correctly when moving the appropriate distance away from them. The video outlines in detail the specifics of what was seen.
I don't believe that is the only issue at play here, based on the numerous debug logs I have provided showing AI taking abnormal amounts of time without a corresponding spoke in CPU usage. (From a programming perspective, that sounds like a livelock / wait loop that isn't being gated out of correctly, but I'm not Gnembon and don't have the tools to deobfuscate the source code to do more detailed debugging.)
@Bob Tanner - you should also attach the debug profile file from the debug folder that is generated from running the debug start/stop commands.
Also "server lag" does not necessarily mean network lag - in this case they're referring to the Minecraft server (the application) lagging due to whatever this bug, or set of bugs, is. You're not going to be able to work around this with adjustments to your JVM arguments, because this is something buggy within the Minecraft server code itself, so we are at Mojang's mercy here.
@Jonathan Hanzel - IF that were the case, then Mojang could easily respond to this bug ticket with that information themselves, and let us know they were trying to deal with Amazon to get it sorted out. Additionally, that has to be something the developer deals with Amazon to get fixed, not the players, so no matter what the action here is still on Mojang.
Confirmed working here as well; be nice if Mojang would have said something either here in one of the multiple tickets opened for this issue or in the patch notes.
Looks like Mojang fixed the issue somewhere between 1.12 or 1.13; unclear exactly where the fix was implemented as there was zero communication about it either here on the supposed bug tracker or in the patch notes of the app.
Still not updated with the 1.15.1 patch notes either, and the Release Changelogs page that is linked to from the launcher is also missing the 1.15.1 patch notes. (https://feedback.minecraft.net/hc/en-us/sections/360001186971-Release-Changelogs)
@Louis That is a separate issue from this. This issue was for Bluetooth controllers 100% not being enabled as input devices on the Amazon App Store version of the app.
The search issue is inherent to JIRA, Mojang can't fix that. Would highly recommend you open up individual bug reports for both issues you are encountering (input lag, auto-jump not disabling due to multiple input detection). Tagging these in on separate issues only serves to muddy the waters, and makes it more difficult to get the individual problems fixed.
Just happened again, but this time it was replaced with the default Steve skin. This is getting more than a little tiresome. What is the point of having a character creator if you are just going to keep overwriting what people have made with one of the two default skins?
Some additional support for this - this behavior does not happen with hoppers that are above and to one side of a minecart with hopper which has a hit box of a full block, so if the minecart with hopper were really pulling from that much of a range, it would pull from a hopper in the same position. This does not happen with any of the full block sized containers in the upper position:
This is something unique about minecart with hoppers interacting with each other, NOT general minecart with hopper behavior.
No, it is not. I am not creating or saving a skin on the Xbox One, because there are currently bugs that do not allow you to make some choices in that version of the creator. This is a skin that I am making either through MCPE or MCE on Android, and then the Xbox One randomly replaces it with one of the two default skins. At no point in the process here is any device losing internet connection even briefly. This skin replacement issue is ONLY happening when connecting in on the Xbox One, which it then saves to the Microsoft account (proving it has internet connection just fine), after which the other devices pull down the replaced skin.
I have been very explicit here in my description of the scenario, which does not match what you are calling a duplicate. Don't do that.
https://bugs.mojang.com/browse/MCPE-61021 is absolutely not a duplicate of this bug. The end result may be similar, and they may have related fixes, but it is not the same issue.
Please note, this ticket has been resolved (check the ticket state), as the issue it was opened for has been fixed. Please open a new ticket, as comments on this issue are likely to be ignored from Mojang, as they consider the issue it was opened for fixed.
Based on your description, you failed to mention a few details that you will want to include in the ticket when you open it:
You may also try reaching out to the community on the Minecraft Discord (linked on the support pages).
Updated the description of this issue to reflect the current status.
Update 1.14.20 was released and rolled out, but once that was done, there was no update screen shown at all. If the expectation is that the update notice is shown on all Bedrock platform devices then this is not working across platforms as I saw no update notice on Xbox One, Android, or Windows 10.
Anybody that has used the "Search feature" of JIRA (and I use that phrase extremely generously) is very familiar with the fact that it is, in a word, useless. I did perform a search, and that is how I found the closed ticket I referenced in the original body of this report. The one you linked to did not get returned via search, so your implication that I had not done that step is both ill advised, and inappropriate, as it would be obvious to the most casual of observation that the only way I would have mentioned another ticket here is if I had searched for and found it.
So while I appreciate what you think you're trying to do here, you have also been super trigger happy with that "This is a dupe" button, and while yes, this one is indeed the same issue as the other one, you do not appear to be doing the proper due diligence with these reports. Given that this is literally the only way for Minecraft players to get any level of technical support from the developer, seeing this type of behavior, especially if it had been someone's first experience with the system, is extremely offputting, and does not help improve the quality of issues being reported. You'd merely see less of them as people just throw their hands in the air feeling that it is pointless to even bother in the first place.
And, yes, I understand that the Helpers are unpaid volunteers and not employees of Mojang, but the fact of the matter is that when people see the bolded name, it carries with it an additional layer of responsibility. I say this not to be rude or condescending, but as an opportunity for improvement moving forward. As I said, this is the players' only lifeline into Mojang, and it's tenuous enough already. Thank you, and good luck.
Confirmed, this issue is a 100% repro rate, and can be seen in the provided Crystal Palace map where a map table already exists in the castle.
Very likely intentional given that the ore in ore blocks also are faintly emissive and glow in the dark.
You can only place the blocks in this room by aiming at the top of the "frame" and letting the concrete powder fall into place. You cannot place it against the wall, or on top of the concrete powder that is already there. If that's intentional, it isn't clear from what the player sees.
This is specifically for bug reports. This is not the right place for feature/parity requests as those are not "bugs"; entity cramming does not exist in Bedrock, so not sure where you think you've tried an entity cramming farm and had it work in "Bedrock".
This type of feedback belongs here: https://feedback.minecraft.net/hc/en-us
There is an entire section for parity requests, both for Java -> Bedrock parity, and Bedrock -> Java parity.
For the rest of the information in your issue here, I would suggest checking out the official Minecraft Discord as that is going to be better addressed there to talk with other players about what Behavior Packs they might be able to recommend to get what you're looking for. https://discordapp.com/invite/minecraft
Same issue here on Switch version. Seeing lots of reports of this bug, but no responses from Mojang. Typical.
Same issue here. Guess I was expecting too much that this would somehow be better than Minecraft with respect to responding to bugs and issues. So many reports of this issue, so much silence from Mojang.
No, this is not the intended behavior - this creates a knock-on bug that was addressed in the Java version already, as this creates multiple infinite emerald loops including the librarian 1 bookshelf for 1 emerald and 1 emerald for 1 book. trades The price should be reduced by a factor, not all the way down to 1 emerald / 1 item for every single trade regardless of starting price, and there should be different minimums depending on the trade to avoid the above infinite loops.
Can confirm this behavior on Bedrock Windows 10 edition as well. This problem only happens if the farmer can both pathfind to, and actually reach, their workstation. If you place the composter someplace where the villager can pathfind to it (on the other side of some trapdoors that prevent them from physically reaching the composter, they will then share their food supply with other villagers.
The not harvesting crops bug is being tracked here:
MCPE-80084This does not address the failure to distribute food once they do have food in their inventory, though. The following tutorial video actually provides a work around to this bug explicitly: https://www.youtube.com/watch?v=I6D4fTRUpQ4
It is unclear if this only affects "new" 1.16 farmers, or if worlds that have been upgraded from previous versions will experience the same problem with existing farmer villagers. (As Bedrock does not provide an easy way to roll back to earlier versions, this scenario is quite difficult to test from the player side.)
I was testing this behavior earlier today in a creative test world, and made the following observation:
Have not done a full test of this with all of the crop types, yet, just carrots.
Depending on the behind the scenes behavior of the farmer when they work at their workstation, if it deletes some number of the crops in their inventory (to act like they have "used" the composter), this could be a self perpetuating situation. This would be worse for wheat, as the villager would hold onto wheat to turn into bread, and then probably "compost" the seeds, eventually filling their inventory with wheat and bread and no seeds. (Again, this is conjecture, because I do not have access to see what the code is actually doing.)
In the above described scenario by GoldenHelmet, I would suggest that in the scenario where you spawned a new villager and converted it to a farmer (or even converting an unemployed villager), if you gave that farmer some of the crop you wanted it to harvest, it would start harvesting them at that point.
There is a related issue where farmer villagers also do not distribute any crops or food that they have in their inventory:
MCPE-91823Additionally, it looks like farmers will only share food when attempting to pathfind to their workstation. (Again, this is behavior shown in the linked video in my previous comment.) If the composter that the farmer is attempting to pathfind to is not next to the villager that needs food, the farmer will never seek them out to share food with them, even if they are within a short range and have both a path and line of sight.
Affects the Stem and Hyphae blocks as well, not just planks.
Raid mobs definitely do spawn on almost any block in the game, including slabs and stairs where just about any other mob will not spawn. Leaf blocks are the only block that they appear to not be able to spawn on.
Example showing what is required to address this issue with raid mobs:
https://www.youtube.com/watch?v=aoVYFi4oPEM
This looks and feels like a bug, because this is a unique situation to raid mobs and only raid mobs. It is also unique to Bedrock, as this behavior does not happen in Java, so this doubly feels like something that should be addressed.
If the tooltip's location were moved to be below the cursor, that would eliminate this issue as well.
There are two bugs at work here, both already reported:
MCPE-80084MCPE-91823Please upvote those bugs.
Confirmed still in 1.16.2
This problem only exists in Creative mode. If the gamemode is Survival (with cheats enabled), the kill command works on the player/self.
I don't believe this has ever worked correctly, but I know it has existed back as far as 1.12, and everything from there through 1.16.2.
Unable to reproduce with any number of sea pickles whether the block above the pickle is originally a water block or not.
Thank you for the additional information; I know in my own creative test world I would not have seen this due to my testing conditions which would have artificially induced the observed "incorrect" behavior. I will update my testing and re-open a new bug if I find something reproducible under the conditions you outlined!
I will try that and let you know; I have not revisited this issue in a while.
This issue has never been fixed; I cannot find where I included videos showing this issue in action over a year ago, but can also confirm this is still a bug that has never been addressed (in spite of Mojang claiming that it has).
For additional reference, see the farm design shown here: https://www.youtube.com/watch?v=mLEdAnYjoL4
Specific timestamp to start watching for this issue: https://youtu.be/mLEdAnYjoL4?t=1148
This is an exceptionally easy bug to reproduce, would be nice if this would actually get FULLY fixed instead of just slap dashed and then ignored again.
MC-160119 - this bug was never fixed; would be nice if this would actually get some attention and be FULLY fixed instead of just half-arsed.
This is not isolated to a specific platform; this will occur on all Bedrock platforms - iOS, Android, Win 10, Xbox, PlayStation, Switch.
Edit: Would also recommend updating the title of this ticket to specifically mention the player suffocation as that is the much more severe effect of this bug.
Experiencing what appears to be a variation on this issue:
(This is in a naturally generated survival village)
Between this, the bug that allows villagers to attach to workstations they cannot pathfind to, and the bug that requires pumpkins be placed with the player facing north before farmers will buy them, villages are not valuable or reliable resources in Bedrock as it stands currently.
This is still an issue on Xbox One. Game bootup/load times are extremely excessive, and take longer than most other significantly larger games. Happens on both an original Xbox One and an Xbox One X - there is no difference in load times; they are both painfully slow to load. Once in game, things are fine, but it takes on the order of minutes, multiple, to go from hitting the A button to launch Minecraft until the main menu is available.
As I am not the original reporter, I cannot add the 1.17 versions to the affected list, but they should be added here.
I cannot give you screenshots because this was on a server and I did not take any. If the items were just invisible, I should still have picked them up because they existed. I did try logging out and back in to the server, but nothing reappeared. At least one other person from that server has stated that they've seen the exact same behavior multiple times. For this and many other reasons, I am unwilling to return to the game in its current broken state.
Found within a few minutes of looking in each of these two worlds in 21w44a:
World seed: 185740704
Monuments at:
Edit: Searched this world a bit more using the grid described below, and found two more. Looks like, as mentioned below, things stopping the spawning include biome change, and depth of ocean available, but that's it.
World seed: -480661120
Monuments at:
They appear to be generating in a rough grid along X/Z axes; as long as the biome remains an ocean, and it is deep enough for the structure to generate, you get one roughly every 500 - 600 blocks, with a bit of noise variations one way or the other. At least that's what it looks like.
I had found the first five monuments in the second world seed listed above in my original casual browsing of the seed - I then went back and did a grid approach, and found the rest of them simply by flying one of the cardinal directions from an existing monument.
There are other bugs being closed as duplicates of this one that accurately describe the issue correctly and are NOT actually duplicates of this, so either the description of this bug needs to be updated, or you need to STOP CLOSING TICKETS THAT AREN'T ACTUALLY DUPLICATES.
The actual issue:
Nether based woods, both Crimson and Warped, will catch fire from things like lava which is incorrect. Both wood types are supposed to be immune from catching fire as they are nether based blocks. Ignore the lighting of the blocks using a flint and steel, that has nothing to do with the ACTUAL big here.
And yes, I DID open this as a separate bug, but you closed it as a duplicate of this one. Several other people have as well of you would look at the list of supposed "duplicate" bugs, NONE OF WHICH talk about what this ticket was originally opened for.
This issue happens very frequently if you continue holding down the activate button/key while eating, at least on PC.
Repro steps:
Expected behavior:
Observed behavior:
Obviously some developer added this intentionally for it to be like this - that does not happen accidentally or through some interaction with unrelated code - however this is absolutely a bug. There is no other precedent for this type of restriction for a recipe (the closest similarity is the boat recipe unlocking when the player enters water for the first time). It is also, more importantly, completely inconsistent with all of the other rail recipes - none of which require the player to have had a minecart in their inventory to unlock. It makes NO sense for the player to have Powered Rails and Detector Rails unlocked but not the basic Rails recipe. And just so we are clear, the solution here is NOT to add the minecart requirement to the other rail recipes.
No, at no point was I offline during this process. This is a similar bug, but not identical to the linked one. I do not see the "Failed to load character" message at all on either platform, and this issue shows up directly on the first client with no change in platform needed. (I have encountered the linked bug, also, and mostly seem to experience that one on the Switch platform.)
I would expect changes to an offline profile to behave the way you are describing, but what I am seeing is the exact opposite of that. At game launch, the online profile is loaded properly with the skins created as expected. After saving and exiting from the game session and returning to the main menu, not only has the current skin been reverted to a default state, so have all other created skins on the account. And then, just to prove that this has all been done while online, those reverted skins are saved to the online account and can be seen as the "new" reverted to default state on all other platforms, as opposed to simply showing the "Unable to load character" error message if it were experiencing network issues for whatever reason.
This bug actually fully reverts character skins and saves them to the online account, without the player's action or permission.
No, this is not a duplicate of that issue, though it is related. The major bug here is how the Deep Dark biome generates and replaces all of some of the overworld mountain biomes at a certain Y level. This is not how the biome was described to work, instead it was supposed to work the same as the Lush Caves and Dripstone Caves where specific 3-dimensional blobs of underground areas would have a new biome override, but this is not how the Deep Dark biome is behaving. The knock-on (and arguably the more impactful) effect is that it breaks rare ore generation also. I am updating the title of this bug to reflect the underlying bug better.
The web feedback tool is 100% broken, and apparently has been for over a month based on when this ticket was opened, and yet the priority on this remains at Normal and. O action has been taken yet? Says a lot about just how little Mojang actually cares about player feedback.
Please see your own definition of the priority of this bug. There is NO WORKAROUND for this, therefore "Normal" is not the correct priority for it. Please adjust as actually appropriate, and better yet, address the bug here so that you can close the ticket.
That might be the way it is supposed to work, but in practice, that is not what is happening. As I described earlier in the ticket, deep dark biome generation is not behaving as described. Instead it is behaving as follows:
if (biome == (stony peaks || jagged peaks)) && y < 0
set biome = deep dark
There may be other mountain biomes where this is happening, but these are the two that I have observed it happening in.
Lumping all of the chunk loading and sound loading issues across all Bedrock platforms seems counterproductive, both from a bug report perspective (there is no longer one bug being reported and counted as part of this bug), as well as from a triage perspective on the Mojang side (how can you possibly try to reproduce something like this that has taken on a life of its own and is now so broad a topic as to be meaningless?).
There are at least four separate bugs identified just within the visible handful of comments shown when you first open this ticket:
I am quite sure if I dig further through the comments, there will be even more issues being lumped in here by having their tickets closed as duplicates of this one massive, "the game is broken" ticket.
Just to add another detail to this issue - the screenshot function, itself, does work if you hit Esc and use the Screenshot icon in the lower left portion of the screen. It is just the hotkey that is not actually connected to the action. Have not tested the 1.21.60 Preview to validate JervieA20's comment.