Dragon armor

@HaterCheaters Ясно, что не клиентом игры. Т.е., ты хочешь клиентом xmpp получить список конференций. Не, такое не делал, поэтому подсказать не смогу. У меня не было такой задачи.

@HaterCheaters Нет, не пробовал. А в чём сложности? Ты хочешь клиентом подключиться к серверу? Или сервером получить список конференций у другого сервера? У меня была другая проблема - не смог добавить необходимый функционал в виде [[CDATA]...], которого требует клиент картохи. А потом выяснил, что можно и без xmpp обойтись, поэтому и все эксперименты с ним закончил. Пробовал на jabberd2.

@StranikS_Scan Благодарю за информацию. Вот про это не знал. Тогда это немного облегчает создание хитбокса. Получается, что для брони достаточно будет указать один индекс, а по нему уже можно будет определить всё остальное.

@StranikS_Scan Всё-таки броня нулевой толщины должна быть. Без внутренних слоёв. Броня башни отсутствует. Ещё там регистрация требуется для просмотра чего-то более высокоуровнего. Если есть у тебя, как сделана броня башни у вафлепазика и гриля. Это почти тоже самое, что и в клиенте доступные коллижн модели. Тут отдельными плоскостями сделано. Сейчас сам не знаю, как именно делать. Ограничения физического движка на коллизию динамического объекта - замкнутый невыпуклый 3d объект (их можно объединять прямо в физическом движке для создания любой формы). Если делать плоскостями или полигонами, то это уже статика будет. Иначе физический движок не поддерживает. Это ты про питон? Но ему эти данные предоставляют. Т.е., это опять в реализацию в физическом движке упирается. А питон уже готовые данные обрабатывает. Ну вот су-5, как раз рубка похожа на то, что надо. Если навести на внутреннюю часть, то не покажет ничего. Если на орудие - 0 мм. Тогда тут должны быть ограничивающие плоскости, чтобы при стрельбе сзади в рубку был урон.

@StranikS_Scan А где коллижены? Те, что в клиенте - это очень упрощенный вариант, где показано лишь бронирование. А как на сервере у них реализовано? Как у картохи осуществляется пробитие при выстреле в открытую рубку? А в закрытую? Имею в виду, что в физическом движке происходит.

@StranikS_Scan Что ты имеешь в виду? О какой механике речь?

Попытался всё-таки сделать хитбоксы как статичную геометрию. Мне кажется, это не правильный путь. Всё же лучше делать как обычную геометрию, т.е. невыпуклыми простейшими геометрическими формами. А им прописывать необходимые индексы, чтобы можно было вычислить толщину брони. Хотя эта физическая модель будет использоваться только в расчётах для снарядов. Решил поискать экспортер моделей для этой игры, чтобы посмотреть их реализацию внутренних модулей. И нашёл статью интересную Создание 3D-модели танка. У них так же используется две модели - одна упрощенная для физических взаимодействий, а вторая так же для расчёта попаданий. Забавно, значит правильно думал, что надо разделять их. У них снаряд может пробить танк насквозь и полететь дальше. Так что сквозные пробития у них есть. С открытой рубкой предполагаю такой вариант. Где нет брони - никаких 0 мм, тут ты прав, может пройти урон, когда снаряд прошёл через пустое место. Но, если он попал во внутреннюю часть брони, тогда должен быть урон. Но тут проблема вырисовывается - нужно два типа брони делать в открытой рубке. Одна - наружняя, с ней происходит расчёт и рикошетов, и толщины. А вторая будет внутренняя и здесь важен лишь факт попадания в неё для нанесения урона - та же броня с толщиной 0 мм, либо специальная пометка, что броня внутренняя. А вот если по внутреннему модулю, например, казённой части орудия, что должно быть? Как-то тестировал гриля именно на этот случай. Как мне помнится, попадание по орудию - это урон. Выше или ниже орудия - снаряд пролетал насквозь. Но вот членов экипажа, по идее, можно было контузить и без урона, хотя у меня тогда не получилось. Пока что других идей нет, хотя это и усложнение моделирования. И так придётся всю модель облепливать бронёй с фиктивной, но толщиной (т.е. все отдельные геометрические 3d элементы должны быть замкнутые).

