Некоторые трения на тему JBForth в l2j у команды разработчиков.

Возник сабж.

Сперва мои мысли.

Значительная часть l2j требует свного скриптописания. Чего там говорить об этом, если даже официал имеет толстенную скриптовую "псевдоассемблерную" обёртку...

Когда, ещё весной, встал вопрос о скриптах (квесты, скиллы, эвенты, админкоманды и т.п.) то мой выбор однозначно упал в сторону Форта. Аргументы за этот выбор я уже приводил не раз, повторюсь вкратце:
- Лёгкость написания и расширения транслятора
- Высокая скорость
- Удобный синтаксис для интерактивной работы
- Возможность внесения изменений без рестарта системы
- Лёгкость освоения новичками, не имеющими опыта программирования вообще
- Очень высокая скорость написания кода (напомню, что язык был изначально придуман для увеличения производительности программиста на порядок, по сравнению существующими в то время конкурентами)
- Высокий уровень надёжности конечных систем из-за большой простоты интерактивной отладки (обычные средства программирования, как правило, интерактивно отлаживать большую систему не позволяют вообще)
- Простота восприятия готовых решений (правда, при использовании при программировании определённого набора неявных соглашений)

Минусы тоже были:
- Неудобный синтаксис математических выражений
- Трудности восприятия некоторыми программистами, воспитанными на традиционных языках
- Скорость, безусловно, ниже, чем на чистой Java

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

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

Тут возникли два спорных момента.

1. Forth потребовал более тесной интеграции в систему. Уже хотя бы для пресловутого калькулятора вероятности срабатывания Stun'а или Anchor'а, пришлось вставлять заглушки в код. Аналогично - модифицировать функции установки уровня маны и здоровья. Вставлять свои перехватчики попыток unescape или респавна после смерти (для той же тюрьмы). И т.п.

Дальше - требуется больше. Из-за пресловутого отсутствия нормального скриптового языка в раннем l2j, пришлось изобретать совершенно кошмарные калькуляторы и парсеры XML для тех же скиллов и статсов. В результате, сейчас внести какие-то мелочные изменения, требуется в лучшем случае ковырять XML и рестартовать весь сервер, в худшем - мучаться с введением ткучи невнятного кода на Java.

2. Форт, благодаря очень высокой информационной насыщенности кода, сейчас зачастую в одну строчку делает то, что на Java занимает десятки или сотни строк! Пример, который я рискнул реализовать с неделю назад - админкоманды //ride_wyvern и //ride_strider. На Java в старом варианте это выглядит так.

А вот как то же самое реализуется на JBForth (комментарии выброшены):

1. : gm_ride_wyvern    "ride" check-access wyvern player@ ride ;
2. : gm_ride_strider       "ride" check-access strider player@ ride ;
3. : gm_unride         "ride" check-access   player@ unride ;

Вам мало выигрыша в размере? Хорошо, вот вам ещё два плюса:
- Уровень GM-доступа к этим командам в JBF меняется без рестарта сервера
- Команды (не эти конкретно, они персонажные) без дополнительных обработок вызываюстя и из игрового чата, и из telnet, и из htm-файлов.

Вот эти команды я для теста на JBF и перевёл...

...

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

Но это, во-первых, урежет некоторые его возможности, во-вторых, идёт вразрез со многими моими планами. Особенно касающихся продвижения работы над скиллами, итемами активно меняющими те, или иные параметры персонажей и т.п.

Так что, если вопрос тесной интеграци JBF встанет жёстко, то мне однозначно придётся форкать проект. Даже если сделать отключаемым Форт, то что, скажите, делать с введением, например, Форт-кода в XML-данные части скиллов? Опять вводить кучу фактически дублирующих друг друга кусков?

Но форк в такой ситуации - это дело весьма плохое для всех сторон.

К сожалению, моего языкового уровня не хватит, чтобы донести все вышеприведённые аргмументы до основной, англоязычной части команды, так что я сформулировал свои мысли и примеры тут, а Juokelis попробует донести их до основной команды а сюда поместить их мысли

