Плагин [ADMN/DEV/FUN] VarScript 1.2 - Пишем скрипты на Groovy

Jampire ага, ты абсолютно прав.
я создал свой varscript с наследованием и замыканиями.

Добиваюсь того, чтобы у Админов была возможность быстро создать сценарий игры, или же взять готовый и отредактировать под себя.

Часто бывают случаи, когда есть потребность в небольшом сценарии:
- Пусть игрок в золотых штанах будет неуязвим для мобов, но не для игроков
- Пусть тут ночью каждую минуту спавнится рандомный зомби
- Хочу, чтобы из заряженных криперов выпадали изумруды при каждом ударе.
и т.д.

Найти подходящий плагин можно не всегда, а писать новый - долго и ресурсоемко.
На варскрипте каждая из задач выполняется в несколько строчек.

 

в подпись тебе нужно запихнуть

Похвально, но 90% админов не знают как настроить конфиг плагина)



Но все-же идея плагина просто незаменимая.

 

Новые возможности VarScript

я максимально интегрировал VarScript с Java при помощи рефлексий.

команда REFLECT - создает оболочку с доступом к объекту.
Эта оболочка имеет доступ:
- ко всем полям (в т.ч. статичным)
- ко всем методам (создается вспомогательный объект ReflectRunnable)
Reflect создается автоматически при доступе к полям не-варскриптового объекта

команда CLASS - создает оболочку с доступом к классу (в т.ч. enum)
Она имеет доступ:
- к конструктору (в зависимости от аргумента)
- ко всем статичным полям
- ко всем статичным методам

Примеры использования:

/> ## записываем в переменнуюColor оболочку класса ChatColor
/> "org.bukkit.ChatColor" CLASS %Color
/> @Color.RED "красный текст" S+ PRINT
/> "e" @Color:getByChar "а тут желтый" S+ PRINT

/> ## записываем в переменную ItemStack оболочку класса ItemStack
/> "org.bukkit.inventory.ItemStack" CLASS %Item
/> 7 @Item NEW PRINT

Теперь на варскрипте можно сделать почти всё.

Например, можно вывести в чат содержимое страницы по ссылке:

Код:

"java.net.URL/2" CLASS %%URLC
"org.apache.commons.io.IOUtils" CLASS %%IOUtils
"http://dpohvar.ru/hello.htm" @URLC NEW %%myurl
@myurl:openConnection @IOUtils:toByteArray %%bytes
"READ: " @bytes S+ PRINT

 

А еще столько же админов не разберутся с VarScript с теми же базами. xD.

 

VarScript 0.5.2
Готов планировщик!
позже будет описание.[DOUBLEPOST=1374686310,1374491009][/DOUBLEPOST]Столкнулся с проблемами на этапе компиляции, поэтому оставляю варскрипт таким, какой он сейчас есть.
Он полностью работоспособен благодаря рефлексиям и рабочему уже планировщику
/me ушел читать книгу красного дракона
UPD:
Надо бороться с перфекционизмом! Доделываю этот VS. Иначе он никогда не выйдет в свет...

 

Может ли VarScript сделать так что-бы при 1 заходе на сервер игрок писал определённую команду в чат, если может то выложите скрипт.

 

Запросто!
.\plugins\VarScript\tasks\hello.yml

enabled: true
events:
- BUKKIT PlayerJoinEvent
actions:
- VARSCRIPT @Player:hasPlayedBefore/0 !IF @Player "Всем привет! Я новичок" SAY THEN

 

Кальян.

 

Эффект мерцания сделан именно с помощью него. Дается эффект на 23 тика.
Если ослепить надолго - игрок не увидит всех глюков)[DOUBLEPOST=1375694468,1375646176][/DOUBLEPOST]
Идет подготовка скрипта HellJump
Тестируем быстродействие.
Задача скрипта - в радиусе 30 блоков найти все свободные платформы размером 2x2

Скорость работы каждой операции пишется в миллисекундах.[DOUBLEPOST=1375816402][/DOUBLEPOST]Модули
Модули в варскрипте - это фактически объекты - синглтоны, они загружаются вместе с плагином.
Доступ к модулям осуществляется как к обычным переменным.
Область видимости модулей - runtime (то есть везде)

