|  |
| | | буду тут немного флудить и хвастаться :)
последние 3 дня и 3 ночи (хмм, как символично) бился над синхронизацией объектов. полностью раскурил movement timestamp, зачем он нужен и какой он должен быть, как он синхронизируется с другими пакетами, что такое CMSG_MOVE_TIME_SKIPPED и CMSG_SET_ACTIVE_MOVER и зачем они нужны, какую роль они играют в синхронизации, зачем нужно следить за m_moveFlags и т.д.
в общем полный набор, впервые в истории раскурен и реализован. к своей радости надо сказать, хожу тут вокруг двух ноутов на столе на кухне и припрыгиваю от радости, насколько всё круто работает :) реально, эмоции через край :) вполне могу предположить, что такой точности синхронизации еще пока никто не реализовал. ну мне по крайней мере об этом неизвестно (да, я посмотрел исходники доступных проектов). ну по крайней мере хочется в это верить :)
самый просто пример оценить качество синхронизации, это три теста:
1. взять два клиента и залогиниться на сервер. прыгать первым, у второго должно наблюдаться небольшое запаздывание, около секунды. через несколько мув-пакетов реакция становится моментальной. особенно хорошо воспроизводится это когда и клиенты и сервер находятся на одном компе.
2. то же - залогиниться двумя клиентам, начинаем двигаться вперед одним из них. у второго наблюдается начало движения и затем небольшой скачек вперед. после остановки первого наблюдается такой же скачек назад. и опять через некоторое количество мув-пакетов все налаживается.
3. самый интересный testcase: создание (SMSG_UPDATE_OBJECT, UPDATE_FULL) объекта, когда он находится в падении. для наглядности идем в стормвинд, после входа там будет что то вроде рва с водой, по обе стороны моста. одним персом идем вниз, в озеро. вторым будем прыгать с моста. но нужно сделать так (в сервере например уменьшить область видимости до 50.000000), что бы взаимный сreate начался после того, как второй прыгнул. в этом тесте при неправильной синхронизации наблюдается кошмар :) в зависимости от кривизны реализации может наблюдаться скачкообразно летящий перс. а может сначала один полететь, причем по крутой дуге аж под мост, потом через некоторое время он же летит снова, но уже более удобоваримо. но все равно с ошибками (клиент обрабатывает MOVEFLAG_FALLEN_FAR, а не должен)...
остальные тесты приведу, когда эти заработают правильно :)
кому не лень, проверьте у себя. расскажите потом. можно с видео :) |
| | | | | ураа, поперла первая заселенка! :)
пока raw. но в целом понятно, если заливать не все снифы подряд, а "думая головой", то такой плотности не будет как здесь: http://wowcore.ru/forum/?forum=1&mpage=1&theme=7bd8d809aa888f073da031e23593e690 |
| | | | | изучал транспорт, наконец то настал момент, когда я смог заняться этим. в частности зиппелин из оггримара в андерсити.
полностью раскурил особенности создания и удаления транспортного ГО, таймстампов и флагов.
хехе, поскольку мувемент был сделан ранее с учетом транспортного флага, собственно персы отображаются корректно другим наблюдающим персам, когда первые заходят и уходят с зиппелина. все заработало сразу.
так же была сразу же сделана синхронизация, поскольку все ее тайны раскрыты. транспорт отображается в правильный момент времени всем наблюдающим, независимо от того, кто когда подошел к транспортному доку или вошел в игру. всё у всех происходит в один визуальный момент времени, а не каждому своё.
так же выяснены особенности передачи координат и особенности мультипликации транспортных ГО. выяснены все необходимые требования, что и как делать, что бы:
- транспорт "возвращался", т.е. циклически ходил
- при движении был виден окружающий мир
- транспорт и его пассажиры креатились для наблюдающих, когда тот проходит мимо или подходит к точке наблюдения
таким образом снимаю проблему взаимодействия пассажиров с наземными юнитами, нет никаких препятствий делать это.
остается пока неразобранный механизм телепорта в другую карту. пепелац то просто ездит от трнаспортного дока куда то в океан, стоит там некоторое время и возвращается обратно. ну это вероятно нужно так же "пристроится" к механизмам "ведения" транспорта по карте и отслеживать текущую позицию. |
| | | | | продолжаю работать над заселенкой. zWorldBuilder готов, вливает со снифов объекты. первые поселенцы в Оггримаре и Андерсити :) все работает в штатном режиме, через спауны. самое время заняться аггрегацией А9. |
| | | | | не, не готов :)
оказалось забыл итемы мобам раздать, кому мечи, кому вилы, кому удочки. в общем и целом база, поля и структуры устаканились, билдер теперь готов к труду и обороне.
влил снифы, специально сделанные "на заселенку". итак, первые поселения Элвин Форест, Вестфалл, Дасквут и конечно же Стормвинд.
мусора почти нет, дупов почти тоже нет. есть куча дейли и эвентовых объектов. их надо будет собирать в отдельные эвентовые слои заселения и спаунить по наступлению соответствующего времени (еще одна, кстати, фича в спаунсистеме). например с 25 декабря по 10 января спаунить новогодние объекты. в общем над этим еще предстоит поработать.
тем не менее, ручной работы над заселенкой все равно не избежать.
в данный момент с пристрастием собираю транспортные объекты :) |
| | | | | В 18-ом спринте мы продолжим заниматься заселением, хоть и немного отставая от графика. Поэтому решено не открывать новый спринт, а продолжить активности в этом.
В предыдущем 17-ом спринте основная работа велась над всякого рода утилитами, облегчающими процесс заселения Миров. Код сервера дорабатывался незначительно, лишь для готовности принять это самое заселение и для устранения небольшого количества ошибок в дизайне.
Так же были написаны утилиты для анализа снифов, что в них, собственно, имеется. Теперь можно их сгруппировать и отфильтровать трафик, что бы максимально избежать дупы и мусор в Мирах.
Примечательно, что WorldBuilder может собирать несколько объектов на одну спаун-точку, но тут был выявлен ньюанс: с GameObject лучше так не делать, т.к. очень и очень часто в оригинале практически в одной точке может находится несколько ГО. Например, самая распространенная ситуация, когда в одной точке (с точностью до 6 знака после запятой!) стоит ГО "костер" и второе ГО "звук костра", который соответственно модельку не имеет и визуально никак не отображается, но тем не менее он есть :) Или, например, столбы с табличками-указателями (они по высоте только различаются). С юнитами же все проще - новый юнит просто добавляется в список шаблонов спаун-точки.
На текущий момент собраны и расставлены грифонщики - их хотя бы проверить можно, т.к. известны координаты их всех (из dbc). А вот что с лифтами делать пока не знаю, вероятно во время тестирования зон только это выявлять. Сама по себе система общения с NPC не реализована, т.к. требует реализацию госсипа, да и не было цели реализовывать разговорные системы.
В следующем спринте будем улучшать методы заселения из снифов, соберем и сгруппируем эти снифы для генерального процесса заселения. Так же будем дополнять код сервера на поддержку транспортных и всех сопутствущих функций, включая area триггеры и телепорты в Миры по ним. В общем и целом цель обеспечить бесперебойное перемещение по всем Мирам из любой точки в любую другую. В инсты пока будем пускать всех подряд, а позже в коде DungeonServer мы это зафильтруем. А так же получить примерное отфильтрованное raw-заселение Миров.
Так же накопился небольшой список доработок, которые нужно зарефакторить. Это, например,
- аггрегатор апдейтпакетов А9,
- телепорт (реализован только ворлдпорт),
- вход в мир с уже залогиненным аккаунтом,
- charserver: открывать порты только после logon ok,
- сделать пинговалку мускул сервера, что бы не отваливался с ошибкой has gone away,
- разобраться с гуидами и способами их хранения. Имеется ввиду их 64х битность, т.к. сейчас в сервере изпользуются 32х битные гуиды и этого более чем достаточно. Но HIGUID часть, оказалось, очень удобна и в некоторых случаях даже полезна, что бы разделить области видимости объектов, например, или поменьше напрягаться с динамическими гуидами для разного типа объектов. |
| | | | | "разобраться с гуидами и способами их хрЕнения. "
если бы не идентичность HIGH_GUID у Item и Bag - было бы лучше |
| | | | | наоборот, это как раз играет на руку. т.к. сумки это те же итемы и расположены они, соответственно, в одной таблице итемов, соответственно формируется свой инкремент гуидов. и поскольку они могут пересекаться с гуидами плееров в этом случае (грубо говоря начиная с еденицы и там и там), то верхний диапазон как раз все культурно разруливает. |
| | | | | сколько ж надо всего что бы на грифоне полететь...
реализовал систему диалогов и, собсно, грифонщиков. пересмотрел свое отношение к диалогам в принципе. и этот принцип подсказал мне, что npc_flags у юнитов - динамические. что юнит готов в данный момент (когда к нему обратились) сказать плееру, те флаги и выставляются.
т.е. к примеру грифонщик. он может давать квесты. если квесты для выдачи существуют, значит этому нпц выставляем флаги и квестгивер, и грифонщик и госсип. если квестов нет, то и неча тада госсип гонять :) |
| | | | | начал перелопачивать AreaTriggers, на предмет где какие триггеры и что делают. ну например некоторые используются для перехода в другие миры, некоторые при исследовании территорий, некоторые срабатывают при входе в inn.
уфф, перелопатил примерно половину списка пока. выяснил, что встречаются особый тип триггеров, которые обычно установлены где нибудь на входе чего нибудь. при входе в стормвинд например есть один. при входе в некоторые инсты - сначала там входишь в какие нибудь узкие ворота и коридор. возможно это эвентовые какие то вещи. может быть по этим триггерам "запускаются" мобы этой локации или что то типа того. что нибудь предвариательно спаунится. теоритезирую.
так же нашел несколько "скрытых" локаций, которые еще недоделаны. идешь идешь, и хобана - дверной проем, а там конец wmo с голубым бекграундом. туда проваливаешься и падаешь вниз в бесконечность. примечательно то, что эти триггеры не срабатывают, когда оказываешься в этом месте обычным клиентом честным образом - т.е. без хаков, как будь то бы это было бы на оффе - прибежал и триггер не сработал. не прислал клиент CMSG_AREATRIGGER. странно, что этот контент включен в релиз продукта.
по факту, точные координаты при телепортах в другие миры выдрал из снифов (SMSG_WORLD_PORT), но разумеется не все. все какие нашел в снифах - сделал. остальные надо как то искать. ну или можно конечно вручную прописывать примерные координаты, куда бы близзы телепортнули бы, на свое усмотрение. не люблю самодеятельность в этих делах, но это, похоже, не тот случай, где нужно с этим париться.
триггерная система работает. в TODO осталось только проверка на рейдовые инсты. ну это там где нужно бы проверить, что бы плеер был в группе, в группе было бы не менее X мемберов, мемберы (и сам плеер) были бы не ниже N уровня и т.д. и т.п.
диалоговая система в целом работает. пока в ней множество стабов ввиду нереализованности остальных подсистем (типа вендоров, квестгиверов, инкиперов и т.п.).
заканчивается реализация таксистов. |
| | | | SeT ··· 15.12.2013, 02:04 |
| | Насчёт триггеров =)
Столкнулся с тем, что в 4.3.4 некоторые триггеры просто не посылаются клиентом, причём могут не посылаться сразу на всей карте. Например в подземелье Нексус. Клиент просто молчит и не посылает опкод при входе в триггер...
Отчего это может зависеть?... |
| | | | | это скорее всего зависит от того, что в 4.х и выше многие опкоды разбиты на группы, посылаемые в разные сетевые соединения. 4.х же работает ненативно, там хак экзешника. ну, видимо не очень корректный. |
| | | | SeT ··· 15.12.2013, 18:47 |
| | хм... Тогда бы CMSG_AREATRIGGER не работал везде, а так получается выборочно -некоторые подземелья (Нексус, Рубиновое святилище), причём сразу во всем подземелье, все триггеры.
Открытый мир, или Окулус, инстанс выше Нексуса, там все уже работает.
Мистика... |
| | | | | отнюдь. коль у нас есть "проблема" со вторым соединением, то скорее всего это так. другое дело, полагаю, никто не знает как именно оно работает. наверняка у них и зоны разные посылаются в разные соединения. хотя выглядит конечно маловероятно.
или вот, например - "не та" фаза. триггеры посылаются только в определенной фазе. |
| | | | | удивлен расположением спаунов вагонов метро :) |
| | | | | запустил метро из сторма в айрон. на этом первая часть транспорта, можно считать, закончена (тип 11, лифты). разобрался как синхронизировать объекты между собой и для активных плееров. а так же, самое главное, научился определять местоположение объекта в любой момент времени, что очень важно для апдейтсистемы и управления областью видимости объектов.
за одно переработал и устаканил классы геймобъектов - разбил их на типы и уникальные реализации делаю в наследуемых классах. удобно. добиваю UpdatePositionTimer и перехожу к MO_TRANSPORT (тип 15). |
| |
|
| |
