Attributes — Teaching¶
Teachable panels for the Attributes system.
Panels¶
| Panel | Folder | Teaches |
|---|---|---|
AttributesBasicsPanel | HostileConsumers/ | The container on its own: string ids, base values, bounds and clamping, what SetBaseValue actually returns, the two writes it refuses, and the change event's odd creation case. |
AttributesCombinerProvidersPanel | Demos/ | The seam: two complete combiners over identical inputs, providers found up the parent chain, enabled versus inactive, and what a broken provider or a cyclic combiner does. |
AttributesSavePanel | HostileConsumers/ | Persistence: why only base values are saved, and a restore that rewinds rather than merges. |
Where to start¶
AttributesBasicsPanel. Attributes is the smallest system here and the container half fits on one screen — ids, values, bounds, and the fact that nothing combines yet.
Then AttributesCombinerProvidersPanel, and read the first tab before you switch anything. Its default state is the one most likely to cost you an afternoon: providers attached, contributing nothing, because no combiner is wired. That is correct behaviour and it is quiet.
The one thing to take away¶
No combiner means no modifiers. Not "modifiers that add up to zero" — the providers are never consulted at all. RevFramework ships no IAttributeCombiner because how bonuses stack is a decision no framework can take for a game, so until you supply one there is no defined way to apply a contribution and none is collected.
The combiner panel ships two of them, complete, at about a dozen lines each. Copying one is a legitimate way to start.
Where this goes next — the Cookbook¶
The panels teach the container. What the container is for is a bigger argument, and it lives in the Cookbook.
Attributes is the supply side of the framework's stat seams: a general store of named numbers that every other system can read without either side knowing about the other. That makes it the piece that turns RevFramework from a set of systems into a set of primitives — and the Cookbook is where the primitives get assembled into things this framework deliberately does not ship.
Characters & Stats — what a character is made of and what reads those numbers. Every recipe in it requires Attributes — the category and its first recipe arrived in the same commit, because before there was somewhere to keep a character's numbers there was nothing to write. Four are below; the fifth gets its own paragraph.
| Recipe | What it builds |
|---|---|
SumOfParts | A worn ring and a running buff raising the same number, with nothing anywhere applying or removing a bonus. |
HouseRules | Three incompatible stacking rules over one unchanged container — the evidence for why no combiner ships. |
StatToMultiplier | Feeding an attribute into the four stat seams Health and Status Effects already publish. |
RoomToCarry | A slot count that follows a stat and shrinks without eating anything. |
Systems You Own is the one to read if you want the argument rather than the API. Its own opening line lists what it covers: a quest objective, a faction standing, an ability, a spawn director — recognisable gameplay systems RevFramework deliberately does not hold, each built as complete game code from mechanisms that already exist.
WhatStandingMeans is the recipe that sits in both categories, and it is the shortest proof of the point: faction reputation turns out to be one attribute id per faction and a table of names you wrote. There is no reputation system to buy, because there was never one to build.
CountsWhatHappened is the quest-objective one, and worth reading immediately afterwards for the opposite reason — it is the case where the obvious approach is wrong, because "hold ten herbs" is a subscription and a latch, and InventoryDelta is a slot delta rather than a count.
Why there is a Demos/ folder here¶
Demos/ holds panels that have to attach a helper or reconfigure something to teach. Attributes needs one because provider components must exist somewhere on an owner's parent chain before anything can be demonstrated about them — so the combiner panel builds its own owner, attaches providers to it, supplies a combiner, and destroys the lot when it is disabled.
It touches nothing in your scene. It is in Demos/ because of what it does, not because of what it is allowed to reach: see HostileConsumers/README.md for the distinction, which is about evidence rather than quality.
Status¶
All three panels are written and pre-placed. AttributesBasicsPanel and AttributesCombinerProvidersPanel are in Samples/Systems/Attributes/Scenes/00_Attributes_Quickstart; AttributesSavePanel has 01_Attributes_Save to itself, as every system's save panel does. Open either and press Play.
Both scenes put the AttributeSet on the player alongside a StableId. That pairing is what makes an owner saveable — they must share a GameObject, because a capture matches them on the same object.
Notes¶
- Compiles only when both
REV_TEACHABLESandREV_ATTRIBUTES_PRESENTare defined. - Teaching content never ships in a player build: the build guard refuses it while
REV_TEACHABLESis set, which is intended — a debug overlay in a shipped game is always a mistake. AttributesSavePanelmutates live attribute state when you press Restore, and holds its payload in memory rather than writing to disk. Sandbox scenes only.- Attributes ships in Complete only, so these panels are absent from the three SKU packages — along with the system they teach.