Вот один из примеров модуля:
файл ./plugins/VarScript/scripts/vs/modules/Select.vs [pastebin] (с комментами)

Этот модуль позволяет положить в стек объект, который мы выделим мышкой.
/> @Select:block 1 EXPLODE - взорвет блок, который выберем.
/> @Select:entity BOLT - ударит молнией моба, на которого нажмем.
Есть короткие алиасы:
@Select:b вместо @Select:block и @Select:e вместо @Select:entity
или для совсем ленивых:
/> sb 1 EXPLODE
/> se BOLT

По умолчанию на выбор дается 10 секунд. Если ничего не выбрано - результат NULL
Узнать, сколько времени дается на выбор:
/> @Select:getTimeout PRINT
установить (пять с половиной секунд)
/> 5.5 @Select:setTimeout

 

Демонстрация модуля ItemScript.
Суть его в том, что в любой предмет можно записать любой сценарий.
В лук записан скрипт для спавна курицы, которая взрывается через 5 секунд или если ее убьют.

 

У меня такое чувство что этот плагин заменит все остальные плагины...

 

Каким же образом он заменит остальные?
Здесь же целые проблемы - нужно разобраться с новым языком, непонятно, как производить отладку, непонятны потери в производительности (вся эта интерпретация происходит с большими задержками, чем обычный java).
Это же только для фана, серьезные вещи здесь будут уступать тем, что написаны на java.

 

Можно заменить все другие плагины, но только в теории

Все верно.
А насчет отладки:
Все возникающие эксепшены пишут причину и место возникновения [строка,символ]
Сейчас можно выводить отладочную информацию в консоль (фиговый вариант, если честно, зато рабочий)
Также я оставил возможность подключения дебаггера, но он будет готов не скоро(если будет вообще)[DOUBLEPOST=1376128780,1376128535][/DOUBLEPOST]Предназначение плагина сейчас такое:
- быстро исполнить любую команду (аналогично essentials)
- побаловаться, повеселиться, взорвать соседа, унизить грифера
- добавить несложный дополнительный функционал, например, предметы с хитрыми абилками.
- Мини-игры (helljump, infection) - можно взять готовый скрипт игры и доработать под себя.

 

Скорость выполнения одного и того же алгоритма на разных языка - различна.
Не знаю, насколько корректное сравнение, но тот же php во много раз медлительнее java.
Сложение двух чисел на java будет происходить быстрее, нежели на VarScript.
А еще же мы не знаем внутреннюю реализацию: сколько там лишних потоков крутится, какая архитектура была выбрана.
Поэтому я считаю, что при большом числе кода, большом количестве обработок плагин на java должен работать быстрее. Ну прямо как с++ vs java, net.

 

Компиляция даже огромного многокилобайтного скрипта занимает всего 1-2 миллисекунды.

На самом деле насчет тормозов - отдельная тема.

Тормоза у меня появились в версии 0.5 из-за смены движка.
Ранее все было по подобию C: компиляция из текста в байт-код, каждая команда кодируется несколькими байтами. Функции располагаются в участках памяти программы, при вызове функции мы прыгаем на нее, оставляя запись в стеке возврата. Ничего сложного.

Теперь реализация ближе к ECMAScript: комиляция происходит из текста в структуру объектов, каждая функция является объектом, при вызове функции - мы создаем новый контекст исполнения, прогоняем его по функции и получаем результат. Да, такие функции дают потерю в производительности. Зато мы получаем много-много новых приемов (наследование, конструкторы, замыкания) - это позволяет построить сложную реализацию меньшим количеством кода.

Например у нас есть массив из 100.000 (ста тысяч) блоков, и мы хотим что-то сделать с ними.
Этот код сработает на ура:
----------------------------------------------------------
BEGIN

@blocks ## цикл, пока массив blocks не пустой​

WHILE

@blocks POP ## вытаскиваем последний блок из массива​

20 SETBLOCKID ## ставим блок стекла​

DROP ## больше нам блок не нужен - выбросили из стека​

REPEAT
----------------------------------------------------------
В сравнении, если ставить блоки в таком цикле - получится быстрее, чем с помощью WorldEdit

