Временные тонкости НвН1, назад в будущее Опции

[Existor]

Проблема такова:
По необъяснимой причине время встает на определенной временной отметке и сдвигаться не собирается. Сам по себе вызов дм команды "dm_settime" сдвигает часы сразу на сутки, а часы за вычетом 1-2 часов(с этими нюансами пока что не было времени плотно разобраться, просто примерно так) от заданного смещения. Изменение часов с помощью скриптовых команд так же двигают сутки, оставляя час неизменным.
Запуск сервера на моей локальной машине с измененым временем стартайма ранее давал положительный результат, но на сервере все снова вставало на круги своя. После моих попыток разобраться с проблемой и решить ее различными методами, смена стартайма прекратила как-то влиять на зависание времени и на моей локальной машине.
На сервере ранее использовался механизм реального времени, основаный на восстановлении текущего времени из базы мускула. Теперь по некоторым причинам мускул отрублен, поэтому используется стандартная база нвн.
Механизм восстановления времени отлажен, ошибок и зацикливаний в нем нет. Врубание\отрубание системы рестора времени влияния не оказывает - время стабильно виснет.
Версия: 1.67
Размер модуля: 50+мб(разбить, чтоли?)

Вот такие пироги...
Кто встречался с подобным и как разруливал данную ситуацию?

[Lexey aka Hawk]

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

[Existor]

Я пробовал написать свой счетчик, но проблема в том, что изменение скриптами текущего часа смещает сутки. Бред какой-то.
Если не трудно, секретно и проч, не могли бы вы привести исходный код "своего счетчика времени"?
Такое ощущение, что система времени просто сошла с ума.

Пока что попробую облегчить модуль в плане веса и вычислительной загрузки. О результатах сообщу.

Сообщение отредактировал Existor - Feb 1 2007, 12:44

[Lexey aka Hawk]

А не надо смещать счетчик времени. Надо вообще СВОЙ писать. 1 тик - 6 секунд реального времени, игровой час на дефолтных установках 2 минуты реального времени или 20 тиков (битов).

[Existor]

А не надо смещать счетчик времени. Надо вообще СВОЙ писать. 1 тик - 6 секунд реального времени, игровой час на дефолтных установках 2 минуты реального времени или 20 тиков (битов).

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

На облегчение модуль не реагирует. Значит, есть основание полагать, что повредилось что-то в текущем модуле, поскольку остальные работают со временем нормально.
Я в ужосе.
Сча буду экспортить модуль в ерф и импортить его в новый модуль, который до этого работал со временем безошибочно. Часов 6 блокировки компьютера насмарку ради эксперемента...

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

Сообщение отредактировал Existor - Feb 1 2007, 14:49

[denis0k]

На старом модуле гема был такой баг. У нас ночью в Лускане был респ бандитов, днем стражи (доброй ессно (IMG:style_emoticons/kolobok_light/smile.gif) ). Частенько время тормозило и были полярные ночи и дни. Скриптовой спавнер видел то же, что и игрок, днем бандитов никогда не было. Но когда время размораживалось, оно прыгало не на следующий час, а сразу фик знает куда. Походу оно не течет в фоне, а считается от аптайма сервера.

[Existor]

Ну и как решали проблему?

[Zik]

К сожалению незнаю конкретики, но ИМХО нехватка ресурсов машины, у нас было точно такое, когда хостились на одном серваке параллельно с еще 2-мя шардами и еще чем то. Переехали на отдельный серв- все стало нормально без изменений в модуле...

[Existor]

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

На дуалкоре с 1гб 667 оператвы время спокойненько тикает.
Мда.

Сообщение отредактировал Existor - Feb 2 2007, 11:40

[denis0k]

Ну и как решали проблему?

Да никак (IMG:style_emoticons/kolobok_light/smile.gif) Ща новый модуль стоит, технически посильнее первого на порядок, но вроде все норм.

[denis0k]

Проблема у нас всплыла в лесном модуле (IMG:style_emoticons/kolobok_light/smile.gif) Связано однозначно с недостатком ресурсов, но удивительно, что все остальное работает очень шустро. В общем, я чуть пошаманил, и кажется нашел выход. Сейчас мод последние 12 игровых часов исправно переключает часы, хотя время клиента отстает где-то на минутку (полчаса) от серверного. Но это имхо нестрашно уже.

Причем у нас ситуация была совсем кошмар - время менялось только раз - при запуске мода скриптом синхронизации с бд (IMG:style_emoticons/kolobok_light/smile.gif) Дальше стояло наглухо.

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

Neverwinter Script

