ncolyer11

Can confirm since 24w33a. Must say it’s odd the tnt does no damage to decorative entities even if it’s just slightly touching the water, and also even less sense that items are included as decorative entities here.

This bug assumes there's enough friction between the player and the inside of the minecart for them and their head to rotate with the cart. The player's FOV doesn't necessarily change when the minecart rotates, this is more in line with a feature request. Not to mention this would break almost every nether wart and chorus plant farm since 1.4.2.

Edit: moved to already pinned comment for clarity

Regarding the pinned comment by @Dylan C. quoting, "I looked in the changelog of all following snapshots and in none of them does it say that fungi no longer grow into a thick variant. So this is a bug", if you go to the first version which they don't grow to 3x3, the changelog has this bug fixed: https://bugs.mojang.com/browse/MC-171048 - this bug clearly states that the 'planted' field of huge fungi wasn't being utilised for differentiating between natural fungi (can grow to 3x3) and planted fungi (can only be 1x1). If you look in the code between these 2 versions, you'll see 20w09a added this line which confirms this change was definitely intentional:

boolean bl = !hugeFungusFeatureConfig.planted && random.nextFloat() < 0.06F;
this.generateStem(structureWorldAccess, random, hugeFungusFeatureConfig, blockPos2, i, bl);
this.generateHat(structureWorldAccess, random, hugeFungusFeatureConfig, blockPos2, i, bl); 

// And what's the last argument in 'generateStem'?
private void generateStem(WorldAccess world, Random random, HugeFungusFeatureConfig config, BlockPos pos, int stemHeight, boolean thickStem) {        
     Mutable mutable = new Mutable();
     BlockState blockState = config.stemState;
     int i = thickStem ? 1 : 0;
// And the same 'thickStem' variable is used during hat generation to make it slightly wider:
private void generateHat(WorldAccess world, Random random, HugeFungusFeatureConfig config, BlockPos pos, int hatHeight, boolean thickStem) {
...

This was most definitely patched intentionally and there's 0 evidence to believe otherwise.

Just checked and this is still in the snapshot 24w09a

This bug is due to the fact that entities have a discrepancy between the original location of the vibration (centred on the bottom of their hitbox) and the floored value that the sculk actually uses for calculations (the centre of the block that the entity is in), unlike blocks which both create a vibration at the centre of the air block they replace, and so flooring that doesn't change anything.

Now within the range of the sculk sensor, the original location position is floored so all vibrations are rounded to the centre of the block they occured in meaning that there is no difference in behaviour between entities and blocks, but if an entity had its original location positioned just outside of the range, e.g. at the bottom of a block 8 blocks away, even though its floored position would've been rounded 'up' into the range of the sculk sensor, this never occurs as the sculk sensor ignores it.

I discuss this in more detail and with diagrams in this updated bug report here: MC-261657

this is almost always because the fringe type has a 1/9 chance of being radius = 1 then radius = 2 so if that happens the vines layers (bottom 3 layers of the hat) are only diagonally connected to the main wart block structure of the tree and hence if any of the wart blocks fail to generate then you will result in a floating viens region.

this is especially prominent in trunk height 4 nether trees that feature the [1,2] fringe type as the top most layer of the vines region itself can be included in the fringe and hence have layer 1 which creates discontinuities in the bottom 2 vines layers as vines check for warts below them b4 generating and if there alr is a wart below the current selected block will have a 100% chance of generating so it going from 2 to 1 essentially resets the chain

is the owner if this report still apparent? I've done a bit of research on huge 3x3 huge fungus generation which i'd like to add 

this report has nothing to do with checking for empty space and it seems you have misinterpreted it

@Dhranios, I saw that report and they may be duplicates yes, but this is to do with how the wart blocks generate in the world without any obstructions.

i.e. irregardless of what blocks may or may not be directly above the fungus before it grows, the huge fungus can generate blocks that are free-floating in the air

can confirm that it was possible in early snapshots (20w08a) and doesn't work in the latest version (1.19 rc2 and also release 1.18.2)

Also it's important to note that:

Regarding the pinned comment by @Dylan C. quoting, "I looked in the changelog of all following snapshots and in none of them does it say that fungi no longer grow into a thick variant. So this is a bug", if you go to the first version which they don't grow to 3x3, the changelog has this bug fixed: https://bugs.mojang.com/browse/MC-171048 - this bug clearly states that the 'planted' field of huge fungi wasn't being utilised for differentiating between natural fungi (can grow to 3x3) and planted fungi (can only be 1x1). If you look in the code between these 2 versions, you'll see 20w09a added this line which confirms this change was definitely intentional:

boolean bl = !hugeFungusFeatureConfig.planted && random.nextFloat() < 0.06F;
this.generateStem(structureWorldAccess, random, hugeFungusFeatureConfig, blockPos2, i, bl);
this.generateHat(structureWorldAccess, random, hugeFungusFeatureConfig, blockPos2, i, bl); 

// And what's the last argument in 'generateStem'?
private void generateStem(WorldAccess world, Random random, HugeFungusFeatureConfig config, BlockPos pos, int stemHeight, boolean thickStem) {        
     Mutable mutable = new Mutable();
     BlockState blockState = config.stemState;
     int i = thickStem ? 1 : 0;
// And the same 'thickStem' variable is used during hat generation to make it slightly wider:
private void generateHat(WorldAccess world, Random random, HugeFungusFeatureConfig config, BlockPos pos, int hatHeight, boolean thickStem) {
...

This was most definitely patched intentionally and there's 0 evidence to believe otherwise.

yea na this would break basically everything

still in 1.19 release-candidate 1

still in 1.19 release-candidate 1

still in 1.19 release-candidate 1

still in 1.19 pre3, also is the report owner still active here?

still in 1.19 pre2

would love to get some clarification or not as to if this is WAI

ah finally found this report, I just wanted to check in and see if the owner of this report is still active as this bug is still in the latest release and snapshot release of the game

hey so I did a bit more analysis on this report and it turns out there was rounding/data type changing happening, but it was in a different place to which i originally thought
i've updated the report with all the new info and the fix should be as simple as keeping the distance value as a double instead of converting it to an integer

I just wanted to clarify that there are considerable implications for this bug depending on how it's fixed.

• If this fix is just adding the invulnerability timer to items boats and minecarts then only items will be affected as boats and minecarts don't utilise the traditional health system. This is mostly a good thing as it means your items won't instantly evaporate when they touch cactus and blast chambers that utilise multiple TNT explosions in quick succession won't be as inefficient. A negative for this type of change would be that box yeeters, a device that uses cacti to quickly break open shulker boxes, will be affected as the shulker boxes will take longer to break and will get stuck in unintended positions. Instead lava could be used but this

• BUT if this fix is one where health is added to carts and boats AND then the invulnerability timer is added then a vast majority of all contraptions that utlise carts and boats will be adversely affected. For example portal loaders will be come laggier as the minecarts will take longer to die and loaders that use boats will become unreliable as the extra time boats take to be destroyed will allow time for entities to ride in them and break the device. Cart yeeters, the new fruitful 1.19 tech, where a minecart is broken instantly to drop its contents and the cart item, will break as the additional time the cart takes to die will mean that the items sprawl out from an unintended position.