Modifiers

A modifier is the game's own buff, debuff and state marker system. Stuns, silences, shields, speed boosts, "is in the shop", "is carrying the idol" and the thing that makes a team change actually network are all modifiers. Applying one is a single call, and most of what goes wrong is in the four failure modes at the bottom of this page.

Adding a modifier

The full signature from the official docs:

// every argument after the name is optional
entity.AddModifier("modifier_citadel_stunned", KeyValues3? kv, caster, ability, team);

In practice there are two shapes worth using.

Plain, with your own timer for the duration

// This is the shape to prefer. It needs no extra type, and the duration is exactly
// what you asked for whatever the modifier's own default happens to be.
pawn.AddModifier("modifier_citadel_cursed");
Timer.Once(3000.Milliseconds(), () => {
    try {
        var p = Players.FromSlot(slot)?.GetHeroPawn()?.As<CCitadelPlayerPawn>();
        if (p != null && p.IsValid) p.RemoveModifier("modifier_citadel_cursed");
    } catch { }
});

Re-reading the pawn from the controller inside the timer rather than capturing it is deliberate. Writing to a pawn handle captured earlier is how a Bedwars player once ended up stuck out of the world with no log line to show for it.

With a duration keyvalue

using var kv = new KeyValues3();
kv.SetFloat("duration", 3.0f);
pawn.AddModifier("modifier_citadel_knockdown", kv);

Removing a modifier

entity.RemoveModifier("modifier_citadel_stunned");   // by name
entity.RemoveModifier(modifierRef);                    // by reference

Removing a modifier that is not applied is harmless. That is what makes the timer pattern above safe: if the modifier expired on its own first, your removal is a no-op.

Reading what is applied

entity.ModifierProp.HasModifier("modifier_citadel_cursed");   // bool
entity.ModifierProp.Modifiers;                                // enumerate them all
entity.ModifierProp.SetModifierState(EModifierState.X, true);

Catching a modifier as it is applied

This hook is more useful than it looks, and it is how BattleBox detects a punch without classifying a single melee. A punchable powerup grants a modifier the instant it breaks, so the modifier arriving is the signal that a punch landed.

public override HookResult OnAddModifier(AddModifierEvent args) {
    string name = args.ModifierVData.Name ?? "";
    var owner = args.ModifierProperty.Owner;     // who it is landing on
    // return HookResult.Stop to REFUSE it, so the buff is never actually gained
    return HookResult.Continue;
}

gun_powerup_pickup/near_rejuv                    // hidden proximity aura, radius 300
gun_powerup_pickup/near_rejuv/target_near_item   // the same aura, per target
gun_powerup_pickup/modifier_check_nearby_player_parry
gun_powerup_pickup/gun_powerup_pickup            // THE REWARD, only when it breaks

int sl = name.IndexOf('/');
if (sl > 0 && name.IndexOf('/', sl + 1) < 0) {
    string a = name.Substring(0, sl), b = name.Substring(sl + 1);
    if (a == b && a.EndsWith("_powerup_pickup")) { /* a punch landed */ }
}

From the console, without a plugin

modifier_create modifier_citadel_disarmed

// with a source path, a target and parameters
modifier_create upgrade_capacitor/modifier_weapon_capacitor_slow player {"duration" "5"}

Useful for finding out whether a modifier does what you think before you write any code. Also worth knowing: modifier_dump_list is a real cvar and will list them.

The four ways this fails quietly

Naming rules that save you a test

• _buildup is the pre-cast indicator, not the effect. Applying it does nothing useful.
• _tracker and _desc are UI-only. They are what the HUD reads, not gameplay.
• _self against _enemy is who receives it. Picking the wrong one applies the effect to the wrong side of the interaction.

The ones worth knowing

Grouped by what you would reach for them for. Every name is in the full list below.

Stopping a player doing things

Defence

Movement and stats

State markers you can read instead of computing

These are the cheap way to know something about a player without a per-tick distance check.

The one that is not really a modifier

All 125 names

Scanned out of the install on 2026-04-21. This is a string scan of the game files, so it is complete for names that appear as literal strings and may miss any that are constructed at runtime. A name being here means it exists in the build; it does not promise it does something useful when applied cold.

Verifying a name yourself

The game's own localisation file is the last word on whether a status exists and what it is called in the UI:

grep -n "modifier_citadel_cursed" \
  09_research_log/github_clones/GameTracking-Deadlock/game/citadel/resource/\
localization/citadel_attributes/citadel_attributes_english.txt

// 88:  "modifier_citadel_cursed"    "Cursed"

A name in citadel_attributes_english.txt has a player-visible status. A name that only turns up in a binary string scan exists but may be internal.