Dragon armor

@blueferret How are you going to do? Do you know about raycast vehicle? Or will you do on physical objects? I know how to make a very simple implementation. Perhaps that will be enough for me. But how are you going to do? What will drive the tank? Force pushing him from behind? The force applied to the wheels? How will you calculate your force? How do you make the difference in power? For example, a 700 and 1400 horsepower engine. Gear ratio, differential, turn in place, suspension.

cPickle is used everywhere in the game client where python objects need to be passed. cPickle is not used for file transfers. This is a good way to avoid creating your own object serialization libraries. I have nothing from physics at the moment. I can't even imagine how the final solution should look like. I still haven't made an arena (cellapp) to test physics. You can use demosSandbox. I think you looked at the examples in the engine. This is enough to get you started. Unfortunately, physics in a game about tanks that move is the most important thing. Maybe. I think they had their own server physics engine. Perhaps they still have their own physics engine. I know English very bad. I am using google translate. I think I also have some bugs.

Там ничего особенного. Разве что подсказало мне про cPickle.

@Plotnik5252ru Желания мало. Нужны ещё и знания. Без них, увы, ничего не сделать, как бы сильно не желал кто-либо сделать что-либо.

@Plotnik5252ru Нет, арта тут уже не ваншотит, а станит. Шарить надо в реверсе, знать Ida, OllyDbg, хорошо бы ещё си(++), питон для скриптов игровых. Авторизация - дело не хитрое, она практически в том же виде осталась, что была в 2010 в исходниках. Основная сложность не тут, надо логику делать в ангаре, а также на арене (бой). Дамп - вещь полезная, конечно, но он абсолютно бесполезен, если его просто захватить (запустить Wireshark, как пример). Надо делать mitm, то есть, свой публичный ключ нужен, а также перенаправление на свой локальный прокси, который будет трафик вновь расшифровывать и зашифровывать уже с помощью публичного ключа от игры. Можно и по-другому, как человек писал на хабре в году, вроде бы, 2014. Ссылка гуглится легко по фразам "расшифровка сетевого трафика WoT" или похожее к этому. В общем, нет, это не просто. Если знаешь, то тоже не так легко.

Думаю, аналогично по сложности. Легче будет разве что из-за использование готовой кодовой базы. Различие между ними очень большие. В сетевом протоколе различия минимальны. А вот во внутреннем устройстве очень существенны будут. Разные скрипты. Надо адаптировать к ним. В скриптах вызываются методы, которые могут отличаться по количеству агрументов, по наличию/отсутствию методов. Есть встроенные в BigWorld функции, связанные с сетью (типа логин, создание/удаление энтитей и другие). Они тоже отличаются. А у меня сделано так же, как в BigWorld, то есть, они внутри эмуля будут. А тогда нужно будет выносить всё подобное в питон. У меня нет дампа трафика тех версий, что усложняет в какой-то степени восстановление сетевого протокола. Ну и финальный вопрос: адаптировать кто будет? Уж лучше сосредоточиться на одной версии и делать её.

Много чего надо ещё сделать. На данный момент надо просто запустить его, а для этого, как уже писал, нужно переделывать ранее сделанное. У меня не так много знаний и опыта в подобных вещах. Продвигается медленно. Смотрел, очень близко к утёкшим исходникам BigWorld 2.01. Но и текущая версия не сильно отличается. Добавилось не так и много.