я не разработчик но в копилку напишу,
согласен со всеми плюсами, особенно:
- Лёгкость освоения новичками, не имеющими опыта программирования вообще

о всей обстановке судить не могу так как плотно с кодом l2j не занимался, нооооо вижу что с фортом работать легко и достаточно удобно.

а какие аргументы были предъявлены против форта?
мб он отъедает много системных ресурсов?
или их смущают "лишние" строки кода реализующие сцепки с фортом?

Ой ой какая миссия на меня ... мне уже и так голова от этого трещит ...
Дело в том чо я за Форт, но:
- Никто из команды не хочет к нему касатса ... так как дел и на Джаве хватает ...
- Так как никто в него не углубляетса - никно не может править ошибки или "дыды" Форта ...
- Чо та еще ... ну короче все кричат зделай отключаемым ...
- Я сам не знаю ... может так и проще, но всетаки ... есть команда .. надо найти какоето общее решение :/

Я сам не програмер и могу токо судить из своей башни, и братса за Форт точно не буду, но кого нибуть принудить к этому тоже неудастса ... так что надо или комуто из команды програмеров очень твердо показать все плюсы Форта или всетаки работать по правилам команды, с чем пока Баланцеру не по пути

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

BLaS:

а какие аргументы были предъявлены против форта?

 

Из того, что донесли до меня:
- no one knows forth, i hate forth lol
...
- i hate forth
...
- no one in the dev team likes it, only Balancer

А, вот, собственно, главное, ИМХО:
- because atm we are soo angry with all the forth bugs/ errors we have, and maybe exploit, and its quite pointless if only one person knows it! the other dev when asked questions about the forth bugs willl look like a fool, because we dont know it
now, his added it to everything
thats really bad
because everyone is kinda angry with all this forth stuff, and am sure when Age comes back he will tell Balancer to either make it an option (turn off or on)
or
remove it all

Причина, выходит, одна. Другие слены команды не знают Форта и поэтому не хотят его внедрения в основной код. В принципе, я их в какой-то степени понимаю, но... Блин, я из-за l2j выучил Java! Это было куда сложнее, ИМХО

Juokelis:

Никто из команды не хочет к нему касатса ... так как дел и на Джаве хватает ...

 

В том-то и прикол, что Форт мог бы очень облегчить жизни на Java Т.к. многие вещи на нём делаются несравнимо проще. Ибо это не язык, а метаязык, для написания проблемно-ориентированных задач. И язык, написанный специельно для l2j, на многих задачах будет куда эффективнее, чем универсальная java.

>- Так как никто в него не углубляетса - никно не может править ошибки или "дыды" Форта

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

>Я сам не знаю ... может так и проще, но всетаки ... есть команда .. надо найти какоето общее решение :/

Вот я не представляю пока, какое. Скажем, взять мою идею с прикруткой кусочков Форт-кода в XML на обработку скиллов. Если реализовать этот вариант - то одним отключением Форта не обойдёшься. Перестанут работать все скиллы. Это же не мой каприз "не хотите Форт - я с вами не дружу". Когда такая проблема возникла весной, я просто начал делать Форт параллельно, не трогая основной код сколько было возможно. Но сейчас всё чаще начинаю упираться в необходимость такого встраивания.

Делать всё на Java? Ну хорошо, вот реальный пример. Сколько месяцев люди жаловались на неработающий Stun? В конце концов меня уже достали этим. Полез, разобрался в калькуляторе (поверьте, изучить Форт, ИМХО, намного проще, чем понять хотя бы логику того, кто этот калькулятор проектировал). Встроил туда отключаемую (слава Богу, тут это было возможно) возможность расчёта вероятностей на Форте.

После первой же перезагрузки основного сервера, на организованном под это дело турнире, в несколько попыток подобрал коэффициенты. Потом исправлял и снова подбирал формулы. Всё это - без перезагрузок, на лету. Долбит вони мага, а Stun непропорционально проходит. Меняю число, //jbf_reload, а они даже не прекращают боя. Но коэффициенты уже другие.

