SkBee++
RUEN

⚠️ Область видимости

setVar/getVar работают только как локальный scratch-буфер — не как настоящий мост в остальной скрипт.

setVar/getVar — и Java-хелперы, и Skript-синтаксис — всегда читают и пишут локальную область видимости переменных Skript (Variables.setVariable(..., local=true)).

Что это значит на практике

Это подтверждено прямым стресс-тестом плагина 1.1:

  • Значение, записанное через setVar, не видно через обычный Skript-синтаксис — ни {name} (глобальная область — это совсем другое хранилище), ни {_name} (локальная область, привязанная к собственному циклу выполнения триггера Skript, в котором прямой вызов из плагина не участвует).
  • Значение не переживает завершение того триггера, который его записал. Тест с трёхкратным вызовом накопительного счётчика (/jvtestcombat, счётчик combat_hits_total) показал одно и то же значение при каждом запуске вместо роста 3 → 6 → 9 — каждый вызов получает свежую локальную область.
  • Команда /jvdebug vars выглядит так, будто это опровергает — но нет: она читает из собственного in-process кэша плагина (VariableBridgeTracker), а не из настоящего хранилища переменных Skript, поэтому продолжает показывать последнее когда-либо записанное значение, даже если реальный скрипт прочитать его не может.

Вывод

Сегодня setVar/getVar работают только как временное хранилище внутри выполнения одного скомпилированного блока, а не как мост к остальной части скрипта или между отдельными срабатываниями триггера — несмотря на название.

Что делать сейчас

Если нужен персистентный счётчик или состояние, используйте sender/event для прямого взаимодействия с Bukkit/Skript API (например, PersistentDataContainer сущности или блока) вместо setVar, пока это ограничение не снято отдельным релизом плагина.