Wormbo
- Wormbo
- wormbo
- Europe/Berlin
- Yes
- No
MC-138939![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
Saplings are known to not care about log blocks when determining whether they can grow at all, and also grow right though them.
There is one exception, though: A log block directly above the sapling will prevent it from growing via random ticks. If there is an air block between the log and the sapling, it will grow just fine, though.Steps to repeat:
- Place a sapling on any block it usually grows on.
- Place a Log directly on top of the sapling.
- Wait. /gamerule randomTickSpeed 1000 w
on't help, as the sapling never grows, unless bone meal is applied.- Place another log on top of the first log and remove log right above the sapling. The sapling will grow into a tree eventually.
Expected behavior:
Since logs don't usually block growth, there should not be a difference between having a log right on top of the sapling or one block higher.Code analysis:
SaplingBlock.randomTick() performs a light level check in addition to having a built-in random success chance. That light level check is not performed in the sapling block itself, but in the block above. Since logs are full opaque blocks, the light level will always be zero in this specific case, preventing the sapling from growing.Saplings are known to not care about log blocks when determining whether they can grow at all, and also grow right though them.
There is one exception, though: A log block directly above the sapling will prevent it from growing via random ticks. If there is an air block between the log and the sapling, it will grow just fine, though.Steps to repeat:
- Place a sapling on any block it usually grows on.
- Place a Log directly on top of the sapling.
- Wait. /gamerule randomTickSpeed 1000 won't help, as the sapling never grows, unless bone meal is applied. (Notably, the sapling's age stays at 0, indicating it never even attempts to grow in the first place, rather than failing growth attempts. Compare this to MC-228758, where the diagonal block allows growth attempts to happen, but makes those fail.)
- Place another log on top of the first log and remove log right above the sapling. The sapling will grow into a tree eventually.
Expected behavior:
Since logs don't usually block growth, there should not be a difference between having a log right on top of the sapling or one block higher.Code analysis:
SaplingBlock.randomTick() performs a light level check in addition to having a built-in random success chance. That light level check is not performed in the sapling block itself, but in the block above. Since logs are full opaque blocks, the light level will always be zero in this specific case, preventing the sapling from growing.
Pufferfish, which are highly poisonous when eaten by the player, can be fed to tamed wolves since this snapshot. In real life, the effect of the pufferfish poison ("Tetrodotoxin") is not specific to humans, but is the pufferfish's last-line defense against all kinds of predators that ignore it puffing up into a spiky ball.
Observed Behavior
Pufferfish items can be fed to tamed wolves and will heal them the same way as tropical fish. The tamed wolf does not get affected by any status effects from this. Feeding pufferfish even works for breeding tamed wolves.
Expected Behavior
Pufferfish can either not be fed to tamed wolves or applies its negative effects.
(I guess a third option would be that the pufferfish is spit out again. That's supposedly how predators react to the taste of young pufferfish, who have not developed the size and spines as mechanical defense yet.)
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
I agree with you, Wormbo; this issue is comparing spawning of fish and dolphins (not limited) with that of squid (limited to 46 to sea level i.e. 64). The other is comparing the spawn conditions of drowned (not limited) with that of zombies (must have block beneath) and mentions that other water mobs also don't have the "must have block beneath" restriction; nothing about sea level. (And, I'd personally say that drowned shouldn't be affected by sea level restrictions, so it's almost the opposite of this issue)
I am going to link them as related simply because they're both spawning issues related to water mobs, but I don't think they're the same bug in any way.
I'm sorry, but how is that bug related to this one? It talks about drowned being able to spawn above the sea floor, not about fish spawning above sea level.
But that's not the point. MC-135660 "complains" about Drowned spawning at any height in the water, like fish. It does specifically not complain about fish spawning in water bodies way above sea level (Y>64), though.
Well, TNT dropping moving blocks almost all the time has made it useful in a very "deconstructive" (as opposed to plain destructive) kind-of way, by being able to automate block breaking, if you make a machine that feeds the blocks into a dedicated blast chamber at exactly the right time.
After this fix, TNT's main (non-duping) use will be griefing and making irregular holes in the ground. Can the community request a change to TNT block breaking in general that would increase the drop rates to make blast chambers worthwhile again? Technical Minecraft is a very interesting part of the game after all, but it seems 1.14 is introducing many changes that break previous achievements in that field, most of them seemingly without replacement.
This is actually a problem all mobs with a ranged projectile attack can face. If they hit another mob, a fight between them will start. This can most commonly be observed between skeletons or shulkers, but witches (or blazes, for that matter, if they hit a mob that's not immune to fire) are no exception.
After a piston push, the water block in front of the piston no longer is a source block, but falling water. You would need to build in a way for the water sources to regenerate at the piston level.
I just loaded the same level I used to test this originally in 1.14.4, and still had fish spawn on that platform.
Between then (
MC-107432) and now (in 18w10b, according to the Minecraft Wiki), the way shulker box coloring works has changed, though. Shulker boxes can be dyed from the default to all 16 different colors and the purple color is different from the default undyed color. I'd assume that shulker mob coloring should would the same way, so summoning a shulker without specifying a color should give it the same color as undyed shulker boxes.I can confirm this behavior on Linux Mint 20 Cinnamon, running vanilla Minecraft 1.16.4 or snapshot 20w51a on OpenJDK 11. When you click a chat link to open an external application (i.e. a screenshot in the system's configured image viewer), the game will stall until that application is closed. It feels like only the UI hangs, as afterwards you get a flood of all the sounds you "missed" while looking at the screenshot.
I could imagine it doesn't happen with web links, because browsers tend to launch the actual UI in a separate process and the originally launched process terminates again after successfully handing off the URL to that UI process. Since that sequence of events completes quite fast and the game is in the pause menu, it's hard to tell, but there definitely is a short hitch in game animations when I open the feedback or bug report link from the in-game menu while on a server (to prevent the game pausing from opening that menu).
As far as logs are concerned, the game doesn't appear to output anything to the log window while all this is going on. The final output for me is the chat message that the screenshot has been saved from pressing F2. Also no additional logs after the image viewer closed and the game resumes.
These parts are notably identical to the same pixels on the nether ore texture. That's likely not intentional, since there they blend well with the surrounding netherrack texture. (I'm attaching a screenshot comparing the two for completeness' sake.)
As far as I understand, "jockey chickens" should have a flag set that makes them despawn like hostile mobs and should prevent them from laying eggs. Unless something changed in that regard, that flag probably should not reset after the rider died, causing the chicken to continue to not lay eggs and eventually despawn. The suffocated jockey theory can only work if something now causes that flag to reset.
This report was not about the lack of a particular biome, but about generation of mushroom islands in general. I looked for other mushroom islands and honestly, they all look very boring now. With the current world generation, mushroom islands seem to generally be large blobs of mostly flat land at about 10 blocks above sea level that have neither beach-like features whatsoever nor any kind of mountainous terrain. They look so much worse now, essentially being a table mountain in an otherwise uniformly deep ocean. I've attached additional screenshots from three 1.17.1 screenshots (seed "ModSass") and 21w38a (same seed as in the initial report) to illustrate that problem.
Again, I don't care whether "mushroom fields shore" still is a thing or not, this just doesn't match the otherwise very improved terrain diversity of the update.
I can confirm this issue. After every reboot, the launcher is logged out. launcher_profiles.json exists and looks fine, but I noticed the system only asks for the password of the keyring after logging in. I'd expect if it does anything with that operating system feature the launchr should probably check before asking for Minecraft login details.
This is on launcher version 2.2.3963, using Linux Mint 20.2 Cinnamon with kernel 5.4.0-86-generic.
Can confirm for 21w40a.
Example on seed 3616322997210486974:
Can confirm for 21w40a.
Any sufficiently large mushroom island will mostly have a steep shoreline, quickly rising to a plateau around Y=70 that stretches across the entire island without much height difference and only sometimes there are shallow hills. This subjectively is a step back from 1.17.1 mushroom island generation, where (even outside the mushroom fields shore biome) there could be low flat areas and shallow lakes, and even rough mountains with interesting shapes.
Here's an example on seed 3616322997210486974:
Compare this to how mushroom islands used to generate:
The behavior changed with the latest version of the launcher, as now the keyring password query pops up before showing a potential list of accounts. However, when clicking on my account the launcher pops up a red notice in the top right corner telling me that something went wrong, then proceeds to the screen where I need to select whether I want to log in with a Microsoft or Mojang account.
Something in the launcher clearly has an issue with reading the stored credentials after a reboot, and its error handling is to wipe its entire account memory and let me start over by entering the account name itself. I'd expect it'd at least remember that part (which it very clearly still knows about) and pass it to the MS account login procedure.
Launcher version: 2.2.7266, updated Linux kernel version: 5.4.0-90-generic
As far as I can tell this seems to be fixed in 1.18rc3. I assume it was fixed some time during the snapshots when mob spawning was being worked on.
Still happening in 1.18rc3.
1.18 release notes confirm this as an intentional change ("Cod, Salmon, Pufferfish, Tropical Fish, Squid, and Dolphins now only spawn in water from height 50 to height 64"), so it is indeed fixed.
Can confirm this still happens in 1.18.1: Nearby blazes get "group aggro" when one is hit, but if they can't see the player, they will just hover up and down in place without ever attempting to reposition in order to actually being able to attack the player. This is different from any other mob with the "group revenge" behavior, as those will still move around to attack.
Still happens in launcher version 2.2.8540, running Linux kernel 5.4.0-92-generic. Now it at least remembers there have been earlier logins with the account, but it still requires me to go through the entire authentication procedure.
Can confirm the behavior in 1.18.1, but I can't necessarily see a reason to call this a bug: Droppers never drop items into the world under any other circumstance when facing an inventory block, even if they can't deposit an item for whatever reason. For example, you can never push a shulker box into another shulker box this way from any side, and you can't push non-fuel items into furnaces from the bottom or sides, and in neither case does the item end up being dropped into the world instead.
It is generally advisable to not use the same game directory for vastly different versions of the game. Not only does the configuration file format change, but also early versions do not protect your worlds from downgrading, which basically destroys them.
Confirmed to still happen in 1.18.1.
Some additional thoughts on this bug: Fleeing uses pathfinding, and that won't work if the mobs don't have solid full blocks available as potential target locations.
The screenshots by Leo and Alex show a setup where the creepers have nowhere to go beyond the trapdoors, since they can't fit into the 1-high area there or there isn't even a reachable area in the first place. The screenshots by Matthew and Marco shows a similar issue in that there's no solid full block beyond the trapdoor, so while creepers could pathfind towards the trapdoor, they have no incentive to actually go there, since there's no pathfinding target that would make them do so.
From my own tests it looks like creepers flee from cats eventually, and assuming they have somewhere to go, they will also cross trapdoors when doing so. However, it sometimes takes quite a long time until they realize they should flee in the first place, and it seems related to how easily they can find a place to flee to. The same also is true for (wither) skeletons fleeing from dogs. I've seen them sometimes starting to walking to a place beyond the trapdoors instead of running, suggesting they have an easier time to find a random movement goal than to find a place to flee to. (I attached a setup I tested with in 1.18.1.)
Still happens in 1.20.1.
I appear to be getting this on a 1.20.1 server.
Another example not involving commands: Wither roses apply damage every tick (actual damage every 10 ticks, due to damage immunity) instead of the expected 2 seconds interval for Wither effect level 1. (Tested on 1.20.1, but likely didn't change in newer versions.)
Still happening in 1.20.2 and current snapshots.
IMHO it only makes sense to default to upright placement if the box would "attach" to the block below (i.e. that one has a full top surface) and can be opened. Next best thing would be "attaching" to the dispenser, if that orientation allows opening. And since dispensing a shulker box isn't even a very frequent thing, I don't see why there wouldn't be a more thorough attachment check, similar to what the shulker mob does. Upright placement without being able to open the box should only be a fallback option if it can't reasonably be rotated any other way.
Not a duplicate of
MC-266742. That one gives an incorrect description of the issue.Copper bulbs now change state immediately, without any delay. They were more useful when they had 1 game tick of delay before the state change.
All ores (stone, deepslate, and even nether quartz/gold) have a blast resistance value of 3. That seems wildly inconsistent with most stone variants, deepslate, netherrack, and the individual resource blocks, which all have blast resistance of 6, except netherrack at 0.4 and quartz blocks at 0.8. Even cobblestone and cobbled deepslate have blast resistance 6, so you can't really argue that the mix of ore and base material weakens the combination.
This is specifically about a log blocking light and thus preventing random growth. MC-228758 explicitly excludes logs and also covers bonemeal growth, while MC-15224 is specifically about mismatched log types.
The case presented here causes the sapling to never even have failed growth attempts (which would be visible in F3 debug by its age property changing from 0 to 1), but not even attempting to grow in the first place.
Can confirm in 1.21.
Diagonal blocks have been a way to force oak saplings to only grow as "fancy oak", i.e. (usually) large oak trees. I'm reasonably sure this behavior has existed for a long time, and currently a very intentional-looking check in the TreeFeature class. The thing that might not be intentional is that trees that generate with vines or other blocks, that are neither leaves nor logs, don't necessarily ignore those block types.
Looking at IglooPieces.IglooPiece#postProcess in both 1.20.1 and 1.21, the template position handling feels wrong, but I can't say whether it's actually the cause:
this.templatePosition is being saved to a local variable, then adjusted with a vertical offset, then super.postProcess is called, and at the end of the method this.templatePosition is reset to the original value.
As far as I can tell, there only seem to be two other structure piece types (ocean ruin and shipwreck) that modify this.templatePosition within their postProcess method, but they both do that only before the super.postProcess call and without resetting it again afterwards. Maybe that reset causes the structure information to be serialized with the wrong Y value after placing the blocks.
It should probably also be noted that MC-2714 is almost as old as the report about quasi-connectivity behavior for pistons, droppers, and dispensers. The confirmation of the bug status happened over 11 years ago. Consequently, players eventually expected the behavior to stay, regardless of the status of that issue report. This fix didn't seem particularly intentional, considering it was not mentioned anywhere.
Somewhat related, keeping the health during conversion seems like a bad change for lightning-based conversions, since the lightning strike itself usually deals a bunch of damage already, making survival of the converted mob less likely than it already is. The change should probably be restricted to non-damaging conversions like drowning zombies or freezing skeletons.
Pale oaks appear to have inherited this generation behavior.
Has this been addressed? I just noticed a separate bunch of leaves around a pale oak tree's branch opposite to the direction of the main trunk's bend in 1.21.4, which suggests this was fixed.
[edit] Found some time to check the code, and it seems the error in the calculation of branch leaves attachment locations has indeed been fixed. Presumably that happened as part of the fix for
MC-59308?