// Аптайм, кратный 6, делим на 120 с остатком.
    // Остаток 0 будет раз в 2 минуты (игровой час) - 120, 240, 360 секунд...
    if (nUptime % 120 == 0)
    {
        /* ...вырезано...*/
       
        // ---
        // Вручную меняем время
        // ---
        // Получим
        int nHour = GetTimeHour();
        int nMinute = GetTimeMinute();
        int nSecond = GetTimeSecond();
        int nMillisecond = GetTimeMillisecond();

        // Ставим время
        SetTime(nHour, nMinute, nSecond, ++nMillisecond);

        /* ...вырезано...*/
    }

Время нельзя двигать назад, установка текущего скорее всего этим и является (отсюда +1 милисекунда), поэтому новый день и прибавлялся (здесь - нет). Проблем с точностью здесь не будет, т.к. скрипт все равно срабатывает не каждые 6 сек. Погрешности бывают до 1.3 сек (!), обычно - пара милисекунд.


Кстати, если интересно. В игре только часы виртуальные и настраиваются в опциях, минуты/секунды реальные. Т.е. при стандартной раскладке в часе игры 2 и реальные, и игровые минуты (IMG:style_emoticons/kolobok_light/smile.gif) Так: 1ч 0м -> 1ч 1м -> 2ч 0м ->... (IMG:style_emoticons/kolobok_light/smile.gif)

[virusman]

Время замораживается зачастую из-за большого количества висящих псевдохертбитов (DelayCommand'ов).

[denis0k]

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

[Zirrex]

Если DelayCommand постоянно висят в памяти (перезапускают скрипты, создавая таким образом псевдохартбит, причем работают со скоростью меньше 6 сек.), то память постепенно забивается скриптовым мусором, который не очищается в отличие от настоящего хартбитового скрипта.

Кстати, на Амена произошла аналогичная проблема. Правда, время все же двигалось, но медленно, хотя иногда и останавливалось вовсе.

Да, заметил еще такую пакость. Если модуль имеет огромные размеры, то хартбит модуля срабатывает не через каждые 6 сек, а с небольшим запаздыванием (сбои начинаются после достижения размеров модуля больше 12 мб.). У меня в модуле запаздывание дошло до 5-6 секунд. Т.е. практически получилось 2 раунда. Как это отражается на АИ, становится заметно, когда модуль работает без рестарта несколько часов.

[Existor]

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

Теперь к проблеме.
Прична - однозначна, нехватка вычислительных ресурсов + корявость системы времени, а точнее - процедуры, отвечающей за связку между гуишным компасом, который по совместительству является и часами, системой, отвечающей за обновление показаний на этом гуишном придатке и системой смены суток. Можете смеятся сколько хотите, но к этому выводу я пришел после длительных экспериментов, никак иначе ЛОГИЧНО объяснить сие явление возможным не представляется.
Смена суток в нвне завязана на СМЕНЕ ПОКАЗАНИЙ игровых ГУИШНЫХ часов(компаса), а не на реальное, движковое время, которое продолжает идти своим чередом даже после прекращения обновления показаний времени на гуи. Скорее всего, процедура СМЕНЫ СУТОК срабатывает уже после изменения показаний времени на гуи, а так как в результате нехватки вычислительных ресурсов показания на гуи встают колом и НЕ ОБНОВЛЯЮТСЯ, то и время суток тоже не меняется.
Итак, МЕГАХИНТ: хотите вернуть модулю его реальное время? Нет ничего проще - взять показания из движка, который продолжает отсчитывать игровое время в нормальном режиме и инициировать процедуру изменения показаний на гребаных недоразвитых гуишных часах, бегать за которым с сопливчиком игровой движок при нехватке ресурсов на более важные задачи почему-то отказывается.

Механизм решения данной проблемы, был описан выше... Подтвержает эту бредятину.

Изменяем показания(неважно, насколько, важно, чтобы показания изменились, система смены суток запустилась на этом ивенте, и внесла коррективы в текущее отображаемое время суток). Вот такие пироги.

Да, заметил еще такую пакость. Если модуль имеет огромные размеры, то хартбит модуля срабатывает не через каждые 6 сек, а с небольшим запаздыванием (сбои начинаются после достижения размеров модуля больше 12 мб.). У меня в модуле запаздывание дошло до 5-6 секунд. Т.е. практически получилось 2 раунда. Как это отражается на АИ, становится заметно, когда модуль работает без рестарта несколько часов.

Первопричина не размер модуля, а производительность хоста. Подвисание времени один из звоночков, что серверу не хватает мозгов(ну или разрабам =) ). Ну а если хост тянет, то и время не встанет.