Напомнить, как бы этот процесс отладки шёл на Java? меняем код, компилируем, обновляем сервер, перезапускаем его... И так - раз 10..15... Ну-ну.

>Или же дружно написать красивый мануальчик - не то что команды там или чтото очень большого, но практический гид как там все, как сним работать, принципы и т.д. Но именно самим описать а не ссылки на всякие страницы кидать

Вполне. Но - на русском. Впрочем, многое итак уже на форуме есть. Увольте, но рассуждать хоть сколь-нибудь абстрактно на английском - это не ко мне

Ех ребята .. вот так и бывает ... т.е. я думаю выкрутимся ...

А пока иду пиво пить ... вернетса "вождь" в четверг - обновим разговор (надеюсь вживой) английско-русско-джаво-фортхски

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

Полного мануала не будет, хотя бы потому, что мне новые возможности проще вводить, чем писать развёрнутый по ним материал, но начну что смогу - http://la2.balancer.ru/wiki/index.php/JBForth

(одно жалко, на документацию придётся тратить время, которое мог бы на разработку потратить )

перевод части треда с девелоперского форума:

все сводиться к тому. что последние три дня они мучаються пытаясь избаваиться от багов в жбфорте, который заваливает консоль и таблицу character_quests эксцепшенами и переменными, убивает скилы в сервере вешая свои обработчики(угу, в конфигах переменная похоже неправильно отрабатывается) и т.п.
т.к. кроме тебя в этом никто не разбирается - приходиться убивать кучу времени в поисках дыры, откуда эти баги посыпались, и было бы не плохо еслиб по-дефолту все фишки вроде анонсов о входе/выходе игроков на сервер, тестовые хендлеры скилов, админ команды/юзер команды и другие кастомные места вносящие серьезные изменения или потенциальные уязвимости были отключены, в идеале вообще чтоб форт был отключаемым( хотя, у меня на нем примочки для Орфен сделаны)

 

от себя - включать по-дефолту какие-то фишки - нехорошая тенденция (вспомним те же анонсы, прокат виверн у пет-менеджера, переименование чаров, смена пароля из .help)
однажды так уже накололся с татушками у Drunkard Borys - какой-то умник сунул ему татушки по смешным ценам, пришлось очень много времени убить на вычищение и откатывание отделных игроков, а это убивает репутацию сервера, та же история с примерочной - включена по-дефолту - извольте получить кучу читов

по-поводу оффа - там на скриптах только АИ частично реализован, то есть пре/постобработчики, реакция на атаку и т.п. в основном в код зашита

>заваливает консоль и таблицу character_quests эксцепшенами и переменными

Про консоль - было исправлено дня три уже назад. Таблица character_quests - максимально подходит для хранения пользовтельских переменных. Заводить две идентичных таблицы? Может быть тогда и character_items опять разобъём на character_inventory, character_warehouse, clan_warehouse и т.п.?

>убивает скилы в сервере вешая свои обработчики(угу, в конфигах переменная похоже неправильно отрабатывается) и т.п.

Хм. Скиллы вообще никак не должны обрабатываться, а датапаке кода такого нет. Если про вероятность - то проверял неоднократно, что к чему. К тому же, эта переменная - чистейшая Java...

>и было бы не плохо еслиб по-дефолту все фишки вроде анонсов о входе/выходе игроков на сервер

Дня четыре, как по дефолту отключено. Однако, сборки с датапаками обновлять одновременно нужно.

>админ команды/юзер команды

Это - один из спорных вопросов выше.

>и другие кастомные места вносящие серьезные изменения или потенциальные уязвимости были отключены, в идеале вообще чтоб форт был отключаемым

Ну и будет тогда у них сборка без Форта. Вообще.

>от себя - включать по-дефолту какие-то фишки - нехорошая тенденция (вспомним те же анонсы

Ещё раз. Пока анонсы были неотключаемыми из конфигов - по дефолту они были выброшены прямо из Форт-кода входа/выхода игроков.

> прокат виверн у пет-менеджера, переименование чаров

Тут - согласен. Моё непонимание политки команды. Опциональность сей фичи была сделана уже едва ли не месяц назад, сразу, как я ввёл слова для дописи информации к диалогам NPC.

> смена пароля из .help)

