You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow users to have more direct control over final biome distribution in terrablender.toml. Right now, only the vanilla weights are available, which is useful, but its also vague how that number actually translates into biome distribution. It relies on users looking into each mod they have, (hopefully) finding their weights, and looking that them all together to understand what it means.
The easiest way to do that is, as an alternative to using weights, allow user to directly set the % that is vanilla in terrablender.toml. From Terrablender's perspective, all it'd need to do is internally set the 'weights' of vanilla regions via a calculation with the weights reported by the biome mods' regions. Then if the only problem was access to vanilla biomes, users have an easy way to set it without a ton of digging and don't need to readjust it every time a biome mod is added or removed to their mod list.
Ideally, however, it'd be nice for users to be able to override weights specific to each detected biome mod. That way, we could even easily adjust how much each mod is expressed individually and have total control over world generation. But that's much harder to implement, and arguably isn't necessary if its assumed that all mod authors include their weights in config files. That said, at least one mod has multiple weights for the overworld, and its still unclear what that means.
Why would this feature be useful?
The most common complaint for years about biome mods is that they take over the game - and rightfully so. Naturally, most biome mods that use Terrablender put high weights on their own modifications. It would help the overall user satisfaction with Terrablender and biome mods by making the adjustment process more clear without requiring mod authors to each provide that option themselves nor requiring users to track it all down in different places.
The text was updated successfully, but these errors were encountered:
Overview
Allow users to have more direct control over final biome distribution in terrablender.toml. Right now, only the vanilla weights are available, which is useful, but its also vague how that number actually translates into biome distribution. It relies on users looking into each mod they have, (hopefully) finding their weights, and looking that them all together to understand what it means.
The easiest way to do that is, as an alternative to using weights, allow user to directly set the % that is vanilla in terrablender.toml. From Terrablender's perspective, all it'd need to do is internally set the 'weights' of vanilla regions via a calculation with the weights reported by the biome mods' regions. Then if the only problem was access to vanilla biomes, users have an easy way to set it without a ton of digging and don't need to readjust it every time a biome mod is added or removed to their mod list.
Ideally, however, it'd be nice for users to be able to override weights specific to each detected biome mod. That way, we could even easily adjust how much each mod is expressed individually and have total control over world generation. But that's much harder to implement, and arguably isn't necessary if its assumed that all mod authors include their weights in config files. That said, at least one mod has multiple weights for the overworld, and its still unclear what that means.
Why would this feature be useful?
The most common complaint for years about biome mods is that they take over the game - and rightfully so. Naturally, most biome mods that use Terrablender put high weights on their own modifications. It would help the overall user satisfaction with Terrablender and biome mods by making the adjustment process more clear without requiring mod authors to each provide that option themselves nor requiring users to track it all down in different places.
The text was updated successfully, but these errors were encountered: