00 — Status Basics¶
Goal¶
Learn the basic status flow: build through the registry, apply through the controller, and inspect the active runtime state.
What This Scene Demonstrates¶
The core mental model:
inputs → registry build → controller apply → active runtime state
- A Status Id, Duration, and Magnitude are used to build a real effect through
StatusRegistry. - The built effect is submitted to
StatusEffectController. - The controller applies real runtime rules, including stacking, refresh, replacement, removal, and expiry.
- The Active list shows what actually happened.
The registry creates effects. The controller owns runtime behaviour. The Active list is the source of truth.
What To Look For¶
-
Overview The Applied, Refreshed, Removed, and Expired counters show controller lifecycle events as they happen.
-
Bindings The target must have a
StatusEffectController. The instigator is optional and is used for stored context when present. -
Apply Choose a Status Id, set Duration, set Magnitude, and provide a Source Id. Preflight explains likely blockers before the effect is submitted. Apply builds a real effect through the registry and submits it to the controller. Apply Stub uses the registry stub path, then lets the controller rules decide the outcome.
-
Active Each row is a live controller-owned status instance. The row shows the status id, runtime type, stacking rule, and remaining time bar. +2s extends timed effects when supported. Remove removes the instance through the controller. Context shows the stored
StatusContextfor that active instance.
Read the scene as:
input → registry build / preflight → controller apply → active list and counters
Sample Scope¶
This scene covers:
- Building effects through
StatusRegistry - Applying effects through
StatusEffectController - Inspecting controller-owned active effects
- Watching applied, refreshed, removed, and expired counters
- Checking remaining duration through the Active list
- Extending supported timed effects
- Removing active effects through the controller
- Recomputing potency for active effects
- Storing source context through
StatusContext
This scene does not cover:
- Full combat behaviour
- Full Health integration behaviour
- Visual reactions for every status type
- Movement or cooldown gameplay demonstrations for every status
- Networking implementation
Some statuses may appear in the Active list and tick down without producing a visible gameplay change in this scene. That does not mean the status failed. It means this scene is focused on the status pipeline, not every gameplay system that may respond to a status.
Authority Note¶
This scene may include a permissive sample authority setup for demonstration purposes. Production projects should provide their own authority implementation.
Networking Reminder¶
RevFramework does not include networking. Multiplayer support is the developer’s responsibility.
How To Use¶
- Enter Play Mode.
- Confirm the Target is assigned and has a
StatusEffectController. - Optionally assign an Instigator if you want clearer source attribution in context.
- Choose a Status Id from the Known Ids grid.
- Set Duration.
- Set Magnitude.
- Set Source Id.
- Read the Preflight message.
- Click Apply to build a real effect through
StatusRegistryand submit it to the controller. - Or click Apply Stub to build through the registry stub path and submit that result to the controller.
- Watch the Applied, Refreshed, Removed, and Expired counters.
- Inspect the Active list.
- Use +2s on supported timed effects to extend the active instance.
- Use Remove to remove an active instance through the controller.
- Click Recompute Potency to call the controller potency recompute path for active effects.
Failure Behaviour¶
-
No target is assigned Meaning: the panel has no receiver for status effects. Corrective action: assign a target GameObject with
StatusEffectController. -
Target has no
StatusEffectControllerMeaning: the target cannot own or process active statuses. Corrective action: addStatusEffectControllerto the target. -
Status Id is empty Meaning: the registry has no id to build from. Corrective action: choose a known id from the grid or type a registered id.
-
Registry cannot build the selected id Meaning:
StatusRegistrycould not create an effect for that id. Corrective action: choose a known id or register that status id. -
Blocked by immunity Meaning: the target has an
IStatusImmunityresponse that rejects the status id or tags. Corrective action: remove or change the immunity component, or choose a status the target is not immune to. -
+2s is not supported Meaning: the active effect is not a
TimedStatusEffect. Corrective action: only use +2s on timed effects that support extension.
The Preflight message explains likely blockers before apply. The operation result, Active list, and counters show the actual controller outcome.
Behind The Scenes¶
This panel uses:
StatusRegistry.KnownIdsString()StatusRegistry.TryBuild(...)StatusRegistry.TryBuildStub(...)StatusEffectController.ApplyStatus(...)StatusEffectController.RemoveStatusAt(...)StatusEffectController.RecomputePotencyForAll()StatusEffectController.ActiveStatusEffectController.GetContext(...)StatusEffectController.StatusAppliedStatusEffectController.StatusRefreshedStatusEffectController.StatusRemovedStatusEffectController.StatusExpiredStatusContext.FromAbility(...)IStatusImmunityIStatusMetadataTimedStatusEffect
Key Takeaway¶
Statuses are built through the registry and applied through the controller.
The controller owns the live runtime state, including stacking, refresh, removal, and expiry.
The Active list and event counters show what actually happened.