I'm coming across an issue since I updated TFC and it's really bothering me. I cannot join a world because it crashes after 3 seconds after being in the world, and it says it's because of the feature placement.
latest.log

I'm getting this same error on 1.20.1 when adding distant horizons 2.0.1 to all the mods gravitas

Are you trying to upgrade a 1.18 world to 1.20 or something? Does this happen with a new world?

I only started on 1.20.1. The issue occured because of an incompatibility between the combination of Sinytra Connector, C2ME (Concurrent Chunk Management Engine), and TFC. Previously, C2ME was working completely fine with it all as long as the config option noTickViewDistance was disabled, and now it just crashes. I have no idea why.
Honestly, this probably shouldn't be fixed on your guys end now that I think of it, but if you can do anything about it, please do, because C2ME helped a lot.

Side note: It only happens after ever rejoining a world. Not on first world load.

Update: It seems to have the same issue with Farmer's Delight and TFC. Logs below.
latest.log

Given this doesn't occur in TFC alone, and based on the specific crash that is occurring, this seems to be an interaction with another mod(s) in which chunks are getting saved + reloaded without data TFC uses to generate them (possibly because a fabric mod is breaking the firing of some Forge events we use to save + load said data). I'm immediately suspicious of any "chunk management", "chunk loading", or fabric mods.

A reproduction case with as few other mods or configuration changes as possible would be very useful.

I'll try to get back to you tomorrow with a clean instance and logs.

I haven't found a way to get the game to launch in the new testing instance, and I don't know how I got it to work in the other one, so I'm going to close this ticket for now and I'll probably come back to this soon if there's any news about Connector relating to C2ME.

For reference, viewing a TFC world in NBT explorer, you should see any chunk with status minecraft:noise (or stages after), should have saved tfc_protochunk_data with additional surface height, and aquifer surface height keys. If that is not the case, the save data is
broken - and given I've seen no clean reproduction case, I'm highly suspicious of any sort of chunk management / fabric mod that may be interfering with our saving.

Reopening for future reproduction cases...

With direction from the other issue, I was able to reproduce this: Using Create's Tree Fertilizer, on any tree, will cause a crash shortly thereafter, as soon as any chunk generation is triggered. The root cause is complicated as it is due to a difficult API limitation on how mojang implements their chunk generator and per-world state:

Between 1.18 - 1.20, Mojang split the concept of ChunkGenerator (containing stateless information about how to generate a world), and RandomState (new, which contains all per-world state needed to generate a world, such as seed-based noise, functions, etc.) It then stores the RandomState on the ChunkMap, which is very inaccessible for mods.

TFC, due to it's involved world generation, uses a significant amount of seed-dependent state, including caches of additional data for partially generated chunks (surface height, aquifer surface height, etc.). Given that ChunkMap modification is very difficult, and given in the past we have always stored this state on the ChunkGenerator, we continued doing that in 1.20.1.

Create, for it's part, causes the issue by creating a simulated world (in order to place the tree - why they specifically need to simulate first, I have no idea), but creates it with the same generator as the overworld. This has the effect of creating a new ChunkMap, and then triggering TFC to overwrite it's own world generator state, stored on the ChunkGenerator, which notably includes the aforementioned cache of partially generated chunk data (effectively wiping a bunch of unsaved chunk data), which then, given these chunks all get saved without this data, creates a wide swathe of corrupted chunks in the vicinity.

The fix I ended up going with, was that if our chunk generator notices a re-initialization, it will duplicate itself for the new ChunkMap first, before initializing. This is not the cleanest solution, but in leiu of any real way to extend RandomState for our own purposes - as was the initial problem when porting 1.18 -> 1.20 - and the difficulty that trying to refactor onto a custom RandomStateExtension would provide, the stateful chunk generator is here to stay.