Кто подскажет по 3D моделям техники для физики. Как лучше с ними поступить. Какой формат хранения выбрать, как лучше сделать. 1. На данный момент у меня fbx. В нём, судя по всему, есть всё необходимое. И поддерживается экспорт из 3d редактора, и импорт геометрии простой. Но может есть что лучше? 2. Разделение на коллизию и хитбокс. Пока что этот момент не до конца обдуман. Первый нужен в физическом движке. А второй для рассчётов попадания снарядов. Эта модель сложнее, потому что нужны будут и внутренние модули, и надо учитывать толщину брони. Ограничения физического движка такие, что приходится броню делать в виде отдельных простых невыпуклых 3d-элементов. И у меня эта броня покрывает всю модель. Тут тоже не до конца продумано. Есть техника с открытой рубкой. Та же вафля сзади открыта. Если туда залетит снаряд, будет пробитие. А если попытаться пробить сквозь? Например, вот тут видно будет хорошо, что имею в виду. Должно быть пробитие с таком случае? У меня сделано пока что так. Открытая рубка - это броня с толщиной 0 мм. 3. В физическом движке есть возможность отдельно делать для модели raycast, как раз тот самый хитбокс и будет участвовать. Но надо ещё и информацию получить по типу поверхности, которую встретил raycast. А у меня эта информация сохраняется в материалах. Например, вот так. index - это из xml файла. Там броня разделена по этим индексам и прописана их толщина. Из этого индекса толщину можно будет получить в дальнейшем для расчётов. type - пока что это тип брони, т.е. основная или экран. Ещё нужно будет добавить экипаж, внутренние модули. Это, ясно-понятно, будет без index, можно и через type обозначить, типа crew, module и добавить ещё одно свойство, характеризующее соответствующий элемент. 4. Кто смотрел коллизию в клиенте игры, знает, что там сделано отдельными полигонами и им присвоен индекс. У меня, как написано в п.2, сделано отдельными невыпуклыми элементами. Просто не знаю, есть ли в физическом движке возможность делать raycast для отдельных полигонов. Потому что ограничения на создание физической модели из отдельных не связанных между собой полигонов - это статика. Это надо попробовать создать. И, если получится, можно точнее делать хитбокс. А у статических объектов есть возможность назначать отдельные свойства каждому полигону или группе полигонов, в отличие от динамики, где можно свойства назначить отдельному элементу.

Всё же отличаются. Например, нет def-файлов, все энтити прямо в коде приложения сделаны. Посмотреть, какие у них есть функции нет возможности, в отличие от ПК версии, где можно сопоставить ID конкретной функции из def, а в скриптах игры найти как именно с ним работать. Инициализация там, возможно, сделана по другому. Это у тебя был целый пакет? Он не полный. И это часть одного фрагмента. И ещё хочу добавить. А там точно питон есть? Ведь если его нет, значит и cPickle нет.

Для чего разбираться? У меня была конкретная цель, поэтому пришлось повозиться, потому что это часть цели. Зачем тебе разбираться? Ты хочешь попрактиковаться в реверсе? Или попрактиковаться в разборе сетевого протокола? Тут довольно сложно всё, особенно если новичок. Хотя есть исходники BigWorld'а, пусть и старые, но многое можно в них подсмотреть в плане реализации. Там нет номера пакета, номеров фрагментов. Ты лишнего вырезал, либо не скопировал. Вот такой пример пакета с тем заголовком, что у тебя. Из недавнего дампа так же после функции дешифровки.

Ты с флагами не разобрался. Поэтому и так. Плюс, не весь пакет сжимается же. Его отдельные части только, которые, может не корректно, называю сообщениями (message в BigWorld). Судя по флагам, это составное сообщение (FLAG_IS_FRAGMENT). И, судя по тем же флагам, последнее из них. Из сообщения вырезаны последние байты? Не вижу сигнатуры шифрованных данных (0xdeadbeef). Ты что сделать хочешь? Для чего тебе дешифровка трафика? Недостатки в части геймплея. Где-то разъезд одной команды простреливается почти с респа другой, где-то ещё какие-то. Но, несмотря даже на эти недостатки, в сравнении с тем, что сейчас - это были превосходные карты. Эта новая мета камень-куст просто ужасна. Когда начинаешь немного разбираться в игре и хочешь как-то поактивнее действовать, обязательно на ключевой позиции есть прострел. И, конечно же, надо борт башни или танка подставлять под эти позиции, чтобы действовать.

