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

[Jampire]

татата

 

[MYXOMOPX]

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

 

[fromgate]

@MYXOMOPX, офигеть!!!!!!!!!!!

 

[Jampire]

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

 

[ptnk]

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

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

 

[DPOH-VAR]

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

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

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

 

[fromgate]

непонятны потери в производительности (вся эта интерпретация происходит с большими задержками, чем обычный java).

С этим как я понимаю можно быть спокойным. В том смысле, что интепретация не добавит какой-то заметной задержки.
Т.е. если код реализующий какой-либо алгоритм вызывает тормоза на VarScript, то реализуйте этот же алгоритм в Java и получите те же тормоза.
@ptnk, тут момент какой. Если администратор сервера освоит VarScript, то у него не будет вопросов "какой плагин делает то или это?", "каким плагином взорвать курицу?" и т.п. Он просто будет брать и делать.
Конечно можно порекомендовать изучать Java (и это правильно ). Но если писать плагин с нуля на Java, то: во-первых, слишком много чести если нужна какая-то мелкая фишка , во-вторых, нужно разбираться с кучей моментов, отлаживать разного рода ситуации, которые могут вызвать ошибки — фактически программируя под VarScript Вы отдаете обработку этого самому VarScript'у. Ну и опять же упрощение целой кучи моментов: то, что у меня на Java займёт здоровенную процедуру, тут может быть реализовано достаточно просто. И это я ещё не разбирался, а сужу только по описанию.
Т.е. для серверо-держателей VarScript это отличный инструмент.

 

[ptnk]

С этим как я понимаю можно быть спокойным. В том смысле, что интепретация не добавит какой-то заметной задержки.
Т.е. если код реализующий какой-либо алгоритм вызывает тормоза на VarScript, то реализуйте этот же алгоритм в Java и получите те же тормоза.

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

 

[fromgate]

@ptnk, Вы говорите о достаточно малых величинах. Знаете, когда-то было "принято" программировать на ассемблере. Это было реально быстрее. Но появились новые процессоры и.... никто ассемблера нынче не знает. Это осталось всё также быстрее, но...
Здесь такая же ситуация, только языком нижнего уровня является Java, а верхнего - VarScript и задержка вводимая интерпретацией скрипта настолько мала, что ею действительно можно пренебречь.

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

Просто потому что в некоторых случаях одну и ту же вещь на Java можно реализовать с разными эффектом. К примеру, реализовать группировку блоков по чанкам в ScLoad, при помощи банального перебора массива блоков, оказалось в десятки раз быстрее, чем посредством удобной, казалось бы, сортировки при помощи HashMap. При переборе анализ нескольких десятков тысяч блоков занимает столько времени, что можно было даже не заморачиваться выносом всего в отдельную задачу.

 

[DPOH-VAR]

Компиляция даже огромного многокилобайтного скрипта занимает всего 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.
Но на самом деле быстродействия варскрипта вполне достаточно для выполнения многих задач.

 

[ptnk]

@ptnk, Вы говорите о достаточно малых величинах. Знаете, когда-то было "принято" программировать на ассемблере. Это было реально быстрее. Но появились новые процессоры и.... никто ассемблера нынче не знает. Это осталось всё также быстрее, но...
Здесь такая же ситуация, только языком нижнего уровня является Java, а верхнего - VarScript и задержка вводимая интерпретацией скрипта настолько мала, что ею действительно можно пренебречь.

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

Просто потому что в некоторых случаях одну и ту же вещь на Java можно реализовать с разными эффектом. К примеру, реализовать группировку блоков по чанкам в ScLoad, при помощи банального перебора массива блоков, оказалось в десятки раз быстрее, чем посредством удобной, казалось бы, сортировки при помощи HashMap. При переборе анализ нескольких десятков тысяч блоков занимает столько времени, что можно было даже не заморачиваться выносом всего в отдельную задачу.

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

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

...
Но на самом деле быстродействия варскрипта вполне достаточно для выполнения многих задач.

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

 

[fromgate]

@ptnk, я ещё раз повторюсь. Речь идёт о задержках, которыми можно пренебречь. Я к примеру не способен заметить задержку в 1-2 мс. Уверен, Вы - тоже. Ошибочный алогоритм, использование тормознутых методов Java, загрузка канала - вот то, что реально создает лаги и т.п.
Если код будет выполнен на основе анализа текста, то анализ текстового файла тут займёт не так уж и много. Вы же играете в майнкрафт? А он по сути дела написан на интепретируемом языке (компиляцию в джава-код можно считать условной, по сути Java-машина на лету занимается его интепретацией; в джаве нет машинного кода). Да, на c/c++ было бы быстрее. А ещё быстрее было бы на ассемблере.

Как может язык, который компилируется в момент обращения к нему(ну как там это назвать) работать быстрее того языка, который уже скомпилирован?

