In FerriteCore I replace the withTable of blockstates with a far more memory-efficient structure. I don't use the original field for this, I add my own fields and set the table to null. This is mostly compatible with Statement, except for one direct usage of the table here. How do you want to handle this? I'm willing to add code to FerriteCore to help; however so far fully implementing Table has always seemed like a fair amount of work for virtually no gain.

This is relevant on both Forge and Fabric.

Figured out a solution I can do on Statement's end, however after testing it, it seems FerriteCore would also need to remove this null check and throw as the state map will definitely not be null after Statement runs and results in that method getting called again later on.

I've removed the null check on my side, you can find builds here. If you can confirm that this is all that's needed from my side I'll try to get a new release out later today.

One other thing I noticed: You're using parallelStream to call createWithTable. Is there some specific reason for using that (as opposed to just stream) there? And if there isn't, would you be opposed to moving it to a single-threaded stream? FC relies on a ThreadLocal to use the same FastMap instance for all states of a block, which obviously doesn't work when createWithTable is called from multiple threads for states of the same block. It should still produce correct results with the parallelStream, but it might use more memory.

If you can confirm that this is all that's needed from my side [...]

Any update on this?

Apologies for the delay. Have been quite busy IRL.

this is all that's needed

The fixed version of Statement and the FC version with the null check do seem compatible, yes.

You're using parallelStream [...]

The parallelStream is mainly a performance thing. With a mod like Towelette there'll be over double the normal amount of states for a lot of blocks and the time it takes to add new states for them all hurts load times rather significantly with createWithTable being one of the main bottlenecks IIRC.

I was going to ask "Does FC specifically need those maps to be different for different threads? What's preventing the use of e.g. a MutableObject instead?", but after some testing it seems that after changing it to use MutableObject it initially seems to work fine with Statement, but then causes a different compatibility issue when using a mod that actually does state changes like Towelette.
In other words, for now the null check is the only change that's needed.

Reopening this as it might be worth us investigating the above later, but for now I'm adding a check to disable those parallel calls if FC is present since it optimizes the bottleneck code that I added the threading for in the first place.