@DrWeb7_1 Не знаю, как делать архитектуру сервера. Долго ходил вокруг методов инициализации из def файлов. Сегодня решил, что оставлю так, как было, лишь поправил некоторые моменты. Но там не всё однозначно, есть секция Properties в def. Там флаги важны. Так думаю, если есть флаг ALL_CLIENTS, например, то надо при изменении этого параметра делать рассылку всем клиентам, если BASE_AND_CLIENT или OWN_CLIENT, то только конкретному клиенту. Надо как-то сделать будет. Эти простыни кода инициализации питона просто вымораживают. Инициализацию всех энтитей решил делать из сишки, это не быстрее по производительности, но в питон уже идёт готовый объект. Можно, конечно, в __init__ делать только базовые вещи, но это минимальное удобство для программирования, разница лишь в двух функциях. Зато полный контроль над создаваемыми объектами (PyObject которые). Сейчас упёрся в инициализацию клиентских энтитей. loginapp работает норм, там всё просто и понятно, нет питона, клиент может логиниться, всё замечательно. Дальше, loginapp передаёт клиент на baseapp. Первое сообщение легко обработать и даже дать ответ на него. Но, дальше-то что? Опишу, вдруг мысль возникнет по ходу дела. Сейчас у меня так. Есть сеть, network_s, который держит все соединения, занимается отправкой и приёмом сетевых пакетов. Есть соединение с клиентом. Залогиненные клиенты определяются по ip:port. Питон не задействован, хз воткнуть его тут или не нужен. Есть клиент, пока что baseapp_client_s. Боюсь, что придётся переделывать, когда появится cellapp, но у меня нет идей, как сделать, чтобы и тут, и там можно было использовать, поэтому пока что так. baseapp_client_s создаётся при первом обращении клиента к baseapp. Авторизация и все дела. Т.к. такого клиента до этого не было, создаю его, создаю в питоне class Client, инициализирую и вызываю питон. Клиент с питоном связаны. В бинарниках BigWorld уже где-то тут создаётся первая энтити. Разумно мне так же делать или нет - не знаю. Ну ладно, в питоне сделать вызов можно, On_Init, а в ней будет создана первая энтити, это Login. Тут у меня сделана инициализация этой энтити из питона в си. То есть, создаётся в питоне self.entity = self.Create_Entity('Login'), но сохраняется и доступна в си также, есть там механизм через tp_members, коряво как-то выглядит. Дальше надо ждать клиента, он отправляет enableEntities. Тут надо отправить клиенту новую энтити через createBasePlayer. Ладно, пока не сложно, отправлю. А вот дальше надо сбросить эту энтити и создать уже Account. Вот как? Т.е., надо удалить текущую энтити, создать новую и повторить алгоритм как при инициализации. Сбросить знаю как, за это отвечает сообщение resetEntities. Эмулировать ожидание перед отправкой? Или слать сразу после создания? А кто отправляет? Из питона? Пока что почти пустой клиент. class Client(LittleWorld.Baseapp_Client): def __init__(self): print 'Client.__init__' LittleWorld.Baseapp_Client.__init__(self) def On_Init(self): self.entity = self.Create_Entity('Login') def onEntitiesEnabled(self): pass Или сделать метод-запрос на создание энтити? Типа Request_New_Entity. А в питоне сделать флаг, какую энтити вызывать? Ах, да, onEntitiesEnabled спёр из питоновых файлов BigWorld'а. Там вызывается этот метод, когда поступает сообщение enableEntities . Кстати, есть такой движок kbengine, внутренне очень похож на BigWorld. Думаю, что BigWorld в своё время утёк полностью, но публично нет серверной части. И на его основе сделали вот это. Когда узнал, прямо обрадовался так. А посмотрел, сетевой части нет, там через TCP чтоли идёт. Есть даже видео об этом движке. Вряд ли он поможет, сильно всё изменено там. И некоторые вещи очень разумно. ID сообщения 2 байта, сразу же решается проблема в недостатке их, больше 65к вряд ли понадобится. Длина сообщения 4 байта, тут тоже уходят все костыли, связанные с размером в BigWorld, когда при превышении длины сообщения над разрядностью доступной длины (один байт, например), первые 4 байта в сообщении вырезаются, помещаются в конец, расширяя его на 4 байта, оригинальная длина помечается меткой 0xFF. Норм так сделано.

@Plotnik5252ru Заходил на сервер. Сыграл с таким вот результатом. И больше не заходил. Клиент у меня сохранился. Недавно смотрел его сетевую часть, но там нет ничего интересного, даже наоборот, там не хватает того, что было позже добавлено. Различия между BigWorld и тем клиентом не такие большие. А между тем клиентом и 0.9.22 существенны. И не могу понять тех, кто ностальгирует по 0.7.0. Ведь важен сам клиент, а за то, что происходит внутри него будет отвечать сервер. Так зачем он нужен, с графикой начала 2000х и никакой оптимизацией, когда 0.9.22 поприятнее будет.

