GPCracker

Да я и сам уже с самого утра это катаю, как скинул мне этот самый полупрозрачный зеленый кубик. Только вот до сих пор не могу вкурить, как это привести в правильный вид, т.е. сделать так, чтобы танк всегда был в этой коробке. Scale и offset. Вообще матрикс состоит из трех частей - scale, rotation, translation. rotation, если судить по осям коробки, правильный, он точно следует за танком, коробка сама не поворачивается, а лишь ресайзится и перемещается. К матрице bounds нужно применить пост-матрицу (т.е. уже на готовой коробке произвести какую-то трансформацию) которая сместит коробку в задний левый угол танка и отресайзит правильным образом. Матрица коррекции (ну это MP, если быть более точным) есть функция угла поворота танка (yaw). И не только. Вопрос в том, как собрать эту самую матрицу. Точнее интересует алгоритм, функции (большинство) уже есть на движке, и перемножить динамически две матрицы это не проблема. Трабла в том, что я не понимаю, что именно нужно сделать. Смысл? Этого достаточно в принципе. Нужен алгоритм. Абстрактный. Т.е. для любого угла поворота танка. И любого угла его наклона на поверхности. Да, кстати. Картофель использует эту штуку для позиционирования камеры аркадного режима относительно танка... Но что-то у них я траблов не замечал.

Короч, чет я не могу вкурить, что за хитрая трансформация там происходит, и самое главное как привести ее в нормальный вид. В общем, на основе имевшегося куска скрипта запилил добавление и удаление бокса по хоткею. Если выходить из боя с отключенным боксом - вылетов не ловил. М.б. кому-то удастся понять, как привести коробку в нормальный вид... Насколько я понял, вращать ее не надо, скорее всего будет достаточно грамотного оффсета и ресайза. bbox_view.zip

Для бокса модели. Компаунд, насколько я понимаю, это целая модель. Они и завезли производительности, выкинув "ненужные" расчеты, но не без косяков, как всегда. Короч, если что удастся понять - отпишусь тут полюбому. Погнал я наверное в треню... Upd. Хмм... А логика все-таки есть. 1. Пушка учитывается. 2. Ось Z танка и карты совпадают (yaw = 0), то матрица совпадает с правильной, т.е. в этом случае мы имеем что нам нужно. 3. Остальные случаи словами описать трудновато. Думаю, какую такую хитрую трансформацию нужно провести, чтобы вернуть матрицу обратно в нормальное положение.

Нее, там просто будет показываться этот самый бокс, об который коллижн считается. Просто он будет следовать за танком. Точнее, он будет как-будто приаттачен к танку. Кажется я понял прикол с вылетом. Я поймал вылет... когда танк, на который я повис [внезапно] сдох, точнее вылет был через полсекунды где-то после этого. Тем не менее, прикрутив bounds техники игрока, я наблюдал за коробочкой весь бой, ничего не вылетало. Походу дела прикол с вылетом происходит из-за смены модели, точнее ее принудительной уборки мусорщиком. Модель убивается, а привязанный к ней MP становится невалидным - отсюда краш. Ну по крайней мере я могу это только так объяснить. Возможно, это не единственный момент с крашами, и есть еще какие-то другие причины, но как говорится, говорю что вижу - после смерти отслеживаемого танка словил краш. Кстати, коробочка ведет себя довольно таки странно. Она вроде как следует за танком, но ее размеры зависят от разворота танка, и поворачивается она при повороте танка такое ощущение что вокруг одного угла. Надо в трене смотреть, на боевых репках обычно строго на месте не крутятся, если не ПТ, конечно. И кстати, пушка походу тоже учитывается. Такое ощущение, что картофель просто где-то накосячил в расчетах.

, ага, я как раз и вспомнил что кидали парни что-то подобное. Нашел в доках по BW. За кубик еще раз спасибо, по красоте зашло. Скрины Как видно, габариты толком даже не соответствуют размерам модели. Что будет дальше - посмотрю бой с такими эддонами, может удастся понять логику, если она тут есть. Блин, поначалу забыл про то, что картошка как всегда, и нельзя просто так взять и запавнить без вылета модель через терминал. Походу надо будет в этом деле порыться и сделать обертку в терминал для вызова таких вещей. З.Ы. Так и до графического отладочного режима не далеко... А это мысль, кстати :) З.Ы.Ы. И надо будет "сферу" с точки и радиуса перевести на offset-scale матрицу. Так с ней полюбому будет проще работать в динамическом режиме.

