Server Registry Stuff

[Notenoughmail]

Makes some adjustments so dealing with ServerEvents.registry is relatively nice.

• During the event, the RegistryAccessContainer has 'access' to non-static registries by making an empty registry on demand and providing that. This is needed for wrapping Holders and HolderSets of server registries
• Server registry builders now have their tags loaded
• Add a wrapper specifically for reference holders. Helpful for when a holder needs to be serialized as the DeferredHolder which is typically made cannot serialize

These changes were tested locally against this commit

[MaxNeedsSnacks]

Is createStandAlone guaranteed to be safe?

[Notenoughmail]

In what context? When serializing with a registry present (the intent & use case I have), yes. For retrieving a value/id from the registry itself (or the holder even), no

[MaxNeedsSnacks]

• During the event, the RegistryAccessContainer has 'access' to non-static registries by making an empty registry on demand and providing that. This is needed for wrapping Holders and HolderSets of server registries

Mind explaining / giving a brief example on why this is needed and why we specifically need to create a new RAC instance here?

[Notenoughmail]

• During the event, the RegistryAccessContainer has 'access' to non-static registries by making an empty registry on demand and providing that. This is needed for wrapping Holders and HolderSets of server registries

Mind explaining / giving a brief example on why this is needed and why we specifically need to create a new RAC instance here?

It is quite common for server registry objects to reference other objects via holders (placed features are literally a configured feature holder and a list of placement modifiers) and holder sets (TFC's forest feature; builder). Kube's wrappers for these two types requires the registry they're for to be present and the codecs will only serialize to the object/tag id if the registry is present in the RegistryOps.

Even if scriptors passed in a ResourceLocation/TagKey and they were lifted to a holder/holder set, the codec would try to encode them as their contents which neither would have. This is also why reference holders specifically have to be used as deferred holders require a value to serialize.

I tried to find a place where these registries existed and that was before datapacks were parsed, but there does not seem to be such a place.

[MaxNeedsSnacks]

I need to give this a proper look before actually merging, but from what I can tell, this is kind of a mirror of what vanilla does for its own datagen in RegistrySetBuilder et al. right?

[Notenoughmail]

more-or-less, vanilla has some extra validation/safeguards by virtue of having a known set of registries and registry entries that this doesn't and the objects are actually added to those registry stubs, otherwise same principle