lunaStellarii

affects 1.21.1

affects 1.21.1
the subtitle captions corresponding to the primary sounds in question are

• "Warden lands hit"

• "Warden takes notice"

• "Warden takes notice angrily"

this is probably entity.warden.listening, entity.warden.listening_angry, and entity.warden.attack_impact-- they're not being attenuated properly.

other sounds besides these may still be an issue, albeit at a lesser but still too large distance, such as sniffing.

can confirm in 1.21 that using a key item to unlock a vault or failing to unlock a vault will not activate sensors, and would expect them to activate and attribute the action to the player

turns out its not just the bottom face, it's any of the faces.  it can even sometimes make the opposite face disappear!

confirmed for 1.21.

confirmed for 1.21 pre-release 1

can confirm in 1.20.6 and 1.21 pre-release 1.

what i expected:
that trial chambers generate around y=0 as in default worlds

what happened:
no trial chambers, or other structures generate despite there being the correct y-levels available to generate in

i was very interested in finding the trial chambers, playing superflat with some friends, and didn't find any structures, only to realize that it's not just trial chambers that do not generate, but generally no structures generate below y=0 regardless.

superflat settings:
minecraft:bedrock,63*minecraft:deepslate,59*minecraft:stone,3*minecraft:dirt,minecraft:grass_block;minecraft:plains

will further note that as of 24w18a, if there is any relation to this behavior, the particles inside the trial spawner and its sounds are receptive/active which are more in line with the normal monster spawners.  this was not the case in any version prior.  mobs still do not spawn as one would expect.

confirmed for 24w19b

Confirmed for 24w14a.

I personally use the doMobSpawning rule to disable natural mob spawning in non-peaceful modes, and have it so only spawners can spawn mobs, as it's a more intentional seeking out of mobs in an otherwise isolated feeling environment.  But when I went to the Trial Chambers, I was surprised to see the Trial Spawners not responding.

This relates to MC-170191, which is Works As Intended.

Can confirm in 23w12a.

Furthermore, copied shriekers will actually become responsive if the chunks are unloaded+reloaded, but responsive in a glitched manner.  It will only work in a 3x3 chunk area, centered on the original shrieker.  If you trigger the original shrieker, it will activate all of the copied shriekers in that 3x3 chunk area.

This does the same exact thing for sculk sensors (MC-261348), which also started this issue in 22w12a, just like this, and seems to do with the saved location NBT data of the original block that was copied.  However, agreeing that in both cases for shriekers and sensors, that it probably relates to MC-207251.

Confirmed in 22w17a.

Steps to replicate:
1. Get a creeper to pursue you near the warden, close enough that the warden will track the vibrations of the creeper walking.
2. Continue to lure the creeper toward you until the warden finally knows where the creeper is and begins its angry/roar animation sequence.
3. Immediately get the creeper to explode as the warden is still in or finishing up its roar sequence.

The warden will be stuck in a loop playing out its roar animation.
I was able to walk and jump around the warden within 10 blocks of it, causing lots of vibrations that it could sense, but it continued its loop several more times before it finally had enough and took me out.

I believe I experienced this when I setup a server on my computer for friends to play on, and all of us saw each other skipping around and out of sync of where we should be.  We would see each other sometimes apparently glitched into blocks (see picture below), and often see blocks updated out of seemingly nowhere due to not seeing immediately where someone actually is and what they're doing.  The rotation of the ghost player may have also been scrambled (i.e. actually looking west but facing east)

Confirmed in 21w43a
There can be quite a number of patches of just 1-tall spikes

Can confirm for 21w17a; following copper ore veins into deepslate blobs leads to stone copper ores being completely surrounded by the deepslate on all sides.

I would like to bump this again because I am finding a pattern and probable cause for its occurrence, as well as evidence for linkage to another significant bug.

I've done extensive testing for hours trying different things, and it actually started with bug MC-166005 - "Stuttering when crossing chunk borders/loading chunks", in which I discovered that villages in 21w16a with the Caves & Cliffs datapack, created enormous lag spikes in the region, up to 30 chunks away from the village boundary.  It turns out that in the same lag spike region, the dark/missing chunk issues were often found.  I would repeat it over and over-- fly to a new village, fly around it a bit, and I would get both lag spikes, and dark chunks.  Repeat with a new village.  While I found that severe lag spikes were unique to having the Caves & Cliffs datapack running, the dark chunks are still repeatable under the same circumstances even in prior versions before datapack usage, i.e. 21w14a.

There are 2 good ways to predictably reproduce the dark/missing chunks, and anticipate where they will occur.  Start in spectator, and go full speed with the mouse wheel + sprinting in either case.

1. Villages - Fly to a village and past it along an axis, X or Z.  The fly-through generates the village and surrounding chunks in an easier straight-line pattern.  Keep flying away to completely unload the village and surrounding area (I go 1000 blocks away).  Turn around and fly back to the village.  There will be a chance the dark chunks will appear near the village, usually arranged in lines, if you flew along an axis.  If the village has a certain size bounding box surrounding it, the dark chunks will usually be straight lines on the perimeter of a larger box around the village.

