SuperCoder79

Hi- here's the code that I found to solve the performance issue without causing feature placement regressions at biome borders, in ChunkGenerator#

applyBiomeDecoration:

Set<Biome> seenBiomes = new HashSet<>();
for (int x1 = -1; x1 <= 1; x1++) {
    for (int z1 = -1; z1 <= 1; z1++) {
        ChunkAccess chunk = worldGenLevel.getChunk(chunkX + x1, chunkZ + z1);

        for (LevelChunkSection section : chunk.getSections()) {
            for (int ax = 0; ax < 4; ax++) {
                for (int ay = 0; ay < 4; ay++) {
                    for (int az = 0; az < 4; az++) {
                        seenBiomes.add(section.getBiomes().get(ax, ay, az));
                    }
                }
            }
        }
    }
}

List<List<Supplier<ConfiguredFeature<?, ?>>>> features = new ArrayList<>();
for (Biome biome : seenBiomes) {
    List<List<Supplier<ConfiguredFeature<?, ?>>>> featuresInBiome = biome.getGenerationSettings().features();

    features.addAll(featuresInBiome);
}

The other change that would be needed is to change the iterator's next() to be next().get(). It would be possible to flatten the suppliers, but I figured that there was no harm in keeping it like this. This would replacing getting all the configured features via the biome source.

The reasoning behind this change is that features can't expand beyond a 3x3 of chunks centered on the current chunk, so it would be possible to optimize by making it so features that would never have a chance of placing anyway would not be considered for spawning.

This code is CC0 and can be used freely.

Hello, with a little bit more debugging it can be seen that the line ".filter(chunk-> chunk instanceof ImposterProtoChunk || chunk instanceof LevelChunk)" is also causing problems, as it's filtering out ProtoChunks along that border. By adding "chunk instanceof ProtoChunk" to the filter, it will include ProtoChunks and fix the issue. Like stated above, this is definitely a stop-gap fix and a better fix should probably be implemented to fix the problem at it's root cause instead of it's side effects.

Perhaps it would be possible to use a noise to gradually change the direction over a distance? That way stalagmites in different parts of the world would point in a different way, although that may not be immediately visible to the player.

Code analysis:

In LargeDripstoneFeature.WindOffsetter, the assignment for the windSpeed value goes like this:

this.windSpeed = new Vec3(wind.sample(random), 0.0, wind.sample(random));

This makes the x and z values of the wind speed always positive, causing the northwest bias. If that line were changed to:

float speedX = wind.sample(random);
float speedZ = wind.sample(random);
this.windSpeed = new Vec3(random.nextBoolean() ? -speedX : speedX, 0.0, random.nextBoolean() ? -speedZ : speedZ);

(Code provided under CC0) It would give all directions an equal chance of generating.

Hello, I've written code to fix this bug and have attached it below. The way I've solved this is to check for water when generating the geode, and flooding it (replacing the air with water) if it's touching water, as it's more than likely the geode is in the ocean or touching a flooded cave. For lava, if the geode finds lava when generating, the geode will fill until the max lava level. To handle this, the new code stores the air positions in a list and defers placement until the geode is fully generated.

Here's the code, in official mappings. The parts I've changed have a "// change:" comment before them.

https://gist.github.com/SuperCoder7979/c06a216ab635790832db954f9754a3aa

Licensed under CC0.

Here's a screenshot taken with the seed -3902724624318935087 at 312 54 323, with the code working:

As you can see, the geode generates flooded 🙂

Hi, a solution for this bug can be to stick all of the valid positions into a list and then pick a position from the list using the random given to the feature. This is the code for the nylium tree Feature (HugeFungusFeature) now: 

private static BlockPos.MutableBlockPos findOnNyliumPosition(LevelAccessor level, BlockPos pos, Block targetBlock) {
    MutableBlockPos mutable = pos.mutable();

    for(int i = pos.getY(); i >= 1; --i) {
        mutable.setY(i);
        Block currentBlock = level.getBlockState(mutable.down()).getBlock();
        if (currentBlock == targetBlock) {
            return mutable;
        }
    }

    return null;
}

As you can see, once it finds the topmost block, it returns. Using the list based code to prevent that, it would look like this:

private static BlockPos.MutableBlockPos getStartPos(LevelAccessor level, Random random, BlockPos pos, Block targetBlock) {
    List<BlockPos.MutableBlockPos> positions = new ArrayList<>();

    BlockPos.MutableBlockPos mutable = pos.mutable();
    for(int i = pos.getY(); i >= 1; --i) {
        mutable.setY(i);
        Block currentBlock = level.getBlockState(mutable.down()).getBlock();
        if (currentBlock == targetBlock) {
            positions.add(mutable.mutable());
        }
    }

    if (positions.size() == 0) {
        return null;
    }
    return positions.get(random.nextInt(positions.size()));
}

You guys can do whatever you please with this; it's CC0.

Unfortunately this does come with a few caveats, as it will reduce the density of trees in a chunk by half as it now attempts to generate on all surfaces instead of the topmost surface, and it will break world generation as it uses the Feature random to select a random surface to generate on. A smarter solution may be to create a new Decorator to select 8 surfaces to plant on instead of doing it in the Feature.

Here it that code in action:

Nope, the seed is fine. The shape of the terrain hasn't changed, only chunk decoration, so I don't think this is a seed related issue.