Что, это тоже отключаемым делать?? Ну так, госсподи, поменять users/main.f - для этого даже перезапуск сервера не нужен. Ну чисто дети... Что, поиск по "password" по файлам запустить сложно??

>однажды так уже накололся с татушками у Drunkard Borys - какой-то умник сунул ему татушки по смешным ценам, пришлось очень много времени убить на вычищение и откатывание отделных игроков, а это убивает репутацию сервера, та же история с примерочной - включена по-дефолту - извольте получить кучу читов

Ещё вспомним теперь, кто отключение этой функции в код добавлял... Почему-то я кипиш об этом не поднимал...

В общем, не вижу я никакой заинтересованности команды l2j в упрощении им же жизни. Ну так пусть как хотят...

zabbix:

по-поводу оффа - там на скриптах только АИ частично реализован, то есть пре/постобработчики, реакция на атаку и т.п. в основном в код зашита

 

Ну так а я что предлагаю? Полностью, что ли, весь сервер на Форт переписывать?? Нет, мне бы хватило, например, на каждый скилл повесить по куску кода активации/деактивации скилла... И Java-код сразу бы облегчился ещё на несколько сот строк, я уже не говорю про общее улучшение понятности системы и лёгкость введения новых эффектов от скиллов.

ну так скилы сейчас в .xml+жаба прописаны, проблема их отладки на датапак-теам, если он не хотят(и не будут) переписывать скилы на jbforth - зачем их мучать 8)

ЗЫ, Лично мне скрипты только для ai нужны А то к чему там прикручен форт - была пустая трата времени, ибо то, что на жабе там сейчас накатано - ни в какие ворота не лезет, и даже из форта не исправишь, текущая система фш просто не справляется со своими задачами

zabbix:

ибо то, что на жабе там сейчас накатано - ни в какие ворота не лезет, и даже из форта не исправишь, текущая система фш просто не справляется со своими задачами

 

Именно так. У меня к серверу две больших (нет, ОГРОМНЫХ) претензии - это его AI (вообще, имеющийся механизм эвентов чаров) и его калькулятор (скиллы, статсы, эффекты оружия, тату, модификаторы свойств персонажа...)

Если про причины, побудившие создать такой AI ничего сказать не могу, то калькулятор - это именно неудачная попытка хоть как-то сделать внешнее (читай - _скриптовое_) управление параметрами. То, с чем несравнимо изящнее мог бы справиться JBForth.

чувствую опять дороги SF и Bala разойдутся и в конце концов Bal приведет сервак в тот вид который он хочет и SF опять обратит на него внимание... если чесно я за Bala - но помочь нечем не могу

Вставлю и свои пять копеек.
Тут спорная ситуация. Лично для меня Форт - кошмар просто. Не потому, что я его не знаю или не хочу изучать, а потому что у меня нет времени его изучать. Основная работа, работа над нашим сервером отнимает все время. И не один я такой.
Но с другой стороны, я понимаю все плюсы Форта и не могу не согласиться с Балансером, что некоторые вещи удобнее и быстрее делать именно с его помощью.
Для меня, например, jython - наиболее приемлемый вариант. Для кого-то forth. Почему бы не оставить и то и другое? Да, были баги/глюки от Форта, но это же не смертельно, согласитесь.

тоже встряну

плюсы форта есть, но в наше ламерское время - эти плюсы не востребованы.
и изящность фортовских формул могут оценить слишком немногие.

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

явский код легко понятен многим, пусть и некрасиво пишется.
на текущий момент это imho большее достоинство чем красота формул форта.

P.S. Бал, а может таки подумаешь на предмет миграции на другой скриптовый
язык с той-же степенью интеграции в движок что и форт? не думаю, что будут возражать против
beanshell в движке - он как/никак в следующем релизе явы обещает стать встроенным скриптовым языком.

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