2. Teleportation - Teleport to a completely new area away from any already generated chunks (I suggest doing nicer numbers like 2000, 2000 so its easy to remember and stay aligned with).  Immediately upon teleporting, fly around in a spiral (increasingly larger radius circle) surrounding your teleportation location in such a way to create as many chunks as quick as possible for up to a minute or so.  Align yourself with the teleportation location, and fly directly along the X or Z axis far enough away to completely unload the area (i.e. 1000 blocks), and return.  Check the area surrounding your teleportation location.  You can try different things each time you teleport to a new location to see different patterns of dark chunks.  While the shapes can vary, you can still find straight line and 'corner' shaped dark chunks.

In either case, here is what I think is happening:

• During chunk generation, the game is demanding a certain amount of resources which can't be met as quickly for whatever the reason is, so let's say we call this "stress".  Based on my findings in bug MC-166055, villages are somehow creating more stress (especially in the C&C datapack to the point of severe lag spikes), so the likelyhood of finding dark chunks around it are higher.  Creating lots of new chunks generally creates more stress, but especially teleporting to a new area that's surrounded by completely ungenerated terrain and flying around-- more chunks have to be generated around the player rapidly, so it's more likely to find dark chunks.  In both cases, revisiting terrain you generated under high-stress conditions, more likely gives dark chunks where it had issues generating.  The dark chunks usually seem to take a shape based on the way you stress-loaded the generation.

Here's a few examples to illustrate what commonly happens in each method:

Case 1 Examples: Dark chunk line perpendicular to village line of sight

Case 2 Examples: Dark chunk "box" surrounding a teleportation location & Other irregular shapes

I'm heavily inclined to believe that the dark/missing chunk issues are caused by anything that causes excess stress during the chunk generation process, and some chunk data is getting at least temporarily corrupted.  Example: the game is generating a chunk, something interrupts the process, causing data to be incomplete.  Let's say we roll with that idea.  Sky lighting maybe doesn't get the chance to have data populated in the sub-chunk, so the default value is 0 (dark) unless otherwise given the opportunity to be filled with a "15".  As some have noticed, the dark chunks can also coincide with trees being chopped at the boundary, which seems like it would be consistent with chunk generation being interrupted as well.  Maybe there's other generation features that can be interrupted too.  They seem like different issues at face value, but might have the same root cause.

note: On a server, some dark chunks will disappear after relogging, some won't.  For the ones that won't disappear, even completely shutting down the server and restarting it multiple times won't fix it, and remain 'permanently' mob-spawnable.

And maybe the reason why it's more difficult to reproduce this issue with the non-C&C generation, is because it's harder to achieve the amount of stress needed to start corrupting chunk data-- less chunk height means less to generate, and a smaller window of opportunity for something to interrupt the chunk generation process?  So something would need to be optimized/fixed with chunk generation so that it's much harder or impossible to interrupt chunk data creation?  And something about villages would need to be potentially optimized?

Just my thoughts based on the patterns I've observed, hope this helps!

So there seems some general behaviors regarding which chunk borders cause issues.  I'm starting to find patterns in a world I generated, testing on a server that is run on my computer, on 21w16a with the caves and cliffs data pack loaded.  It seems that for me, the issues exclusively occur on a server run with the datapack as it doesnt happen on a 21w14a server (before the datapack), nor in singleplayer, but still match the issues described in this report and should still be of use to know and may help pinpoint the general issues regardless.  My situation seems to have, if anything, amplified the issues.

note: upon further reading, it seems that while this issue can be taken generally, it does specifically address some sources regarding the server+C&C datapack combo in bug report MC-223383

There seem to be 'permanently problematic' (type A) areas, as well as 'semi-problematic' (type B) areas that I'll refer to as (fig.1, below).  I'll be referencing type A and type B regions numerous times, so here's how I'm defining them here on out:

• Type A Region, Permanently Problematic: The region in question always causes lag spikes.

• Type B Region, Semi-Problematic: The region in question only sometimes causes lag spikes, and depends on whether the player has loaded the type A region, and what the player is doing.

Fig.1 - Hovering in a location in the type B region, that is about to load in the type A region in front.

The area near spawn in my world was a village, and a type A region-- leaving the area and returning, logging out and back in, restarting the server... lag spikes always occurred when crossing chunk borders in the area, and also resulted in the shift+F3 pie chart reading increasingly higher "scheduled executables" with each lag spike to no bound.  This happened in other areas of the world too.  These type A regions can be separated by hundreds of blocks or more, discovered from any mode of gameplay.

It is worth noting that all villages I encountered were type A regions, but not all type A regions were villages (the issues also occurred in seemingly 'random' areas with no notable features/pattern).  **  Note in fig.1, that the chunks stopped loading at the village boundary, and a massive lag spike followed.  To verify that this occurs with villages at the least, and does not completely depend on what the player is doing, I recreated the world from scratch, and teleported to near the village in question.  Loading the village the first time (i.e. chunks freshly created) did not result in formation of a type A region.  However, completely leaving the area and returning to the village boundary (now that the chunks are already generated) results in type A region formation. So the general point here to note, is that the issue might only occur after the chunks are generated, when they are revisited.  In the case of the village, approaching the village from any side of the rectangular bounding box, results in lag spikes once the village boundary is loaded.

