Describe the bug
Hi, I'm having a deadlock in my server with Blue Skies installed. As far as I've seen debugging the code, when Blue Skies tries to generate a Gatekeeper structure, it calls its RemoveSnowStructureProcessor, which calls getPrecipitationAt:

public StructureTemplate.StructureBlockInfo process(LevelReader world, BlockPos pos, BlockPos pos2, StructureTemplate.StructureBlockInfo existing, StructureTemplate.StructureBlockInfo placed, StructurePlaceSettings settings, StructureTemplate template) {
        if (((Biome)world.getBiome(pos).value()).getPrecipitationAt(pos) != Precipitation.SNOW) {
...
    }

This ends with the following call stack:

net.minecraft.server.level.ServerChunkCache.getChunk(ServerChunkCache.java)
net.minecraft.world.level.Level.getChunk(Level.java:187
net.minecraft.world.level.LevelReader.getChunk(LevelReader.java:129)
net.minecraft.world.level.Level.getChunk(Level.java:182)
net.minecraft.world.level.Level.getHeight(Level.java:336)
com.teamtea.eclipticseasons.common.core.map.MapChecker.getSurfaceBiome(MapChecker.java:152)
com.teamtea.eclipticseasons.common.core.biome.WeatherManager.getPrecipitationAt(WeatherManager.java:346)
com.teamtea.eclipticseasons.common.core.biome.WeatherManager.getPrecipitationAt(WeatherManager.java:332)
net.minecraft.world.level.biome.Biome.handler$dhc000$eclipticseasons$getPrecipitationAt(Biome.java:2026)

Because this is all called during the chunk genenration, it seems that calling getChunk causes a deadlock as it is trying to access the chunk being generated.

In MapChecker line 151, in getHeightSafe the else return path is executed, returning an invalid buildHeight (-64 in my case), making the game enter the if and run the line 153 (getHeight), which causes the calls that end causing the deadlock.

To Reproduce
There are probably more things involved than what I can say to reproduce it, as this is happening in a heavily modded server (+400 mods).

Steps to reproduce the behavior:

1. Have Ecliptic Seasons, Blue Skies and Chunky mods installed.
2. Run a world generation task using Chunky.
3. The server may hang during world gen because of the described behavior.

Expected behavior
The server shouldn't hanf or freeze.

Platform(please complete the following information):

• Minecraft Verison: 1.20.1
• Platform Verison: Forge 47.4.0
• Mod Version: EclipticSeasons-1.20.1-forge-0.11.1.0.1

Additional context

call_stack.txt

same issus

It seems this issue didn't occur before.
Are you new to using this mod, or did you recently upgrade Blue Sky?

Are you new to using this mod, or did you recently upgrade Blue Sky?

I've been using Blue Skies for a few months, and the same with Ecliptic Seasons (I don't remember which version I used previously because I update mods regularly), and the last released version is from on year ago. I think this is a rare case, because when I first generated the world it didn't happen (in a 400 chunk radius), but now when expanding the world to a bigger area it happened once.

Oh, Gatekeeper. By the way, ES aren't really suitable for world generation mods that use getPrecipitationAt. Actually, I’d recommend they use coldEnoughToSnow instead. That’s because solar terms don’t have fixed winter biomes, and precipitation changes along with the seasons.

Actually, I previously added a mechanism to check whether a chunk is loaded, but it caused quite a few issues on the server. That eventually led us to study magic — looks like the time has come.

Due to Minecraft's chunk management, it's very difficult to reliably check if a chunk is loaded on the server — or rather, it's basically useless. It can easily trigger cascading chunk loads.

I’ll be releasing version 0.11.2 soon, feel free to give it a try.

Hi, I'll check it later tonight, as I have to duplicate the server in my local machine and load a world backup from yesterday to be able to test it. I'll let you know the results.

That was fast!
I can confirm that whathever change you did in 0.11.2 it's working and now the worldgen is progressing accordingly :D

Thank you!

Version 0.11.2 is essentially a composite update, bringing improvements in several areas.
The primary goal is to construct our own heightmap instead of relying on Mojang's hardcoded implementation.
This benefits the performance of computing our specific snow-covered blocks and other rendering logic.

You'll notice that before this version, Snowy Tree had some visual disconnection issues when the Snow Under Tree option was disabled.
That's because chunk section rendering has a Y-distance limitation.
Moreover, it used to be quite difficult to make tall and thin blocks like bamboo snow-covered, since they are considered solid blocks.

Of course, this new approach also requires adjustments to some previous logic.

As for this issue specifically, we mainly strengthened the neighbor chunk loading detection mechanism.
Minecraft 1.20 servers behave oddly—when trying to check whether a chunk is loaded, the method isLoaded often doesn’t work as expected,
especially if the chunk is loading but hasn’t fully entered the world state yet.
Using getChunk directly in such cases schedules a waiting task, which may lead to deadlocks.

So instead, we now use a specialized method that ensures the chunk has already been generated—without waiting—by checking the current result directly.