Dragon armor

@4D_wot Ещё ничего и не сделано. Есть несколько скринов. И есть наработки. Как будет что-то, чем можно поделиться, так и опубликую. Сейчас просто нечего даже демонстрировать.

Тут от сервера зависит поведение, не от клиента. Можно ведь сделать так, как было до ввода физики. При этом в версии 0.9.22. Ходовой нету на данный момент. Возможно, что из-за этого. Но башня есть, а она не помогает на боку лежать. Вот такая проблема - танк не переворачивается. В оригинальной игре проблема, что он легко на бок ложится, у меня же наоборот, отказывается на боку лежать.

У меня есть уже мысли по этому поводу, потому что это придётся делать. У танка есть коллизия - это то, как он себя ведёт в виртуальном физическом мире. Наезд на камень, столкновение с препятствием или другим танком. Вот в эту коллизию орудие не входит. Но тут проблема ещё больше. В эту коллизию и башня не вся входит. Если подъехать к чему-то на танке, у которого башня выходит за габарит корпуса и попробовать покрутить ей около объекта, то башня просто пройдёт сквозь него, будь то танк, ландшафт или другая геометрия. К сожалению для меня, вся коллизия только на сервере, в клиенте её нельзя посмотреть. И как она выглядит, можно лишь примерно представить, в тренировочной комнате, например, положив какой-то танк на бок и смотреть, где один танк упирается в другой, а где проходит сквозь. Мне вот не понятна одна вещь - как танк на бок ложится? Не получается у меня. Замоделил упрощенную коллизию вафли, а она отказывается на боку лежать, ей полки по бокам мешают. Олдфаги, вспоминайте, можно ли вафлю положить на бок? Не, есть реальные видео, где танк на бок прилёг отдохнуть, а у меня что-то не выходит. Ну или ходовую надо добавить как реальный физический объект, тогда получится. Но есть ещё и вторая модель, это уже называется hitbox, то есть то, что используется для рассчёта попадания. К примеру, хотя орудие и без коллизии, если на него навестить, то танк подсветится. Вот это есть в клиенте, находится в папке collision_client с каждым танком. На сервере, опять же, своя модель. У меня пока что нет чётких мыслей, как лучше будет делать, или две модели, или всё в одной объединить.

Да. Видимый 3d объект и его модель коллизии различались. Не знаю, как так получилось, потому что эти камни - не ландшафт, а объект, которому коллизия назначается ручками. Есть идея, что не ручками, а автоматически. А физический движок оперирует только выпуклыми объектами. И, если у камня был где-то выступ, ниже вогнутость, а ещё ниже опять выступ, то коллизия построится по двум крайним точкам, игнорируя вогрутость. Для пояснения есть такая вот картинка. Если делать автоматическую генерацию коллизии, то, будь это камнем на карте, выстрел ближе к лобовому окну машины привёл бы к тому самому забавному эффекту, противника видим - попадаем в камень. Пока печатал, мысль одна у меня возникла. Получается, что клиент генерировал коллизию правильно, а сервер по какой-то причине нет. Это получается типичный рассинхрон, когда данные на клиенте и на сервере не совпадают.

Это оптимизация. Для того, чтобы от сервера к клиенту не отправлять те данные, которые никогда не меняются (положение статических объектов, как пример). На клиенте и сервере находятся одинаковые данные (в данном случае, за исключением самих моделей танков, хз что там на сервере). Клиент загружает 3d модель, текстуры, модель коллизии. Серверу нужна только коллизия. Клиенту коллизия тоже необходима, позиционирование башни этому пример, когда мышь наводится на какую-то точку, клиент делает raycast и отправляет серверу позицию, находящуюся на ландшафте или танке (или в условной бесконечности, если в небо навести), в которую он хотел бы, чтобы башня повернулась. Хз понятно объяснил или нет, мне то это всё как-раз понятно и непонятно, что может быть другим непонятно, отсюда следует не совсем понятность, как надо объяснить, чтобы было понятно. Это самое простое. За исключением "дыр" на ландшафте, это первое, что было сделано.

