-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config entry dependencies #195
base: v8
Are you sure you want to change the base?
Conversation
Adding the colour formatting programmatically allows us to use the same text in contexts where we don't want colour
Not functional yet, but can be set on fields
The sub-category implementation is pretty clean, but for some reason the root level needed a whole separate filter, because hidden entries were being added back at the wrong index...
Implement disablement for lists and sub-categories
This comment was marked as outdated.
This comment was marked as outdated.
To allow for having multiple dependencies and non-boolean dependencies, lets store dependencies in the form of a class. This allows any one entry to depend on multiple other entries. **All** dependencies must be met for the entry to be enabled. A dependency can be set to "hide when disabled", if one of the unmet dependencies has this set, the entry is not shown at all. A dependency can have multiple conditions defined, if **any** condition is met the dependency is satisfied.
Static dependency generator methods seem cleaner than having the user construct an object and then run setter methods on it. Similar UX to using builders.
- Move dependency generators to the base `Dependency` class. - Move all dependencies into the same package, to allow constructors to be package-private. - Add javadoc to `Dependency`'s methods.
`SelectionDependency` allows entries to depend on a `SelectionListEntry` being set to a particular value. Multiple condition values can also be set. If any are met the dependency is satisfied. Sub-classes such as `EnumListEntry` are also supported.
Selection/Enum entries can now be dependencies too: selection.dependencies.mp4Multiple condition values can be set, e.g: entryBuilder.startBooleanToggle(Component.literal("I only work when a good option is chosen..."), true)
.setTooltip(Component.literal("Select good or better above"))
.addDependency(Dependency.disabledWhenNotSatisfied(enumDependency,
DependencyDemoEnum.EXCELLENT,
DependencyDemoEnum.GOOD))
.build(); |
Ah, looks good after a primitive check! Thanks for implementing it! |
Also, satisfied -> met.
Untested, but hopefully mostly ok... Need to setup an Autoconfig demo that can be run in-game... TODO: Allow a single field to have multiple dependencies. Config fields can be annotated with `@DependsOn()` which can have the following parameters set: - `value` the i18n key of the field to be depended on - `hiddenWhenNotMet` whether the dependency should cause the dependent entry to become completely hidden - `conditions` an array of condition strings that will be parsed to the appropriate type and compared against the dependency's value.
A wrapper annotation which contains a list of `@DependsOn` annotations. ConfigScreenProvider iterates over each DependsOn and adds multiple dependencies.
Added an initial annotation implementation. I've haven't tested it yet because I couldn't figure out an easy way to run the Autoconfig demo in my debugging environment. No compiler warnings though so fingers crossed... 🤞 EDIT: Figured out I can shift-click the button in mod-menu to open the autoconfig example.
Thanks, looking forward to more detailed feedback when you have time 👍 |
Move most of the implementation into the abstract class `ConfigEntryDependency`
Instead of each config entry having a collection of dependencies, create a new special DependencyGroup that can contain multiple other dependencies. `DependencyGroup` implements `Dependency`, so it can be nested if desired. However, the annotation equivalent (`@DependsOnGroup`) cannot be nested due to annotation design limitations. In other words, Autoconfig can only have one group per field. Conditions are effectively logical operators, allowing for more advanced dependencies. E.g. `ALL` requires all dependencies be met, while `ANY` only requires one-or-more.
56440c4
to
eed9e56
Compare
`DependencyManager` is used to build and setup dependencies in Autoconfig. It needs to keep track of all config entries created/transformed. Made it so that GuiRegistryAccess can have a DependencyManager instance associated with it.
bfc0910
to
47110ca
Compare
Each condition type has its own interface, e.g. Comparative for numeric comparison or Equality for simple `.equals()`, `MultiCondition` for dealing with collections. Additionally, there are interfaces that control how the value is provided. - `StaticCondition` has a constant value - `MatcherCondition` uses the value of another `ConfigEntry` This breaks tooltip generation _again_
This could be used for e.g. comparative checking on numeric list entries
The underlying cloth-config implementation shouldn't need flags
If a dependency has multiple conditions it may make sense to match "all" instead of "any"...
Allow the predicate to take two dissimilar params, e.g. regex Pattern and String. Most of the time, both params will just be the Condition's <T>
Instead of implementing a whole bunch of condition implementations, lets have a single predicate-based condition and move all the complexity into various builders.
Generate tooltips and descriptions when building rather than while rendering
Instead of building a specific implementation of Dependency
They are redundant now that we use builders
Ported the demo from my previous draft PR shedaniel#195
As per #26, it'd be great if config entries could be hidden or disabled when a different config entry is in a certain state. i.e. one depends on the other.
This branch has evolved significantly since initially opening this as a Draft PR. It is becoming a fairly comprehensive dependency system, although that has lead to a few areas that are perhaps overly complex. At the very least there are edge-cases that have had little-to-no testing.
The main usage scenario (any entry depending on a boolean entry) is feature complete, barring any design changes.
Original description
I've begun working on implementing this, it's currently in early stages (hence draft PR) but I was hoping to spark discussion so I don't spend ages implementing things in a way you disagree with or make it difficult to achieve other features you have planned.
Goals:
@EnableIf
and@EnableIfGroup
declare a dependency that will enable/disable the annotated config entry@ShowIf
and@ShowIfGroup
declare a dependency that will show/hide the annotated config entry@EnableIf
or@ShowIf
annotations on a single field will automatically create a group that depends on all of those dependencies.@EnabledWhen
,@DisabledUnless
, etc?List
entries.RegexCondition
class for text-based dependencies?