![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png)
[Mojang] Cory Scheviak
- cojomax99
- cojomax99
- Europe/Stockholm
- Yes
- No
MC-73![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
![[Helper] Misode](../../../data/avatars/users/93314.png){kind=small}
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak
[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
[Mojang] Georgii Gavrichev[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak![[Mojang] Agnes Larsson](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Agnes Larsson[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak[Mojang] Cory Scheviak
It still happens to me [Mojang] Cory Scheviak
Jessica Washer While not actually a change "a day" before the release, I agree: no time to evaluate. [~FVbico ] :Yes logically correct. [Mojang] Cory Scheviak IMO, All living entities should move along in water streams as in previous versions. Otherwise this breaks many in place precedence mechanics. So many 1.12.2 worlds I've attempted to update are broken in one way or another, this being one more last minute break. I seriously question why.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
I reset the report to how it was before it was resolved by [Mojang] Cory Scheviak. Please don't change what the report is about. This ticket was exclusively for burning mobs not being put out by snow, and that's what was resolved as WAI.
[Mojang] Cory Scheviak >>> MC-135049
Thanks for looking into this 
Fixed on my side too in 18w31a. Thanks [Mojang] Cory Scheviak!
[Mojang] Cory Scheviak I created a buffet world with the world generator : "surface" and with the snowny tundra biome with this seed
-2744617464920158396
and the coordinates are
/tp @s 336.50 72.00 112.50 -180.00 15.15
There are 6 villagers in this village. In the same coordinates I gave myself the Bad Omen effect
/effect give @s minecraft:bad_omen
I takes 1min and 30s because of MC-138114 and MC-138550 for the first raid. the raid starts for 16 seconds and then the raid bar disappear after being filled.
Uploaded crashed MC-140944.rar
.
@[Mojang] Cory Scheviak , actually the crash occurred in the second wave of the raid is loading.
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
See [Mojang] Cory Scheviak's comment on MC-137470:
As stated by someone else in the comments above, they are not actually targeting you, they simply are looking at you like most mobs do. Pillagers just like holding their weapons out
Working as intended as per MC-139836:
Vindicators are able to break down doors on Hard difficulty, much like zombies can only break down doors on Hard difficulty. The other mobs are intentionally not able to break down the doors. The Vindicator AI may be a bit derpy, but they do choose sometimes to chop down doors
Pillager patrol spawning has nothing to do with villages, player-created or not. They spawn randomly in the world, and if you haven't seen any, it's just because you've been (un)lucky
![[Mod] Sonicwave](../../../data/avatars/users/94627.png){kind=small}
The wiki may not always be correct since Mojang doesn't check it for accuracy; on MC-143959 [Mojang] Cory Scheviak stated that "Pillager patrol spawning has nothing to do with villages, player-created or not. They spawn randomly in the world, and if you haven't seen any, it's just because you've been (un)lucky".
[Mojang] Cory Scheviak Then WAI is not the right resolution, it should be re-resolved as "postponed".
No, since [Mojang] Cory Scheviak confirmed that this is supposed to happen and is therefore not a bug.
If they're attacking you while you're in creative mode, please check MC-146524.
As per [Mojang] Cory Scheviak's comment in MC-159350:
One note - AI stops functioning below y=0 and acts weird above y = 255.
![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
[Mojang] Cory Scheviak I can still reproduce with 1.16-pre2.
- Create world in 1.15.2 and execute: /advancement grant @s only recipes/misc/composter
- Upgrade to pre-release and run /advancement revoke @s only minecraft:recipes/decorations/composter
Couldn't revoke advancement [...] as they don't have it
Please note that this might be Won't fix, because it only removes the advancement triggering the recipe unlock, the recipe itself persists.
From the log:
Ignored advancement 'minecraft:recipes/misc/composter' in progress file G:\Minecraft\Snapshot\saves\Data Fixer Composter\advancements\f5e14d7c-b630-40f7-8582-4e0e2bd87435.json - it doesn't exist anymore?
![[Helper] pine1needle](../../../data/avatars/users/41329.png){kind=small}
This comment by [Mojang] Cory Scheviak implies to me that the two structures having the same salt is intended, but I don't know for sure.
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
Can confirm in 20w51a, however, the comment by [Mojang] Cory Scheviak in MC-159350, states that this feature "Works As Intended".
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
[Mojang] Cory Scheviak, try it with /execute in minecraft:overworld run tp @s -121.19 24.53 194.42 295.17 -56.69
Hi [Mojang] Cory Scheviak, I'm able to reproduce this issue in 21w20a using the following setup. Simply summon an axolotl on the diamond block and you should be able to reproduce this. I've also attached an updated video that demonstrates this behavior in 21w20a. If you still can't seem to reproduce this, I'm willing to attach a world file. 
This is working as intended as stated in this comment by [Mojang] Cory Scheviak.
Valid for replaceable blocks like snow layers and crimson/warped roots and nether sprouts, but not applicable to non-replaceables like flowers, fungus, and lily pads.
The vindicator (not raider) cannot break doors like zombies.
According to the bug MC-139836, [Mojang] Cory Scheviak said: "Vindicators are able to break down doors on Hard difficulty, much like zombies can only break down doors on Hard difficulty. The other mobs are intentionally not able to break down the doors. The Vindicator AI may be a bit derpy, but they do choose sometimes to chop down doors "
However, vindicator cannot chop down doors in game within all difficulty. Only raider vindicator can do that but they already know how to open doors during raids.
1. Build two houses with villagers in it. Make sure that the mobs outside of houses can see the villagers..
2. Summon zombie and vindicator outside the houses on normal or hard difficulty.
3. Zombie can break the doors, But vindicator cannot.
Note: Raider vindicator do break doors during raids but also "open doors" at the same time.
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
From this comment by [Mojang] Cory Scheviak (unless this behavior has changed since) pillager patrols seem to not take into account villages (and by proxy, on-going raids in villages) when choosing where to spawn.
> "Pillager patrol spawning has nothing to do with villages, player-created or not. They spawn randomly in the world, and if you haven't seen any, it's just because you've been (un)lucky"
Snow currently does not put out fire on blocks, so it should not put out fire on entities either.
Turtles are working as intended, but fixed issue with dolphins so they will no longer sit in boats.
Whoops, marked the fix version incorrectly, thanks!
It works as intended because Drowned, while happy underwater, are classified as undead mobs rather than water mobs and therefore aren't affected by the impaling enchantment.
I have been unable to reproduce a crash despite testing the seeds given here as well as many others. One thing to note is that a Cartographer will not trade you an explorer map if there are no structures nearby, or if you have already loaded the chunks of a nearby structure then it will not give you a map to that either.
The only sinking I see is for the boat to properly sink into the water so it can actually work. Other than that, I cannot reproduce an actual issue, since the boat is always usable.
It would greatly help testing to have access to a map with a spawner built that has these issues
The only time I can get boats to actually sink is when I am underwater and place a boat also underwater, which is weird. But that's not the same issue you are having, and I cannot get a boat to sink from dry land.
Thanks for the info
The fix allows for a new section called "nbt" in the "item" block of the json. This way you can provide any nbt you want for the items to be rendered as you like, and they should be rendered as they would be in your inventory!
I can't repro on pre7 - is this still happening for anybody else?
As requested by OP, I solved the issue using a LinkedHashMultiSet. This provides a consistent ordering across game restarts based on the iteration order.
If you're still encountering this issue I will need your save file, as I am unable to otherwise reproduce.
I can confirm that slowing down in lesser water levels is intended.
Can you upload your entire world save file? Thanks!
Double checked phantoms - they spawn in the world regardless of if it's a new or old chunk. You just need to stay awake for long enough.
This seems like an odd use of a very arbitrary piece of code, the order of doors is not considered in any place in our codebase. Do you have a map download / video of what is the intended behavior and why things need to be rebuilt? Thanks!
Indeed works as intended to be consistent with coral blocks. Coral is more stone-like than plant-like once hardened.
Found the issue still existed with maps that were on item frames, but fixed for those that were held in hand. Fixing both cases now
Also, think I tracked down the saving issue as well, so if you want to create an issue for that one I can get it fixed!
This bug was a side-effect of a different bug that I already fixed (
MC-133294) so I am going to mark this one as fixed as well.Maps in item frames are now properly refreshed and persistent.
Golems now check for a solid block below them and air block at head level and above
With cactus as our precedent, this behavior is working as intended!
Working as intended - if you look at the player from third person, you'll see they're using both hands to hold the crossbow when it's charged.
Sorry about that, reopened without marking as unfixed. Decided internally that more thinking is required for this one
Vindicators are able to break down doors on Hard difficulty, much like zombies can only break down doors on Hard difficulty. The other mobs are intentionally not able to break down the doors. The Vindicator AI may be a bit derpy, but they do choose sometimes to chop down doors
There's nothing in code specifically about snow - I need more information. How many villagers are there? How long after starting the world did you trigger the raid? Where were you standing?
There are now captains that spawn randomly in outposts, but not every pillager spawned at an outpost will be a captain.
I cannot duplicate based on this comment, either the seed or the coordinates are incorrect.
EDIT: Nevermind, you meant snowy tundra not taiga
I'd like to fix this bug but I need better reproduction steps, because I can't get it to happen on my end with your seed and coordinates. I tried summoning a witch and a pillager while the raid was loading, but didn't crash. Sending the world save would help!
Hehe, this one disguised itself as a bug that hadn't been fixed yet, but in fact is one I've already fixed and will be in the next snapshot!
They can hold any item in their mouths - but they never eat non-food items, and eventually spit them out once they come across a food item.
Pillager patrol spawning has nothing to do with villages, player-created or not. They spawn randomly in the world, and if you haven't seen any, it's just because you've been (un)lucky
As Mac Rat said, this is how targeting in MC works. WAI
Not really an issue as it is how all 'avoidance' currently works in the game. Noted as a potential polish for the future!
As stated, witches aren't hostile towards villagers, so they have no reason to run from them. They will be hiding inside during raids anyway when functioning correctly.
This is how every "cross texture" block works, like all other flowers for example.
As stated by someone else in the comments above, they are not actually targeting you, they simply are looking at you like most mobs do. Pillagers just like holding their weapons out
Anybody still experiencing this bug?
Yes, I think it is a lag-related issue, not a crossbow-specific issue. Closing it until proven otherwise
Cannot confirm, tested in both that snapshot and latest.
Can't reproduce - can you check your hard drive usage when you play the sound?
Is this still happening in 19w09a?
This is fixed for me, can you please double check?
Have you tried removing the corner by your house? They sometimes get stuck on corners due to a pathfinding issue right now (as of 19w14a).
I've tested in 1.12 vs the latest snapshot, and I don't see any difference. Evokers stop to cast a spell, then very quickly run away. Nothing has changed in that regard as far as I can tell.
Foxes have a longer range they are aware of things around them than other animals, so this range is still acceptable.
This is partially working as intended, since foxes faceplant in snow. That being said, the fact the fox is rotated the wrong direction in your picture is a bug, and I will fix that!
Evokers move quickly by default. I'm marking as Cannot Reproduce until I see video evidence of an Evoker moving quicker than they did in previous versions.
This is the intended behavior of patrols - they watch the player at a distance and then attack if the player gets too close, otherwise they are not aggro'd.
Have not yet been able to repro this case myself. You can no longer duplicate ominous banners through crafting, so that's one less case where this would happen.
They're probably stuck somewhere, try ringing a bell in different spots around the village and looking around - it will highlight the mobs and spawn particles pointing in the direction of the mobs when it locates them.
A map to test on or a repro case would be helpful. I cannot reproduce this on a map created before 1.14 that is updated to 1.14 nor on a new 1.14-created map.
There is a difference between memory leaks and objects that simply haven't been garbage collected yet, and if you load too much into memory given the memory limit, it could cause problems that seem like a memory leak but actually are not. So that's a bit tricky to say for sure.
This is more of a feature request than a bug. For now, raiders automatically join raids if they are in the area and that functionality is WAI.
As you all have noticed, we did in fact change how enchanting works in 1.14. The reason behind this change was to peak the probability of getting the rare high level enchantments at level 30 rather than level ~26 as it has been previously. While this change was meant to fix this issue, it has illuminated a completely different issue in the enchanting system that you all have taken notice to. We are not completely happy with the enchantment system as it is, and will be making adjustments to it, but these changes will not make it into any dot release of 1.14. So, for now, this bug will be marked as WAI.
I see the issue here. Our recipe loader checks to make sure a recipe is valid before trying to load it, but all capital letters are forbidden now. One of the datapacks you used had four items with capital letters: Diamond_horse_armor, Golden_horse_armor, Iron_horse_armor, and Jungle_log. When I edited the levels.dat to use lowercase letters for these instead of uppercase, I was able to load the world. I'll attach the level.dat file to this message. level.dat
Can anybody on this report please attach the launcher logs leading up to this crash? Not the crash report, the logs. It would be very beneficial to see this.
Can you give more specific instructions on how to reproduce?
What is your server.properties set to when you run the server before and after? What are you doing in game to change the difficulty and what are you setting it to? What are you expecting to happen? What is actually happening? I cannot find any difference between what's happening in 1.14 and what happened in 1.13.2.
Do you have any more specific reproduction steps? I have not been able to reproduce this myself after starting raids constantly or standing around an outpost for 15 minutes in a row.
Happy birthday, Minecraft!
Can you please upload the map where this is occurring? I am unable to reproduce on my own.
Hey everyone!
Sorry for the lack of description about this one in the blog post. As stated by Tim, these are two different things. The functionality spoken about in the blog post is actually now obsolete, as the raid center is no longer connected to the location of the bell when you enter a village. At the time, however, we had increased this search to 64 blocks from the raid trigger location to search for a bell, and that's what the blog post was speaking of.
The bell-glow-search-radius is currently 48, and that is working as intended. Though this value is subject to change in the future, these are two separate things, so this is currently WAI
This is working as intended - any illager within range will join a nearby raid. As stated by Violine, the issue with Outposts spawning inside villages should be fixed, and this should never be an issue unless you actually build your village near an Outpost.
This is not a bug, so I am marking it as invalid. It is a valid feature request, however, and one I will take into consideration. Keep an eye out
As a player-triggered event, raids should not be subject to the same light level restrictions that patrols are.
This is working as intended, because the bell just checks if there are raiders nearby. It doesn't check if the raid is still ongoing. This allows the bell to also be used outside of a village to find nearby raiders
Both of these cases are working as intended, as both pick a random location and attempt to go there.
Patrols have no association with villages. In fact, they can't spawn if there is a village, so destroying a village actually makes it so they can spawn
It seems likely from the video that your raid timed out, since it stops on its own after a few days to prevent it from going on forever if the player can't find all the raiders.
WAI, though the saturation is being reconsidered due to this aspect.
While this is most likely a valid bug (still have to repro for myself), no mobs use AI below y=0. Do not use a void world as a testing ground because this is an invalid test case.
I still cannot reproduce given the steps provided - a world save would be extremely helpful in bringing me closer to solving this. One note - AI stops functioning below y=0 and acts weird above y = 255. I see one example posted is between those values, but most of the examples given are about bees going above or below the world height limits, which is not really a valid use case / test case.
Hi, is this still an issue after the latest snapshot! If so, can you please upload your world save so I can test it out for myself and see what's going on? Thanks!
Is this still an issue in 19w42a?
Thanks for the info and world save, that really helped in tracking this down!
Thanks for your uploads! You can now delete your test world download if you don't want anybody stealing credit
Is this still an issue in 1.14.4?
Still present in 44a?
WAI for now. If it's improved in the future it'll be a feature, not a bug fix.
I cannot reproduce this - it does take a while to reach the proper gossip level, but once there it has attacked me every time.
We do like the idea, but at the moment this is a feature request, not a bug.
Bees outside of a nest or hive only become upset at honey being harvested if there is a bee inside the hive. The bee inside the hive is the reason the bees outside the hive get angry. If there is no bee inside the hive, bees outside will not get angry.
I've tried for an hour but can't get a reliable repro case for this. If someone can post repro steps or a map with a repro case that would be extremely helpful.
Closing until I get repro steps / proof that this bug is still happening in 1.14.4+
Created a new Giant Tree Taiga buffet world and within seconds found a berry bush - can't reproduce.
Tried an Amplified world on seed -1881547168
Found a bee nest at ( -161, 89, -5 )
I tested on three iterations of the same Buffet world and found berry bushes each time. 1.15-pre2
It appears I forgot to add this addition to the changelog that all taiga biomes should have both foxes and berry bushes now - including Giant Tree Taiga variants!
Try seed: 4462037519884683501 and let me know.
There is nothing in the code constricting crop growth to bees that are near their nest / hive. Is it possible this bee had used up its max number of crops grown (10)?
Bees don't like water
this is intentional
Works as intended, as it is a critical part of the feature
Currently, as with all features that generate in the world, in order to get the new features you must generate terrain that has never been generated in previous versions.
WAI as gilded blackstone is not a gold ore and cannot be smelted into gold ingots.
Gilded Blackstone is only found in Bastion Remnants as part of the structures.
As we added new large structures to the nether in the Nether Update, we had to adjust the spacing and separation for fortresses accordingly to make everything fit without constant overlaps
Is this still occurring in 20w17a?
Java has the correct implementation, we will fix this issue in Bedrock.
Witches aren't illagers - they are just along for the ride!
Some bridges that existed in previous times no longer exist in modern times
Cannot reproduce this in 20w19a. Can anyone else?
Looks like a duplicate of
MC-157303Only campfire/soul campfire achieve this
Is this still an issue? If so, can you post updated seed/coords, since the ones you posted are now outdated due to worldgen/biome changes?
Is anybody still experiencing this?
Can't reproduce - can you upload your world save file?
I can't repro this - can anybody confirm if they have experienced this in Nether Update snapshots?
Since it is a different type of fire, it should not emit the same orange particles the regular campfire emits.
We do check if a villager can reach the job site before it accepts it as a potential job site, but there are probably some pathfinding quirks that are interfering with it that you're running into. Those are tricky to locate and fix.
The timeout is something we should have anyway and should help some of these issues hopefully, at least the stone blocks issue.
Pelle - Timeout is definitely the "safer" option - there will be more developments in the coming versions for pathfinding but for now, this is the easiest solution and the one that will work the best.
It does check if it is pathable when it chooses to go somewhere but does not check as it paths, as that would be very expensive for each villager to do that.
Right clicking upsets them if you don't use an item they want, so it is intentional that the arm swings, since the action is still taking place
Basically WAI, as any action / interaction should now cause an arm swing.
Now, you can pick up a bucket of water using an empty bucket. One bucket of water will be added to your creative inventory. Only one. If you use your empty bucket on ten, twenty, etc blocks of water, you will only ever get the one bucket of water added to your inventory.
Any action taken by the player that results in something happening should result in an arm swing, as this is an indication to not only the current player, but to other players, that something was done.
I cannot repro this - do you have updated repro steps or are the steps in the description still valid? I tried for a good 10 minutes but could not get this to happen.
I can't reproduce this upgrading either a 1.14 or 1.15 world to latest - I don't get a message and the recipe is already unlocked still.
Really odd - I see why I'd get such a log message because there is in fact no data fixer for this, but...I'm not getting the log message. I do, however, get the "Couldn't revoke advancement" message, though the recipe exists. I am curious why I'm not getting the log message...
Is this still happening in 1.16-pre2? I tested against 20w22a and replicated this, but I cannot repro it in the pres, so I think it may have been fixed incidentally.
Is this still an issue in 1.16-pre3?
I cannot reproduce this during the milking, but I can reproduce it when consuming the stew.
I cannot reproduce this - maybe you could upload the world where this is occurring?
If the bed is > 48 blocks from that Villager, then this is WAI. Villagers can only know about things so far away from them. They go from home to home at night because that is what they deem as the safest thing to do, they are not actually trying to sleep in occupied beds.
This crash has to do with entities changing dimensions. Are you still experiencing this crash or was it a one time thing?
Cannot reproduce in 1.14.4 or 1.16-pre8
It works for me - under what circumstances are you trying to do it?
Cannot reproduce. Sometimes it takes quite a while for a villager to lose their jobsite, but once it is work hours and they cannot reach their jobsite, they eventually lose their profession. Tested both in the overworld and in the nether.
Need a world save or a distance of how far - there is a certain amount of time that if a Villager cannot reach its jobsite by that time, it will give up the job site. That is likely what is happening.
I have done some investigation, and this looks like your world save has been corrupted a bit, unfortunately. Potentially due to this bug: MC-161823
The actual workstation the villager thinks is there is one block next to the bed, away from the tree. I'll see what I can do, but my hands might be tied until we fix the corruption bug on this one, unfortunately. If you want a quick fix for your villager, just place a bed to the left and one block closer to where the villager is and that should fix it for that villager
This is the intended order of world gen operations. The geode generated before the mineshaft, which then tore through it. The reason there is so much open air there is because of the mineshaft room that is generated there.
Does anybody have a seed where this issue is still occurring?
Pigs panic run, follow carrot, and random pathfind over Big Dripleaf blocks as expected (normally) for me. Unless you can show a video of what you mean that goes contrary to what I am seeing, I'm marking this as CR.
Resolving as duplicate of
MC-208691since the real issue is that axolotls take damage from non-entity sources.I just tried on 21w18a with the seed and coordinates you sent, Avoma , and I see the clusters/buds generating properly within the geode.
One extra note - you cannot be within a few chunks of a village for a patrol to spawn. I tested in a superflat world and saw a patrol spawn given I was far enough away from the village. Can someone confirm this bug still exists when standing far enough away from a village?
Okay - I see what you are referring to now. This is a "feature overlapping feature" bug, where a geode will generate, then another feature (a geode, a monument, etc) generates over it because it comes later. It's not as much an amethyst crystal generating on a non-budding amethyst block as much as it is another feature coming in later and replacing the budding amethyst block, which is unfortunately a complex issue
Thanks for all the feedback!
Bad Omen goes away when the raid begins - it gets converted into the strength of the raid. Neither of these examples unfortunately prove the issue. Unless there is a video of a raid beginning and not having had Bad Omen before it starts, I still don't have proof this bug exists. Both of the examples given include having previously had Bad Omen. It lasts a very long time, so it is still possible you had it and forgot about it. If there is an issue I want to fix it, but hard to do so without a way to see it happen
Is this still an issue?
Is this still an issue?
I see someone reporting this as an issue for 21w20a but I have tested myself and it appears fixed. Can anybody give me a seed / coords where this issue still occurs?
The issue of bamboo actually staying placed in world after worldgen is complete is fixed by the fixes in 21w20a.
This is likely because the blocks are destroyed on tick and you are using `randomTickSpeed` 0
Recreated the situation in the video, cannot reproduce. Does anybody have a world save where this occurs reliably?
Your screenshot is of a completely unrelated section of stronghold. Unfortunately, the overlap between features is a separate much more difficult issue to solve. Geodes generating no longer remove end portal frame blocks, and that is the best we can do for now. If you find an end portal that has a block destroyed by a geode overlapping it, then this bug can be reopened. Until then, the overlap is a separate issue, as the portal is not at risk.
Valid for replaceable blocks like snow layers and crimson/warped roots and nether sprouts, but not applicable to non-replaceables like flowers, fungus, and lily pads.
This has more to do with how the roots detect a proper 'stopping' place. The mud itself is not detected as a 'stopping' place because, as Sniper1.1 says, it can be replaced with muddy roots instead. There also needs to be room for the roots to grow properly out in horizontal directions, which sometimes fails on platforms or ledges, like this. I don't think this is a bug, but rather just very picky tree gen.
Can you provide more information? What level of Wind Burst is the mace in the gif enchanted with?
Now that editing signs functionality has been added, an arm swing makes sense. Closing this as WAI.
Spawn eggs are intended to spawn adult mobs as per the resolution of
MC-135098