Оказывается, всё под носом было. Позиция находится в секции BSMI. Если смотреть файл bsmi_section.py, то это элемент _01_64, то есть это первый элемент секции размером 64 байта, что соответствует матрице 4х4. Тогда получается, что количество статичных объектов на карте будет равно количеству элементов в секции.

@DrWeb7_1 У меня самописный на сишке.

@DrWeb7_1 За статичные элементы, судя по названию, отвечают три перечисленные мной секции. Ещё есть BSGD (Static Geometry Data), но там, как мне помнится, содержится геометрия модели (копия из primitives_processed). Мне же надо координаты статичных объектов найти. Да и со статикой не всё ясно. Где их количество на карте? В какой секции? Пока не занимался этим.

Пора возобновить тему. Так как изначально было понятно, что это абсолютно не нужная и бесполезная вещь, которую делаю, то до меня дошла интересная идея, что в одну харю, никого и ни о чём не спрашивая, буду делать ещё пару лет до какого-то результата, которым можно поделиться. А спрашивая каждую мелочь, вместо того, чтобы самому найти ответ, можно и ускорить результат. Вдруг у кого-то уже есть ответ на вопрос, на который мне нужно потратить прилично времени. Первое, что нужно было, это вьювер. Так как использовать клиент для тестирования каждой детали - это очень долго. Поэтому прикрутил 3d визуализацию. Пока что только для загрузки геометрии карты. Вид так себе, но большего и не нужно. И тут первый вопрос возник. У меня очень большая надежда на то, что на сервере и в клиенте используются одни и те же статичные модели. Танки-то понятно, что разные, там даже папка с коллизией называется по-другому. А вот если и в статике не так, то совсем плохо. Потому что для физического движка нужна коллизия. И в движке используется bsp версии 2. Кто-то разбирался с этим? Вот что у меня получается при загрузке из файла танка (тут просто показательно). Это дамп загруженной геометрии, если напрямую сохранить. Там ведь bsp-дерево строится. Как это можно привести к какому-то нормальному виду? Боюсь, что придётся собственный алгоритм для обсчёта коллизии добавлять (благо физический движок позволяет это). Второе, это space.bin. Мне много из него не надо. Судя по всему, нужны секции BSMI, BSMO и, возможно, BSMA. Дошёл уже до моделек, которые на карте должны быть. Compiled space utils не полон, эти секции там не расписаны. Явно где-то в них хранится положение на карте. Может кто дошёл до этого, или это уже известо? Где хранятся координаты статики на карте?

Как бы да. Но моды-то разрешены. В eula написано, что нельзя своими ручонками лезть в продукт. Однако моды используют именно этот путь, официального api для модов до сих пор нет. Значит, модам можно. Поэтому и это мод. ВотЬ. Но то, что @DEN_SMOG спрашивал, ответ "Да". У меня все скрины сделаны не из тренировочного боя, а из полноценной battle area (пусть так будет). Проблема в том, что, кроме как зайти в бой, больше ничего нельзя. Хотя, всё-равно сервер решает, куда пустить игрока путём отправки соответствующего пакета. Уже написал, что сделать надо, ссылку на физический движок скинул. Можно использовать и любой другой, на данный момент не сложно поменять движки. Просто у данного продукта есть, как мне кажется, хорошее достоинство (по описанию) - бОльшая точность эмуляции физики, хоть и в ущерб производительности. И ещё, у него интерфейс на pure C, что для меня большой плюс. @RUS_TAHK На данный момент, никак. Эмуляция - достаточно широкое понятие. Именно в данном случае - это про сервер. Возможно всё. Просто для невозможного требуется больше времени. Надо собраться с мыслями и хоть что-то дееспособное запилить, а то только скрины и есть. Как бы, наоборот, лень - двигатель прогресса.

