fabric-registry-sync cannot be skipped

[GStefanowich]

I've been receiving a lot of reports from players that use Fabric (Loader) to add custom blocks and items to the game that my mod has been kicking them from their servers after attempting to add my mod to their server.

• Registry remapping failed! CLIENT GStefanowich/MC-Server-Protection#41

My mod is designed to be a server-side only mod, and isn't required clientside. It adds a couple of BlockEntities because BlockEntities can give blocks better interaction with less overhead than a Mixin. For example, creating a CustomChestBlockEntity.class is easier than Mixing into and causing incompatibilities in the ChestBlockEntity.class by just entirely overriding it's functionality.

BlockEntities (in vanilla scenarios) are not synced with the client, because they're only used on the Logical Side.

Many mods rely on Fabric (API) as a Dependency, so it is present on many Fabric servers. fabric-registry-sync-v0 runs a sync between the client and the server upon trying to connect, to gaurantee mod-version compatibility between the two. If any Block / Item / Fluid / or BlockEntity is missing, it kicks the client with a warning.

Because my mod is ServerSide only, the only real fix for this situation currently is to start requiring the mod be installed ClientSide (which I'd like to avoid). Marking Fabric-API as incompatible would be unthinkable.

There doesn't seem to be any way to let my BlockEntities skip this sync'ing process either. From what I gather the sync'ing process only skips Vanilla Registries. If there was a way to mark a Registry Value as to be skipped, that'd be greatly appreciated.

[warjort]

See #1921

Basically not synchronizing modded block entity types could mean the BlockEntityType registry has different entries/raw ids.
The raw id is just a "next number" so it is based on loading/registration order which can be different client/server.
Especially if you have server only mods like you have.
This can cause the wrong BlockEntityType to be deserialized on the client since mc 1.18.0.

They are not synced in vanilla because there are no mod block entity types, so the registries will agree client/server.
The order is just the list of registrations in BlockEntityTypes.

[GStefanowich]

I'm not sure if it's a possible solution, if even possible at all, or sure of how difficult it might be.

Maybe sort the non-sync'ed registry entries at the end of the list? I'm not sure if a BlockEntity was #141 for example, and the client only had up to #139 if it would ignore the ID or throw an IndexOutOfRange.

[Patbox]

Fabric registry sync supports skipping entries if you force it on server level. You could use library like polymer (created by me) to mark these block entity types as server side. Only real issue are BlockState ids, but these can be solved as well (polymer does that too)

[modmuss50]

I did prototype an API to allow server only registry entries that arent synced to the client. At the time I couldnt find a valid usecase, it seems like I should revive that PR as its easy enough to do.

[GStefanowich]

Hadn't even realized that that was a PR (It was over a year ago). Would be an awesome addition, especially since I've been seeing more and more "Server mods"- Not just my own mod.

[VelizarBG]

Now that #3004 is a thing can we please have some API like modmuss' prototype or Patbox's polymer-reg-sync-manipulator submodule where we can prevent a registry entry from being synced to the client so players can join without having it. Personally, I need it because I have a couple custom ArgumentTypes which are used on a sever's datapack but are not needed on the client and players shouldn't have to have them in order to play. Such a feature would be greatly appreciated.