www.mudconnector.su
https://forum.mudconnector.su/

Синхронизация итп, отделено.
https://forum.mudconnector.su/viewtopic.php?f=14&t=789
Страница 4 из 5

Автор:  KadVar [ Пт дек 26, 2014 1:01 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Kalevala писал(а):
KadVar писал(а):
Т.е. основные преимущества - возможность что-то быстро подкрутить в онлайне без перекомпиляции.
Я почему спрашиваю, когда я еще что-то активно дописывал, я вначале собирал, потом тестировал :),
и только потом ставил на "боевую" версию, т.е. возможность что-то быстро сломать починить
была не так уж востребована :)

Да не "что-то" подкрутить )) у нас на луа уже целый класс написан. Потом добавление умения "стандартным" способом предполагает написание его в коде (Си Си++) затем вы пересобираете мад, запускаете. Бац... хрень вылезла. Вы опять лезете в код, меняете, опять пересобираете, запускаете. Бац еще и.т.д. А тут можно не пересобирать ничего. И тестовую версию отдельно не надо запускать. Ну поставили в скрипте-умении условно говоря фильтр по имени персонажа которым тестируете, чтобы для него работало, а для других нет и ковыряете. Просто? Просто. Быстро? Быстро.

Честно - никогда не страдал от подобных проблем.
Сборка кода на С++ на современных компах почти мгновенна.
Для ДОБАВЛЕНИЯ функционала понимаю в чем небольшие преимущества, а вот для ИЗМЕНЕНИЯ ?
Подкрутил какую-нибудь формулу, ошибся слегка... Бац... и половина тех кто в онлайне сдохла :)
Как-то я "сцу".

Kalevala писал(а):
KadVar писал(а):
Большее удобство реализации чем на С++ если честно не понимаю с чем могло быть связано.

да хотя бы тем, что вам с памятью не надо заморачиваться никак. Да я понимаю, что при наличии прямых рук и на С++ не будет никаких заморочек с памятью, но это у выс они прямые, а у других?

А у кого совсем непрямые, того лучше в движок не пускать "дописывать".
Я к чему... с зонами - нет вопросов. Для движка не вижу существенных плюсов, пытаюсь
понять, может всё-таки есть они...

К слову: какой-то "аккаунтинг" по времени выполнения есть ?
Ну чтобы какой-нибудь track(написанный на луа) не сожрал весь процессор ?


Kalevala писал(а):
KadVar писал(а):
К слову: как решаете проблемы с "мобпрогсами" на lua ?
Конкретно с wait. Его нету просто, или какие-то автопроверки генерятся ?
Объясню проблему, если между действием А и Б есть некий wait и прошло
время, то до начала реализации действия Б хорошо-бы проверить его адекватность.
Чтобы не оказалось, что ситуация реально изменилась (игроки к примеру кого-нибудь
прибили) и действие Б уже будет малоправильным.


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


Т.е. в реальности у вас 99% триггеров без delay ?
Атомарные так сказать ?

Автор:  Kalevala [ Пт дек 26, 2014 1:56 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

KadVar писал(а):

Честно - никогда не страдал от подобных проблем.
Сборка кода на С++ на современных компах почти мгновенна.
Для ДОБАВЛЕНИЯ функционала понимаю в чем небольшие преимущества, а вот для ИЗМЕНЕНИЯ ?
Подкрутил какую-нибудь формулу, ошибся слегка... Бац... и половина тех кто в онлайне сдохла :)
Как-то я "сцу".

Ну это уже вопрос к пряморукости опять же. Как-то особо не страдаем от таких проблем )))
Сборка/разборка/пересборка. Вопрос ЗАЧЕМ? Если можно делать без этого. Нет ну никто не спорит, хотите пересобирайте, мне лично стало гораздо удобнее. Кроме этого есть и другие причины. Ну вот нужно умение изменить, а кодера нет. Зато есть имм с соответствующим доступом. Взял и поменял без всяких пересобираний движков. Возникла у вас необходимость вообще отключить умение. Взяли отключили. Я уж не говорю про игровые ситуации. Допустим нужно вам сделать чтобы в какой-нибудь зоне умение работало лучше, а в другой хуже бац поменяли заработало по другому. Все это можно делать оперативно.

Kalevala писал(а):
А у кого совсем непрямые, того лучше в движок не пускать "дописывать".
Я к чему... с зонами - нет вопросов. Для движка не вижу существенных плюсов, пытаюсь
понять, может всё-таки есть они...
К слову: какой-то "аккаунтинг" по времени выполнения есть ?
Ну чтобы какой-нибудь track(написанный на луа) не сожрал весь процессор ?

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

KadVar писал(а):
Т.е. в реальности у вас 99% триггеров без delay ?
Атомарные так сказать ?


Не совсем понял, что вы имеете в виду. У вас, что все прогсы разнесены по времени что ли?