Ты немного сути не понимаешь. Очень рекомендую как-нибудь посмотреть видео "Максим Барышников — Миллион пользователей онлайн в World of Tanks с инженерной точки зрения". Там рассказывается о BigWorld. Нельзя попробовать залогиниться через cellapp, потому что cellapp - это арена, на которой происходит бой. Прежде, чем туда попасть, клиент должен быть на baseapp, а до этого залогиниться через loginapp. Можно было бы без всего этого, но у меня уже существующий оригинальный клиент, поэтому приходится и сетевой протокол расшифровывать, и реализацию свою делать, и в какой-то степени создавать так же, как и должно быть на оригинальном сервере, хоть и в очень упрощенном виде. Через baseapp, конечно же.

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

Не всё так просто оказалось, как рассчитывал. В результате разделения на baseapp и cellapp, приходится многое переделывать. Доделать надо работу с def-файлами. Парсер у меня написан более-менее нормально, но очень много лишнего вокруг него. Всё-таки, когда всё было в куче без разделения, это выглядело не так прохо. А сейчас не подходит. Смотрел бинарники сервера BigWorld, так и не смог понять, откуда всё начинается и кто, всё-таки, создаёт начальную энтити. Поэтому сделаю в скриптах напрямую. Тоже интересный момент. Когда клиент авторизуется на baseapp, для него создаётся энтити Login. Не могу утверждать, но вот эта вот очередь результат работы этой энтити. То есть, это уже залогиненный клиент, но его можно держать в подвешенном состоянии. Затем, если всё нормально, буквально через полсекунды, создаётся энтити Account. Нужно или нет делать также? В Login передаётся ник и db_id. И всё. Сейчас поискал, никнейм больше не передаётся, кроме как в Login. Можно будет поэкспериментировать. Но держать в подвешенном состоянии клиент можно и раньше с меньшими усилиями и ресурсами со стороны сервера. Мной это уже даже протестировано. Только нет номера очереди, просто будет выводиться сообщение, что сервер перегружен с предложением покинуть очередь. Клиент будет автоматически пытаться залогиниться примерно раз в 20 секунд. Удобно, можно лимит залогиненных держать и не пускать никого сверх этого. Сейчас заодно с baseapp, пытаюсь делать связку с пиноном. Пока что выходит не очень. Что там надо, какие функции предусмотреть, что именно с питоном связывать? Не понятно. Когда клиент логинится, надо его в питон выносить? Типа Client будет. А что ему прописывать? Какие функции? Но и энтити нужны в питоне. Получается, и клиент, и энтити будут одновременно там. Переписывать код сейчас приходится меньше, всё же есть кое-какая реализация, сделанная раньше. Но как посмотрю, что накодил и с мыслью "Ну ладно, оно же работает", закрываю.

Хз. Кстати, вопрос по питону. Как лучше делать, кому инициализировать класс. Есть связка питона и сишки. Какой-то класс, допустим Avatar. Его можно создать в сишке, там же инициализировать, а потом вызвать __init__ в питоновом скрипте. А можно создавать в питоне, а из него вызывать __init__ и инициализацию делать. Вот какой способ выбрать? Так вот, если инициализация из питона. class Avatar(Entity, ClientCommandsPort, Chat, AvatarObserver): def __init__(self, name): Entity.__init__(self) ClientCommandsPort.__init__(self) Chat.__init__(self) AvatarObserver.__init__(self) Если же создание класса будет через сишное API, то Entity уже будет инициализирован и его вызывать не надо. Через API. Py_Entity_s *entity = (Py_Entity_s *)PyType_GenericAlloc((PyTypeObject *)entity_type->pclass, 0); ... pFunction = PyObject_GetAttr(&entity->py_object, "__init__"); res = PyEval_CallObjectWithKeywords(pFunction, argc, kw);

