GPCracker

Upd. Дописал таки классы сканера целей. В общем, этот модуль раньше был кусками написан в хуках, теперь я его вынес в отдельный модуль, немного оптимизировал и (самое интересное) добавил новый функционал, вроде "коробочки" и "эллипса". Алгоритмы приоритетов для различных сканеров не особо простые на первый взгляд, но в принципе логичны и предсказуемы. Распишу что и как после релиза, пока кратко могу сказать, что новая система работает в двух режимах - захват и сопровождение цели. При помощи отладчика запустил все это дело на реплее. Результаты в общих чертах такие. Note: Буферизацию расчета матрикс провадера коробочки "от засвета до отсвета" пока не пилил, он в текущем виде считается (точнее собирается набором функций строк в 50 кода) каждый раз при запросе, что не есть гуд (жрет ресурсы, сколько - пока не ясно, но полагаю, что существенно), но для отладки сойдет. Note: У сканера довольно приличное количество параметров получилось, пришлось даже отдельный класс запилить, ибо заголовок инита расползался строки на три. Большая часть из них в последствии будет вынесена в конфиг. Note: Сканер целей работает в режиме непрерывного цикла, периодически запрашивает информацию у различных сканирующих модулей. В тестовом режиме (и скорее всего в релизе будет так же) интервал опроса 0.04 сек без учета времени выполнения запроса (интервал между стартами запросов). Note: Для тех, кто в танке. Повышение интервала опроса сканеров уменьшает их частоту, влияние сканеров на ФПС при этом значительно снижается. Но при если частота запросов будет меньше 24-25 раз/сек, то сканер будет работать в "импульсном" режиме, повышается шанс его несрабатывания в случаях, когда цель была обозначена на короткое время. Нормальный режим (наведение непосредственно на танк, при котором подсвечивается контур) при указанной частоте на ФПС заметного влияния не оказывает. Рентген (наведение непосредственно на танк, но находящийся за каким-то непрозрачным препятствием, контур не подсвечивается) - снижения ФПС тоже не замечено. Коробочка (самый тяжелый алгоритм, расчет "в лоб", без буферизации матрикс провайдера) - если грубо округлять в худшую сторону - на указанной частоте падение со 120 до 80 (по 15 союзникам в начале боя, в последствии расчет будет только по живым противникам, т.е. это худший случай в плане количества техники в расчете). В последствии, за счет оптимизации, падение, естественно, будет меньше. На сколько - пока не ясно, посмотрим в процессе. Эллипс-сфера в тех же условиях, что и коробочка (по сути тот же небуферизованный MP, округление в худшую сторону, те же 15 танков), дает падение со 120 до 105. Опять же пока не ясно, сколько из этого падения вытащит оптимизация. З.Ы. Это всего лишь ориентировочный отладочный сравнительный тест с целью проверки работоспособности кода. З.Ы.Ы. "Эллипс-сфера" дает весьма ощутимый выигрыш в скорости вычислений, но при этом ничем не хуже "коробочки" при захвате цели. Скрины того и другого (с единичным скейлом, при захвате используется обычно 1,5+) есть в постах выше.

Самое время начинать получать зарплату :)

@ReN28, по твоему логу:

Тоже на линуксе такое ставил. В разработке модов он не особо полезен, а вот при написании чего-то чисто под питон - довольно прикольная штука. Странно.. И что же ему не понравилось, интересно? Там же все сорцами прямо распространяется, просто в архив упаковывается. Обычный зип архив. Ага. На рубоарде есть тулза на вечный триал для касперского, KRT кажется называется, но тема видна только зареганным пользователям, раз в месяц двухминутная процедура и все, полный функционал, о обновлениями все ок. На тот же нод куча ключей в инете валяется. На вкус и цвет, короч. Чем лично мне больше нравится каспер - есть встроенный файрвол, через который довольно удобно можно резать прогам интернет, которым он не нужен.

Темы само собой на твой вкус и цвет. Из плагинов у меня стоит BracketHighlighter (подсветка скобок), FileDiffs (дифф между двумя файлами, да, ST3 умеет правильно раскрашивать диффы от рождения), JSONLint (подсветка синтаксиса JSON, поиск ошибок), Package Control, само собой, Show Character Code (мелкий плагин, показывает код символа), TrailingSpaces (подсветка и удаление ненужных пробелов в конце строки), ну и WoTScriptTerminal. Больше каких-то особых потребностей пока не возникало. Это на винде. На линуксе кроме этого есть еще пара плагинов, которые не очень комфортно и потребно ставить на винду (но в принципе возможно) (плагины-интерфейсы для различных сложных штук типа того же синтаксического анализа скрипта в реалтайме (название не помню, а винда в ext4 не умеет, посмотреть безе перезагрузки не вариант), не особо-то полезные для разработки под WoT). Ну и само собой русский и английский словари, для проверки орфографии, если конечно не хочешь клепать кучу опечаток и орфографических ошибок.