, спасибо. Кстати, для тех, кто не совсем в теме всего происходящего, небольшое пояснение, зачем нужен куб и почему именно куб. bounds This read-only attribute gives the bounding box for the model. It returns a MatrixProvider. The matrix specifies what transformation would need to be applied to a 1x1x1 cube placed at the world-space origin to scale, rotate and translate it to bound the model. The bounds themselves are read in from the <boundingBox> property of the .visual file that was used to create the model, and don't update to reflect the current pose of the model.Т.е. если применить MP к модели куба (пока правда не совсем понятно, как) и запавнить такую модель в пространстве, вокруг танка должна появиться эта самая коробка. Смысл полупрозрачности - чтобы лучше было видно сам танк.GUI с уголками выглядит конечно неплохо, но с ним тяжело дебажить, ибо непонятна ориентация коробки. Если удастся повесить MP для контроля над моделью, она сама будет кататься вместе с танком, точнее просто будет показывать его коробку в текущем состоянии. Единственно пока не совсем понятно, как прикрутить MP к модели... Хотя кажется уже понял. The Servo class is a Motor that sets the transform of a model to the given MatrixProvider. As the MatrixProvider is updated, the model will move.

Ну то что картошка как всегда это уже не удивляет. Насчёт в сторону дула - не подтвердилось, у меня на ручном тесте вообще разнобой какой-то был, зависимости смещения бокса модели от разворота частей танка я не увидел. Насчёт пропорции - да, вроде совпадают. Как время появится может еще раз загляну в это дело. Бокс без пушки можно и влоб посчитать по 8-16 точкам, только матричных операций будет ну уж очень много. Но можно. Есть вариант прикинуть попроще считая танк статичным просто взяв по минмакс aabb, прикинуть оффсет-скейл матрицу и помножить слева на МП танка. Так или иначе, танец с бубном и костылями получается, пока картошка не пофиксит. Кстати, такой момент - ни у кого случаем не завалялась модельки кубика метр на метр с начальной точкой в углу (0,0,0)/(1,1,1) по координатам, желательно полупрозрачного? Ну чисто графически в клиенте отрисовать эту коробочку в 3d,м может тогда какая-нибудь конкретика появится... Я AS и флешки [пока] не юзаю. Да даже если и буду - то уже сразу на AS3. Так что для меня эта проблема не актуальна.

Не, я конечно тебя понимаю, ты и многие другие хотят поскорее получить мод. Но только вот дело даже не в новых фичах. Дело в том, что и часть того, что раньше работало, тоже отвалилось. И я пытаюсь это пофиксить. Как раз таки одна из довольно интересных фичей - неточное указание цели. И опять же, дело далеко не только в новых фичах. Я еще попутно изучаю движок игры. За счет этого подвожу оптимизацию, исправляю ошибки и т.д. Вообще, для меня по большей части стимул в разработке модов это освоение питона и челлендж по части каких-то интересных алгоритмов, и подходов к их эффективной реализации. Делать мод ради мода как-то не особо интересно, учитывая что я уже довольно давно не играю. А так... Есть еще один интересный вариант, классы в движке, с которыми я пока не работал. Возможно через них будет какое-то решение. Upd 14. В общем, как временное решение можно посчитать bounds матрицу по габаритам танка с нормально повернутой башней. Для многих танков башня в принципе за пределы корпуса не выходит. Считать орудие смысла не вижу, ибо оно частично-коллизионное, да и машины типа гриля будут из-за него сильно раздуваться в расчетных габаритах. Габариты есть в typeDescriptor, ЕМНИП, и там виде двух угловых точек AABB. Пересчитать по ним offset-scale матрицу и помножить на matrixProvider самой техники... Что получится из этого - пока не знаю, но других идей как-то решить эту проблему пока не вижу. А там может картошка и пофиксит...

Upd 13. Да, с этими замутами картохи столкнулся не я один. Как вариант предлагают создать фейк-модель старого образца и у нее уже брать эту матрицу. Трабла только в том, что картоха, перейдя на компаунд, получила нехилую такую оптимизацию. Если впилить еще и фейковые модели, то фпс просто на днище провалится скорее всего. Короче, в данном случае это не решение вопроса.

