Custom Effects

SL_UseSkill cannot cast a skill the character has not learned — Item.TryQuickSlotUse refuses one outright. Without a way to teach invisibly, a mod that fires its own skill must either put it in the player's menu or not work at all.

The learning is vanilla's TryUnlockSkill. Only the display lists are patched; the authoritative knowledge is left alone. So the skill is genuinely learned, castable and networked — it simply is not listed, and skill-limit mods, which count those same display lists, do not see it.

Nothing is persisted: the display lists are rebuilt from scratch every session, which is why uninstalling this library just makes the skill visible again rather than corrupting a save.

Vanilla has no equivalent. SL_Stun is cancelled by almost any state change, and SL_Petrify makes the target count as dead and revivable. Neither gives you a timed removal from the fight that returns the character untouched.

There are no toggles: Duration is the only field.

A weapon VFX like VFXRunicBlade has no position of its own. Its particle systems each carry a VFXParticlesOnWeapon, which does not follow the hand — it takes the weapon's mesh and makes it the particle emission shape.

Two things make it give up, and both are silent. When it gives up, the particle system keeps whatever shape the prefab was authored with and the effect still plays — just in the wrong place and the wrong form, with nothing logged. That fallback looks exactly like a positioning bug, which it is not: no Position, Rotation, ParentMode or Delay can affect it, because position was never the mechanism.

This effect sets those two fields on its own copy of the VFX before the game clones it. Everything else is left to vanilla PlayVFX.

A status effect's transforms hang below StatusManager, which sits a metre above the character's root. A prefab carrying its own vertical offset stacks the two and plays two metres up, with the second metre inside the prefab itself. Nothing is logged and nothing errors; the effect simply plays in the wrong place.

You cannot fix it from stock XML. SL_PlayVFX has no Position field, and ParentMode offers only This and FXWorld — neither anchors to a character. Adding the vanilla VFXPositionOnChar hook does not work either: it answers the broadcast VFXSystem.Play sends and reads the character passed to it, and that character is null here, so it does nothing. This effect places the VFX itself.

Detach solves a separate problem. A VFX near the end of a status forces you to extend the status Lifespan to give it room — and that extends every other effect too. Character gives the VFX its own clock while it keeps riding the character; World leaves it where it stood, for a VFX that marks a place rather than a creature.

Two separate things make a flicker impossible from stock XML:

• Every PlayVFX instantiates its own copy of the prefab and keeps it in a private field. Two effects pointed at the same VFXPrefab therefore produce two independent VFX, and neither can stop the other. Stacking SL_PlayTimedVFX entries at intervals does not pulse one effect — it spawns several, each stopping on its own clock
• VFXSystem.Stop() calls ParticleSystem.Stop() with no arguments, which means StopEmitting. Emission halts, but every particle already in the air lives out its startLifetime first

This effect owns one instance for its whole life and drives it from a single coroutine. HardClear uses StopEmittingAndClear to destroy the live particles rather than let them fade, which is what makes a short blink actually read as a blink.

PulseAt is relative to activation, not to the status. Effect.Delay is applied before the effect activates, so subtract it: a mark at 9.83s on an effect with <Delay>1.15</Delay> is 8.68.

SL_PlaySoundEffect fires and forgets. The audio manager hands back a sound source and the vanilla effect discards it, so there is no handle to stop — which makes the status Lifespan the only control you have over when a sound ends. Extend a Lifespan for any other reason and every sound in the status is dragged along with it.

This plays the sound itself so it can keep that handle. Everything else was checked against the decompiled vanilla effect rather than assumed, so swapping one for the other changes nothing except that it now stops.

A status applied to an AI is owned by the master client, so only the master runs its effects locally. Every other client depends on this:

if (m_statuses.TryGetValue((UID)_statusUID, out status))
    status.OnReceiveActivatedEffects(_affectedCharacter, _activatedEffectsInfos);

The receiving client must already hold that exact status UID — and every application mints a new one, so an announcement that arrives before the status itself is discarded silently.

This acts when the status arrives, which happens reliably on every client, rather than when its effects are announced. Nothing is sent, so nothing can be lost: both clients hold the same XML and replay it themselves. If the announcement does arrive afterwards it is suppressed, so nothing plays twice.

Limits:

• Conditions are evaluated locally: an effect gated on state a remote client cannot read correctly may decide differently there. Avoid EffectConditions on effects you mark
• Timing is per-client: each client times from its own status arrival, so a long sequence can sit tens of milliseconds apart between screens. Invisible for visuals; do not build gameplay on it
• It reports itself in the log — played N visual effects, and (N FAILED) with a warning naming the effect if any throws