Всмысле? Нет, шарик внутри Scene Root. Не, моделится (ну всмысле конвертится) он нормально, только вот его смещение 0,5 по всем координатам относительно Scene Root пропадает, и его приходится задавать вручную на уровне перемножения матриц уже в клиенте, что не есть гуд. Слушай, а в том коде, что ты скинул... ротейшн часть где? Скейл и оффсет есть, а ротейшн куда-то пропал... Или я чего-то не понимаю? И потом... Ты тем кодом отдельно выкидываешь модели, и отдельно ноды, так? А где идет учет координат самих моделей, и структуры нод, в которых они находятся, ведь по сути глобальные координаты (трансформация) есть произведение матриц трансформации всех участков (нод). И еще, где-то читал, сейчас уже не получается найти, что есть еще parentInvertedTransform, или как оно правильно называется, и его нужно зачищать через alt+P кажется, чтобы задавать трансформацию относительно родителя. Короче, такие веселые пироги, все до конца не раскурил еще, да и увлекаюсь я моделями особо. По сути, для моделей, (ну насколько я понял, там у тебя два типа - пустишки-ноды и меши), ну вот я как раз про второе, если по простому делать, нужно брать глобальный трансформ модели и умножать его справа (потому что трансформ родителя применяется после трансформа потомка) на инвертированную матрицу Scene Root (глобальную трансформацию) (таким образом нейтрализуется трансформация Scene Root, умножение матрицы на обратную дает единичную, умножение на единичную - и так понятно, что можно пропустить), в таком случае ты получишь трансформацию модели относительно SceneRoot, который ты экспортишь. Это если не используется вложенность и последовательность преобразований, а трансформации соблюсти надо. Я что-то вообще в коде не нашел трансформа для моделей... Может плохо искал. Там так написано, что черт ногу сломит, все в перемешку :( или ты просто их тупо с единичной трансформацией кидаешь?

Непорядок :) Смещение самой Scene Root? Я про координаты объектов относительно Scene Root.

В общем, продолжение веселых скринов про коробочку. Пока сие создается при помощи некоторых костылей со смещением (скорее всего проблема связана с неправильным экспортом модельки, уточняю), но вообще подобный режим планируется как замена стандартной "коробочки" в местах, где важна производительность - коллижн тест (True/False) по сфере выполняется значительно быстрее. Правильную сферу тоже можно сделать, но для этого нужны дополнительные телодвижения и это дополнительные вычисления при ее расчете. По сути расчеты для движка практически элементарные, но с алгоритмами придется повозиться. Пока что не вижу весомых причин копать в эту сторону. Попутно проапгрейдил пару внутренних классов AAS. Кстати, существует весьма немаленькая вероятность, что первые версии после обновы будут вообще без GUI, ибо есть некоторые вопросы, по поводу того, как его правильно прикрутить в новых условиях.

, у меня закралось такое смутное подозрение, что "астероид" не учитывает смещение объектов относительно Scene Root... Или это всего лишь подозрение?

Не понял смысл фразы. Значит я был прав. :) Пока есть более приоритетные задачи. В частности, не мешало бы поднять то, что вообще не работает.

Для того, чтобы и "прицел" (правильнее - маркер орудия) не падал - нужно вводить костыли на уровне коллижн-тестов. Другого варианта я не знаю. Почему проваливается маркер орудия - подробно рассказано в теме AAS. Там вообще много чего интересного написано. НО НА РАБОТУ МОДА ПРОВАЛ СВЕДЕНИЯ НИКАК НЕ ВЛИЯЕТ. ПО БОЛЬШЕЙ ЧАСТИ ОНО ТАКИ И ОБОЗНАЧАЕТ ТО, ЧТО МОД РАБОТАЕТ. Ага. Чукча не читатель, чукча писатель.

ТС, прикрепи в шапку кеймап, а то ведь достанут же :) Ну или парсер добавь :)

@Alex2010g, @Хорунжий, прекращаем перепалку либо уходим в ЛС, ибо у всех остальных по большому счету нет желания это читать.

Ну это если сильно заморачиваться или если нужна именно статистика. Вообще даже на паузе игра перерисовывает картинку, так что можно иногда для некоторых ситуаций смотреть разницу даже на статике. А так - гонял и динамику. Там тоже ощутимой разницы по цифрам нет. Точно значение прям в единицах тут не имеет значения, ибо это только часть кода. Потребление ресурсов в данном постоянное и не зависит от игровой ситуации, значение имеет только количество коробок. ФПС больше на эффектах проседает, чем на расчете коробочек.