Upon leaving type A areas (i.e. villages), it induced type B areas, and it gets a little complicated in how it works.  There are two states that type B regions can be in: problematic, and non-problematic.  Chunks that were not problematic before, became problematic temporarily.  The problematic behavior however will vanish when moving further away from both the type A and type B areas to unload everything.  Returning to the type B area alone will no longer be problematic, you can move in any direction without any spikes, as long as you are away from the type A area.  Returning to the type A area again will restart the issues in the type B area.

Problematic behaviors noted:

• Directional-dependent lag spikes

  • **Example, directions are random: moving north, east or south across chunk borders caused lag spikes, but moving west didn't.  You can move east across chunk borders successively-- 1, 2, 3, 4 and 5, and every single crossing will cause a spike.  But, moving west in the opposite direction across the same borders successively-- 5, 4, 3, 2, 1, never causes a spike.

  • The directional dependence is somewhat inconsistent if speaking generally, however upon further investigation, there is one reliable pattern that occurs when flying through the problematic type B region, away from the type A region. When moving away, at some point the lag spikes will stop.  As soon as the spiking stops when moving away, indicating you are sufficiently far from the type A region, immediately backtracking causes the spikes occur, and switch behaviors to become directionally-dependent.  They no longer occur moving away, but will only occur moving toward the type A region.  Moving back and forth anywhere in the type B region at this point will stay directionally-dependent until either: (1) unloading the type B region, or (2) revisiting the type A region.

• Biome identifying and rendering issues

  • When a type B region is in a non-problematic state, biomes are identified correctly.  When a type B region is in a problematic state, as induced by loading the type A region, biome identification is scrambled-- biomes are misnamed in the F3 info, and therefore biome colors are also incorrectly rendered (see figures 2-4 below)
    

    [media]

    Fig.2 - Type B region in a non-problematic state with correct naming and (mostly fine) rendering.

    [media]

    Fig.3 - Same Type B region in a problematic state with incorrect naming and rendering.  The colors of the ocean shows a line along a chunk boundary revealing where issues are occurring.  The grass in the lower left corner of the image is also visibly less saturated compared to fig.2, due to it being miscategorized as ocean.

    [media]

    Fig.4 - Same Type B region, hovering over landmass that is being miscategorized as ocean, per F3 info.  Following the terrain in the direction of the bottom left corner of the image goes deeper into the type B region, towards the type A region, pictured in fig.1.  All of the type B region spanning 24-26 more chunks in this direction, is all land, but still all considered ocean by the game.

• Potential correlation to bug MC-214793 - Dark/Incorrectly Lit Chunks & Mob Spawning

  • In the type B region near its edge, several chunk lighting issues were found.
    

    [media]

    Fig.5 - Same Type B region, looking at the same area pictured in figs.2-4 from a different angle.  The landmass in the left side of the image here, matches the land in the middle of the previous figures.  Some chunks are completely dark, and other locations see an abrupt change in light level at chunk borders, particularly from the coral reef in the top part of the image.  The dark chunks also approximately defined the lag spike region-- moving up to the left results in lag spikes, chunks down to the right were not problematic.

Fig.6 - Two long strips of dark chunks, with potential correlation to type B regions.  The dark chunk strip on the right was created when moving away from a village type A region, located directly to the right.  The dark chunk strip on the left was created when moving away from an unknown source type A region, located directly to the left.  In both cases, the dark chunk strip is perpendicular to the line of sight to the type A region.

• • The dark chunk issues are inconsistent in the aspect that they do not always materialize every time the type B region is problematic.  While inconsistent, the issue is sometimes reproducible in the the exact same chunks if it occurs-- the dark chunks can appear in the same arrangement in the same location.  However, the abrupt lighting changes at chunk boundaries in the coral reef still remain regardless.

  • Dark chunk issues are however consistent in the aspect that they will occur no matter which side of the type A region that you start at and fly directly away from, and happen in the type B region when you move some distance away.

  • The perfectly dark chunks are treated as mob-spawnable by the game, regardless of night or daytime (mobs will spawn in such dark chunks midday)

  • On the rare occasion, dark chunks can sometimes be completely missing, and F3 gives "waiting for chunk" indefinitely.

Anyone else able to find and agree with any patterns?  On a server running the caves & cliffs datapack?  In singleplayer?

Hope this helps find the source of the issue!

Definitely confirmed for 21w14a. This all occurs in singleplayer, and can confirm it also happens when running a server at least in 21w13a.  The lighting issue does not disappear with F3+a chunk reloading, but fixed when saving and quitting to title, and rejoining the world.

The lighting glitch is more than just client-side visual, because mob spawning is able to occur in it midday.

Furthermore, the glitch can be more severe sometimes where the chunk entirely fails to render.  When inside the chunk space, F3 is missing chunk info and states "waiting for chunk" indefinitely.  This cannot be solved with F3+a either.