Draco894

Affects versions 1.20.31.1; 1.20.40.22

" Reed Cartwright added a comment - 20/Apr/22 7:00 PM - edited

I figured out what changed in 1.18.30 that broke creeper farms.

Code Analysis

When spiders (and most mobs) spawn, the game will cancel the spawning attempt if the mob collides with any block that has an AABB (axis-aligned bounding box). The function used for this is the virtual function BlockLegacy::getAABB() or its overrides. A refactoring occurred between 1.17 and 1.18 that added a boolean parameter to this function. I'll call it param_5. When param_5 is set to false, many blocks return an empty AABB. This is likely used to distinguish different types of AABBs, such as collision boxes or hit boxes. Notably param_5 is set to false when the game checks if a mob collides with any block.

In 1.18.30, ButtonBlock::getAABB() has been added to the game. (Buttons used BlockLegacy::getAABB() in earlier versions.) The dev who wrote this function included logic that returns an empty AABB if param_5 is false. This returns an empty bounding box during mob spawning, causing buttons to stop blocking spider spawns. This isn't a minor inconvenience. Even a small creeper farm can have thousands of buttons that would need to be replaced by an alternative block (if one even exists).

The Fix

Remove the logic in ButtonBlock::getAABB() that returns an empty bounding box if param_5 is false. ButtonBlock::getAABB() should always return an accurate bounding box regardless of the value of param_5. Given how quickly changes to pathfinding on coral fans was fixed, I hope that this bug can be quickly fixed as well."

I have a feeling this might be the fix/what broke it this time again.

@GoldenHelmet Moss carpet in Bedrock are treated like wool carpet, can confirm from my SMP base on the previous season that ended 9/1/23.

As for the spiders spawning where they shouldn't because something broke with buttons I present the following screenshots. Ghost overlay is courtesy of MaddHatter and Bud's Technical Resource pack.

My point being Pico, what has been reported here is not a bug. These mobs are intended to be minecartable as I previously indicated. As I also stated these same mobs, save for Iron Golems and only Horses (Donkeys and Mules ride carts), work on Java. There are other bugs, eg random fatal damage while flying, that the devs could be focusing on rather than this frivolous ticket.

So in all actuality for parity sake Java needs horses and Iron Golems added to the cartable mobs, instead of taking this away from Bedrock. Just my honest thoughts.

Yes Pico that would be a Java bug report (MC = Java; MCPE = Bedrock). As I said, if the Dev team so chooses to update horses and other equestrian mobs to not ride minecarts or boats, I am all for parity. However the spirit of this bug report is disparity. By that I mean most of the mobs listed are able to ride a minecart in Java, see uploaded photos.

This seems to fall into the same category as MCPE-161197

If we are going for Vanilla parity then we should only look at Horses, MC-96212 , otherwise leave it as "Working as Intended" since there are ways to break boats and minecarts without player direct action (eg minecart ran into a cactus, activator rails). We use mobs in minecarts/boats as Mob Switches (permanent mobs that block others from spawning), Ghast Block Blast Chambers (especially given that TNT duping does not exist on Bedrock like Java), and general transportation (eg in game Zoos). @Picomos plays @EVGENSYPERPRO

@Mega_Spud can you help clarify this ticket

In testing with 1.18.2 Java, 1.17.41 Bedrock, and 1.18.12 Bedrock hunger does match Java. However players are noticing the difference with when hunger starts depleting, as opposed to how long it takes to go from full hunger and 0 saturation to starvation.

1. Created brand new world (survival Hard difficulty)
2. Focused on running and jumping on spawn island while collecting food
3. Chopped down 1 tree for wood (4 wood blocks)
4. As hunger bar depleted, noticed that walking did not take away hunger haunches
5. After hunger hit 3 haunches left resorted to jumping as much as possible to deplete hunger
6. Hunger depleted to 1 haunch remaining after 10 minutes of gameplay

Attachments: Screenshots of morning and evening, mcworld file

