Goal: Move Nourished away from requiring users to manually edit configuration and override files. Configuration should be something players can interact with directly in-game, just like the Dynamic UI editor.
🧠 Overview
The current Nourished configuration system is powerful and flexible, but it still requires users to understand the underlying file structure.
At the moment, users may need to manually navigate through the config folder and work with separate files for things such as:
Classification overrides
Food overrides
Tool overrides
Tips
Exclusions
Custom text
Custom colors
Nutrient values
Other item-specific overrides
This means that even though Nourished provides a lot of customization, the user experience still depends on the player understanding how Nourished stores its data.
The long-term goal is to break away from that workflow.
The configuration files should remain as the underlying storage system, but the player should not have to interact with those files directly for normal configuration.
Instead, Nourished should provide an in-game Dynamic Configuration editor that acts as a visual front-end for the existing configuration and override systems.
🎯 Core Concept
The eventual workflow should be:
Find item in JEI → Drag item into Dynamic Configuration → Edit → Save
The player should be able to take an item directly from JEI and use it as the starting point for configuring that item in Nourished.
For example:
“This food is classified incorrectly.”
Instead of:
Leaving the game
Finding the config folder
Finding the correct override file
Looking up the item's registry ID
Understanding the JSON structure
Adding the correct entry
Saving the file
Reloading
Checking whether it worked
The player should be able to:
Open Dynamic Configuration
Find the food in JEI
Drag it into the editor
Change the classification
Press Save
Continue playing
The underlying data system still does the work, but the player never needs to see the implementation details.
🖥️ Dynamic Configuration
Dynamic Configuration should become its own in-game configuration environment.
This is separate from the Dynamic UI Editor.
Dynamic UI Editor
Controls the presentation of Nourished.
Position
Size
Layout
Text
Icons
Bars
Colors
HUD behavior
Module configuration
Dynamic Configuration
Controls the data and behavior of Nourished.
Nutrient values
Classifications
Food overrides
Tool overrides
Tips
Exclusions
Custom text
Custom colors
Other supported item data
The two systems should remain conceptually separate.
🧬 Endgame Value Editor
The Endgame Value Editor is the larger end goal of Dynamic Configuration.
This is where the system becomes much more powerful than a traditional configuration screen.
The editor should allow an item to become the object being edited rather than forcing the user to navigate through configuration categories.
Basic workflow
JEI
↓
Drag Item
↓
Dynamic Configuration
↓
Edit Values
↓
Preview Changes
↓
Save
The item itself becomes the entry point into its Nourished configuration.
📦 Item Editing
When an item is added to the editor, Nourished should be able to display all of the configuration that applies to that item.
Potential sections include:
Nutrition
Calories
Fruits
Vegetables
Proteins
Grains
Dairy
Future nutrient systems
Other supported nutritional values
Classification
Primary classification
Additional classifications
Source classifications
User overrides
Display
Custom color
Custom text
Custom labels
Tips
Behavior
Excluded from nutrition tracking
Excluded from classification
Other supported behavior overrides
The exact list can grow over time.
The important part is that the editor should be data-driven, rather than requiring a new special-purpose screen every time Nourished gains another configurable property.
🎨 Visual Editing
Where possible, values should be edited visually instead of requiring raw text entry.
Examples:
Color picker for colors
Sliders for numerical values
Toggles for boolean settings
Dropdowns/cycles for classifications
Text fields for custom text
Visual nutrient editors
Item previews
Live previews where practical
The goal is to make configuration understandable without requiring the user to know the underlying data format.
💾 Save System
One of the most important parts of the editor is the Save workflow.
The user should not have to know which file an override belongs in.
Instead:
Edit → Save → Choose Destination
The editor should determine what data needs to be written and place it into the appropriate existing configuration structure.
Potential save destinations could include:
Local configuration
World configuration
Server configuration
Override data
Datapack-based data
Other supported destinations in the future
The exact destinations can be determined as the system develops.
Important principle
The editor should reuse the existing configuration infrastructure wherever possible.
Do not create a second, parallel configuration system simply because the UI is different.
The Dynamic Configuration editor should act as a front-end to the existing data/override architecture.
🔄 Remove the Reload Hassle
A major goal is to eliminate the current:
Edit file → reload → check result
workflow.
If the user changes a value through Dynamic Configuration, the system should be able to apply the change immediately whenever technically possible.
The ideal workflow is:
Edit → Preview → Save → Applied
rather than:
Edit → Save file → Reload → Check
If a specific type of data genuinely cannot be applied immediately, that limitation should be handled explicitly rather than making reloads the default workflow for everything.
🗂️ Existing Override Files
The existing override files should not necessarily disappear.
They are useful as the underlying storage format.
The important change is that users should no longer be required to manually interact with them.
For example, the current system may have separate files for:
food_overridessource_classificationsTool overrides
Tips
Exclusions
Custom text
Custom colors
Other override data
Dynamic Configuration should understand those systems and write the appropriate data automatically.
User-facing model
“I am editing this food.”
Internal model
“This requires a classification override and these nutritional values need to be written to the appropriate configuration structure.”
The second part should happen automatically.
📚 Documentation Philosophy
This should also simplify the documentation.
Currently, documentation needs to explain:
Which file to use
Where the file is located
What the JSON structure looks like
Which registry ID to use
Which properties are available
How overrides interact
When to reload
With Dynamic Configuration, the documentation can instead explain the concept and the editor can handle the implementation.
Manual editing should remain available for advanced users, but it should no longer be the expected workflow for normal users.
🛠️ TODO — Foundation
Define Dynamic Configuration architecture
Determine how Dynamic Configuration opens in-game
Add a dedicated keybind
Define editor window/module layout
Determine how items are added to the editor
Investigate JEI drag-and-drop integration
Define item selection state
Define how an item becomes an editable configuration target
Determine how existing configuration values are resolved
Ensure server configuration takes precedence where appropriate
Ensure existing override layers remain compatible
Avoid creating parallel configuration storage
🛠️ TODO — JEI Integration
Allow items to be dragged from JEI into Dynamic Configuration
Detect dropped items
Resolve the item's registry identity
Load existing Nourished data for the item
Display the item visually in the editor
Show whether the value is default, inherited, or overridden
Allow replacing/removing the current item
Support editing multiple items where practical
Investigate batch editing for future use
🛠️ TODO — Nutrient Editor
Display current nutrient values
Display source of each value
Edit nutrient values
Add sliders where appropriate
Add direct numeric entry where appropriate
Add reset-to-default
Add reset-all
Preview resulting values
Support future nutrient types without rebuilding the entire editor
Integrate future macro-nutrient systems
Ensure nutrient registration and editing use the existing nutrient infrastructure
🛠️ TODO — Classification Editor
Display current classification
Display inherited classifications
Allow classification override
Allow removing an override
Support source classifications
Make classification conflicts understandable
Provide reset-to-default
Save through the existing override system
🛠️ TODO — Food Overrides
Display current food override
Edit food values
Add/remove food overrides
Support all currently available food override properties
Show inherited/default values
Reset individual properties
Reset complete item override
🛠️ TODO — Other Item Properties
Tool overrides
Tips
Exclusions
Custom text
Custom colors
Other currently supported override types
Future configurable properties
The editor should be designed so that adding another configurable property does not require rebuilding the entire system.
🛠️ TODO — Color Editing
Reuse the existing Dynamic UI color-editing infrastructure where appropriate.
Add color editing to Dynamic Configuration
Reuse the existing color picker
Support item-specific colors
Support custom text colors
Preview colors immediately
Save colors through the existing color/configuration system
Reset individual colors
Reset all item colors
🛠️ TODO — Save System
Create unified Save action
Detect which properties were changed
Determine appropriate storage destination
Allow user to select save destination
Write to existing configuration structures
Validate data before writing
Prevent malformed configuration from being written
Provide save confirmation
Handle save failures visibly
Support cancel/discard changes
Add reset functionality
🛠️ TODO — Live Application
Determine which values can be applied immediately
Apply supported changes without reload
Refresh affected Nourished systems
Refresh relevant HUD modules
Refresh cached values where necessary
Ensure client/server synchronization remains correct
Determine what genuinely requires a reload/reconnect
Avoid making reload the default solution
🛠️ TODO — UX
Make the editor understandable without documentation
Clearly distinguish default values from overrides
Clearly show modified values
Add Reset buttons
Add Save/Cancel workflow
Add confirmation for destructive operations where appropriate
Support scrolling
Support resizing
Follow Dynamic UI design language
Reuse MariesLib UI infrastructure
Avoid turning the editor into another giant traditional config window
🧩 Long-Term Goal
The eventual goal is for Nourished configuration to feel less like editing a mod's configuration and more like using an in-game editor.
A player should be able to look at something in their game and think:
“I want to change this.”
Then:
Find it → Edit it → Save it.
They should not have to understand how Nourished stores that information internally.
The configuration files still exist.
The override architecture still exists.
The data still gets stored in the config folder.
But the player interacts with Dynamic Configuration, not the filesystem.
🚀 End State
The ideal Nourished workflow eventually becomes:
Dynamic UI
Customize the interface.
Move it. Resize it. Recolor it. Configure it.
Dynamic Configuration
Customize Nourished's settings.
Open it with a keybind. Change configuration in-game.
Endgame Value Editor
Customize the actual game data.
Take an item from JEI. Drop it into the editor. Change its values. Save it.
And underneath all three is the same philosophy:
The player should be able to configure Nourished without having to fight the configuration system itself.
The filesystem is there for advanced users.
The in-game editors are there for everyone else.