Dragon armor

Как и предполагал, подобное можно сделать, когда залогинишься на 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 Дратути. В ангаре счётчик очереди понаблюдать хочется?

@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 вы получаете возможность арендовать множество машин и " "выходить на них в бой, не совершая покупку. После завершения акции " "начисленная техника не исчезает, и вы имеете возможность разоружить её, не " "беспокоясь о сохранности оборудования, снаряжения и экипажа."