From what the community has documented on the Wiki (https://minecraft.fandom.com/wiki/Hunger) and looking into the file. I think the problem is with the "minecraft:player.exhaustion" values lines 97-99.

In past iterations this was the entry:

"minecraft:player.saturation": {
"value": 20
},
"minecraft:player.exhaustion": {
"value": 0,
"max": 4
},

This is the current:

"minecraft:exhaustion_values": {
"heal": 6,
"jump": 0.05,
"sprint_jump": 0.2,
"mine": 0.005,
"attack": 0.1,
"damage": 0.1,
"walk": 0.0,
"sprint": 0.01,
"swim": 0.01
},
"minecraft:player.saturation": {
"value": 5,
"max": 20
},
"minecraft:player.exhaustion": {
"value": 0,
"max": 20
},

It appears to be a copy paste from the Java file, given the value of 5 for Saturation. A fix could be to revert the saturation section, lines 93-95, to match the past. Then correcting the exhaustion value to be "max": 4 instead of 20 on line 99. Is just what I am seeing and surmising based on how the saturation depletes so quickly.

Thank you Dhakos, I will give it a look over while doing some AFK. shouldn't be to hard to find what the intended result was and what broke it.

I can confirm. In latest releases when Bedrock hunger was made to "match" Java's, hunger saturation and depletion appear to be double rate. Eating golden carrots I have burned through a number of stacks, where previously cooked chicken sufficed. No difference to play style. If someone knows which json files were updated could you please let me know and I will do some code comparison to pre-1.18.30

This might be related or a separate issue. Skulk can generate hanging unattached and grow on all sides of sensor when spreading.

This ticket needs to be reopened under a similar issue to glow lichen in strongholds. Seed: 6160187550968571116 Precise coordinates: 325 -30 928

Addendum: This is in the 1.19.024 Beta.

Tested in Beta 1.18.10.26 once water is removed spawner functions as intended.

Potentially related to MCPE-142285

Nhi Vo I completed a similar process as GoldenHelmet did. Any fish that are found in deep biomes spawn at a nearby valid space Y=>50. I never noticed spawning according to the second condition GoldenHelmet describes.

In my digging in the .json files for spawn rules the only variation between cod, salmon, and squid is nested in the Vanilla, 1.18.0, and 1.15 folders was the height filter on cod and salmon in 1.18.0.

Package paths:
WindowsApp folder \data\behavior_packs\vanilla\spawn_rules

WindowsApp folder \data\behavior_packs\vanilla_1.15\spawn_rules

WindowsApp folder \data\behavior_packs\vanilla_1.18.0\spawn_rules

 cod.json example:
Vanilla

{
  "format_version": "1.8.0",
  "minecraft:spawn_rules": {
    "description": {
      "identifier": "minecraft:cod",
      "population_control": "water_animal"
    },
    "conditions": [
      {
        "minecraft:spawns_on_surface": {},
        "minecraft:spawns_underwater": {},

        "minecraft:distance_filter": {
          "min": 12,
          "max": 32
        },
        "minecraft:weight": {
          "default": 75
        },
        "minecraft:density_limit": {
          "surface":20
        },
        "minecraft:herd": {
          "min_size":4,
          "max_size":7
        },

        "minecraft:biome_filter": [
          {"test": "has_biome_tag", "operator":"==", "value": "ocean"},
          {"test": "has_biome_tag", "operator":"!=", "value": "warm"}
        ]
      }
    ]
  }
}

1.18

{
  "format_version": "1.8.0",
  "minecraft:spawn_rules": {
    "description": {
      "identifier": "minecraft:cod",
      "population_control": "water_animal"
    },
    "conditions": [
      {
        "minecraft:spawns_on_surface": {},
        "minecraft:spawns_underwater": {},

        "minecraft:distance_filter": {
          "min": 12,
          "max": 32
        },
        "minecraft:weight": {
          "default": 75
        },
        "minecraft:density_limit": {
          "surface":20
        },
        "minecraft:height_filter": {
          "min": 50,
          "max": 64
        },
        "minecraft:herd": {
          "min_size":4,
          "max_size":7
        },

        "minecraft:biome_filter": [
          \{"test": "has_biome_tag", "operator":"==", "value": "ocean"},
          \{"test": "has_biome_tag", "operator":"!=", "value": "warm"}
        ]
      }
    ]
  }
}

This is a difficult one as water caves can come above Y = 50. Perhaps updating the spawn rule to match Drowned minus light level. The only bug in copying over code I can foresee is where Drowned can spawn within cave systems, where we don't want salmon and cod spawning.

Second thought is matching them to vanilla squid spawn rules with a biome discriminator for the correct biomes, as squid spawn in warm oceans if I am not mistaken.

Agreed all keybinds should be able to be custom mapped. However is it not possible to rebind the movement keys?