В общем, подвезу, пожалуй, более интересную картинку, раз уж на склад поступило :) Таки нашел я способ вычислить матрицу коробочки в динамике. Чисто математические преобразования. Не без костылей правда, но по большому счету там по мелочи, в виде трансляционных матриц вместо точек и минмакс по циклу, поскольку движок сравнивать больше 2х за раз не умеет. Нужно еще будет подвезти оптимизацию, ибо пока только в dev-режиме. Да, для тех, кому очень интересно - коробка динамическая, сама следует за танком, и считается на движке. При желании часть компонентов (например пушку) можно будет выкинуть на мороз из расчета, тем самым немного сократив количество точек в расчете. Рисовал правда только для своего танка, пока никакого заметного падения ФПС не обнаружил. На досуге запущу для всех союзников, понаблюдаю за результатом. Для противников пока не вариант, ибо нужно контролить засвет, иначе "здравствуйте, я краш вашего клиента". BoundingBox - Quadratisch. Praktisch. Gut. Upd. 15 коробок работают стабильно, влияния на ФПС не замечено. Хм... Даже клиент не вылетает, если танк пропадает из засвета. Просто теряет свою коробку где-нить и все.

Я про модельку уже в клиенте. Вся эта свистопляска с созданием своей модели кубика была из-за того, что у того, который ты мне скинул, не работала даже рут-нода, и к нему невозможно было ничего приаттачить. Ну и попутно грани разукрасил, раз уж на то пошло, докинул 9 дополнительных нод по углам и в центре. Те скрины, что я скинул в AAS - это как раз таки собранная аттачем моделька. Динамическая, само собой, твердо ездит вместе с танком без пинков под зад (ручных апдейтов), просадок фпс с ней не замечено, но суммарные бонды по ней все равно не получается считать. З.Ы. Если честно, я в моделировании не шарю от слова вообще, в 3D только чертежи разве что в компасе клепаю. Но там совсем другие пироги.

В общем, можно сделать так Но толку от этого все равно пока мало. Считать групповую коробку пока не получается. Но картинка прикольная :) Для желающих задать вполне логичный вопрос "почему стороны коробки стали разноцветными" сразу отвечу - для того, чтобы было видно, где у коробки origin, и как она вообще сориентирована. В данном случае - это задний левый нижний угол танка, ближний к камере. Низ синий, если что, но это не очень хорошо видно.

, мне кажется, или я тут случайно баг нашел? #export_bw_primitives_processed.py from .common import visual_property_dict должно быть from .common.consts import visual_property_dict Трейс из консоли тупо не копируется :( По крайней мере я не нашел способа... Upd. Да, если так зафиксить, оно таки без ошибок экспортится. Надо будет потом текстурки подрихтовать, и вообще козырно будет. По крайней мере, ноды грузятся нормально.

Error: mesh.uv_layers is None Как с этим бороться?

Что-то у меня никак не получается экспортировать модель. Вместо .model экспортер упорно подставляет .temp_model, но с ним никаких файлов в указанной папке не создается. Экспортировал как написано тут, под спойлером про Blender. Пути в настройках прописывал, поиск танков работает нормально. Только вот они мне не особо нужны... Это баг, фича, или я что-то делаю не так?

@Pavel3333, типа как, к примеру, на ютубе? Хм... Чтобы смотреть, сколько хейтеров зашло в тему? :)

Вот самое интересное. Дифф между двумя патчами. Хоть блин самому считай эту матрицу... Кстати, для статики бонды есть. Только вот как их по-шустрому в динамику перегнать, и с учетом трансформаций самого танка... Тот еще вопрос. Учитывая, что нужна MPшка, а не матрикс. Upd. Чисто случайно наткнулся. У сервера свои коллижн-модели танков. Теперь понятно "как непробил!?" (шутка). А правда, в чем интересно разница между клиентскими и серверными моделями?

Самое что интересное, у картохи вроде как все ок работает, или они не используют этот bounds... Хотя, зачем тогда слать как аргумент. Если выполнить такой код в аркадном режиме BigWorld.camera().setDynamicColliders([])То можно "заглянуть внутрь своего танка". Точнее залететь камерой внутрь корпуса. Без этого кода камера будет не попадать внутрь танка, а отлетать вперед/назад. Решил по приколу заскейлить в 2 раза bounds, перед тем, как отдавать его в составе коллайдеров... Ничего не изменилось. Такое ощущение, что он вообще не юзается. Даже если в 10 раз увеличить.

Ну как-бы получает доступ из питона, но отправляет в модули движка, причем в те классы, которых в документации 15.3.1 нет. scripts/client/AvatarInputHandler/DynamicCameras/ArcadeCamera.py def __setModelsToCollideWith(self, vehicles) И улетает в классы BigWorld.ThirdPersonProvider() BigWorld.HomingCamera() Ни у кого случаем доки на BW поновее 15.3.1 не завалялось?