Когда-то гугл мне сказал, что это Internet Gate Rooms. Сейчас он заявляет, что это Indie Game Reviewer. Оно это, или нет, не помню. Ещё есть встроенный родительский контроль и ограничение по времени, проведённое в игре. В каких-то странах, видимо, требуется законодательно подобный функционал. msgid "PromoPremiumIgrWindow/text" msgstr "" "Играя в %(iconIgr)s вы получаете возможность арендовать множество машин и " "выходить на них в бой, не совершая покупку. После завершения акции " "начисленная техника не исчезает, и вы имеете возможность разоружить её, не " "беспокоясь о сохранности оборудования, снаряжения и экипажа."

@Plotnik5252ru Это уже давно было сделано. Теперь надо структуризировать. @DrWeb7_1 Полный список всей техники на арене. Смотри __onVehicleListUpdate. infoAsDict = {'vehicleType': getVehicleType(info[1]), 'name': info[2], 'team': info[3], 'isAlive': info[4], 'isAvatarReady': info[5], 'isTeamKiller': info[6], 'accountDBID': info[7], 'clanAbbrev': info[8], 'clanDBID': info[9], 'prebattleID': info[10], 'isPrebattleCreator': bool(info[11]), 'forbidInBattleInvitations': bool(info[12]), 'events': info[13], 'igrType': info[14], 'personalMissionIDs': info[15], 'crewGroup': info[16], 'ranked': info[17]} return (info[0], infoAsDict) Передаётся Vehicle ID, всё об игроке (ник, клан, команда), в vehicleType полная информация об технике (vehicles.VehicleDescr). Есть даже информация об установленных модулях, но для всей техники, исключая игрока, она пустая (только не помню, тут это или где-то ещё). Что интересно, передаётся даже то, какая рация, шасси, двигатель, баки установлены на технике (у всех).

@DrWeb7_1 Если ты про сетевое сообщение клиенту, то создаётся энтити Avatar (через createBasePlayer), а у неё есть свойство name. Вот в нём и идёт никнейм игрока. Техника создаётся позже, через Avatar.updateArena, флаг updateType == VEHICLE_LIST. Также, через updateArena создаётся всё остальное. И после этого, клиенту отправляется сообщение createCellPlayer. И это тоже Avatar, но свойства другие передаются. Надо будет вспомнить, как так делятся свойства между baseapp и cellapp.

OK. I'm using c pure. @DrWeb7_1 Хотел уже нормально протестировать baseapp, чтобы заодно и сетевую часть затронуть, как вдруг мысль у меня возникла. Зачем для cellapp нужна энтити Account? Она же только для baseapp актуальна. Решил посмотреть, как в BigWorld это сделано. Действительно, нет Account.py. Вот жеж. Сколько смотрел, а только сейчас догадался про дополнительное назначение секций в .def файлах. В Account нет секции с CellMethods. Посмотрел в доступных исходниках и бинарниках. Есть условие там: если нет секции и нет питон-файла, то энтити пропускается. Может быть, у меня из-за этого были ошибки в сетевой части (неправильное сопоставление messageID с энтити). А вот энтити Avatar содержит и CellMethods, и BaseMethods. Нужна и там, и там. Пока что не понятно. Точнее, только питон-файла.

@DrWeb7_1 Сейчас в ЛС скину. Ошибся порядком. 70 Кб.

Не, сейчас там просто забиты данные. Посмотри, как __vehicle формируется. Надо разбираться, что у меня там. Не помню уже. По-хорошему, надо сделать список доступной техники и формировать для него нужный массив данных. У вафли нет модулей, поэтому там легко всё сделать. Можешь сам поиграться со значениями, добавить другую технику, 268/5 например. Не заменить, а ещё одну добавить. Тебе скинуть, что сервер шлёт клиенту после логина? Почти 700кб данных. О технике, экипаже, имуществе и прочему. cPickle питоновый.

Вообще обо всей доступной технике. У меня скрины были вот такие У клиента нет нужного списка модулей, в логах игры экзепшн с ошибкой об отсутствующем элементе. И такой объём данных обо всём гоняется постоянно. А потом удивляемся, что это ангар так долго грузится. Это не ангар, это ожидание по сети всех данных. Вон как у меня сейчас сделано. Очень плохо. Функция Get_Vehicle в Client. v_nation = nations.INDICES['germany'] v_id = 190 # 240 F97_ELC_EVEN_90 #190 WE100 И закомментированного полно. Мои прошлые попытки. Кстати, попробуй в эмуле выбрать технику из исследований. Зависнет или что будет?

