Enchanted

Status: Parked design draft. Not started. Requires Discover → Model →

Verify against real consumer code (Nourished's MarieTooltipHelper) before

• any implementation begins.

#Problem

• TooltipColorRegistry and TooltipMessageRegistry each solve one narrow

• slice of tooltip customization — a flat key/item → color or key/item →

• message map. Real modpack customization requests keep wanting more:

conditional coloring by threshold, hiding a line entirely, matching by item tag instead of just item id, combining a color change and a text change in one rule. Two separate flat-map registries can't express any of that, and bolting more special-case fields onto each one doesn't scale.

#Scope — explicit

• In scope: general rule-based customization of tooltip lines that

• MarieTooltipHelper.getTooltipLines() already generates, for

Marie-registered values on Marie-registered mods. A rule matches a line by value key, item id, or item tag, and transforms it: recolor, replace text, or hide.

Out of scope — vetoed, do not revisit without explicit sign-off:

cross-mod tooltip interception (rewriting Mekanism/Create/AE 2's own tooltips). This was proposed and rejected: text-matching against another mod's tooltip output breaks on translation and formatting changes, and it's fragile by construction. TooltipRuleEngine only ever touches lines Marie

• itself generated.

#Relationship to existing registries

• Replaces TooltipColorRegistry. Recolor becomes one transformer type

among several, not a standalone registry.

• Extends TooltipMessageRegistry. Replace-text becomes another

transformer type; the existing byKey / byItem matching concept carries

forward as matcher types rather than being reinvented.

• Existing tooltip_colors.json / tooltip_messages.json config shape

should have a documented migration path if this ships — not designed yet,

flag as an open question below.

#Proposed shape (draft, not final — subject to Discover/Model/Verify)

Matcher/transformer pattern:

• Matcher — what a rule applies to. One of: value key, item id, item

tag. (Open question: can a rule combine matchers, e.g. "this value key on

this item tag," or is it strictly one matcher per rule?)

• Transformer — what the rule does when matched. One of: recolor,

replace-text, hide-line. Threshold-banded color is a variant of recolor —

different colors for different value ranges, not a separate transformer

type.

• Two-tier source, mirroring the existing pattern: config-folder

(modpack creator, hand-edited) and datapack (higher priority, same

override-stack shape already used by ColorRegistry /

TooltipColorRegistry / TooltipMessageRegistry).

• Explicit modId — rules are scoped to a specific consuming mod's

namespace, not global across all Marie-registered mods sharing a config

folder.

#Discover → Model → Verify plan

1. Discover — read MarieTooltipHelper.getTooltipLines() and the

current TooltipColorRegistry / TooltipMessageRegistry call sites in

Nourished end to end. Extract every responsibility currently baked into

those two registries and their consumers: matching, precedence

resolution, transformation, rendering. List them as separate

responsibilities, not as "what the code currently does in order."

2. Model — design one interface per responsibility identified in

Discover, from first principles, independent of the current

implementation. Likely candidates: a TooltipRuleMatcher contract, a

TooltipLineTransformer contract, a rule-set resolver that owns

precedence (config vs. datapack, specificity ordering), and whatever

currently-implicit line-hiding behavior needs its own explicit contract

rather than being a side effect of an empty replace-text.

3. Verify — confirm TooltipColorRegistry and TooltipMessageRegistry

could both be rebuilt as thin wrappers over the new interfaces, using

only those interfaces and nothing else. If either can't be cleanly

rebuilt this way, the interface split is wrong — go back to Model.

#Open questions (resolve before or during Discover, not invented here)

• Can a single rule use more than one matcher (key + item together), or is

matching strictly single-dimension per rule?

• Migration path for existing tooltip_colors.json / tooltip_messages.json

files if TooltipRuleEngine ships — auto-migrate on first load, manual

migration doc, or permanent coexistence?

• Where does this live — marie-ui (alongside the registries it replaces)

or a new package? Given the marie-ui package cleanup

(geometry/ / component/ / edit/) is already in flight, decide whether

tooltips gets a fourth subfolder or stays where it is.

• @ApiStatus tier on day one — Experimental by default per standing

rule, but confirm no consumer needs it locked sooner.

#Non-goals restated

Do not let this design creep into cross-mod tooltip rewriting. If a future

request wants that, it's a new, separate design — not an extension of this

one.