Сообщение отредактировал Existor - Mar 11 2008, 18:40

[virusman]

Самое любопытное, что даже при перегрузке НВН-сервер лагает, но не тратит 100% CPU.

[Misty Dragon]

Первопричина не размер модуля, а производительность хоста. Подвисание времени один из звоночков, что серверу не хватает мозгов(ну или разрабам =) ). Ну а если хост тянет, то и время не встанет.

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

[Zirrex]

Причина - однозначна, нехватка вычислительных ресурсов

Я не знаю, как серверному модулю может не хватать данных ресурсов, если пиковая загрузка процессора не превышает 15%?

Ну а если хост тянет, то и время не встанет.

Как раз таких проблем нету. Хост мощный. Из-за корявости самой игры (скорей всего из-за аддонов), даже слишком мощный сервер мало помогает. Не забывайте, сколько этой игре лет (а она умудряется тормозить даже сейчас). Без корректировки времени, описанной выше, думаю, подобное будет происходить на практически любом модуле, который насчитывает 150 и более локаций. Потом, я сие проверял на совершенно пустом модуле с одной локацией. Тормозов по времени не было совершенно (что не удивительно). Но стоило внедрить в модуль локации, которые были в нем изначально, так началось отставание времени. Замечу, что проверялось это без скриптов. Потом, игра не очень любит, когда делаются огромного размера локации. При построении локации лучше всего придерживаться размеров 16х16, и не более. То что Аврора позволяет сделать локации 32х32, еще не значит, что их нужно делать такого размера. Я проэксперементировал с такой локацией. Да, она грузится, но очень уж долго. У людей со слабыми компьютерами может даже подвесить игру.

Не на серваке все отрабатывает на ура. Часы работают, как надо.

В том то и дело, что именно не на сервере часы идут, но не останавливаются, хотя происходит постоянное запаздывание модульного хартбита.

Сообщение отредактировал Zirrex - Apr 4 2008, 10:22

[greenpeace]

вверх

ув. комрады научите как юзать дм_сеттайм чтобы устанавливать точное время в игре?
я попробовал высчитать значения которые нужно ввести чтобы получить 7 мес 11 дней 18 часов. это состовляет 327723.447 мин реального времени

игровой час на дефолтных установках 2 минуты реального времени

если час (60 мин) это 100%, то 2 минуты это 3.3333333333333335%
таким образом 327723.447 мин реального времени - 96.6666667% = 10924.1148 мин игрового = 182.06858 часа
однако если округлить и ввести 182 0 0 0 получается совсем левая дата :/

[virusman]

Шизофрения происходит от того, что в скриптовых функциях времени:
* Год, месяц, день, час - внутриигровые
* Минуты, секунды - реальные
То есть при установке времени надо указывать игровые год, месяц, день и час, а минуты и секунды - сконвертированные в реальные с учётом коэффициента. К примеру, 8 часов 40 минут в игре - это 8 часов + 4 минуты, если коэффициент сжатия времени 10:1 (1 час = 6 минут).

[virusman]

Раскопал все причины данной проблемы.. Технические тонкости движка, наверное, никому не интересны, но если что - я добавил в NWNX Fixes движковый фикс для этого бага. После тестирования на своём шарде, наверное, добавлю это в основной репозитарий.

[greye]

Технические тонкости движка, наверное, никому не интересны

Очень даже интересны.

[virusman]

Ок.
В нвсервере есть так называемый Main Loop - бесконечный цикл, на каждом проходе которого обрабатываются сетевые пакеты, события, списки видимости, отложенные события, прокладывание маршрутов, все скрипты и т.п.
Где-то в конце каждого прохода выбирается только одна лока, и в ней обновляется погода и хертбит.
Через n циклов (где n - количество лок), когда все локи закончились, обрабатывается модульное событие, и если с последнего раза прошло меньше 6 секунд - обновляется время. Больше 6 секунд - вызывается модульный хертбит.
На серверах, где среднее время одного прохода по Main Loop больше, чем 6000/n мс, всегда вызывается только модульный хертбит и никогда не обновляется время. Таким образом, появление бага зависит от количества локаций и общей производительности (загруженности) модуля.
Мой фикс принудительно запускает обновление времени после модульного хертбита.

[Ilerien]

Ура, долой скриптовый таймер (IMG:style_emoticons/kolobok_light/smile.gif)

[virusman]

Профилируем нвсервер. (IMG:style_emoticons/kolobok_light/smile.gif)
http://my.virusman.ru/nwnx_files/vtune_nwserver_2.png