Квесты на смену профессии.

Заапдейтился до SVN-594 и начал рассматривать скрипты на смену профессии, тут-же возникли непонятки - берем профу Warriora (квест 401_PathToWarrior) разглядываю сорцы - ситуация прежняя, квест сам по себе есть смены профессии нету (медальку выдают). в тоже время нахожу хтмл data/html/villagemaster/7066-3
.htm в котором вызывается фортовская смена профессии (медальку забирают):

1. <a action="bypass -h forth to_hWarrior">

Получается "мухи отдельно - котлеты отдельно"? зачем мешать форт с жытоном?

Помоему проше в конце выполнения квеста (сразу после выдачи медали) сказать:

1. st.getPlayer().setClassId(1);

(Медальку оставляем плееру на память )

Нет. По контекстсту он идет ко вполне определенному персонажу и тет уже ему меняет профессию.
К тому-же квест может быть закончен раньше появления 20 уровня, а профессия может быть изменена только по достижении 20 уровня.

awarm:

Нет. По контекстсту он идет ко вполне определенному персонажу и тет уже ему меняет профессию.
К тому-же квест может быть закончен раньше появления 20 уровня, а профессия может быть изменена только по достижении 20 уровня.

 

Ясно-понятно. Тогда почему-бы этому NPC (7066:Grand Master Pabris) не быть третьим addTalkId(7066) у квеста 401_PathToWarrior дабы все что касается данной профессии лежало в одном месте?! По моему это более логично...

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

В пользу JBF могу, кроме более простого синтаксиса, добавить только то, что отладка на нём не требует рестарта сервера Ну, это не считая более высокой скорости, которая как раз в этом случае не принципиальна

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

awarm:

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

 

Судя по тому что в них регулярно вносятся изменения - их все-же ктото тестирует. Скорее всего автор скрипта просто не знал метода смены класса у плеера... (кстати вызов st.getPlayer().setClassId(xxx); я не проверял, но судя по сорцам работать должен)

awarm:

Если тебе не нравится тот метод, которым это в данный момент сделан
о, ну так переделай. У нас вроде как это только приветствуется.

 

Не то что-бы совсем не нравится - дело в концептуальном подходе к написанию квестов/скриптов - IMHO скрипт для скрипта должен быть написан в одном стиле и на одном языке.
На счет записаться в девелоперы - скилл программинга на Яве пока никакой. Как почувствую что пора - запишусь.

Balancer:

В пользу JBF могу, кроме более простого синтаксиса, добавить только то, что отладка на нём не требует рестарта сервера Ну, это не считая более высокой скорости, которая как раз в этом случае не принципиальна

 

Более простой синтаксис? Да ну нафиг ;D пишу на куче скриптовых языках и от синтаксиса форта просто тошнит конечно понимаю что такой скриптовый язык интерпретируется/работает на порядки быстрее но это как было сказано выше не принципиально... на счет перезагрузки сервера - бегло просмотрел сорцы на предмет перезагрузки квестов - если в gameserver/model/quest/jython/QuestJython.java добавить что-нибудь типа:

1. public void reload() {
2.     try {
3.         bsf.exec("jython", "quest", 0, 0, "import data");
4.     } catch (Exception e) {
5.         e.printStackTrace();
6.     }
7. }

(на счет класса bsf - его там переинитить/пересоздать наверно придется... не силен я пока в яве.) и вызвать это дело админовской командой не получится-ли у нас релоадилки квестов?

Serge:

конечно понимаю что такой скриптовый язык интерпретируется/работает на порядки быстрее

 

Здрасьте, приехали. Что JBForth, что Jython выполняют скомпилированный код и с исходным ситаксисом ничего общего не имеют

А что до синтаксиса - ну, нравится писать мириады круглых и фигурных скобок и засорять винчестер левыми *.class из Jython - дело хозяйское

А если сюда добавить ситаксис XML, без которого многие нынешние скрипты на Jython не работают - то тут 20 раз нужно подумать о сложности синтаксиса

Balancer:

Здрасьте, приехали. Что JBForth, что Jython выполняют скомпилированный код и с и сходным ситаксисом ничего общего не имеют

 

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

Balancer:

А что до синтаксиса - ну, нравится писать мириады круглых и фигурных скобок и засорять винчестер левыми *.class из Jython - дело хозяйское

 

Да! Да! Да! токо не мириады а то это уже регэксп проверки email-а на спам получится IMO со скобочками код более нагляден... к сожалению в питоновском синтаксисе они отсутствуют. :-( на счет кэширования скомпиленных Жытоновских скриптов - по моему достаточно грамотное решение.

Balancer:

А если сюда добавить синтаксис XML, без которого многие нынешние скрипты на Jyth
on не работают - то тут 20 раз нужно подумать о сложности синтаксиса

 

"сюда" это куда? не попадались скрипты юзающее XML (и слава богу)

Теперь по топику: кто-нибудь из девелоперов может сказать конструкция предложенная в первом посте st.getPlayer().setClassId(1); рабочая? и прототип функции reload() для QuestJython имеет шанс быть заэмплименченным?