Dragon armor

@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 модель, а не упрощенная.

Не, на википедии в статье о Bullet, а потом в гугл полез. Мне теория нужна, поэтому не принципиально, какой движок и какая версия.