Вообще, есть. Кроме этого, несколько человек просили меня эмулем поделиться, на что им писал, что нечего показывать ещё. Ведь нечего же? Запустить только да в ангаре покрутить танк. Ну в бой, даже не так, "в бой" выйти можно. И всё. А что нужно, это со скриптами разобраться. Если ты смотрел, там огромные бинарные данные есть, которые передаются на отправку. Это то, что, по-хорошему, надо бы разобрать и выяснить, как подобное сформировать. Там используется дамп трафика из моего личного аккаунта. Просто скопировал как массив 16-ричных данных, чтобы работало. Есть ещё в технике непонятное, там надо клиенту отправить список всех частей, из каких состоит танк (почему сам клиент не может взять их, непонятно). У меня, вроде бы, просто забиты вручную эти данные. Ну и куча всего по скриптам.

А ты всё это время тестировал эмуль? Статический анализ, не отладчик. Не знаю, что произошло.

@DrWeb7_1 Да брось пока что. Толку-то от того эмуля? Надо нормально этот протестировать и поделюсь с тобой. Только надо, так думаю, ещё и питоновые скрипты переписывать. Если loginapp можно полностью в эмуле оставить, то baseapp неплохо бы частично перенести в питон, а cellapp тем более там должен быть. Плюс, в скриптах там такой ужас сейчас. Надо порядок навести. Сетевая часть оказалась ну очень сложной. BigWorld сделали, по сути, свою реализацию TCP, только с полным контролем. С probe так нечего не получилось. Актуальный клиент отказывается его отправлять. Хотел посмотреть, как формируется контрольная сумма, надолго задумалась программа, очень похожая на Ida при анализе бинарника, мне надо было уйти, перевёл компьютер в спящий режим. А по возвращению он из спящего режима не вышел, ожили куллеры, диски, но никакой реакции не было, и, что очень странно, ни на кнопку перезагрузки, ни на зажимание кнопки питания. Пришлось выключить, а когда включил, получил сообщение от биоса, что POST не пройден и предложение выбрать настройки по умолчанию. Впервые подобное произошло. Ну его, этот бинарник. @DrWeb7_1 Там, похоже, стандартные питоновые скрипты не найдены.

Так можно не дублирующие пакеты делать. Пинг - очень простой пакет на 12 байт, который, тем не менее, проходит все стадии парсинга пакетов. Кстати, картоха изменила немного сетевой протокол. По крайней мере, не шифрованные пакеты (тот же пинг) теперь в начале дополняются четырьмя байтами. Похоже, это контрольная сумма, но не банальный crc32 (он просто не подошёл). Хотел тут посмотреть, что за пакет probe такой, а не вышло. Можно, к слову сказать, из клиента отправить и снифером захватить. Не знаю, остался ли функционал, в 0.9.* есть такая функция BigWorld.probe с двумя параметрами, последний - колбек ("argument 2 must be callable"), подозреваю, аналогично колбеку login, который зовётся BigWorld.connect, третий параметр def __serverResponseHandler(self, stage, status, responseDataJSON). Вызываться должен до логина. Ни разу мне в дамп не попал, зачем нужен - не понятно. Ради интереса попробую. В общем, мой сервер можно будет уронить банальной отправкой кучи сообщений ping. Ну и ладно.

@DrWeb7_1 Пока что не знаю. Но при этом снаружи-то ничего и не должно измениться. А может и должно. Вот например, надо loginapp выносить в питон? Это потянет БД за собой туда же. Или надо интерфейс взаимодействия делать. Вчера попробовал простой тест провести. Сделал бесконечный цикл отправки сообщения ping на сервер. Не успевает обрабатываться, использование памяти выросло до 600 мб и продолжило бы расти. Как только прервал отправку, достаточно быстро всё дообрабатывалось и отправилось. Интересно, а как у картохи дела с этим обстоят? Какая защита от подобных действий?