А это как раз подход к реализации. Я уже несколько раз сталкивался с тем, что быстрый и очевидный код в джаве может исполняться быстрее чем с виду более громоздкий код. Соответственно если интерпретатор эти моменты учитывает, то скрипт написанный одним человеком может вполне выполняться быстрее чем если он тот же алгоритм реализует при помощи Java.

По поводу php, не буду спорить. У меня был сайт на Joomla с небольшим магазином. Все тормоза были не от php, а от того, что у провайдера жадность превалировала над совестью. Смена провайдера на американского решила все тормоза. И если бы я поставил магазин написанный на perl'е или на чем угодно изменений я бы не заметил. Т.е. php полностью решал свою задачу. А за сколько мс выдается текст - за 1 или за 0.1 мне лично плевать: он доставляется мне из штатов за 100 мс. и скоростью выполнения скрипта тут можно пренебречь.

 

[DPOH-VAR]

... Ну там произвести лексический анализ, построить семантическое дерево, потом как-то сгенерировать выходной код (знания посредственные, но во что-то это все дело преобразуется, может в тот же java байт код). В итоге ну не может это работать даже на ровне по скорости- вся эта обработка и разбор будут занимать много времени и чем больше кусок кода - тем страшнее все будет.

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

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

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

 

[ptnk]

@ptnk, я ещё раз повторюсь. Речь идёт о задержках, которыми можно пренебречь. Я к примеру не способен заметить задержку в 1-2 мс. Уверен, Вы - тоже. Ошибочный алогоритм, использование тормознутых методов Java, загрузка канала - вот то, что реально создает лаги и т.п.
Если код будет выполнен на основе анализа текста, то анализ текстового файла тут займёт не так уж и много. Вы же играете в майнкрафт? А он по сути дела написан на интепретируемом языке (компиляцию в джава-код можно считать условной, по сути Java-машина на лету занимается его интепретацией; в джаве нет машинного кода). Да, на c/c++ было бы быстрее. А ещё быстрее было бы на ассемблере.


А это как раз подход к реализации. Я уже несколько раз сталкивался с тем, что быстрый и очевидный код в джаве может исполняться быстрее чем с виду более громоздкий код. Соответственно если интерпретатор эти моменты учитывает, то скрипт написанный одним человеком может вполне выполняться быстрее чем если он тот же алгоритм реализует при помощи Java.

По поводу php, не буду спорить. У меня был сайт на Joomla с небольшим магазином. Все тормоза были не от php, а от того, что у провайдера жадность превалировала над совестью. Смена провайдера на американского решила все тормоза. И если бы я поставил магазин написанный на perl'е или на чем угодно изменений я бы не заметил. Т.е. php полностью решал свою задачу. А за сколько мс выдается текст - за 1 или за 0.1 мне лично плевать: он доставляется мне из штатов за 100 мс. и скоростью выполнения скрипта тут можно пренебречь.

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

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

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

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

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

 

[fromgate]

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

ЦЕЛЫХ 50мс Этого более чем достаточно.

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

Ну если хотите. Как сам майнкрафт. Как баккит. Как все плагины. Это всё кустарное производство

Ну да, что спорить. Вы видите проблему, а я вижу возможности. Мне хотелось бы, что бы эти возможности увидели администраторы серверов (тогда мир майнкрафта будет разнообразнее), ну а "проблема в один тик".... оставим убеждённость в том, что это проблема Вам...
@DPOH-VAR, ктатит, профайлер не предусматривал? Уверен, что реальное время выполнения будет измеряться не в мс, а наносекундах.

 

[ptnk]

ЦЕЛЫХ 50мс Этого более чем достаточно.


Ну если хотите. Как сам майнкрафт. Как баккит. Как все плагины. Это всё кустарное производство

Ну да, что спорить. Вы видите проблему, а я вижу возможности. Мне хотелось бы, что бы эти возможности увидели администраторы серверов (тогда мир майнкрафта будет разнообразнее), ну а "проблема в один тик".... оставим убеждённость в том, что это проблема Вам...

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

 

[DPOH-VAR]

профайлер не предусматривал?

Если только такой:
SYSTIME %%start
<какой-то код>
SYSTIME @START - PRINT
Получаем миллисекунды
Насчет наносекунд - сделаю обязательно. Например NANOTIME

@ptnk
Секунды над курицей изменяются по задержке:
<пишем текст тад курицей>
20 TICKS
<пишем ей другой текст>
Задержка осуществляется с помощью BukkitTask - тут нет ничего страшного или тормозного.

Смотрим далее..
У нас есть набор(HashSet) куриц.
На низком уровне регистрируется EntityDeathEvent и PlayerInteractEvent (их тут всего два)
PlayerInteractEvent:
если у игрока есть специфический предмет с определенными NBT тегами, читаем программу из тега, компилируем и исполняем ее.
Программа, которую мы прочитали швыряет курицу и добавляет ее в HashSet
EntityDeathEvent:
если умершая курица была в HashSet, то взрываем ее и удаляем из набора.

