# FAQ

Frequently asked questions about AP StatusFX Suite.

# Does this require the Gameplay Ability System (GAS)?

No GAS required

AP StatusFX Suite is completely standalone with zero GAS dependency. It uses only core engine modules (GameplayTags, NetCore). If your project already uses GAS, the plugin works alongside it without conflict — they operate on separate systems.

# Does this work in multiplayer?

Built for multiplayer

Yes — multiplayer was the primary design goal. All mutations are server-authoritative. Effects replicate to clients via FastArray delta serialization (the same pattern Fortnite uses for inventory). Late-join clients receive the full current state automatically. Tested with dedicated servers and listen servers.

# Can I use this in a singleplayer game?

Absolutely. The component works identically in singleplayer — just call the Apply/Remove methods directly without needing Server RPCs.

# Do I need to know C++ to use this?

Fully Blueprint accessible

No. 100% of functionality is accessible from Blueprint. Create effect definitions as data assets in the Content Browser, apply effects with a single Blueprint node, and bind events visually. C++ access is available for advanced users who want it.

# How do I create a new effect type?

Right-click in the Content Browser → Miscellaneous → Data Asset → select AP StatusFX Definition. Configure the tag, duration, tick interval, stacking policy, interactions, and immunity — all from the Details panel. No code required.

See Quick Start — Section 4 for a full walkthrough.

# Can designers balance effects without programmer involvement?

Designer-friendly

Yes. Effect definitions are data assets that designers edit directly in the editor. Duration, tick rate, stack limits, interaction rules, and immunity settings are all exposed as editable properties. No recompilation needed.

# How does this handle stacking?

Five built-in policies are available:

Policy	Behavior
None (Refresh)	Resets the timer on reapplication. Stack count stays at 1.
Stack Duration	Each application extends the remaining time.
Stack Intensity	Each application adds a stack (up to MaxStacks). Duration is shared.
Independent Instances	Each application creates a separate tracked instance.
Custom Resolver	Override with your own Blueprint logic via `UAP_StackingResolver`.

See Quick Start — Section 8 for full details.

# Can effects interact with each other?

Yes. Each definition can specify:

Tags it removes on application (e.g., Frozen removes Burning)
Tags that block it from being applied

For more complex interactions with immunity grants, use a DataTable assigned in Project Settings. See Quick Start — Section 9 for setup instructions.

# What about performance with many effects?

Performance-first design

Uses TimerManager handles — no Tick dependency
Only changed effects replicate via delta serialization
Independent stacking has a configurable global cap (default 50) as a safety net
Interaction rule lookup uses a flat TMap for O(1) access per tag

See the Changelog for implementation details.

# Known Limitations in v1.0

v1.0 Known Limitations

Client removal reason — Clients always receive RemovedManually. The specific removal reason is server-only state. Planned fix in v1.1.

Client stack change events — Clients fire OnEffectRefreshed instead of OnEffectStackChanged for stack count changes. Bind both delegates for correct display. Planned fix in v1.1.

OnEffectTick is server-only — TimerManager callbacks don't run on clients. Clients read bIsTicking from snapshots for UI indicators. Client tick simulation planned for v1.1.

AfterPrime Systems — Building the Gameplay Foundation