Ага, и какой-нить хороший сайтик, чтоб было чем в бою заняться :)

Upd 10. Коллижн коробочки таки запустился... Только вот ведет себя как-то не совсем адекватно. Такое чувство, что коробочка немного меньше танка... Поработаю прицельно с камерой в реплее (ну там сканирование как в бою, по крестику прицела, только данные вручную обрабатываю через WST... не зря его пилил кстати, однозначно, очень сильно выручает), может пойму в чем прикол. Возможно, это как-то связано с переделками картохи по части движка и компаундов... Upd 11. Похоже я был прав. Уголки должны выглядеть примерно так же, как и в "светлячке" spoter'а (текстура, кстати, оттуда, за что ему отдельное спасибо). Но как видно на скринах, все немного не так. Коробка явно смещена вперед по курсу танка. Насколько и от чего это смещение зависит - еще предстоит понять. По крайней мере теперь я понимаю причину немного неадекватного поведения коллайдера - матрица немного не такая, как ожидалось. "А вот и скрины подъехали" Теперь, блин, задача - вернуть коробочку на место... Блин, да что за... Она до кучи еще и по-разному смещена у разных танков, причем независимо ни от системы координат карты, ни от координат танка... Хотя размер и ориентация похоже в порядке... Надо попробовать запилить оффсет в размер бокса и разворот по yaw на 180. Полюбас что-то одно должно сработать, ИМХО. Бл********ь, это просто полный П. Пробовал сдвинуть на минус 1, развернуть на пи/2, и инвертнуть координату z. Во всех трех случаях одна коробочка ровно ложится на фвшку, а вот вторая на другом танке находится вообще хз где, притом что преобразование для них выполняется одинаково. Реально П какой-то. Upd 12. Короч, я хз реально что они там запилили. О каком-то адекватном преобразовании вряд ли тут можно говорить, ибо величина этого смешения никак с размерами коробки или танка не связаны. Upd 12.1 Коробас можно сконструктить самому, только нужно для начала как-то получить размеры танка в зависимости от его текущего состояния... Короч, полный П, я не знаю, как это разрулить. Но без этой штуки вряд ли получится запилить BBox и BSphere. Upd 12.2 Да, ручками однозначно можно, в дескрипторе нужные боксы есть... Только даже если и написать такой алгоритм, комп его на хайлоаде явно не потянет без значительных потерь фпс. Короче, света в туннеле пока не видно. Спрошу у народа конечно насчет этой штуки, но не факт, что кто-то в курсе, что там нынче намутила картошка. В общем, с геометрическими сканерами пока тупик, пока висит эта трабла с PyCompoundModel.bounds.

Питон, господа, он самый :) Хотя, кажется, я уже начал понимать причины замены звукового движка - картохины "звукоделы" не подружились с питонщиками, и зная только звуковой движок не особо что-то могли сделать :)

Upd 7. Самое веселое как всегда напоследок. Остался модуль аналитической геометрии и модуль геометрического сканера. Нужно кой-чего (не буду грузить подробностями, ибо 95% все равно не поймут чего) переделать (есть идеи как оптимизировать BBox, что из этого получится - пока не знаю) и запилить BoundingSphere. Если все взлетит нормально, в AAS появятся новые плюшки (ну как вариант, если по производительности норм будет, поддержка, а может даже и захват цели, в режиме корректировки дальномера, при непрямом наведении). Upd 8. Что-то как-то тяжеловато этот ангем идет, особенно тесты. Давненько я матрицы и трехмерную геометрию в уме не считал. Тут еще это возможное попадание нуля в знаменатель... не говоря уже про то что вообще в одном месте может получится 0.0 / 0.0. Не, на выхлоп этот бред не пролезет никак, там min(max)/max(min) фильтрация, но его надо как-то грамотно и эффективно обработать. Хм... Правда вычислительная сложность всего этого дела значительно так (по крайней мере, по моим ощущениям) упала. По идее, должно значительно бодрее шуршать, чем раньше... но как говорится, если что - откатимся :) Запилил "сферу", норм, коллижн получился в одну строку для луча, и четыре строчки условно для сегмента (отрезка, заданного двумя точками), одна - все тот же луч, две - проверка на зону, где лежат точки (внутри/снаружи) и сравнение знаков косинусов, если обе точки снаружи, а луч "пробивает". Для луча - векторное произведение, все остальное скалярные и простые умножения/сложения, почти везде квадратичные (чтобы корни не считать). На тесте вроде ок, по скорости посмотрим позже, что из этого выйдет. Upd 9. Допилил таки "коробку", пришлось немного переработать алгоритм, в целях оптимизации вычислений взять за основу матрицу не прямого преобразования, а обратного, ибо она нужна бывает значительно чаще, ну и до кучи впилил отдельные функции для True/False тестов, ибо расчет конкретной точки там не важен, а значит выкинув его можно немного сэкономить. Запилил первичную версию "коробчатого сканера", м.б. на днях допилю "сферический", возможно даже тесты получится погонять. Пожалуй, надо сразу поискать реплеи для тестов. Благо есть где :)