Автор:  KadVar [ Пт дек 26, 2014 2:37 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Kalevala писал(а):
Не совсем понял, что вы имеете в виду. У вас, что все прогсы разнесены по времени что ли?


Не все, но порядка 50%.
В основном это касается "толкания длинных спичей". Т.е. во-многом косметический эффект.
Т.е. моб когда начинает что-то говорить, то это по-хорошему должно поступать "порциями".
Т.е. он говорит 1 абзац, ждет несколько секунд, затем говорит второй.
Потому как иначе это выглядит немного странно в том смысле, что "по экрану пробегает
дофига надписей мгновенно + что-то меняется".

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

Автор:  Kalevala [ Пт дек 26, 2014 2:51 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

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

Что касается Lua в нем есть библиотека coroutine из хелпа по Lua
Lua поддерживает подпрограммы, эту технологию часто называют общей многопоточностью.
Подпрограмма Lua представляет собой независимый поток выполнения. Несмотря на это, в отличие от потоков в традиционных многопоточных системах, подпрограмма может приостановить свое выполнение только в результате явного вызова функции yield.


Что-то такое наверное можно, но я не копал там глубоко. Пока вроде не требуется.

P.S. Тут подумал в Аладоне такое довольно легко можно реализовать через триггер рэндом и тот же Lua.
Триггер RANDOM срабатывает раз в 4 секунды. Выглядеть будет примерно так: Проверяем переменную шага и переменную времени, если время вышло и номер шага тот, то выводим текст, увеличиваем шаг переустанавливаем время и выходим. Переменная шага просто инкрементный счетчик по номеру абзаца текста, а в переменную времени запоминаем текущее время в секундах. Обе переменных объявляем глобальными на первом шаге например.
Так по идее любые куски текста можно вывести.

Автор:  KadVar [ Пт дек 26, 2014 3:29 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

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

Автор:  Kalevala [ Пт дек 26, 2014 3:33 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

KadVar писал(а):
Да проблема не в реализации wait, я думаю с этим вообще не будет, если запускать саму луа в отдельном потоке.
Проблема в проверках, которые надо делать между действиями.
Я поэтому и спросил, что думал, что возможно у вас есть готовое решение этой проблемы.


А в чем проблема проверок? Завести переменные, да проверять.

Автор:  KadVar [ Пт дек 26, 2014 3:54 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Kalevala писал(а):
А в чем проблема проверок? Завести переменные, да проверять.


Надо как-то автоматизировать процесс.
Иначе не напроверяешься... т.е. в семантике мобпрограммы-на-луа проверок после каждого wait быть не должно,
они должны делаться автоматом. Беглое рассмотрение вопроса дает довольно большой объем частностей.
Это всё проходимо, проходимо вообще всё :), меня интересовало как другие решали такие проблемы. (если решали)

Автор:  Kalevala [ Пт дек 26, 2014 4:06 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

KadVar писал(а):
Надо как-то автоматизировать процесс.
Иначе не напроверяешься... т.е. в семантике мобпрограммы-на-луа проверок после каждого wait быть не должно,
они должны делаться автоматом. Беглое рассмотрение вопроса дает довольно большой объем частностей.
Это всё проходимо, проходимо вообще всё :), меня интересовало как другие решали такие проблемы. (если решали)


Ммм видимо без примеров не обойтись. Что вы подразумеваете под проверками или их отсутствием. Приведите в пример конкретную ситуацию.

Автор:  KadVar [ Пт дек 26, 2014 5:03 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Ну эээ.. схематично

Код:
onReceiveItem = old_sword
  say А спасибо тебе чувак, что ты принес мне мой старый меч
  say Подожди, я сейчас найду для тебя что-нибудь блаблабла
  echo Пожилой кузнец стал копаться под прилавком
  wait 3 second
  say А вот нашел я офигительную хрень
  give хрень player.name


Вот тут, после "wait 3 second" хорошоб проверить, что моб все еще
не в состоянии "дерется с player.name", к примеру :)))
И вручную делать это в том случае, если количество say, к примеру 100
(а бывает и больше, некоторые баллады поют, зарразы :)) как-то не очень хочется.

Очевидно надо проверки на старт проводить и после каждого wait, но чую этого
недостаточно будет...

Автор:  Kalevala [ Пт дек 26, 2014 5:19 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

KadVar писал(а):
Ну эээ.. схематично

Код:
onReceiveItem = old_sword
  say А спасибо тебе чувак, что ты принес мне мой старый меч
  say Подожди, я сейчас найду для тебя что-нибудь блаблабла
  echo Пожилой кузнец стал копаться под прилавком
  wait 3 second
  say А вот нашел я офигительную хрень
  give хрень player.name


Вот тут, после "wait 3 second" хорошоб проверить, что моб все еще
не в состоянии "дерется с player.name", к примеру :)))
И вручную делать это в том случае, если количество say, к примеру 100
(а бывает и больше, некоторые баллады поют, зарразы :)) как-то не очень хочется.

Очевидно надо проверки на старт проводить и после каждого wait, но чую этого
недостаточно будет...


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

Страница 4 из 5 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/