Sync system

[zeroeightysix]

A feature fiber is still missing is a system to synchronise configurations (merge, check, etc) between server and client.
Feel free to leave design ideas, etc. in the comments.

[quat1024]

In my eyes there are 4 common types of synchronization between elements:

• neither-authoritative, no syncing (debug sysouts, unimportant stuff, etc)
• server-authoritative (gameplay modifiers that clients need to know about, "game rules")
• client-authoritative (cosmetic features)
• both-authoritative, where the config elements must already match between server and client, checked during the handshake (config options that control whether things are registered, config options that aren't reasonable to change w/o restarting)

also:

• basically this means there's 2 config sets on the client, there's the one from the client's config file, and the "effective" one, which is merged with server-authoritative options from the server and is discarded at session end
• does it make sense to completely remove client-authoritative optioms from te dedi server's config file? 🤔

[quat1024]

Thanks falkeron for kicking sense into me lmao, all this can be accomplished with a simple server category for config options that gets cut and pasted onto the client as-is

[quat1024]

After more discussion on Discord:

• Config elements are either syncable or not syncable.
  • Non-syncable client config options do not (need to) appear in the dedicated server's config file.
• Server has authority over the details of constraints for syncable elements.
  • being more specific, the server keeps a collection of rules like "OptionA is not allowed to be more than 5; OptionB can't be more than ten characters long", etc etc.
  • The server can freely change these constraints at any time.
• Two types of client-to-server packets, two types of server-to-client responses.
• One is a "please tell me if this config file is wrong, if so, what constraints does it invalidate?" message
  • payload: the client's config IR, stripped down to only syncable elements
  • response: zero or more of the constraints that are invalidated by this file, which options invalidate them
  • When a client is connected to a server, opens their config UI, and changes a setting, this packet is sent to the server.
  • The client config UI can react by displaying a useful error message like "The server does not allow OptionA > 5"
• The other is a "please coerce this config file into one that does not invalidate any constraints" message
  • payload: the client's config IR, stripped down to only syncable elements
  • response: a new config IR that has been modified to pass all constraints
  • Sent on initial join and also when the client presses OK in their config UI.
  • Client reacts by blindly merging the response into its own config IR, which has the effect of overwriting all syncable elements with whatever the server says they should be.
• Additionally, there's a server-to-client message that just asks the client to send a new "coerce me please" message (sent whenever the server's constraints are changed by a server operator)

[quat1024]

Yet more thinking 🤔 : it would be nice to not have to roundtrip every single time a client wants to know if a config option is valid, duh. This actually greatly simplifies everything ever:

• s->c "here are my constraints"
  • sent on login, sent on an admin using the other packet
• c(operator)->s "set this constraint"

Client just performs in-UI validation/config coercion on its own. This handles cases where the server needs to specifically override a config option by just supplying an equals constraint, which the client happily coerces

[quat1024]

The current constraints system doesn't have something in place for coercing an arbitrary user-supplied value to fit the constraint. This is kind of a tricky thing, and it's important to get right because some level of coercion will happen every time a client connects to a server with rules about what config options can be what, and their config options don't follow the rules.

It's easy to implement for some options, where coercing a number to fit "x < 5" is just min(x, 5), and it's easy to implement for some constraints, where coercing a string to fit "apple" is just setting the string to "apple", but is it always that easy?

[zeroeightysix]

But is it always that easy?

I've actually thought about adding custom constraints written in javascript or lua. It's easy to transmit over a network, (de)serialise, and allows the developer to implement their wildest constraints.

[quat1024]

If you have the name of a constraint mymod:my_constraint attached to a more or less arbitrary json blob, you can just trust the game to load that blob and produce a Constraint object from it.

Including a scripting language is... a bit much?

[zeroeightysix]

Problem is serialisation: one of fiber's features is producing schematics of configurations - how are you going to serialise a custom constraint?

[kvverti]

I see the need for only two or three types of sync:

• Server authoritative: used for server configs. The server is the sole source of truth for these config values and it makes sure clients are always synced. Clients cannot change these config values when connected to a multiplayer server.
• Both authoritative: used for instance configs. Clients must disconnect if any of these config values differ between it and the server.
• Server restricted: used to allow servers to restrict the values of client-only configuration. For example, a server can use this to disable minimaps. This may be better implemented on a case-by-case basis in the mods themselves rather than here.