Fabrication

Fabrication

305k Downloads

Config system overhaul

unascribed opened this issue ยท 16 comments

commented

A lot of features in Fabrication would benefit from having even a mote of customizability instead of a simple on/off choice. Additionally, there should be a way to set config options per-world and have options synced from the server.

Due to the way the mixin system in Fabrication works, there's a problem to be had if you have an option set to false and you join a world or server with the value set to true; the mixin is not loaded, and we now have a chicken-and-egg problem if you restart the game to load the mixin; it still won't be loaded because at load time we don't know what the server or world you'll be joining wants the feature set to.

To this end, features.ini should have its three possible values changed to five:

  • Force Off (works as false does now)
  • Prefer Off
  • No Preference (works as unset does now)
  • Prefer On
  • Force On (works as true does now)

On servers, we may additionally want to offer a "Banned" option that forces all unmodified Fabrication clients to disable the feature. Some people have stricter standards and while I don't believe Fabrication contains any unfair features or cheats, others are likely to disagree.

A non-Force value on a global config allows the server or world to override it. No Preference adopts the profile's setting, and a Prefer value will be used as the setting if there is no stronger setting available to override it.

An options.ini should also be added, used as a dumping ground for simple options for features that don't justify having an entire INI file all to themselves. The config GUI should be updated and possibly overhauled to allow for modifying all INIs and using these new features.ini values.

The GUI should also receive a "Reset to default" button for each screen, and the CLIENT/SERVER switcher should become GLOBAL/WORLD or GLOBAL/SERVER depending on if you're in singleplayer or multiplayer. In singleplayer, there should be an option to lock the world options for those prone to cheating.

commented

Banned has been implemented. Splitting server/client configs has not.

commented

A truth table on the new options:

Client Server Result
Force Off anything false
anything Banned false
anything Force Off false
Force On Force Off true
Prefer Off Prefer Off false
Force On Prefer Off true
Prefer On Prefer Off true
No Preference Prefer Off false
Prefer Off Force On true
Force On Force On true
Prefer On Force On true
No Preference Force On true
Prefer Off Prefer On false
Force On Prefer On true
Prefer On Prefer On true
No Preference Prefer On true
Prefer Off No Preference false
No Preference No Preference set by profile
Prefer On No Preference true
Force On No Preference true

Basically, when there is doubt, the client wins, except for Banned on the server. It has to work this way, as Force Off means the mixin is not loaded on the client at all, so the client must get preference.

commented

I suppose we'd want GLOBAL/WORLD for singleplayer, and GLOBAL/CLIENT/SERVER for multiplayer. Hmm.

commented

having just [banned, true, false, unset] on both client and server would make it a lot simpler and i belive still mostly cover the truth table/ functionality
Banned serving as Force off on client and true as both on and prefer on
(may be horribly wrong here tho as am sleep deprived)

commented

"Force Off"'s primary function is to disable mixins that cause a conflict with some other mod you have installed. It's possible a server may want to prevent a mixin from loading, but not prevent their players from using that feature themselves.

Unset's main problem is it's unclear; nobody really knows what it means or does, and some assume that unset is just a funny word for false and therefore true is "set".

commented

I suppose this begs the question; what are some features that you may want to force-off on the server that clients could still enable?

I can't really think of any, honestly. I considered it at first because Fabrication has such a breadth of features it's often safe to assume some edge case is possible.

commented

and even if there are some i fail to see why server cant be set to false and client to true

commented

Right, because you suggested keeping "Banned".

This also fixes the main issue I have with it when testing, which is I tend to turn features off temporarily for demos, and sometimes I leave them off and then I restart my client and can't enable them again until I restart my client again...

commented

image

Mockup of how these options would look in the GUI.

I don't think I'll be working on this right now but I wanted to write down my thoughts on this and start thinking more in detail about how this should work and be approached.

commented

Unset means "mixin on, use profile setting".

commented

unset currently means mixin on but disabled right? (because if it doesn't my suggestion has issues)

commented

How I see your suggested four option system is:

  • Banned: Mixin not loaded, clients on a server cannot enable
  • False: Mixin loaded, feature not enabled
  • Unset: Mixin loaded, use profile setting
  • True: Mixin loaded, feature enabled
commented

But there's not any features you may want to disable the mixin for on the server but still allow clients to enable. All the features like that are stuff that require the client and server to work together, or options that are server-only anyway.

commented

The profiles system probably also needs thinking about. Nobody seems to really understand what it does or why it exists.

commented

which makes my suggestion a issue since its missing mixin off, client can enable
for the server at least

commented

so i think the only one from the original set without a purpose is "Prefer On",
the only thing really to decide is what naming is best
even though it does bother me slightly that theres no neat way to have the same keywords on both client and server in that scenario

What do you think about
Default, On, Off, Unload

With Banned being synonymous with Unload on client