Azarel Howard
- azariah001
- azariah001
- Australia/Brisbane
- Yes
- No
MCPE-144168
Magma cube spawning is crazy aggressive in tunnels in the nether. The game is spawning so many magma cubes I can't do anything in certain areas. So I've started literally glassing my entire tunnel network. And even then. Just found this guy chilling inside a glass block.
I've also seen/heard Max and Medium size magma cubes spawning inside the walls neighbouring a 1x2 tunnel rail tunnel I have and suffocating. Know they were there because some of the small ones spilt into the tunnel.
Love the updates but seriously magma cube spawn rates are so high we've resorted to turning magma cream into magma blocks or just straight up throwing it in lava. Magma cream is not a limited resource on our server and they're only somewhat manageable because all of our armour pieces have Thorns.
So, we've just had this happen on a privately hosted server. And as a result, have been able to isolate exactly what's happening.
May I present exhibit A which comprises 23 freshly harvested ink sacks from squid. And two stacks of 36 purchased from 2 different traders at different times.
Exhibit B - Universal Minecraft Editor
So the top one is obviously the fresh ones from squid. The other two... well notice that damage counter. This isn't the first time bedrock has had this problem so I can't say I was surprised when I saw it. The traders are literally selling damaged goods. Lol.
Ink Sack Stacks - 23 from squid - 2 by 36 from traders.png
Mobs that are standing in water, such as those that would be in a mob farm, do not consistently have the flame effect applied to their drops. At best it's about 50% of the time, at worst it's around 25% of food drops that have the flame effect applied.
For instance see below images. All tests, except the last couple, were done with a Sharpness 5 Fire Aspect 2 Netherite Sword.
This first one I'm not sure how many cows I killed, likely around 30-40.
This second lot is exactly 20 cows worth.
And... 20 sheep
And 20 chickens, just to be thorough.
And... 20 cows with Looting 3 added into the mix
Expected outcome that applied up till around 1.17.30, 100% of mob drops, when one hit killed or just final blow killed with a Fire Aspect sword, would drop their cooked variants even when standing in water or rain.
Did some tests and cannot predict when the drops are going to be cooked or not, all drops are either/or and never mixed so at least it's specifically dependent on whether the mob is "officially" on fire at time of death or not. Regardless of whether they sound or appear on fire btw.
Just spawned a bunch of cows between a water logged lower slab and a solid block (1.5 blocks of standing space) such that they weren't able to bob any significant distance and... I got the below results. Clearly it doesn't matter a whole lot how much water the mob is standing in. : already retest with a full block of water below and a upper half slab above head... 100% raw drops, same outcome with rain, the rain test was accidental...
Issue is replicable both on a world upgraded from 1.15 to 1.16 to 1.17 as well as a 1.17 currently .32 server and a fresh 1.17.34 creative world.
Mobs that are standing in water, such as those that would be in a mob farm, do not consistently have the flame effect applied to their drops. At best it's about 50% of the time, at worst it's around 25% of food drops that have the flame effect applied.
For instance see below images. All tests, except the last couple, were done with a Sharpness 5 Fire Aspect 2 Netherite Sword.
This first one I'm not sure how many cows I killed, likely around 30-40.
This second lot is exactly 20 cows worth.
And... 20 sheep
And 20 chickens, just to be thorough.
And... 20 cows with Looting 3 added into the mix
Expected outcome that applied up till around 1.17.30, 100% of mob drops, when one hit killed or just final blow killed with a Fire Aspect sword, would drop their cooked variants even when standing in water or rain.
Did some tests and cannot predict when the drops are going to be cooked or not, all drops are either/or and never mixed so at least it's specifically dependent on whether the mob is "officially" on fire at time of death or not. Regardless of whether they sound or appear on fire btw.
Just spawned a bunch of cows between a water logged lower slab and a solid block (1.5 blocks of standing space) such that they weren't able to bob any significant distance and... I got the below results. Clearly it doesn't matter a whole lot how much water the mob is standing in. : already retested with a full block of water below and a upper half slab above head... 100% raw drops, same outcome with rain, the rain test was accidental...
Issue is replicable both on a world upgraded from 1.15 to 1.16 to 1.17 as well as a 1.17 currently .32 server and a fresh 1.17.34 creative world.
Hi Team
So this issue has been around for Magma cubes since, probably 1.16 launch actually. However, it's still happening and now I've caught overworld Slimes doing it too. Reporting together as I assume they share 90% of their code.
Also based upon the Wiki's there's a good chance this is actually a parity issue.
"A slime needs roughly a 3×2.1x3 free space to spawn. The area in which the slime spawns must be clear of solid or liquid obstructions. When a slime attempts to spawn, the game checks for the space requirement of a large slime, and the size is determined later. Therefore, since large slimes are slightly taller than 2 blocks, no slimes, regardless of size, are able to spawn at all in 2-block-high areas." Minecraft Fandom - Slime I can tell you I'm getting plenty of small and medium slimes in this clearing... Magma Cubes page lists the same spawn requirements. But same results in game, lots of small and mediums in 2 high cuttings with regular intrusions by larges embedded in the floor.1. Large Slime's Spawning in 2 high space. So, I've had a few of these spawn in this space, this time I saw it happen. So the Slime is spawning above the solid blocks with the top of it's head in the solid block above which kills lighting on the entity entirety causing it to flash black for a second. Then it does this awkward half hop and sinks into the floor...
Aside from spawning in the first place. That's the other thing that should be impossible, mobs should not be able to just sink into solid blocks, IMO.
2. Large Magma Cubes spawned "embedded" in the floor because the tunnel is only technically two high. Pretty sure I've seen them appear already in the solid blocks although it's possible the same sequence happens as with Slimes described above.
Hi Team
So this issue has been around for Magma cubes since, probably 1.16 launch actually. However, it's still happening and now I've caught overworld Slimes doing it too. Reporting together as I assume they share 90% of their code.
Also based upon the Wiki's there's a good chance this is actually a parity issue.
"A slime needs roughly a 3×2.1x3 free space to spawn. The area in which the slime spawns must be clear of solid or liquid obstructions. When a slime attempts to spawn, the game checks for the space requirement of a large slime, and the size is determined later. Therefore, since large slimes are slightly taller than 2 blocks, no slimes, regardless of size, are able to spawn at all in 2-block-high areas." Minecraft Fandom - Slime I can tell you I'm getting plenty of small and medium slimes in this clearing... Magma Cubes page lists the same spawn requirements. But same results in game, lots of small and mediums in 2 high cuttings with regular intrusions by larges embedded in the floor.1. Large Slime's Spawning in 2 high space. So, I've had a few of these spawn in this space, this time I saw it happen. So the Slime is spawning above the solid blocks with the top of it's head in the solid block above which kills lighting on the entity entirety causing it to flash black for a second. Then it does this awkward half hop and sinks into the floor...
Aside from spawning in the first place. That's the other thing that should be impossible, mobs should not be able to just sink into solid blocks, IMO.
2. Large Magma Cubes spawned "embedded" in the floor because the tunnel is only technically two high. Pretty sure I've seen them appear already in the solid blocks although it's possible the same sequence happens as with Slimes described above.
Azarel Howard: The bug tracker staff is made up of volunteers, not Mojang employees. We have no input into priority or scheduling of bug fixes, so when we get comments like that there's nothing we can do but ignore them. You should direct those comments to the Community Management team.
Some thoughts on your comments:
- As far as I know, the simultaneous release of 1.16 versions in Java and Bedrock was not intended to be meaningful. Mojang didn't make any announcement about enhanced parity or an intention to keep releases in sync for the future.
- There are lots of YouTube showcase and tutorial videos on building trading halls and other artificial villages in Bedrock. Some of them describe ways to stack them vertically for greater volume. That might be a workaround you would find useful.
- The latest release of the server software is 1.16.1.
- This is not a party issue. That villagers allocate workstations and beds to themselves is a parity feature; how they do it is not. Parity's goal is to give each version equivalent gameplay experiences, but it doesn't promise that the same steps will produce them in both.
I started trying to design a more efficient iron farm about a month ago and found it really hard to validate that my design was even working as the spawn rates were crazy low. As in a stack of iron blocks per 24 hour period on average.
So when I heard there was a beta running with a potential fix I figured I'd dive in and give my 2 cents. And boy was I not disappointed. Now, this is not going to get us up to Java spawn rates. That's going to take another rebuild in villager mechanics to fully implement gossip and the way gossip interacts with the golem spawning system. But the results are truly impressive nonetheless.
So how'd my farm go? Well, with no modifications I went from a stack of iron blocks a day or 24 ingots an hour to slightly more than 4.5 stacks of iron blocks in around 8 hours or 324 ingots per hour which is truly nuts in comparison. Personally, this is more than plenty for a single player world, and probably enough for a small multiplayer server unless you like flashing your iron wealth by building with it.
Now, I would like to see the rates hit 1000 ingots an hour because I think large servers are going to want more and that's a more balanced number than what we see in Java whilst not totally nerfing Java as I know Mojang is aiming at mechanics parity between the two in future. But. If they fix the village border mechanics so that you can stack villages, this point would be moot as you'd be able to just stack away and it would only take 3 layers to hit that number.
Confirmed Affects 1.16.0.55 Beta on Windows 10 PC
Issue is also confirmed to exist for TNT minecarts. Naturally.
@Tony Yu clearly not. Java has 100% drop rate, unless that's being stealth reverted in 1.16... but I doubt it because the Java community would already be at Mojang's throat if that was the case. This is a major parity issue in bedrock and is officially limiting my servers ability to make concrete for large projects in particular.
This needs to be made a top priority. Considering the village and pillage update was (I believe) the first of the simultaneous bedrock and java feature launches it is extremely frustrating to see bedrocks villagers continue to be ignored.
My friend and I just built a 40 villager librarian hall using the standing in water trick to prevent them from delinking.... It didn't work. We literally watched the entire hall relink to tables on opposing chunks.... Our hall covers a total of 4 chunks it's going to be a pain to re-pair all of the librarians every time we use the hall.....
This is on fully updated serves and clients running 1.16.2 I think that's gone stable... Problem is the Microsoft store said we were on 1.16.1 on launch day so it's really hard to know ... Could be .1 whatever the "stable" release is currently.
This is turning into one of most important parity issues now that Java's villagers aren't picky about their workstations and will simply utilise the closest one by seniority.
Saw the patch notes and immediately new this would be an issue. Our server runs at 6 chunk tick distance. This is going to seriously knee cap some of our farms.
I agree with the OP. These volume sliders are nice but largely pointless if they don't affect the single most annoying sounds in the game.
I note the existence of:
MCPE-14420dropper and dispenser sound is not directional (added to development teams bug tracker in 2016) andMCPE-48919Blocks that use click.ogg play at full volume (exists).To me this indicates that the source of the issue is that these sounds do not exist within the volumetric volume system that all other game sounds inhabit and that are controlled by the new sliders. I think if the devs do not wish the move these sounds into the main volumetric audio space (likely because of the PVP trap consequences that may arise) then there should be an additional slider for "sounds that originate at player" or you know general Redstone sounds.
So, we've just had this happen on a privately hosted server. And as a result, have been able to isolate exactly what's happening.
May I present exhibit A which comprises 23 freshly harvested ink sacks from squid. And two stacks of 36 purchased from 2 different traders at different times.
Exhibit B - Universal Minecraft Editor
So the top one is obviously the fresh ones from squid. The other two... well notice that damage counter. This isn't the first time bedrock has had this problem so I can't say I was surprised when I saw it. The traders are literally selling damaged goods. Lol.
So we've had this issue occur with a storage system on a 1.16.200 private server. With a mix of chests crossing the chunk boundary variously broken and not broken, handy.
The actual cause of this issue is that the double chests are (somehow) losing their pairing coordinates, TBH I'd be curious if the cause is tangentially linked to the villagers on chunk boundaries dissappearing issue.
Anyway, depending on the chest it looks like they either completely lose the pairing coordinates or they're reset to 0,0. The side that loses their pairing coordinates remains functional as a single chest. The side that references 0,0... crashes the server. For my amusement, I placed a chest at 0,0 at the same Y height and... it still crashed. I'm guessing because that chest didn't have the required backreference pairing coordinates to the other chest.
Once 1.16.201 is live, we'll break and replace the chests and report back on if the issue reoccurs or not.
EDIT: Apparently 1.16.201 has been live since mid-December.... our hoster hasn't released the update for the server yet, yay....
BTW this is what a working double chest looks like, well, half of one.
I am able to replicate this issue in an offline creative world (while wearing elytra) as well as on a private Bedrock server. Issue is pervasive and effects all players on our server. Including when in our tunnels where flying isn't possible.
I'll find/create a bug report for this as well but tangentially we're noticing that when we go through our nether portals it's possible to come out inside the obsidian. Thankfully you usually only take a couple of hits of suffocation damage before the server figures out it screwed up and shifts you over a block but... it happens pretty regularly and might be related.
Edit: Found the related ticket if you're reading this and have this issue go here
MCPE-28765turns out this issue occurs more frequently going from the overworld to nether. There is a workaround in this instance. However for nether to overworld, the issue I'm encountering, no known workaround exists currently.Note that I mention this issue because being able to phase through blocks occurs in conjunction with this issue on our server, some of the time. It's not 100% correlated but it happens often enough to be worth mentioning.
Playing on a dedicated server with Xbox, Switch, and PC players. I am a PC player.
Got a new way to replicate. May or may not be directly related. The end result is the same however. Throw an ender pearl straight up into the air and then jump into the end portal directly. My expectation was one of two, either I would go through and nothing would happen because the ender pearl got reset by the change in dimension. Or... I would respawn and, as I would expect the end to remain loaded for a few seconds after my exit, the ender pearl continues it's trip through the air above the end portal landing on the ground and pulling me back into the end. Seems logical. Instead...
Insta death at my bed where I instantly respawned and got stuck as both dead and alive with no respawn button. My inventory must have dropped on the other side into the end portal however as none of my items appeared on the other side however the XP did drop at the bed and I instantly picked it up, hence why I know I was simultaneously dead and alive because I heard the level up chimes as the XP was collected. Required a relog to respawn. I did spawn at my bed though. Went through the portal into the end again, np, went back to the dragon fountain and jumped in again after unsuccessfully looking for my items, same thing, both dead and alive, had to relog again.
I had the idea of successfully using an ender pearl in the end to see if that would help, it did manage to stop the dead and alive thing, so I now either properly die, or get to half a heart when I go through. Slow falling potions do work though. And there's definitely a difference in stepping off into the portal vs jumping into the portal in the amount of damage taken. Stepping off into the portal sometimes only yields 6 hearts of damage but not 100% of the time. Taking a 3 block leap down into the portal still only took me to half a heart though so it's not like the players velocity is being carried through the portal 1:1. Downloaded our world and there was nothing obviously out of place in my player object when I inspected it in Universal Minecraft Editor.
We've observed this bug on a private server. Thus far it's wiped out 3/4's of a cow farm and lit the interior of someone's house on fire. House wasn't mob proofed until recently so I can't rule out a hostile mob having spawned inside and then having been struck by lightning but so far as we know the fire just spontaneously started from a lightning strike.
I've confirmed that channeling tridents can't summon lightning on to lightning rods below slabs although I haven't messed around with more than 1 air block above the lightning rod so ... Incomplete testing.
Either way for now it's a good thing we have lightning rods. Time to deploy a lot of them. Especially around our trading halls.
Fix dropped in 1.17.30 today. Hype.
Just added another clip. Establishing that this bug also happens when going in and out of the nether.
If we can't discuss theories and speculation in the structure of a bug tracker, how are we supposed to coordinate and validate our testing? The average Discord or Reddit thread is so chaotic this sort of targeted and topical discussion is basically impossible. This is the only forum for solid structured discourse regarding specific issues. On Discord and Reddit we're shouting into the wind and hoping to find each other, here, we're already here. Unless you'd rather these threads become filled with links to discussion threads off platform?
[MCPE Mod] Auldrick
Sorry, but them's the rules. Of course, that's not a satisfying answer and you're being quite reasonable while asking for a justification, so let me try to do so this once.
The problem is that the devs' only source of information about the bug comes from these reports. That means they have to read them top to bottom, including comments because as often as not those have the best clues. As moderators, we need to ensure that the devs can do this as efficiently as possible, From past experience, we know that a leniently moderated report will become dominated by distracting, useless comments: "me too" comments, complaints about how long it's taking, questions that we can't answer, attempts to report similar or related problems that need to be in a report of their own, and suggestions and analysis from nontechnical people that, while well-meaning, are based on false beliefs. And those are just the general categories of useless comments, from the devs' viewpoint. Some widespread bugs have garnered hundreds of such comments. When a ticket becomes so overloaded with drivel, the devs simply can't waste the time it takes to trudge through it looking for clues. Our job as moderators is to prevent that, but we are even fewer than the devs and we're volunteers who don't really want to spend all our free time here. And while many of us are technical, some even former devs, we don't know the game's internals and often aren't qualified to pick out what's useful to the devs, so we have to leave questionable stuff alone. So it's important that on a ticket with many comments – that is, one that affects many people severely – we keep those comments focused and informative to the devs.
We often say this as "this is not a discussion site". Although it looks somewhat like one and was meant by the Jira authors to function as one, they anticipated an audience of developers, not nontechnical people who are ignorant of the development process and who therefore have no basis on which to judge what is relevant here. The Jira software is not ideal for the use Mojang has put it to, it was just the closest they could find at the time, and now they're pretty much committed to it. So it falls to us moderators to keep it adapted to the use Mojang has put it to, and keeping comments focused is how we do that.
On topic:
The issue at hand looks to be mathematical. For some reason tridents that aren't at whole number coordinates are being unloaded incorrectly, that is, not at all. Tridents that are located by pistons against the north or west edges of a block, can be inferred, and if my favorite Bedrock map editor was working currently, confirmed, to be exactly located at x.0000 coordinates. However, when thrown on to a block or otherwise piston located against the south or east edges of blocks, they will have full decimal coordinates. In the case of the south and east edges something like x.999999.
@Hannah out of curiosity. Did you login to your world at your village/trading hall or somewhere else?
There's a possibly related bug where persistent entities (like tamed passive mobs, villagers, etc.) remain loaded for way longer than they should if they're in the chunks around where a player logs in. And by way longer I mean they stay loaded the entire session even if the player is a thousand plus blocks away. You can imagine this get's way worse on servers.
But I'm curious if it's contributing to the issues we're seeing with villagers in this bug, as being out of the player's immediate vicinity would disable their pathing and ability to move but... they'd still be hunting and trying to get to workstations that would be removed/unloaded by the chunks around them.
Affects 1.19.2
We've discovered that creeper explosions are much more dangerous all of a sudden. And if explosion damage at feet level is more lethal then that explains this as creeper explosions start from their feet(ish).
Effects 1.19.73