Open Kasardas opened 1 year ago
Hm, looks like the crash happens in Biolith...
I think the biolith authors should be able to fix the crash quite easily. If they don't I might be able to prevent the game from crashing there, but that would probably omit the biomes that are managed by biolith.
I will flag this issue as external for now. But I will continue to keep track of the issue.
I am going to publish an updated Biolith to address this issue per se, but there are other issues with the combination of Biolith and bclib. Cinderscapes will declare a breaks relationship with bclib because of the behavior described in https://github.com/TerraformersMC/Biolith/issues/4#issuecomment-1596249675 which is certain to cause user frustration otherwise. It is fairly likely in the future Terrestria will also place some biomes by noise and at that time we may need to do the same in Terrestria.
If you would prefer a new issue, let me know. I suspect the above behavior may stem from some kind of stored state or a different code path in bclib during world creation vs. save loads. A key difference between Biolith and TerraBlender is Biolith does not insert its noise-based biomes into MultiNoiseBiomeSource.biomeEntries
but rather modifies the output of MultiNoiseBiomeSource.getBiomeEntries()
(possibleBiomes()
).
I poked around in bclib's mixins but the problem did not jump right out to me so I suspect/hope it may be more apparent to someone familiar with bclib.
No, this issue is fine, and I think this is actually a Bug in BCLib.
Some Background: When a world was created with the BetterX World type, the game will create the loaded dimensions with our ChunkLoader and more importantly our BiomeSources (which do not inherit from vanillas MultiNoiseBiomeSource). When we get to the point where we usually merge the biomes from other sources, the vanilla Nether Source was nether loaded and thus, your Mod never got a chance to inject the custom Biomes.
The good thing is, that this is easily fixable.
Oh, and BCLib does not touch the Overworld, so the only other conflict could come up for the End.
And there is also another, simple solution (but it would require your Mod to include some files in the data directory, and I understand if you don't want to do that).
Our Biome sources use a custom registry to determine whether or not a Biome is supposed to be placed in a certain Dimension. The registry is read from Datapacks, so other mods can easily extend it.
You can place a json file for each Biome into /data/[modid]/worldgen/betterx/biome/
. Here is an example for the Nether Wastes in Minecraft:
{
"type": "bclib:biome",
"biome": "minecraft:nether_wastes",
"fogDensity": 1.0,
"genChance": 1.0,
"intended_for": "OTHER_NETHER",
"vertical": false
}
The value for intended_for
are
OTHER_NETHER
OTHER_END_CENTER
OTHER_END_VOID
(Where vanilla would spawn the small end islands)OTHER_END_LAND
OTHER_END_BARRENS
This will do the same as the BCLib code, but (especially in the end) the type for a merged Biome is always OTHER_END_LAND
.
The vertical
value is only available for Nether Biomes, and will ensure that the biome spans the entire height of the nether (especially with an amplified nether)
Oh, and finally: If there is some data I can read from your mods that tell me which biomes go where, I'd be happy to read it to ensure they are loaded properly.
For the Overworld and the End, I could definitely expose data like that; impl has the following two methods:
public void BiomeCoordinator.OVERWORLD.writeBiomeParameters(Consumer<Pair<MultiNoiseUtil.NoiseHypercube, RegistryKey<Biome>>> parameters);
public void BiomeCoordinator.OVERWORLD.writeBiomeEntries(Consumer<Pair<MultiNoiseUtil.NoiseHypercube, RegistryEntry<Biome>>> parameters);
(And equivalents for BiomeCoordinator.NETHER). The first can be called any time after the end of the mod initialization phase, and the second any time after the registry is available. If you can describe what sort of an API would be easiest for you to use, I can write something that translates the output of those functions. (The RegistryKey version is deprecated but only because I am no longer using it; I can keep it if someone else wants it.)
Regarding data for the custom registry, the main issue is Biolith is just a utility for other mods (like Bclib). I cannot create those files (or I suppose I could but only after the server is starting up). We could provide some documentation for users of Biolith to add the files themselves...
The End is a whole different thing and I am not sure how we could make our libraries compatible there. Biolith replaces TheEndBiomeSource.getBiome()
with the same multi-noise implementation we use in the Overworld and Nether and provides a complete noise point for biome selection. It may be the best thing for us to do is to somehow coordinate so users can pick which End library they prefer...
First off, thanks a lot for investing the time. I really appreciate it :)
It may be the best thing for us to do is to somehow coordinate so users can pick which End library they prefer...
BCLib will only add our custom ChunkGenerator/BiomeSource if players choose one of the BetterX World-Types when creating the world.
If they choose any other type (or disable the Custom Biome Source for any dimension), we do not interfere and just register our Biomes with the Fabric Biome API and hope for the best :)
. And if End Biome are visible through a call to
possibleBiomes
(the type of the end BiomeSource does not matter) we will automatically add them as regular highland biomes.
For the Overworld and the End, I could definitely expose data like that;
I am wondering what the best approach is without adding additional runtime dependencies. Maybe an entry point? One that receives a Supplier<List<Pair<MultiNoiseUtil.NoiseHypercube, RegistryEntry<Biome>>>>
. BCLib could call that supplier when it is ready to merge the biomes. But that would not include a hint as to where the Biome should get used in the "regular" End (as in small island or highland biome).
I could also add an entry point to BCLib, one that BCLib would call when it needs a list of biomes...
For the Overworld and the End, I could definitely expose data like that;
I was thinking, and I guess the most flexible solution would be Biome-Tags? Using IS_NETHER is a simple way to find all nether biomes.
If we would use Biome Tags for the different End Biome types (c:IS_END_HIGHLAND
, c:IS_END_MIDLAND
,...), BCLib could spawn them in the correct locations...
For the Overworld and the End, I could definitely expose data like that; impl has the following two methods:
Kind of a critical error there ^^^ -- I intended to say, "For the Overworld and the Nether".
But that would not include a hint as to where the Biome should get used in the "regular" End (as in small island or highland biome).
Actually, it does; the End's native noise gives an exact relation between continentalness noise and the vanilla biomes (meaning, it mirrors the use of that single noise in generating the vanilla island terrain). Biolith's End noise retains this by mapping the vanilla biomes in such a manner as to cause the multi-noise biome selection to place them in the same locations as the vanilla method did. Therefore you can generally know where our biomes belong by looking at the continentalness noise.
The only issue with using tags is we have to push everybody who uses Biolith to define the custom tags for their biomes, which is somewhat similar to the other data-based approach.
Also, as aside, bclib can't really place Biolith-based End biomes in the right place; they should be distributed using multi-noise points, and many of our replacement biomes need access to the second-best-fit noise value in order to situate themselves correctly (f.e. biomes which are intended to transition from a specific biome to another specific biome). So anything we do to allow the biomes to generate in a bclib-controlled End is just a best-effort sort of thing anyway.
The biome overlay code appears to work in bclib worlds for the Overworld and Nether, so we may be compatible in the Overworld already and in the Nether once you publish the fix mentioned above.
By now the fix is live as BCLib 3.0.8.
We do have a concept of edge biomes so maybe it would be possible to map transitional Biomes to those edges... But I absolutely agree. It will allays be just a best-effort.
The only issue with using tags is we have to push everybody who uses Biolith to define the custom tags for their biomes, which is somewhat similar to the other data-based approach.
Oh sorry, I figured you might be able to add Biomes to a Tag at runtime. As I said, I am happy to either provide or use an entry point that passes the required information.
By now the fix is live as BCLib 3.0.8.
Thanks; I'm going to push the updated Cinderscapes in a moment.
Regarding the rest of this discussion, I haven't dropped it; I'm just bogged down with work stuff at the moment. I want to do some testing with both mods configured to generate End biomes and try to understand how that affects them and what our options actually are. There's a good chance I will have to make a dev dependency on bclib like we do for TB and in that case the simplest solution to getting biomes over to bclib would be for you to add an API.
What happened?
On creating new world, a crash occur
BetterNether
9.0.4 and 9.0.5
BCLib
3.0.5 and 3.0.6
Fabric API
0.83.1
Fabric Loader
0.14.21
Minecraft
1.20.0
Relevant log output
Other Mods