Один вопрос. BS может отпарсить и выполнить вырожение из строки? Аналог функций eval в PHP и Perl? Для скриптописания, особенно эвентов и для активного руления игроками - штука очень нужная.

>Бал, а может таки подумаешь на предмет миграции на другой скриптовый
язык с той-же степенью интеграции в движок что и форт?

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

И вот опять, вводят ГМ-команды, на написание которых на JBForth вместо десятков строк Java уходят считанные строки. Опять кому-то рестартовать сервер ради их введения... То же переименование игроков, что сейчас ввели. Мало того, что давным-давно работает на Форте "вручную":
//"NewName" player@ target@ player_rename
Так ещё и описать такое слово всегда можно так:
: gm_setname "edit-player" check-access player@ target@ player_rename ;
Всё, //jbf_reload и слово работает. И уровень доступа к нему динамически менять можно...

На beanshell так можно?

BeanShell - Lightweight Scripting for Java - посмотри.

насколько я понимаю - eval есть практически во всех скриптовых языках.
не думаю что bsh исключение.

просто на форт у меня времени точно не хватит, а вот скрипты на bsh без проблем
и писать и отлаживать.

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

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

>насчет скорости - не думаю что это имеет такое значение.

Имеет. Одно дело квест отрабатывать, другое - скиллы просчитывать. Второе используется на пару порядков чаще и на загруженной машине может стать серьёзной нагрузкой.

>хотя надо посмотреть - возможно bsh может свои скрипты компилить в обычный код, как это делает jsp.

Jython компилируется в байткод. В чистую Java. Вообще, пока не измерил, думал он из-за этого Форт порвёт. Оказалось (по ранним тестам, сейчас - не знаю, надо будет снова побенчить), что JBF в 2..3 раза быстрее на рекурсивныз вычислительных задачах (расчёт чисел Фибоначчи), которые для Форта самые невыгодные

...

А теперь - вопрос на засыпку. Я думаю, что из разработчиков не я один не знаю Beanshell. Так чем BS изучать проще, чем JBF?

И, в любом случае. JBF уже есть. Уже работает в полном объёме. На нём уже пишутся работоспособные квесты, эвенты, команды администратора и пользователя и т.п.

На BeanShell это всё ещё предстоит писать.

Игра стоит свеч?

Или это только каприз группы разработчиков?

BeanShell - Introduction - краткий перечень возможностей.

Бал, пойми меня правильно - ты молодец и с фортом и скриптами и кучей времени
которое на это тратишь. но одному это делать наного сложнее чем толпой.

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

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

Будет, будет, будет... Я это уже скоро год слышу! Сперва "будет новый квестовй движок от [тут несколько вариантов имён в разное время]". Потом - "будет скриптовый движок". Теперь - "будет новый скриптовый движок"... А JBF тем временем просто работает. И работает быстро и эффективно.

Где обещанное ещё год назад исполнение кода, записанное в данных скиллов? Вместо него - идиотский калькулятор. А на Форте этот код мог работать ещё прошлой весной...

Пока я вижу только что лень некоторых из программеров серьёзно тормозит развитие проекта. Чтобы начать программировать на Форте - не нужно изучать ничего нового. Достаточно понять несколько принципов, укладывающихся в сжатом виде в несколько абзацев. Вон, посмотри на BLaS'а. Человек - вообще не программист. А ему одних только примеров кода хватило, чтобы научиться самому программировать и, более того, начать уже мне помогать с документацией на Wiki.

Бал, фишка в том, что ты знаешь beanshell. и все разработчики l2j его знают.
там чистая ява. только скриптовая.

насчет каприза - согласен. но imho если-б на уровне форта был интегрирован beanshell -
оно-б окупилось тем, что добавилась-бы полностью скриптовая ява в дополнении к компилированной.
и перестали-б всякую фигню в классы компилировать.

там дел-то

$ wget http://www.beanshell.org/bsh-2.0b4.jar
$ java -jar bsh-2.0b4.jar

дальше появится GUI обвязка на которой сразу можно пробовать.


выкачай его, не пожалей получаса на посмотреть.