Attributes — Core¶

Folder Overview¶

The authored data and the persisted shape: what an attribute row looks like in the inspector, and what a container writes into a save.

Nothing here has behaviour. The state machine that holds values at runtime lives in Internal; the component that fronts it lives in UnityIntegration.

What Lives Here¶

AttributeEntry¶

One authored row: an id, a starting base value, and optional bounds expressed as has-flags plus values — flags rather than nullables because Unity serialises the struct in a list.

The row is honest about bad authoring rather than helpful with it. A blank or duplicate id, or a non-finite value, makes the row inert and reported — never silently repaired. An inverted bound pair (min above max) is ignored as a pair. Rewriting an authored number into a different one behind the inspector's back is the failure mode the sign convention forbids.

AttributeSetSnapshot / AttributeBaseValue¶

What one owner persists: base values only, sorted by id so identical state serialises identically.

Effective values are never persisted — they are functions of contributions and the project's combiner, and their inputs are stored by the systems that own them. Bounds are never persisted — they are authoring-time configuration. No value in a save file is written by more than one participant, which is what makes restore order irrelevant to this system.

Important Notes¶

Bounds may be negative, and so may values¶

The container imposes no sign convention. A debt, a temperature, a signed standing your own layer keeps — all representable. Where Currency's cap rule quietly rewrites a negative bound to zero, this system reports and ignores, and the difference is deliberate: it is stated in the sign-convention section of Documentation/Attributes.

Related Documentation¶

• Attributes Runtime Overview
• Abstractions
• Internal