SkBee++
RUEN

⚠️ Scope Warning

setVar/getVar only work as local scratch storage -- not as a real bridge to the rest of your script.

setVar/getVar — both the Java-side helpers and the Skript-side syntax — always read and write Skript’s local variable scope (Variables.setVariable(..., local=true)).

What this means in practice

Confirmed by direct stress-testing of the 1.1 plugin:

  • A value written via setVar is not visible through plain Skript syntax — neither bare {name} (global scope — an entirely different store) nor {_name} (local scope, tied to Skript’s own trigger execution cycle, which the plugin’s direct API call doesn’t participate in).
  • A value does not survive past the trigger execution that wrote it. A repeated-invocation counter test (/jvtestcombat, a combat_hits_total counter) reported the same accumulated value on every one of three runs instead of increasing 3 → 6 → 9 — each invocation gets a fresh local scope.
  • /jvdebug vars looks like it contradicts this — it doesn’t: it reads from the plugin’s own in-process cache (VariableBridgeTracker), not from Skript’s actual variable storage, so it keeps showing the last value ever written even though a real script can’t retrieve it.

Bottom line

Today, setVar/getVar only work as scratch storage within a single compiled block’s own execution — not as a bridge to the rest of a script, or across separate trigger runs, despite the name.

What to do instead, for now

If you need a persistent counter or piece of state, interact with the Bukkit/Skript API directly via sender/event (for example, an entity’s or block’s PersistentDataContainer) instead of setVar, until this limitation is addressed in a future release.