Synchronize Registry-Affecting Configs to Client before Registry Sync

[lcy0x1]

This PR addresses the following problem:

Sometimes modders would like to have a config option to disable certain items in game, or allow users to add more contents that needs to be statically registered. It was not recommended to do it in start up config as it will cause registry desync when server and client has different settings, causing misleading error message. This PR solves the issue by allowing mods to synchronize server-side registry-affecting configs to client, and ask client-side players if they want to apply those configs (and restart) or not.

This PR introduce the following concepts:

• Registry-affecting configs (RAC): It could be an entry in a regular start up config, a custom json, or files of any other format. Reading and writing of those files are not handled by this PR.
• RegistryConfigHandler: It is a handler that is responsible for encoding RACs into JsonElement for synchronization, decoding json, check if client and server have different configs that will cause registry desync or any other problem, and overwrite client config with the server one.
• StartUpRegistryConfigHandler: A template implementation of RegistryConfigHandler for those who use ModConfigSpec start up config.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[KnightMiner]

The problem with configs to remove items is not limited to just syncing to clients for the record. It also notably causes issues with missing mappings as you can change the config option to remove an item that previously existed. With removal of a mod its more clear that it might damage old worlds, but with simply changing a config option that is expected to be more stable.

What is the usecase for conditionally registered items? Every usecase I have seen so far works just as well if you just hide the item when "disabled"

[TelepathicGrunt]

Wouldn’t the feature flag pr technically be usable for hiding items safely?

[lcy0x1]

The problem with configs to remove items is not limited to just syncing to clients for the record. It also notably causes issues with missing mappings as you can change the config option to remove an item that previously existed. With removal of a mod its more clear that it might damage old worlds, but with simply changing a config option that is expected to be more stable.

What is the usecase for conditionally registered items? Every usecase I have seen so far works just as well if you just hide the item when "disabled"

This is not limited to just builtin toml configs. Modders should warn players about the potential issues of changing those configs.

On example use case: I have a mod that have items of a kind that modpack devs would like to add more while they provide textures themselves. Exact logic of those items are provided by datamaps, but it would be cleaner to have those statically defined to have custom texture.

[lcy0x1]

I have already implemented this feature in my mods and tested this PR with my mods.

I just want to have a way to synchronize the data to client and prompt client users if they would like to implement.

[lukebemish]

I have to agree with KnightMiner here -- I can only imagine how often the following would play out with this sort of feature:

• Player makes world
• Player plays on world
• Player joins server on same installation, sees prompt to restart to be able to play on the server, restarts
• Player leaves server and plays on world
• World gets corrupted due to registry entries now missing that were removed on the server-join-and-restart; player is confused

More broadly -- I really dislike the idea of a player playing on a server changing settings locally that affect play outside the server. That seems like a huge source of confusion waiting to happen, all things told. Especially since as far as I can tell there's no mechanism in place here to recover the original client settings later?

[lcy0x1]

I have to agree with KnightMiner here -- I can only imagine how often the following would play out with this sort of feature:

• Player makes world
• Player plays on world
• Player joins server on same installation, sees prompt to restart to be able to play on the server, restarts
• Player leaves server and plays on world
• World gets corrupted due to registry entries now missing that were removed on the server-join-and-restart; player is confused

More broadly -- I really dislike the idea of a player playing on a server changing settings locally that affect play outside the server. That seems like a huge source of confusion waiting to happen, all things told. Especially since as far as I can tell there's no mechanism in place here to recover the original client settings later?

It is to be expected that applying the config from a server would probably corrupt the client world, and player needs to be informed about it.

An instance that player would join a server is usually dedicated for that server, where single player worlds are mostly used to test the server.

Mods that use external resources to affect static registry is already widely used (thingspack, KubeJS, etc). Currently when things doesn’t match it just says registry mismatch and requires player to download newest resources manually. This PR is a feature to allow players to update local resource in one click. Script-like mods should not use this feature for safety reasons.

[lcy0x1]

Is it better for me to create a warning screen to stress that replacing those configs could seriously damage single player saves, and add an option to backup those configs?

[lukebemish]

I think the feature is inherently problematic if this is a risk at all. It's way too easy to do accidentally, and "doing dangerous stuff that will potentially break other worlds" should never be a prerequisite to joining a server, warning screen or no.

[lcy0x1]

I think the feature is inherently problematic if this is a risk at all. It's way too easy to do accidentally, and "doing dangerous stuff that will potentially break other worlds" should never be a prerequisite to joining a server, warning screen or no.

Though this is an actual requirement regardless of this PR. The only difference is that without it players need to manually download files from the server website / group chat, like how they update mods, but with this feature it’s much easier.

[lukebemish]

It is not a requirement without this PR -- generally speaking this sort of stuff is handled by just making an instance for that server, with whatever files in question. Folks don't generally play on their local worlds and a server from the same instance, if the two require different config files. Only with this PR is that something people are at risk of doing.

[lcy0x1]

This PR makes updates to those servers easier, and when players accidentally delete all their configs it allows them to download from server again with ease.

[lukebemish]

Yes; it also adds a very easy way for players to permanently mess up a local world, something players generally expect to not be possible if they're not actually changing any configs themselves or anything.