А вот этот - сработает в разы медленнее:
----------------------------------------------------------
%SetGlass{ ## объявление функции

20 SETBLOCKID DROP​

}
BEGIN

@blocks ## цикл, пока массив blocks не пустой​

WHILE

@blocks POP ## вытаскиваем последний блок из массива​

SetGlass ## вызов функции SetGlass​

REPEAT
----------------------------------------------------------
Следующий - тоже медленнее первого, зато очень изящный подход:
----------------------------------------------------------
@blocks:{ ## цикл по каждому элементу из block

20 SETBLOCKID​

} DROP
----------------------------------------------------------
При вызове функции задержка мизерная, но в цикле на 100000 элементов она уже сильно заметна.

А рефлексии...
ME HP примерно в 2-3 раз быстрее, чем ME:getHealth
Все из за алгоритма поиска рефлексии.
Если же импортировать метод в переменную
"org.bukkit.entity.Player" CLASS %Player
@Player.getHealth %getHP
А потом вызвать этот метод для игрока:
@getHP ME APPLY
Скорость исполнения будет аналогична варианту ME HP

Итого имеем:
Хотите отличной производительности - пишите свой код на Java.
Но на самом деле быстродействия варскрипта вполне достаточно для выполнения многих задач.

 

Разница в таких языках по сравнению с нормальными может достигать сотни раз (я и привел php в пример). Все, что дополнительно интерпретируется работать быстрее не может. А здесь куча дополнительной нагрузки.
Как там реализовано ядро сервера? Приоритетная очередь событий, очередь заданий(тасков)? Каким же образом с помощью дополнительного интерпретатора мы можем ускорить обработку? - Чем меньше количество событий, заданий, чем быстрее они выполняются - тем быстрее работа. А здесь мы получаем некоторые издержки интерпретации, да и еще добавляем свои события и таски, чтобы интерпретированные данные работали в нужный момент.

Как может язык, который компилируется в момент обращения к нему(ну как там это назвать) работать быстрее того языка, который уже скомпилирован? - Ну там произвести лексический анализ, построить семантическое дерево, потом как-то сгенерировать выходной код (знания посредственные, но во что-то это все дело преобразуется, может в тот же java байт код). В итоге ну не может это работать даже на ровне по скорости- вся эта обработка и разбор будут занимать много времени и чем больше кусок кода - тем страшнее все будет.
:3. Вот такое мнение.[DOUBLEPOST=1376133245,1376132856][/DOUBLEPOST]

Я понимаю, что этого достаточно для выполнения многих задач. Но по сути мы меняем одно на другое, хотя и на интересное.

 

У меня все в 100 раз проще.
Нет никакого семантического дерева. А вместо лексического анализа - просто разбиение строки на токены.
На выходе - простая структура.

Читать java код и компилировать его в байткод на самом деле не сложно, есть несколько библиотек, реализующих это. Действительно, производительность будет выше. Но какой в этом смысл? Если хочешь писать на Java - пиши плагин.

К тому же VarScript может цепляться к другим плагинам и паразитировать на них
Например, для некоторой игры, вместо того, чтобы писать свою реализацию управления мобами, я установил плагин ControllableMobs, и передавал ему нужные вызовы.

 

С учетом того, что в майне 50ms на тик (или я не прав?), а тут у нас еще нужно некоторое время на то, чтобы проверить очередь заданий и выполнить их, проверить все шедуллеры на то, что их время еще не пришло, а если пришло то запустить и еще немного подождать. А если плагинов целый вагон, то по времени мы можем даже в минус уйти. Поэтому каждая ms здесь важна.

:3. кустарное производство. Главное, чтобы это приносило некоторое удовольствие и душевный покой.

 

Я вижу проблемы. В последней мини игре такое количество кода и слушателей событий, что мне интересно становится, а почему еще не глючит. Таких арен для мини игры можно поставить несколько штук.
Но вся фишка в том, что это дебагать при разработке я замучался, а тут это непонятно как дебагать.
Ну и получается, что для стабильной работы, чтобы не лагало я смогу таких арен разместить 4 штуки с java, и к примеру на одну меньше с интерпретатором.
и еще не понятно, наскоько будет больше мучения с интерпретатором.