-
Notifications
You must be signed in to change notification settings - Fork 9
.rules file End User Documentation
Concrete adds a rules engine for configuration. The engine has a very high level of customization but may have a slight learning curve. This document will explain how the rules engine functions in general. If you're trying to customize a mod's default rules file, it should hopefully document the specifics for that mod.
The primary citizen of your rules file is the rule. The basic building blocks of a rule are predicates and effects, which are whitespace-delimited (predicate and effect names cannot have spaces). A rule whose predicates are matched will have its effects used. Every rule has a weight-based (largest-preferred) priority level to prevent conflict. For example:
5 predA predB -> shebam
This will apply the effect shebam any time both predA and predB are true, unless, of course, a rule with priority higher than 5 disagrees (i.e. applies an effect that contradicts shebam).
There are a few logic predicates native to the rules engine which allow you to compose logic and build more complex rules. Each logic predicate has a special prefix to be attached to the front of a standard predicate:
-
!- Negation. Inverts the output of the following predicate. -
%- Tag. Tags let you combine other predicates with boolean logic. Tags are able to refer to other tags, so make sure to avoid creating infinite loops. See tag section below (not yet written). -
(- Numeric comparisons. You can even add a closing)to make it look pretty. This operator lets you do comparisons against variables provided by the mod's rule engine. Comparisons look like(x>=4)with any of the operators=,>,<,!=,>=, and<=. Refer to the mod's documentation to see what variables are exposed, if any.
Your own rules engine mod will surely provide its own predicates, math variables, or both, that make sense in the context of what that mod is for. Mod-provided predicates might have their own prefixes, and there may or may not also be a default interpretation for non-prefixed predicates. Consult the mod's documentation.
Effects and how they're interpreted are largely up to the mod implementing the rules engine, so refer to the mod's documentation for specific effects. This section will explain general information about how rules are evaluated.
The rules engine supports multiple classes of effects. This may result in mods having some effects that only partially contradict each other or don't contradict each other at all. When a mod has multiple classes of effects, it's helpful to think of the ruleset as being evaluated separately for each class. For example, a rule might match and apply an effect at priority level 5, but a priority level 4 rule might still partially apply, because it has effects that were not contradicted by the priority 5 rule. Your rules engine using mod will hopefully provide no-op rules that you can use to stop lower priority rules from applying a given class of effects.
The built in tags are provided to allow more complex logic for rules. The tag predicates themselves are actually references, and then you have to define the matching tag (though tags can go before or after the rules that use them). A tag definition looks like:
tagname [predicates]
and then can be referenced in a rule or another tag as %tagname. Tags can use both and and or logic. Predicates separated by whitespace form an and group, and predicates or and groups separated by commas or newlines form or groups. For example, D [%A, %B %C] would mean D is true if A is true, or if B and C are both true.