А разве нельзя на стадии загрузки звуковых банков просто загружать только один? Например, в питоне подшаманить. Я так понимаю вы чисто на WW мутите, питон не используете?

Одна из причин необходимости обновления движка. То, что сейчас - это первая попытка, можно сказать публичная бета - тестил саму систему и идею. Оптимизации сразу завезти не получилось.

Судя по твоему описанию, похоже на какой-то баг. Или я чего-то не помню. Смотреть надо. В этом моде вообще все пилотируется еще устаревшим движком, я до него еще не добрался толком, да и нормальную версию движка еще до конца не допилил. Пока не могу придумать, как без костылей запилить, то что я хочу туда запилить. Если коротко, под движком мода здесь я подразумеваю VehicleAttachedEntityManager, по сути это специальный класс, который управляет связанными с танком сущностями, такими как маркеры на миникарте, контура и т.д.

Конфиг глобальный. Если ты вышел из боя со включенными маркерами, то следующий бой они тоже будут, пока не выключишь.

Ну для гита так-то тоже гуи есть... Только он мне пока не особо-то и нужен. Команд там не так уж и много надо... просто давно не коммиттил ничего.. с февраля где-то. Накатил серьезный патч на модуль аналитической геометрии, надеюсь это завезет немного скорости. Хочу навесить неточный захват на targetLock. По крайней мере хотя бы для поддержки цели. Конечно, гонять с захватом куда удобнее, чем искать постоянно точку для привязки дальномера, но постоянно перемещать прицел на танк для поддержки дальномера и пытаться "попасть" рентгеном в танк за холмом (без сквозных контуров) тоже не особо прикольно. В общем, хочу это дело немного подлатать, заодно и поправить пару старых багов. Да и модуль расчета дистанции дальномера пора бы уже оформить отдельно. Пока все в привате, пушить смысла нет, все равно не получится запустить, ибо еще сам толком не тестил, да и до интеграции еще как до луны пешком. Upd 1. В общем, сегодня пол-дня провозился с ридером для конфига. Переписал оный нуля, заодно и поправил кой-чего, впилил пару фич, впилил перехват xml_section перед непосредственным чтением таковой. Смысл эксперимента - запилить переназначение секции в конфиге. В другую часть конфига или вообще в другой xml-файл. Основа (то, что было раньше в немного переделанном виде) вроде работает, буду тестить ремаппинг, посмотрим, что можно из него выжать и получится ли вообще. Upd 2. Пути в лучшем случае будут только полными. Указать локально, т.е. "рядом с текущей секцией" не получится, придется писать локацию полностью. Ладно, будем тестить что есть :) Upd 3. Поправил пару недопечаток, вроде перенаправление робит как надо. Если что - дотестим уже на реальных конфигах. Довольно прикольно получилось, срабатывает практически отовсюду, даже на элементах списков и кастомных словарей. Короч, если все и в дальнейшем будет робить нормально, вместо <original_item>test_value</original_item>можно будет написать <original_item override="test_override.xml/override_item" />а по пути test_override.xml/override_item уже дописать <override_item>test_value</override_item>На строках, само собой, смысла особого не имеет, а вот на более крупных объектах - очень даже. В принципе можно весь конфиг заремаппить куда-нить, или его часть. Кстати, надо затестить, можно ли его так в res_mods/configs заремаппить :) Upd 4. ЛоЛ, рут тоже можно ремаппить на рут другого файла :) <root override="../configs/test_remap.xml" />Not bad, not bad. Upd 5. Гы-гы, веселая штука, дабл ремап тоже робит :) Короч, надо просмотреть еще раз и перенести из теста в библиотеку :) Upd 6. Бинго. Еще немного допилил, чтобы формат корня конфига тоже парсился. Поправил немного юзабилити, чтобы писать меньше букв. Походу больше сократить не получится. Значит можно и переносить.

