Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Server Configs, Client Options, and Instance Properties (An argument for why configs should be in Fabric API)

See original GitHub issue

The proposal:

Server Configs are serverside configurations that are synced from the server to the client and are a part of the data pack. These options are reloadable at any time with the data pack. Each mod’s server configs would reside in their data packs, something like this: wander:configs/trees.json5 - This would be the configs for the adjusting configs in the trees category for the mod Wander (File format undecided)
Client Options are clientside options, much like the ones that mojang provides, and belong in the options menus. Fabric API would provide hooks for adding your options in there without breaking other people’s options they add. These options do not require a game or server restart, and can happen live at any time. Each mod would have its options file in an options directory on the client. Ex: options/wander.json5 - an example of an option would be to change sky colors in wander biomes (File format undecided)
Instance Properties are per-instance properties that define registry changes or something that requires a full game restart or a full server restart. Instance Properties are a Fabric Loader function. Each mod would have its properties file in a properties directory in the server and client’s directories. Ex: properties/wander.json5 - an example property would be something like choosing not to register new blocks and use vanilla logs instead (File format undecided). These options are not synced and are intended to ship with modpacks (as Forge configs are today in Forge).

Why configs and options should be in Fabric API:

Configs are part of data packs, fabric loader doesn’t load resources or anything like that
Mods adding options buttons willy-nilly would lead to multiple mods putting buttons in the same place and stuff like that. Having this in Fabric API would keep everything organized and not troublesome.

Issue Analytics

State:
Created 4 years ago
Comments:13 (6 by maintainers)

Top GitHub Comments

1reaction

LemmaEOFcommented, Mar 22, 2019

honestly, the best thing we could do would be to just put config files in datapacks and have ResourceReloadListener to apply them.

0reactions

LemmaEOFcommented, Mar 23, 2019

I’ve made a bit of abstraction in the PR so that you can choose where to get the config file from. Using this with a ResourceReload Listener will make it so you can search through data packs for a config directory. I’d have to make something special for datapack-searching, though, because not every datapack is gonna have the configs for all mods.

Top Results From Across the Web

tutorial:setup [Fabric Wiki]

To make it use the builtin compiler: Open the 'Gradle Settings' dialog from the Gradle tab. Change the 'Build and run using' and...

connection — Fabric documentation

Most Connection parameters honor Invoke-style configuration as well as any applicable SSH config file directives. For example, to end up with a connection ......

9.0 Service Fabric Client REST API Reference - Microsoft Learn

To maintain backward compatibility, the cluster will always support any previously supported api-version. So requests with api-version=1.0 or ...

Configuration settings - Operations Manual - Neo4j

When set to SERVER , client-side routing is short-circuited, and requests will rely on server-side routing (which must be enabled for proper operation,...

Configuration and Method Reference - Rollbar Docs

There are 2 types of configuration data -- context and payload. Context provides information about the environment of the error while payload describes ......