Sculk shriekers rarely generate inside ancient cities

In an effort to better understand the issue, I painstakingly marked and counted sculk shriekers in multiple Ancient Cities this weekend. It seems there they are approximately twice as common in Java compared to Bedrock.

Two samples of my data:

Ancient City #1: Java: 50, Bedrock: 28

Ancient City #2: Java: 47, Bedrock: 27

Affects 1.19.0.30/31 beta and preview.

Even though this issue now has a Fix Versions of 1.19.0.34 and 1.19.0.35, I am not seeing any change in the number of shriekers in ancient cities compared to previous betas and previews. So it still appears to be broken. I even tested with both the Wild Update/Vanilla Experiments toggles turned on and off in case setting those experimental settings made a difference.

Still affects 1.19.10.20.

The sculk sensors and shriekers appear to have a chance to generate when sculk patches get applied on top of existing patches during world generation. Because there is also a sculk patch generation bug MCPE-154229, the lack of sculk is partially responsible for the lack of sculk shriekers. But not entirely - even when overloading the sculk patches with a custom Deep Dark biome, an additional change was needed to get the 50-60 sculk shriekers Java Edition commonly generates in Prerelease 3 Ancient Cities. Specifically, there appears to be a world-generation-friendly simulation of the sculk catalyst charges controlled by the "charge_amount", "spread_attempts", "growth_rounds", and "spread_rounds" sculk patch feature properties. Raising "spread_attempts" from 1 to 2 produced the best results in terms of getting Java Edition parity with the least amount of extra CPU usage.

I have attached two files,

and

, which use two different methods to increase sculk and sculk shriekers. (See MCPE-154229 for the details of the pros and cons of each add-on.) The sculk shriekers should increase everywhere, not just in Ancient Cities, when this modification is used. Feel free to try them out and see if they work better for you. The "Custom Biome" experimental feature must be enabled for these to work.

This issue still affects 1.19.10.21. Here are the latest sculk shrieker counts found in Ancient Cities from Java RC2 and Bedrock 1.19.10.21 Preview using two randomly selected worlds with a reasonable number of nearby Ancient Cities to check:

Seed: 5673454449901731471

Java XYZ         Counts       Bedrock XYZ    Counts
120 -40 -232       47         72 -40 -216      15
72 -40 120         69         200 -40 120      16
232 -40 536        64         152 -40 488      19
488 -40 600        43         456 -40 504      20

Seed: 2109102841218426599

Java XYZ         Counts       Bedrock XYZ    Counts
-200 -40 -200      37         -200 -40 -168    15
88 -40 456         57         168 -40 456      20
472 -40 584        47         440 -40 504      20
232 -40 -232       59         120 -40 -216     9
936 -40 8          44         968 -40 168      17
1256 -40 152       49         1192 -40 184     13

Average shriekers present in these cities in both Java worlds: 51.6
Average shriekers present in these cities in both Bedrock worlds: 16.4

Additionally, many of the shriekers found in Bedrock are tallied from the extra shriekers present in the loot structures controlled by the "extra_growth_chance" object in the "features\sculk_patch_feature_ancient_city.json". There are very, very few freestanding sculk shriekers present in the open areas of Bedrock Ancient Cities which is where the real issue lies. When the extra_growth_chance object is disabled, the cities are practically devoid of shriekers.

Finally, when the sculk patch density is turned up to produce visually similar results to the sculk patches in Java and rule out MCPE-154229 as the main cause of the problem, Bedrock's growth generator (controlled by "growth_rounds", which is normally set to 0 in both Java and Bedrock) seems to operate differently and produce fewer shrieker blocks given the same number of charges, charge amounts, and attempts.

It turns out the extra_growth_chance object (responsible for generating extra sculk shriekers) works in regular sculk patches just as it does in Ancient City structures. Because of this, additional shriekers can be added to not only the pathways of the Ancient Cities, but to the Deep Dark biome as a whole.

What's more, because it bypasses the charge system, extra shriekers can be generated everywhere without incurring much of a penalty in terms of CPU usage. The only downside of it not being tied to the charge system is a more likely chance of lone shriekers being generated which have no sculk sensor to awaken them. This can be remedied somewhat by increasing the chances of a sculk sensor to generate per sculk patch.

Also, due to a nice little quirk in the object's implementation, negative range_min values are allowed and are treated as 0 by the shrieker generator. So it is possible to have less than a 50% chance of generating a shrieker (which would be described by "range_min": 0, "range_max": 1.) For example, to do a 1-in-7 chance of generating a shrieker in a patch, the description would read "range_min": -5, "range_max": 1. When the dice roll selects -5, -4, -3, -2, -1, or 0 from the configured range, no shrieker is generated. Only when 1 is selected is a shrieker generated. Thus a 1-in-7 chance. This provides for a nice way to create a few additional shriekers in the Deep Dark and Ancient Cities to supplement the naturally generated ones.

This is what

and

do, The A version uses 2 spread_rounds (and zero growth_rounds, unlike the previous version of this add-on) with 32 spread_attempts (half as many as the default) with a reduced charge_amount (20) to better distribute sensors and shriekers inside a patch. The extra_growth_chance is used to generate additional shriekers to supplement their counts to Java Edition levels.

Version B uses zero growth_rounds and the default of 1 spread_rounds but with 64 spread_attempts and a higher charge_amount of 29 to attempt to duplicate the version A result. If you're wondering, 32 spread attempts with 2 spread rounds produces different results than 64 spread attempts with 1 spread round. The former produces fewer sensors and sculk blocks, but more shriekers than the latter (which is exactly what this bug pertains to) and because of that, the extra_growth_chance object can be configured to generate fewer supplemental shriekers, which is good due to the lone shrieker issue mentioned above.

So I prefer version A myself because the distribution is more balanced and the sculk consumes less of the Ancient City architecture. But version B produces more sculk like Java Edition does and may ( ? ) use less CPU.

I didn’t see it in the 1.19.10.24 Preview changelog, so it probably affects 1.19.10.24 Preview.

Updated

slightly (251 iterations instead of 249 and 35 charge instead of 32) to generate sculk patches which more closely resemble Java Edition's by a bit. Also changed the GUID's on the 101A and 101B add-ons so all three can be installed at the same time. (Only one will be active, however, since they all change the same features.)

So to summarize, these three add-ons generate roughly the same result in different ways (while using the same constrained Y-extent of 128):

• uses growth_rounds = 1 and spread_rounds = 1

• uses growth_rounds = 0 and spread_rounds = 2 with extra_growth_chance present to generate extra shriekers.

• uses growth_rounds = 0 and spread_rounds = 1 with extra_growth_chance present to generate extra shriekers.

Seems finally fixed in 1.19.30.20 preview

This revision is looking really good so far. Preliminary investigation reveals cities are now generating 40 to 60+ shriekers, which is right in line with Java Edition. Additionally, areas of the Deep Dark outside of the cities are also seeing enhanced shrieker and sensor generation, making the Deep Dark as a whole a much more dangerous place to visit on Bedrock.

Interestingly, the only change to the feature files was the removal of all entries from the "can_place_sculk_patch_on" array. I'm not sure if the removal causes all blocks to be potential targets for sculk patches to start, or if the sculk patch runtime inserts its own default values if nothing is explicitly defined. From my past experience working with these files, it doesn't seem like allowing more block placements would generate these kinds of amazing shrieker and sensor numbers. So I wonder if there were some additional improvements to the C++ runtime?

In any case, great job! 😃