Если про сетевые пакеты, то их более чем достаточно. В крайнем случае, оставить неизвестные (или неизвестное назначение полей) в покое, что плохого может случиться? Есть скриншоты же в этой теме (вафля е100, это же не фотошоп). Поэтому бла-бла-бла не сильно много. Есть лень. И нет вдохновения делать дальше. Не обязательно арендовать сервер. Для тестирования этого не нужно. У меня запускается всё на одном компьютере. Модифицировать нужно два файла (scripts_config.xml и заменить loginapp_wot.pubkey на свой публичный ключ), сам клиент полностью остаётся оригинальным. Собственно, на скринах также видно, что это и сделано, есть выбор сервера (локального эмулятора). Всегда подразумевал, что это эмуляция сервера, т.е. возможность запуска оригинального клиента игры без официального сервера. Да ладно тебе. Вон 0.7.0 спустя столько лет запустили. А чем тут хуже? Не хочу делать громких заявлений. Но ты представь сервер без арты, фугасов, голдострелов, дисбалансных имб, без необходимости сраной прокачки, с необходимыми правками ТТХ (быстрыми, а не полгода сбора статистики и "Ой, 268/4 чуть-чуть выбивается, мы не видели и не знали этого, когда вводили, ведь статистики не было, уууу.") . Не попробуешь? А, а, а? Проблема, как уже писал, в необходимости создать хоть какое-то подобие движения танка. У меня как-то исчезла мотивация, вот просто не хочется ничего по этой теме делать. Слишком много проблем возникает при решении одной проблемы, а результата не видно. Решил проблему - на тебе ещё несколько. Хотя пример реализации есть, попробовать можно скопировать один-в-один, хоть что-то будет, а потом по ходу поправить или переделать. Физический движок Newton, пример ArticulatedJoints, в котором есть подобное. Почему сам ещё не сделал - банально выдаёт ошибку при работе примера. Надо бы собирать на VS2012, а в VS2005 что-то не работает, на ассерте спотыкается. Кстати, цитирование криво работает. Почему блок цитирования появляется сверху, а не на месте курсора? Приходится перетаскивать. Очень не удобно. Ты на C(можно и ++) принеси. Вот тогда будет толк. У меня есть пример в UE4 (блюпринт вроде называется там это "программирование"). Толку-то от него. Нет. Тут это так не работает. Всё нужное более-менее есть. Даже от новой версии можно что-то брать. Всё-равно на низком уровне (сетевые пакеты) практически ничего не изменилось. Да. Когда нибудь. Может быть. Ну наверное. Ну, может быть, наверное. Запускаю-то не треню, а баттл арену.

@anomal3 Имел в виду ссылку на пример создания хотя бы многоколёсной техники. А примеры использования есть в каждом физическом движке. Мне не нужна физически точная симуляция. Точно не нужна детализация до траков. Все эти красивости нужны клиенту, у ВГ это сделано просто прекрасно. На сервере нужно сделать правдоподобное движение гусеничной техники. Кстати, а подвеска там работает? Если по неровной поверхности, например.

Никак. Опорные катки двигаются. Такая условность. И так, судя по видео, сделано у них. Это для клиента красота нужна. Для сервера ничего подобного не надо. Надо было сразу же привести ссылки на них. Сделать по примеру можно. Либо взять другой физический движок. Сейчас не проблема его сменить.

VS2005 последняя (возможно, ещё 2008), которая работает быстрее меня. Остальные - медленное неповоротливое нечто. Запуск ещё можно перетерпеть. Но настолько медленная работа IDE меня не устраивает. Например, в "Code Definition Window" код в 2005 показывается мгновенно, в других спустя 2-15 секунд. Специально проверял загрузку ЦПУ в этот момент, может из-за этого, но нет. Поэтому до последнего буду сидеть в VS2005. Не знаю, что делать, с чего начать, как сделать. Сейчас - гусеничная техника. Прикрутил. Физика есть. Ни в одном из них нет готового варианта. Суть физических движков одна, поэтому выбор (в данном случае) - дело вкуса. Нет, загружаю готовый. Это та же карта, что и в клиенте.