Пока что небольшой отдых. В рангах пытаюсь выбиться в лиги. Такое себе, один шеврон до несгораемого ранга раза 3 проходил. В плюсе на этот один шеврон за сегодня. BSP формат коллизии для статической геометрии. Серверная, скорее всего, своя. Это в клиенте. А на сервере? Хотя есть видео "Дневники разработчиков 2014. Новая физика! [World of Tanks]". Там говорят, что хавок используется. Зачем? Пореалистичнее можно сделать. У меня есть несколько идей, как рИализЬму добавить. Использую Newton. Но на данный момент даже не знаю, как выглядеть будет конечный результат. Зачем? Мне старая графика и старый клиент нравится. А карты-то какие. Просто летаешь над картой и восхищяешься, какие же они были хорошие, даже с учётом тех недостатоков, что у них были. Жаль, что насладиться ими в полной мере не успел.

Разные программисты делали разные части проекта. Может так. У них питон основной язык. Используют то, что есть в языке.

У них zlib зависит от типа отдельного сообщения. Одно может быть сжато, другое cPickle, а третье - строка (json например). И всё в одном пакете. Смотреть надо в скриптах игровых, как интересующее сообщение создаётся. И такое может быть. С флагами пакета разобрался? В исходниках BigWorld о них есть достаточно информации.

Нет, там md5. m = hashlib.md5() m.update(params['session']) params['session'] = m.hexdigest() Там постоянно cPickle, во многих zlib. Ты пакеты на отдельные сообщения разбираешь?

Ты вон о каком параметре. Это хеш, вроде md5. В скриптах игры мне так и не удалось разобраться, какие именно данные хешируются. Для чего нужен - так же не знаю. На авторизацию не влияет. В энтити Login получает db_id. Вслед за этим создаётся энтити Account, в которой содержится никнейм. Смотри соответствующие def файлы. Также заметь, что не занимался тестированием того, что произойдёт, если в "name" отправить один никнейм, а в Login другой. Какой именно примет клиент и будет ли разница - не знаю.

Можно проверить же. Попробуй в старом клиенет поменять и посмотреть, изменится ли визуально. В клиенте отображаются связи между модулями/техникой, чтобы эти данные не гонять постоянно. Серверу тоже надо брать откуда-то информацию. Вот например, часть файла. <_150mm_Rohr_L29_5> shared <maxAmmo> 30 </maxAmmo> <unlocks> <vehicle> G97_Waffentrager_IV <cost> 163500 </cost> </vehicle> </unlocks> При исследовании 150мм орудия будет открыт вафлепаз. И сервер следует этим инструкциям. Исследовал - сервер отправил клиенту информацию, что эта техника теперь доступна для исследования. Это же такой тип игры, где сервер сам играет за клиента, а ему отображает лишь визуальную картинку.

@MemoryCore Уточни вопрос. После авторизации - значит при подключении на baseapp? Там blowfish используется. Алгоритм шифрования не менялся с BigWorld 2.01, в исходниках можно посмотреть реализацию. Если ты про шифрование данных авторизации - там RSA. 32 бита наверное. Ты про первый нешифрованный пакет после авторизации от клиента к серверу? Насчёт терминологии не знаю, это число нужно для того, чтобы идентифицировать пользователя. Дальше оно не используется. В клиенте визуальное отображение, в xml файлах связи между техникой, модулями, порядком открытия (т.е. при исследовании модуля/техники что должно стать доступным). Да, в клиенте xml. На сервере данные те же. Но сервер отправляет клиенту то, что исследовано, а что нет. Сейчас же даже первый уровень техники не открыт, потому что сервер не отправляет клиенту информацию об этом. Вот такой скрин есть у меня из старой версии эмуля. Хотя вся техника доступна.

Да. Возможны любые изменения со стороны сервера.

MySQL применяется из-за огромной нагрузки на БД. Если нагрузка небольшая, sqlite справится. И для него вьюверов на любой вкус. Разбивка пространства же. Ничего сложного в теории. Движок предполагалось использовать для карт неогранниченного размера. А на одном cpu или в одном процессе такое не просчитать и не обработать. Вот для танков этот подход очень не оптимален из-за размера карт 1х1 км, когда у энтити по 500 м с каждой стороны зона интереса расположена. Хотя Барышников тоже объяснял это тем, что вполне возможно увеличение размера карт и эта технология понадобится. Линия фронта, хотя бы. Но какие проблемы с производительностью клиента там были. Аж гуглить пришлось. Да. У меня архитектура BigWorld даже близко не повторяется. Только необходимый минимум для клиента. Одна карта - один процесс. Да, возможно. Любые изменения со стороны сервера.

