Запуск эвента

[virusav]

Есть эвент 15 (рыбалка в Тернистой Долине), идет каждое воскресенье с 14:00 до 16:00.
В базе указано это же время.
В логах: старт эвента в 13:00, окончание - в 15:00.

Получается, что при старте и остановке эвента не учитывается перевод часов.

Нужны ли какие-нибудь дополнительные настройки в конфигах или базе (например, `realmlist`.`timezone`=12)?

[Кот ДаWINчи]

что-то подобное здесь уже спрашивали. Ответ был: "Перестартони MySQL" (если у тебя сервер онлайн 24/7)

[NeatElves]

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

[virusav]

В базе время старта 14:00, сервер показывает время в игре 14:00, а эвент не стартует.
Лезу в лог и вижу, что эвент стартовал на час раньше.

[Fear]

Сообщение от virusav

В базе время старта 14:00, сервер показывает время в игре 14:00, а эвент не стартует.
Лезу в лог и вижу, что эвент стартовал на час раньше.

Время на MySQL-сервере бежит вперед на час?

[virusav]

time_zone=SYSTEM

[tempura]

сделать две вещи надо бы:
1. унифицировать все даты стартов евентов (это в YTDB)
2. разобраться с таймзоной мускл (это локально)
больше в голову ничего не приходит

Может таймзону явно указать GMT+... (сколько нужно)?

[virusav]

1. Эвент должен стартовать и останавливаться нормально по указанному в базе времени.
2. Время мускуля = время системы.

[tempura]

Я это выше читал.

но навскидку можешь глянуть даты старта евентов в базе? Когда-то (я давно не смотрел, точнее не скажу) там были даты старта от 2007 до 2010 годов.
Есть же еженедельные евенты, которым очень просто прописать старт на перую неделю первого месяца этого года (например)? Причем не каким-то отдельным, а ВСЕМ привести дату старта к узкому промежутку.

А понятия сисетмное время и GMT+... - это все-таки разные вещи. Одно дело мусклу в твоем компе рыться в поисках нужного времени, другое дело ему прямо указать по какому считать.

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

[Кот ДаWINчи]

Не поленился, провел эксперимент:

1. На машине windows server 2003 x64
2. MySQL 5.1.11 (какой стоял тот и оставил)
3. поставил сервер 3.3.5а (первый попавшийся под руку) собственной компиляции с репозитория insider42
4. база YTDB из бакапа основного сервера.
5. ивенты

Специально ничего не настраивал. т.е. все настройки системы и mysql - по-умолчанию.

начинаю проверять на ивенте 16 - ящики на арене гурубаши: Стартует на час раньше положенного. дата начала ивента - 04.08.2007 года.

меняю эту дату на 01.01.2007, перестартовываю мускуль и сервер - начинает работать нормально.

ВЫВОД: если начало ивента происходит в летнее время, то каким-то неведомым способом производится корректировака времени на 1 час.

Эксперимент продолжаю...

[virusav]

Об этом выше писал NeatElves в посте 3.

[virusav]

Появилась новая потеха: нпц для эвента появляются, а квестеры - нет.
Бывает, что наоборот.

[NeatElves]

Подтверждаю, пример - Омерзительный Гринч, есть 6 точек спавна, все 6 в пулле, все привязаны к евенту нового года, в мире моба нет(ранее был - точки спавна и пулл и привязка к евенту, год ничего не менялось)...

А как давно замечена эта проблема?

Если недавно...
Обновление для Windows 7 (KB2443685) 14 декабря 2010
Установите это обновление, чтобы устранить проблемы, вызванные изменениями законодательства в отношении летнего времени и часовых поясов в некоторых странах.

Хотя, моя не специалист, привел просто для справки. Если оффтопик - значит оффтопик

[virusav]

Дома ХР, а на сервере Server 2003, да и не то это.
Проблема замечена недавно.

[virusav]

Если нпц Омерзительный Гринч вынести из пулла, то спавнится сразу во всех точках, т.е. именно пулл не дает нпц появиться в мире.

[virusav]

Из гуидов 13752,82719,82722,82723,83031,83035 оставил только 2 последних для теста.

Если очистить таблицу `game_event_gameobject`, то нпц спавнится, как и положено.
Если таблицу не трогать, то нпц нет.