А что делать сейчас? Надо сделать возможность передвижения техники по карте. Потом усложнять. Толку-то от того, что в ангар зайти можно? Главное - танчики на карте, а не в ангаре, который, кстати, можно и не грузить вовсе, а сразу же создавать арену. На скринах, что были раньше, показано, что только и есть сейчас примитивная физика, т.е. гравитация и коллизия с ландшафтом. Есть пример из физического движка. Можно его на первое время попробовать. Проблема, что там C++, к тому же для VS2010 или даже 2012, а у меня древняя VS2005. И мне не нравится, как там сделано, это не raycast, а физические примитивы. Но этот пример хотя бы работает, пусть и плохо. Так нечего ещё. Зайти в ангар - это всё, что есть на данный момент. Ещё арену можно создать, но на скринах видно, что всё криво-косо спавнится. Там что-то непонятное. Видимо, в java так принято - десять вложенных папок и один файл в итоге. Этот проект,как понимаю, только авторизацию клиента производит. У меня это есть и это наиболее лёгкая часть. Есть там непонятные параметры, но на первое время они не мешают.

Это графический движок. А тут физический. Нельзя выгружать ничего вне зависимости от положения камеры. И камеры для физического движка нет. Проблемы, кстати, возникли. Мне не понятно, почему разработчик(и) физдвижка сделал фиксированный массив, но из-за этого при просчёте точки контакта возникает ошибка в дебаг-версии, в релизе просто молча будет проигнорировано. Но это не большая проблема, достаточно будет ландшафт разделить на ещё меньшие куски при экспорте в физический движок. При этом, физический движок обработал всю геометрию ландшафта без проблем. Нигде. Работа остановилась. Уже долгое время пытаюсь создать гусеничную технику на физическом движке. Успешно сделал только подвеску, так и она "сломалась" почему-то, хотя до этого работало всё нормально. Пытался искать примеры реализации гусеничной техники, но их нет. Есть множество для колёсного транспорта, но и те для четырёх колёс. Единственный пример находил, но он в Blueprint сделанный на UnrealEngine. При этом, мне не известно, как именно там сделано, всё ли raycast или только какая-то часть. Надо raycast, а не физическими примитивами. Или не надо и можно сделать по-другому. Но мне жутко лень.

Работа очень медленно продвигается. Но проект не заброшен.

@Monstrofil Не, так не считается. Есть sln? Нет! Значит нет и исходников. Точка, Ну да, оказывается есть, дезинформировал. Не обращал внимания на них. Точнее, когда искал, не находил того, что было нужно. Или не стал заморачиваться и разбираться. В общем, нинужно. Всё-равно от туда толком ничего не взять. Хотя придётся архитектуру движка в очень общем виде повторять. Последние думы привели меня к мысли, что придётся делать baseapp, loginapp, cellapp и другие app из-за того, что для каждого из них нужны немного разные данные клиента/сервера, что в скриптах отражено. Переписывать скрипты нет желания, лучше подстроиться под них. Когда-то спрашивал, как можно запустить несколько разных интерпретаторов питона в одном приложении. И пришёл к выводу, что проще сделать несколько разных процессов и межпроцессный обмен между ними. Побочным эффектом, кстати, может быть запуск их на разных компьютерах с обменом через сеть. Ну это если сделать. Но сейчас надо с техникой разбираться. Например, подвеска, то, что нужно для симуляции, расположение опорных катков. Думал брать из визуальной модели шасси. Только ничего не придумал. @SkepticalFox Писал уже, нет ещё ничего, чем делиться можно. Сначала надо сделать что-то рабочее.

Только это исходники до ВГ. ВГшного утёкшего, насколько мне известно, вообще ничего нет. Есть скомпилированные линуксовые бинарники, но ковырять их такое себе удовольствие. Хотя их и попроще было бы.

Это скрипты. К исходному коду отношения не имеет. И нужны исходники сервера, а их нет даже в утёкших исходниках BigWorld от 2009 года.

