Clear block state map before recreating it during bake.

[Acuadragon100]

Fix for players being unable to join servers.

[BluSpring]

I don't think this patch is valid, the actual cause of the problem is more likely due to onClear never getting called, which would be doing pretty much what you are doing except differently. I'm pretty sure it's never called since Kilt doesn't really utilize Neo's configuration tasks (including registry resync), which is intentional. You should look into getting onClear / Registry#clear getting called but using Fabric's registry sync code instead.

[Acuadragon100]

On second thought, aren't we doing some things twice at the moment?
I mean, NeoForgeRegistryCallbacks.BlockCallbacks does a bunch of things which Fabric API already takes care of. The main thing it does which Fabric API does not is handle the clear function for the registry (although BlockCallbacks also runs BlockStateBase::initCache for all block states, but this happens during world load via Blocks::rebuildCache anyway).
Maybe we should just disable BlockCallbacks::onBake completely?

[BluSpring]

I have seen some weird shit happen from disabling stuff, and since things seem to work for the most part at the moment it should be fine to keep around.
Also, unfortunately, some mods (Architectury API-based mods) do seem to actually utilize the behaviour that BlockCallbacks::onBake is intended to deal with.

[Acuadragon100]

Fair enough, but Block::BLOCK_STATE_REGISTRY is filled twice on the server side as well. I don't think a registry sync will deal with that, so we probably still need to clear Block::BLOCK_STATE_REGISTRY manually before BakeCallback::onBake runs. I don't think we want to do that via ClearCallback::onClear because other mods might not expect that. The best place I can think of doing it would be either in MappedRegistry::freeze, or directly in BlockCallbacks::onBake (Fabric API fills Block::BLOCK_STATE_REGISTRY via RegistryEntryAddedCallback).

Honestly, the more I think about it, the more this patch feels like the best solution.

[BluSpring]

I feel like either way onClear still needs to be called somewhere, from what I can gather it's not getting called at the moment.

[BluSpring]

If anything, we can honestly limit the clearing in the MappedRegistryInject so we don't cause problems to other mods.

[Acuadragon100]

I feel like either way onClear still needs to be called somewhere, from what I can gather it's not getting called at the moment.

As far as I can see, clear is only used from RegistryManager::applySnapshot, which is only really used by the NeoForge registry sync or when errors occur.

[BluSpring]

Yeah, we really need to call it, because some Neo mods hook into the onClear event that is dispatched by these registries.

[Acuadragon100]

Ah, I see.
Do you think we should run RegistryManager::applySnapshot from a RegistryIdRemapCallback? We could limit it to only vanilla registries and registries with a NeoForge mod id. I was thinking we could add phase ordering so it runs after most events.

For reference, it might look something like this:
https://github.com/KiltMC/Kilt/compare/version/1.21.1...Acuadragon100:version/1.21.1-clear-on-registry-sync?expand=1

[BluSpring]

Personally not a big fan of applySnapshot and I'm not sure if it'll find any use.

[Acuadragon100]

Hmm...
In that case I'm not really sure about the best way to do this. Would you prefer just running onClear and onBake directly in the RegistryIdRemapCallback?

[BluSpring]

Might be our best bet here, to be honest.

[Acuadragon100]

Might be our best bet here, to be honest.

Do we want to do that for Fabric-specific registries as well, or only vanilla/NeoForge ones?

[BluSpring]

Best to track for all, since we're still bridging it.