Добавил вывод данных в блок:

    // now recheck that all eventPools linked with events after our skip pools with parents
    for(std::map<uint16,int16>::const_iterator itr = pool2event.begin(); itr != pool2event.end();  ++itr)
    {
        uint16 pool_id = itr->first;
        int16 event_id = itr->second;

        sPoolMgr.CheckEventLinkAndReport(pool_id, event_id, creature2event, go2event);

и получил (таблица `game_event_gameobject` не пуста):

2010-12-19 00:19:00 creature2event
2010-12-19 00:19:00 pool_id=1083, event_id=15, g=83031, e=2
2010-12-19 00:19:00 pool_id=1083, event_id=15, g=83035, e=2
2010-12-19 00:19:00 go2event
2010-12-19 00:19:00 creature2event
2010-12-19 00:19:00 pool_id=1095, event_id=15, g=83031, e=2
2010-12-19 00:19:00 pool_id=1095, event_id=15, g=83035, e=2
2010-12-19 00:19:00 go2event
2010-12-19 00:19:00 creature2event
2010-12-19 00:19:00 pool_id=1102, event_id=15, g=83031, e=2
2010-12-19 00:19:00 pool_id=1102, event_id=15, g=83035, e=2
2010-12-19 00:19:00 go2event
2010-12-19 00:19:00 creature2event
2010-12-19 00:19:00 pool_id=1104, event_id=15, g=83031, e=2
2010-12-19 00:19:00 pool_id=1104, event_id=15, g=83035, e=2
2010-12-19 00:19:00 go2event
2010-12-19 00:19:00 creature2event
2010-12-19 00:19:00 pool_id=9867, event_id=2, g=83031, e=2
2010-12-19 00:19:00 pool_id=9867, event_id=2, g=83035, e=2
2010-12-19 00:19:00 go2event

creature2event - данные по связке нпц-эвент.
go2event - данные по связке го-эвент.

Получается, что для двух гуидов нпц находятся какие-то левые пуллы и эвенты.

[NeatElves]

А если убрать Гринча из эвента, то спавнится один из пулла.
Но есть еще и куча нпц без пуллов, приписаны к эвентам, но при старте этих эвентов нпц в мире нет.(

[NeatElves]

10915 - заработал спавн мобов в евентах.)

[virusav]

Значит, остается только косяк с неправильным стартом эвентов из-за перевода часов.

[Vladimir]

тут возможно больше косяк - в том какое время надо использовать системное.
И как я понимаю это проблема только *nix?

[Кот ДаWINчи]

И как я понимаю это проблема только *nix?

В windows проблема тоже есть.

[virusav]

Системы с багом указывал:

Сообщение от virusav

Дома ХР, а на сервере Server 2003...

Мне кажется, что системное время надо использовать всегда.
Тогда не должно быть таких косяков.

[Ambal]

Сообщение от virusav

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

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

[rsa]

Сообщение от Vladimir

тут возможно больше косяк - в том какое время надо использовать системное.
И как я понимаю это проблема только *nix?

я так понимаю это проблема рук. при наличии на сервере ntp и правильной таймзоны в мускуле описанной проблемы нет.

[virusav]

Т.е. должно быть `realmlist`.`timezone`=12?

[tempura]

Сообщение от rsa

я так понимаю это проблема рук. при наличии на сервере ntp и правильной таймзоны в мускуле описанной проблемы нет.

Для контроля, тыскызыть, приведите пожалуйста дамп entry и start_time из таблицы game_event.

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

И вообще 9-10 посты перечитывать...

[Кот ДаWINчи]

Сообщение от virusav

Т.е. должно быть `realmlist`.`timezone`=12?

нет.

в каком-нибудь навикате наберите:

SHOW VARIABLES LIKE '%time_zone%';

Получите весь список переменных MySQL, связанных с таймзоной. там на 99% для переменной time_zone будет стоять "SYSTEM".

Для изменения нужно выполнить запрос: (пример для Москвы)

SET time_zone = '+03:00';

Вечером у себя протестирую, и отпишусь.

[KiriX]

Сообщение от Кот ДаWINчи

Вечером у себя протестирую, и отпишусь.

С нетерпением ждём результата, спасибо

[virusav]

У меня в базе стоит SYSTEM, уже писал об этом.
Т.е. время берется системное, с нужной временной зоной, с учетом перевода часов.

[Кот ДаWINчи]

в mangos/src/game/GameEventMgr.cpp вижу строчку 113:

QueryResult *result = WorldDatabase.Query("SELECT entry,UNIX_TIMESTAMP(start_time),UNIX_TIMESTAMP(end_time),occurence,length,holiday,description FROM game_event");

т.е. дата в формате TIMESTAMP преобразуется в UNIX формат при помощи MySQL. А далее уже идет обработка сервером мангоса.
Так вот, возникает мысль, а что если умный MySQL при переводе корректирует переход на летнее время? (Взял на испытание... сейчас попробую проверить).

[tempura]

Сообщение от Кот ДаWINчи

Вечером у себя протестирую, и отпишусь.

Незачем, так и есть.

Сообщение от Кот ДаWINчи

Так вот, возникает мысль, а что если умный MySQL при переводе корректирует переход на летнее время? (Взял на испытание... сейчас попробую проверить).

В точку, так и есть.

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

[virusav]

В запросе время старта берется из базы с преобразованием к юникс-формату.
В остальном берется

time_t currenttime = time(NULL);

Для отладки выводил время из базы и от функции выше - одинаковые, хоть и берутся разными способами.
Ведь в мускуле указано, что надо брать системное время, а currenttime, как я понимаю, делает то же самое.

[tempura]

да причем тут время системы и время базы?

[Кот ДаWINчи]

Возник интересный вопрос. Сейчас у нас отменили летнее время. Что-нибудь в данном вопросе изменилось?

[rsa]

Сообщение от Кот ДаWINчи

Возник интересный вопрос. Сейчас у нас отменили летнее время. Что-нибудь в данном вопросе изменилось?

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

[Кот ДаWINчи]

интересно, а в коде Мангоса ?

[rsa]

а мангосу на все эти пляски начхать - там по жизни используется time_t time(null) которое коррекции не подлежит - это счетчик секунд от 1 января 1970г. вот база - та выдает время с коррекцией на TZ если правильно попросить...