Пожалуй, надо попробовать возобновить разработку, хотя очень лень, а когда подумаю, сколько надо сделать, так всё желание отбивает. Не совсем правильно сделал, что создал тему до того, как будет что-то, чем можно поделиться. Энтузиазм угас, надоедает бороться с проблемами, которые порождают новые проблемы, решая которые опять возникают проблемы. Пытаюсь разобраться с физикой. В примерах к Newton есть демка гусеничной техники. Но разработчик движка честно предупреждает в одной из тем на форуме, что подобным образом созданная техника хороша для демонстрации. Создаётся достаточно просто - большое количество физических примитивов. Из-за этого будет просадка производительности, когда техники будет чуть больше, чем одна. Когда немного разобрался, как работает данная демка, удивился, что так странно выполнено. Один-в-один как в WoT https://youtu.be/-vO7qdL9Xh8?t=224 . Т.е. никаких гусениц, опорные катки не опорные, а работают, как колесо. Некоторое гугление позволило узнать новый термин - raycast vehicle. Вот это и надо будет создать. Один сервер - одна карта. Это моя изначальная задумка. Потому что иначе нужен кластер. Выбрать можно любую карту, которая есть в клиенте, как и любую технику, даже ту, для которой нет 3D модели, только грубый физический хитбокс (некий T23, средний танк США). Только сейчас надо прописывать в скриптах, какую карту грузить. У меня выбрана карта степи (или как её там), потому что есть дамп сетевого трафика именно с этой картой. Песчаная река, а не степи.

После начала раунда, когда сервер отправил всю информацию об арене, он отправляет пакеты с этим флагом. Используется в том случае, когда пакет не требует подтверждения доставки. У клиента увеличивается на единицу, у сервера, видимо, один счётчик на всех, начинается с любого числа, системы увеличения не нашёл. Первый пакет, например, 12360490, потом 12360511, 12360531 и так далее. На данный момент в эмуляторе не делал. Использую локальный mitm-клиент, который отправляет трафик на локальный сервер через библиотеку Enet, чтобы на данный момент мне не писать сетевой код. Как делать, знаю, позже реализую. Движок поддерживает до 65k методов. Когда их общее количество меньше 255, используется один байт на идентификатор метода. А когда больше, делает нечто, что на данный момент мне не известно. Т.к. у меня версия игры перед 1.0, то передо мной не стоит задача разобраться в этом. Но не думаю, что там сложно, надо бы сделать, просто нет желания. BigWorld остался прежним же, сетевая часть не изменилась вообще. Поэтому и mitm, чтобы подобное не делать каждый раз, как только выходит очередное обновление. У меня mitm-прокси не изменялся с тех пор, как его написал больше года назад. Добавил только запись в pcap файл перехваченного трафика, чтобы Rawcap постоянно не запускать. Проблема возникает, когда сервер хочет перенаправить клиент на другой сервер (сообщение switchBaseApp). В этом случае клиент уходит из mitm. @RUS_TAHK @Spectr20 Не знаю. Мне сейчас крайне лениво что-то делать, с момента последнего сообщения практически ничего нет нового. Поэтому по срокам ничего написать не могу. Постоянно возникают проблемы, сложности. Сейчас опять упёрся в то, что одна из секций в файле техники читается, но не записывается, когда есть константа IS_CELLAPP (это для сервера, означает боевую арену). Если IS_CLIENT, то всё нормально, но просто выставить IS_CLIENT нельзя, это сразу же тянет весь клиент с его GUI и прочим, что на сервере не нужно. Оригинальный сервер, по видимому, использует что-то другое, чего в клиенте игры нет. А когда что-то долго делаешь, но не видишь результата работы, желание делать уходит. Не то, чтобы всё забросил, но на данный момент надоело. Продолжу неспешно делать, о результатах буду писать. Когда появится что-то, чем можно поделиться (и будет стабильно запускаться), тогда опубликую.

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

Как? У меня есть желание сделать типа 3D вьювера того, что происходит на сервере. Но не представляю, как это должно выглядеть. Поэтому либо смотрю в клиенте, как работает, либо делаю экспорт в obj из физического движка, чтобы посмотреть уже в блендере, каким образом модель выглядит в нём. Ещё немного погуглил. Оказывается, triangle mesh может быть только статичным объектом. Не всё так просто в физике, как полагал изначально. Каким тогда образом накладываются, например, декали на танк от выстрела? Там же уже нужна точная 3D модель, а не упрощенная.