Is your idea related to a problem? Please describe.

Terraforged world generation doesn't see Tinkers' config. Right now, it generates both overworld floating island types every 10 chunks or so by default. That's configurable at world creation time, but the other island types aren't.

Describe the solution you'd like

I realize Tinkers' Construct isn't where the problem is coming from, but it's where the solution would have to come from. Terraforged provides instructions for other mods to register structure generation settings: https://github.com/TerraForged/TerraForged/wiki/Mod:-Structures:-Compatibility

It seems like this might be partially done already, since some of the islands work but others don't.

Describe alternatives you've considered

Terraforged also supports third-party datapacks for this purpose. Given the popularity of both mods I'm hoping you'll find it worthwhile to fix at the mod level, but if not I'll take a stab at that.

Versions:

• Minecraft: 1.16.5
• Forge: 36.1.18
• Mantle: 1.6.97
• Tinkers Construct: 3.0.3.152

Confirm below that this enhancement is not covered on the roadmap or "Whats New?"

Not that I can find.

We already do what is described on that page you linked. We add all our strctures to the proper dimension settings, if TerraForged does not support that they are doing things wrong.

We also add all our structures to the default structure map. If its not working, I suggest you talk to the devs of terraforged and tell them Tinkers does exactly what they say is needed for compatibility and it does not work.

I'll look around to make sure I haven't missed something and then bug them if I need to. Thanks!

More info from the TF thread (linked above):

TC's config doesn't work because they don't actually update the structure settings data when the config changes. They redirect reads of the data to their config, but don't actually update the data value (besides perhaps when the game first loads, so you might be able to edit the config & restart MC with success) - when minecraft converts those settings to/from json, their config redirects are lost and you end up with just the unmodified data values which is what TF sees. TC will have similar issues if you were to configure their structures via datapack and then later want to change the settings via their config.

I'm hoping they're correct and this change would let me apply non-default settings to an existing world, even if I still wouldn't be able to change them afterwards.

Let me clarify: are you finding terraforged cannot configure our islands, or are you finding our configs do not work when terraforged is installed? What you are describing as the issue and what they are saying is the problem are two very different things.

If what the dev is describing is true, I would expect terraforged to easily override our settings, our settings would just not update old worlds, especially since the time we add the structure settings is a time when the config has finished loading in my testing.

Hi. TF does indeed pick up your structure settings so it can offer sliders within our ui to allow the user to configure them. We don't have an option to change these settings after world creation though as this breaks structure locating in generated chunks.

The issue I'm describing in that ramble quoted above is related to this class. When the StructureSeparationSettings are serialized to json, its codec reads the data values from the class fields rather than the getter methods so the serialized data does not contain any config value changes. When that data is deserialized back into a StructureSeparationSettings instance it uses the default implementation of the class (ie not your extended version) so the redirects to your config no longer exist/happen in the instances used by TF's chunk generator (it's more by luck that they do in vanilla's).

A more robust approach I think would be to listen for config changes and replace the StructureSeparationSettings instance with an updated copy in the world-gen registry. That way the fields & therefore the serialized data would reflect what's in the config (it also removes the overhead of looking up a config value from inside world-gen where it may be called quite frequently).

Ah, Mojang not using their own getters, of course

Honestly, config cannot change after we create the structure separation settings, so might be easier to just use static settings regardless

As someone not familiar with the underlying architecture, what's the expected impact of this change? That TF will use the information from TC's config files at worldgen? When generating new chunks after initial worldgen?

If you are just playing with Tinkers, you should see little change.

If you are doing weird stuff with datapacks and worldgen config, it will ensure our config value is the one Terraforged sees.

Okay, I'll experiment and see if that's enough to rescue an existing world from an island-covered fate. Thanks.

Fixed in one of the recent releases