Azarel Howard

Effects 1.19.73

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).

Affects 1.19.2

@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.

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?

Reply from

@unknown
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.

Just added another clip. Establishing that this bug also happens when going in and out of the nether.

Fix dropped in 1.17.30 today. Hype.

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.

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.

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-28765 turns 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.

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.

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.

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-14420 dropper and dispenser sound is not directional (added to development teams bug tracker in 2016) and

• MCPE-48919 Blocks 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.

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.

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.

@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.

Confirmed Affects 1.16.0.55 Beta on Windows 10 PC

Issue is also confirmed to exist for TNT minecarts. Naturally.

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.