Немного о том, как считается точка коллизии луча и ориентированной по осям ограничивающей коробки. Если представить такую коробку трехмерной и повернутой ("кубик", у которого все стороны разной длины), то получится как раз "коробка" танка. А луч - это тот самый "сканирующий лазер" камеры игрока. Это к вопросу, который возникает у многих, что такое BoundingBox, и чем он полезен. Вот кстати еще немного видео, по части поворотов предметов и не только в играх, если кому интересно. Блин, половину команд гита уже сходу вспомнить не могу...

Ух... Что-то уж больно потная сессия. В прямом и переносном смысле одновременно. В прямом - потому что реально жара, и в общаге без кондея на верхних этажах на солнечной стороне просто ****** конкретный. Надо сваливать на июль из общаги однозначно. В переносном - 15 предметов в общей сложности за этот семестр, из них 3 курсача и 6 экзаменов. 1 зачет чувствую пойдет на август, ну его нафиг, да и не успеваю уже. Все остальное разгреб более-менее успешно. Сегодня сдал последний экзамен. В общем, если все пойдет по плану, где-то через недельку плюс-минус думаю че-нить коммитну. Опять же, вся движуха параллельно с разработкой девайса на диплом (е**нуть за две недели перед защитой не вариант, не в нашем случае, ибо нужно чтобы в железе работало, а не только красивые схемы-чертежи намалевать, а на отладку порой до**я времени уходит), так что ничего особо не обещаю. Плюс в недавнем патче с AS3 картоха постаралась (это тем, кто про AnimatedSixthSense спрашивал), не стоит забывать также и про обновления движка. С последним правда более-менее разобрался "заочно". Короче, дел как обычно выше крыши, а времени и сил... Как-то так, в общем. Если что-то появится - оно первым делом появится на GitHub.

Событие одно, а варианта два. Сразу возникает машинный вопрос - какой выбирать? По сути ты и должен решить этот вопрос... установив рандомные (или не совсем) варианты одного эвента и заоверрайдив им звуковое событие (поле в xml). Что вполне логично.

Нужно ставить питон по-нормальному, кидать dll из системной папки в папку с питоном, привязывать Орион к полному питону. Ну как варик можно еще пиды скинуть в папку с Орионом, вопрос совместимости и версий - отдельная тема. Проблема в отсутствии нужных пидов, и ее уже неоднократно разбирали, читай тему. И неплохо бы научиться читать то, что тебе пишет отладчик (заботать инглиш, или научиться пользоваться гугл-транслейтом, и юзать гугл тоже уметь не помешает), и хоть немного думать головой, а не задавать в комьюнити элементарных вопросов.

Не, если конечно немного переделать, то можно беспалевно расшаривать обзор с созвзводным. Эффективность, конечно, ниже, но и палевность тоже. Хотя карт таких, где можно через всю карту простреливать, тоже не так уж и много. А что касаемо запуска - есть профильная тема, обсуждать все это дело лучше там, а не флудить здесь.

Еще один злостный читераст...

Я не говорю сейчас по патчи того, что уже есть. Там да, те еще пряники с заменой классов и т.п. вещами. Изначально тема создана с акцентом на интеграцию своих графических элементов, рассмотрение основных методов взаимодействия с ними, а также основных подходов к решению некоторых задач с использованием этих алгоритмов. Объяснить населению, что и как в принципе устроено, и как все это дело работает, за какие рычаги нужно тянуть, чтобы получить необходимый результат. А не просто слить кусок кода в стиле "разбирайтесь сами что к чему и для чего". А то, что в через XFW красиво - так это по сути запилили красивое API на тех же самых костылях. Не, не говорю ничего плохого, движение правильное, я как-бы тоже так часто делаю, вынося взаимодействие непосредственно с игрой в отдельные функции и модули. Местами (при правильном подходе) очень сильно упрощает последующие правки в процессе адаптации под следующий патч. Но прикол-то в том, что реализация мода на основе XFW не всегда оправдана. А вообще - красиво сделано то, что сделано с душой и полным пониманием всего происходящего процесса.