У каждого слушателя есть уже готовая к запуску функция, которую надо только пнуть, чтобы она запустилась. Когда нужно, функция получает пинок и переменную Event в придачу.

Единственное, чего тут действительно много, это объектов BukkitTask в ожидании. Их количество равно количеству куриц. Как только курица сдохла, таски отрубаются в месте с ней. А потом их жрет gc.
Но даже несколько сотен объектов BukkitTask никак не сказываются в плане производительности на моем слабеньком ноутбуке с запущенной IDEA в режиме дебага.

 

[ptnk]

Если только такой:
SYSTIME %%start
<какой-то код>
SYSTIME @start - PRINT
Получаем миллисекунды
Насчет наносекунд - сделаю обязательно. Например NANOTIME

@ptnk
Секунды над курицей изменяются по задержке:
<пишем текст тад курицей>
20 TICKS
<пишем ей другой текст>
Задержка осуществляется с помощью BukkitTask - тут нет ничего страшного или тормозного.

Смотрим далее..
У нас есть набор(HashSet) куриц.
На низком уровне регистрируется EntityDeathEvent и PlayerInteractEvent (их тут всего два)
PlayerInteractEvent:
если у игрока есть специфический предмет с определенными NBT тегами, читаем программу из тега, компилируем и исполняем ее.
Программа, которую мы прочитали швыряет курицу и добавляет ее в HashSet
EntityDeathEvent:
если умершая курица была в HashSet, то взрываем ее и удаляем из набора.

У каждого слушателя есть уже готовая к запуску функция, которую надо только пнуть, чтобы она запустилась. Когда нужно, функция получает пинок и переменную Event в придачу.

Единственное, чего тут действительно много, это объектов BukkitTask в ожидании. Их количество равно количеству куриц. Как только курица сдохла, таски отрубаются в месте с ней. А потом их жрет gc.
Но даже несколько сотен объектов BukkitTask никак не сказываются в плане производительности на моем слабеньком ноутбуке с запущенной IDEA в режиме дебага.

Это все очень интересно и позновательно, но для обычного пользователя это сложно (как и тот же lua на computercraft)
Если хочешь подогреть интерес, то нужна система загрузки\сохранения с сайта и готовая баз скриптов.
Для более продвинутого пользователя, кто может и знает какие-то азы, ну или там цикл просто сможет жахнуть - это покажется интересным.
Для тех, кто знает и пишет плагины, это баловство. Я вот для себя не вижу, где это можно применить. Ведь это тоже самое, но в другой упаковке.

 

[ufes]

Для тех, кто знает и пишет плагины, это баловство. Я вот для себя не вижу, где это можно применить. Ведь это тоже самое, но в другой упаковке.

Мелкие задачи намного удобнее будет реализовать скриптами, чем под каждую делать отдельный плагин. Или например если какой-нибудь эвент сервер, то удобнее для каждой игры написать скрипт, чем делать плагин.

ptnk, тут момент какой. Если администратор сервера освоит VarScript, то у него не будет вопросов "какой плагин делает то или это?", "каким плагином взорвать курицу?" и т.п. Он просто будет брать и делать.
Конечно можно порекомендовать изучать Java (и это правильно ). Но если писать плагин с нуля на Java, то: во-первых, слишком много чести если нужна какая-то мелкая фишка , во-вторых, нужно разбираться с кучей моментов, отлаживать разного рода ситуации, которые могут вызвать ошибки — фактически программируя под VarScript Вы отдаете обработку этого самому VarScript'у. Ну и опять же упрощение целой кучи моментов: то, что у меня на Java займёт здоровенную процедуру, тут может быть реализовано достаточно просто. И это я ещё не разбирался, а сужу только по описанию.
Т.е. для серверо-держателей VarScript это отличный инструмент.

 

[ptnk]

Мелкие задачи намного удобнее будет реализовать скриптами, чем под каждую делать отдельный плагин. Или например если какой-нибудь эвент сервер, то удобнее для каждой игры написать скрипт, чем делать плагин.

Если это маленькие писЮльки, то да, проще воспользовать скрипт в одну строку. Но при этом придется прочитать мануалы, ну или проглядеть, быстренько ознакомится с синтаксисом, найти и узнать как реализуется эта маленькая писюлька и сделать её. Но на данный момент не любую маленькую писюльку ты сделаешь из-за малохой дкоументированости.
Ивенты всякие бывают, а вдруг понадобится разделение команд, подсчёт очков, игровой магазин, вывод очков справа я просто буду умиляться вашим скриптам и вашим приключениям по их отладке. (Или существует нормальный способ, как к этому делу подключиться, поставить точки останова и радоваться?).