Support Components¶
Small components the Attributes teaching panels attach to objects they build themselves. Not panels, and not part of the Attributes public API.
Components in This Folder¶
| Component | Purpose |
|---|---|
DemoAttributeProvider | One contribution to one attribute — the smallest honest IAttributeModifierProvider. Attached by AttributesCombinerProvidersPanel to the sandbox owner it builds. |
Why It Is A Separate File¶
DemoAttributeProvider is a MonoBehaviour the demo panel adds at runtime, and it lives in its own file named after the class deliberately. A MonoBehaviour declared as a nested type, or in a file whose name does not match, has no MonoScript associated with it — and AddComponent for such a type can fail at runtime with an error that names the file rather than the type, which is a miserable thing to debug.
The combiners in the demo panel are nested classes and that is fine, because IAttributeCombiner is plain C# handed over through SetCombiner. Nothing calls AddComponent for them.
What It Is Deliberately Not¶
It is not a shipped provider, and Attributes does not have one. That is the same decision as the missing combiner: what grants a bonus, and how much, is a project's own vocabulary. This component stands in for whatever does that in your game — an equipped sword, a buff, a perk, a difficulty setting — and the only thing that makes it a demo rather than production code is that its value is typed into the Inspector instead of coming from somewhere real.
The shape is exactly right, and worth copying. Read CollectModifiers and note what it does not do: it appends, and it returns. It does not clear the buffer, because the buffer already holds the contributions of every provider that ran before it and clearing it would silently discard them. It does not read the current value. It does not decide how its number combines with anyone else's — that is the combiner's job, and keeping the two apart is what lets a project change its stacking rules without editing a single provider.