В любом случае, этот функционал должен быть. Если создан новый аккаунт - генерируется начальное состояние. Все эти танки 1 лвл в оригинале. Просто состояние не будет сохраняться. Например, установить оборудование можно будет, но сохранить не возможно. И каждый раз состояние аккаунта при входе в ангар будет одно и тоже. На первое время не критично. Но с БД надо будет думать что-то.

@Plotnik5252ru Там внутренние отличия будут. Разница достаточно большая по сетевому протоколу. А сеть - очень важный элемент в подобном.

Индексы у техники и экипажа отдельные. Очень похоже, что как в БД добавляется. Но такой объём хранить? Как у картохи сделано, узнать бы. Тут всё приходится придумывать. В BigWorld ничего этого уже нет. Никаких. Как состояние хранить? Каждый раз перестраивать? Оно, конечно, не сильно и нужно. Можно вообще без неё обойтись. Кстати, идея. На первое время сойдёт. Впринципе, можно генерировать новое состояние каждый раз.

Как и в прошлый раз, взял дамп своего трафика и передал клиенту. Новая версия сетевого протокола работает нормально. Есть недоработки, возможно, баги, но уже и ретрансмиты проходят в случае потери пакетов, чего не было в прошлую версию протокола, написанную на коленке. На данный момент клиент подключается напрямую к эмулю без прокси-клиента. Трафик был сдамплен где-то в новогоднее наступление 2017-2018, поэтому снежинка. Такая ностальгия. Ещё 5к боёв, чуть-чуть техники, слотов в притык. Без правильного оборудования, камуфляжа, нормального экипажа, даже без расходников. И со снарядами по умолчанию. Игрушечные фугасики на таком калибре. И единственный нормальный экипаж за ЛБЗ. Даже отметку удалось взять. А магазин-то, какой магазин! Максимум функционала, ничего лишнего, сверхбыстрая загрузка, быстрый отклик. В создании техники уже разобрался. В создании экипажа тоже, при чём со всеми перками сразу (как на прес-аккаунте), хотя это пока что не протестировано, т.к. не на чем. Не знаю, как лучше в БД это сохранять. В оригинале есть индекс у техники, экипажа. Он, во-первых, уникален, во-вторых, увеличивается с каждой новой техникой или нанятым танкистом и связан с ним до конца его дней. Пока что попробую делать без привязки к индексу. Можно попробовать всё загонять в БД через cPickle. Не уверен, что прямо таки критично будет. Хоть и внешне достаточно плохое решение.

Как и предполагал, подобное можно сделать, когда залогинишься на baseapp, но дальше сервер держит в подвешенном состоянии. Т.к. в BigWorld кластер и loginapp - это отдельный сервер, то он не знает о нагрузке на baseapp. Хоть и ресурсы выделены (например, трафик уже шифруется). А baseapp, в свою очередь, может быть перегружен. Теперь пытаюсь разобраться с энтити Account. У меня сделано очень плохо на данный момент, хочу задействовать базу данных, чтобы изменения сохранялись. Но это достаточно сложно хотя бы потому, что не понятно, что именно сохранять и в каком виде. Должны быть таблицы техники, экипажа, товаров (там всё остальное?). Их надо как-то заполнить начальными значениями. А ассоциации экипаж - техника? Как это реализовать? У меня есть такой код для создания техники: items.vehicles.g_cache.vehicle(nationID, itemTypeName) nationID = nations.INDICES['germany'] itemTypeName = 190 Создаст вафлю е100. Возвращается VehicleType. Вот там всё, что можно устанавливать на танк? А это уже из ClientGoodies.py def synchronize(self, isFullSync, diff): if isFullSync: self.__cache.clear() goodiesFull = diff.get(('goodies', '_r'), {}) if goodiesFull: self.__cache = dict(goodiesFull) for item in ('goodies',): itemDiff = diff.get(item, None) if itemDiff is not None: synchronizeDicts(itemDiff, self.__cache.setdefault(item, {})) return Вот тут что происходит? for item in ('goodies',): зачем так делать? Приставка '_r' встречается в некоторых местах. По видимому, это полное обновление, replace может быть? А без неё только то, чего нет для экономии трафика. @Putin192 Дратути. В ангаре счётчик очереди понаблюдать хочется?