Jump to content
Korean Random

GPCracker

User
  • Content Count

    2,827
  • Joined

  • Last visited

  • Days Won

    61

GPCracker last won the day on April 25 2019

GPCracker had the most liked content!

Community Reputation

2,084 ⭐⭐⭐⭐⭐

4 Followers

About GPCracker

  • Rank
    Piranhas Team
  • Birthday 11/05/1994

Basic information

  • Gender
    Мужчина
  • City
    Москва
  • Interests
    Схемотехника, программирование и телекоммуникации.

Recent Profile Visitors

25,508 profile views
  1. Это не глюк. В режиме корректировки дальномера препятствия не учитываются (в противном случае теряется основной смысл корректировки дальномера - вертикальная стабилизация орудия на границе перекрывающего цель объекта). Вся интересующая тебя математика расчетов прописана здесь. За маркер орудия отвечает отдельный алгоритм интегрального (рассчитывается по точкам) баллистического (с учетом траектории полета снаряда) теста на столкновения, там учитываются все влияющие на полет снаряда объекты. Когда удаленная цель перекрыта близким объектом, маркер орудия отображается выше перекрестия прицела. Когда близкая цель маячит на фоне неба или далекого ландшафта, маркер орудия будет проваливаться существенно ниже перекрестия прицела, поскольку точками прерывания баллистического коллижн-теста могут быть только твердые (влияющие на полет снаряда) объекты или же граница локации. Первую проблему без кучи костылей и велосипедов решить нереально, да и смысла особого в этом нет, поскольку это своего рода маркер, показывающий игроку, что какой-то близкий суслик (его вроде не видно, а он есть) мешает стрелять. Для второй проблемы есть плагин AimCorrectionGunMarkerFix, подключаемый в нужном режиме прицеливания как раз таки через этот самый параметр. Есть два режима выбора дистанции для корректировки дальномера - ручной, когда удерживается клавиша, и автоматический, когда дистанция определяется с учетом выбранной игроком цели в автоматическом режиме. За целеуказание (механизм определения наиболее вероятной цели игрока) отвечает модуль TargetScanner, его параметры настраиваются здесь. В некоторых ситуациях скрипты модификации могут не совсем корректно понимать интересы игрока, поэтому отключать информационные панели не рекомендуется. Параметры графического интерфейса настраиваются здесь, сам интерфейс на работу модулей целеуказания и корректировки дальномера влияет так же, как линейка на размер... монитора, то есть никак, информационные панели нужны исключительно для контроля за текущим состоянием (которое иногда может отличаться от ожидаемого игроком). Точка прицеливания (куда именно наводится орудие) трехмерная, а прицел у игрока двухмерный (вверх-вниз, влево-вправо). Параметром дальности управляет система прицеливания в игре в автоматическом режиме, причем незаметно для игрока. Корректировка дальномера влияет лишь на выбор расчетной дальности, определяющей угол возвышения орудия (для понимания сути вопроса настоятельно рекомендую ознакомиться со старой советской литературой), в само же прицеливание, то есть наведение орудия на цель (то, что игрок обычно делает мышкой), модификация не вмешивается (заранее оставлю специальное отдельное пояснение для особо одаренных - модификация ни на слабые точки, ни на танки в целом орудие не наводит, на упреждение никого не берет). По сути Advanced Aiming System делает то же самое, что и BalCalcMod от Ktod, только в автоматическом режиме. По умолчанию орудие в игре наводится на ближайшее твердое препятствие (линейный коллижн-тест в точке перекрестия прицела), влияющее на полет снаряда (ландшафт, элементы окружения локации, танки противника, граница локации). Стандартный алгоритм прост и примитивен, но у него есть существенные проблемы, вызывающие регулярное адское воспламенение пятых точек танкистов, у которых руки не под хрен заточены. Во-первых, нереально нормально выстрелить в точку, где танка противника еще пока нет, но он там будет в момент подлета снаряда. Иными словами, проблематична стрельба из любых бревнометов (орудий с низкой скоростью полета снаряда) по любому движущемуся или играющему от башни противнику, стрельба на упреждение на фоне далекого ландшафта или границы локации. Во-вторых, выбивание разного рода сусликов (которые вроде как и не светятся, но они там есть, ибо ваша лампочка не может срабатывать сама по себе) из кустов на фоне неба тоже порой вызывает, мягко выражаясь, проблемы (происходят регулярные так называемые перелеты, когда снаряд пролетает аккуратно над целью вместо попадания в нее). В-третьих, стоять и отхватывать откровенно излишних проблем со здоровьем в ожидании нормализации орудия по дистанции стрельбы после выезда из-за угла (а иначе вместо выстрела происходит какой-то плевок в землю) тоже мало кого прикалывает. А собственно, весь этот приход белого пушного зверька происходит по одной лишь простой причине - нарисованные танкисты не в курсе, что адекватный игрок принципиально не собирается обстреливать ландшафт, здания, границу локации и прочие статичные объекты, у него только одна цель - танки противника. А потому и дальномер нужно выставлять согласно дальности до противника, а не до хрен знает чего (не, ну логично же, блин). Почему этого до сих пор не поняла картошка, спросите вы? Ну так адекватные товарищи, которые изначально занимались разработкой системы прицеливания в игре, это понимали, но нормально решить данную проблему автоматического дальномера можно только лишь отказавшись от автоматического дальномера вовсе, то есть реализовав прицеливание по принципу снайперских винтовок в Battlefield 4 или Sniper Ghost Warrior, но любой подобный вариант был бы слишком сложным для целевой аудитории, а еще бы негативно влиял на динамичность игры. А если же решать эту проблему в рамках автоматического дальномера, то все сводится к сложной системе целеуказания, для нормальной работы которой без прямого вмешательства игрока (вроде нажимания и зажимания кнопок на клавиатуре и тому подобной фигни, совершенно неприемлемой для большого проекта, ориентированного на домохозяев) необходимо написать кода на несколько тысяч строк как минимум, если не больше (примерно столько же, сколько сейчас занимают основные модули модификации и все необходимые функции из библиотеки). И еще при этом каким-то образом объяснить целевой аудитории, как это все работает. Учитывая относительно незначительный процент людей с мозгами (замечающих данную проблему) и элементарным чувством собственного достоинства (не привыкших жрать кактус), все это дело совершенно никак с точки зрения большого бизнеса не оправдано, а потому на исправление данного косяка успешно и невообразимо надолго забили болт и положили еще один сверху. А те разработчики, что пришли уже позже, так и вообще не понимают толком, о чем там речь идет, и чего старожилы и редкие новички до сих пор периодически бомбят в профильных темах. В общем, данная проблема изначально решалась (и до сих пор решается) исключительно силами сообщества. Оставлю это здесь на всякий случай. Не стоит путать понятия "точка прицеливания" и "точка построения маркера орудия" (или просто "маркер орудия"). Маркер орудия (gun marker) - так внутри скриптов официально называется "сведение". Точка построения маркера орудия трехмерная, и является результатом интегрального баллистического коллижн-теста. Центр "сведения" - это проекция точки построения маркера орудия на экран монитора. Что касается точки прицеливания, она тоже трехмерная, но ее проекция всегда находится в середине перекрестия прицела (неподвижной части графического интерфейса). Если перевести сказанное выше на язык артиллеристов, то точка прицеливания - это место, куда пытается навести артиллерийскую батарею (танк на сервере) корректировщик (клиент игры), а точка построения маркера орудия - место, где по расчетам (теоретически) артиллеристов (серверный прицел) или корректировщика (клиентский прицел) снаряд должен столкнуться с каким-то твердым препятствием, если выстрелить прямо сейчас, не дожидаясь полноценного наведения орудия на цель. Все дело в том, что орудие в игре сводится экспоненциально. Это пороговое отношение множителей разброса (текущего к минимальному), ниже которого можно условно считать сведение полным (математику можно посмотреть здесь). #точка-прицеливания #aiming-point #маркер-орудия #gun-marker #сведение #корректировка-дальномера #aiming-correction #провал-сведения #сканер-целей #target-scanner #частые-вопросы #faq
  2. Тсс, не пали контору :) Ну а если серьезно, то при активной корректировке дальномера используется текущее расстояние до танка противника (или заданное вручную расстояние), а все препятствия между камерой игрока (точка игрового пространства, откуда игрок смотрит в большой мир) и танком противника игнорируются. Данный подход позволяет решить "проблему угла" - при выезде из-за близко расположенного к игроку укрытия и стрельбе по удаленной цели при прохождении прицелом визуальной границы между близким и удаленным объектами происходит резкое увеличение расчетного расстояния дальномера, и орудию требуется некоторое время на нормализацию по высоте. Если же игрок попытается выстрелить до того, как орудие поднимется на нужный угол вертикальной наводки, то вместо нормального (ожидаемого игроком) выстрела происходит так называемый недолет. При активной автоматической корректировке на дальномере всегда выставлено правильное расстояние, и никаких "нормализаций угла наведения орудия" при выезде из-за укрытия не происходит. Что же до продемонстрированного в ролике трюка, то это своего рода unexpected but useful behavior (неожиданное, но весьма интересное поведение). Keep calm! It's not a bug, it's a feature!
  3. В баллистическом (вид от траектории) режиме прицеливания корректировка не работает (вне зависимости от того, какой вид используется - стандартный перспективный или дополнительный ортогональный). На данный момент она не реализована в принципе (там просто стоит заглушка, которая ничего не делает), по причине отсутствия реальной необходимости в ее [корректировки] наличии, а равно как и четкого понимания, что и как именно необходимо корректировать. Если ты реально гуру и понимаешь, как модификация работает с математической точки зрения (как осуществляются расчеты при корректировке прицеливания), и имеешь четкое понимание, что именно, в каких ситуациях, при каких условиях, а, самое главное, как и зачем нужно корректировать в этом режиме прицеливания, или хотя бы можешь нормально описать (картинки приветствуются) те ситуации, в которых в этом режиме прицеливания наведение фактически осуществляется не туда, куда игрок в действительности хочет прицелиться, и при этом погрешность получается весьма существенной (что приводит к частым неслучайным промахам), you are welcome, ну то есть пиши, обсудим.
  4. Предлагаю для всех типов данных и контейнеров обдуманно и осознанно выбирать базовые типы. Везде и всегда. Предлагаю посмотреть как это реализовано у меня - в код модификации вшита базовая структура файла конфигурации, в ней для каждого параметра прописаны типы данных и значения по умолчанию. В процессе чтения файла конфигурации происходит автоматическое преобразование полученных из файла сырых данных в целевой объект данных в соответствии с указанным в базовой структуре типом, определяющим характер и последовательность преобразований. К примеру, так в базовой структуре конфигурации выглядит сочетание клавиш, так оно прописано в файлах конфигурации, в конечной рабочей конфигурации параметр является экземпляром вот этого класса, а вот, собственно, цепочка преобразования (раз, два). А вот как выглядит проверка и что происходит на самом деле. Еще немного магии происходит здесь и здесь. В результате проверки получается обработчик, который и управляет конечным значением параметра. Параметр switch определяет, в каком режиме работает сочетание - переключатель (каждое нажатие инициирует переключение статуса на противоположное) или кнопка (активный статус только при удержании в нажатом положении). Параметр invert инвертирует push-событие клавиатуры - переключатель срабатывает на отпускание основной клавиши сочетания, а кнопка возвращает неактивный статус при удержании клавиши в нажатом положении (для примера). Параметр repeat включает обработку повторов при длительном удержании клавиши в нажатом положении, практически никогда не используется. Чтение локализованных текстовых шаблонов с макросами реализовано аналогичным образом - так описан шаблон в базовой структуре конфигурации, а так он выглядит в файлах конфигурации (это ссылка на файл локализации). Полную цепочку преобразований при необходимости отследишь самостоятельно. Вот так скромно и неприметно выглядит форматирование текстового шаблона в коде модификации, а вот что происходит на самом деле. Думаю в качестве примера по переносу сложности из логики в данные вполне пойдет. Что касается кода в классах (типах) данных - он пишется один раз, отлаживается в модульном режиме, после чего про внутренности можно вообще забыть, особенно если при разработке модуля были предусмотрены все возможные (адекватные и логичные, естественно) варианты его использования, и вероятность возникновения необходимости добавления дополнительного функционала минимальна. Так что у меня уже давным-давно металл автоматически конвертируется в танки, причем тихо, скромно, неприметно и практически беспалевно. Могу лишь настоятельно посоветовать прочитать внимательно предоставленные ранее материалы еще раз с самого начала. Хотя ладно, пожалуй немного упрощу тебе задачу. Хуки - это интерфейс, а модули и классы - это движок. Разделяй и властвуй. А при отладке некоторых модулей (при правильном подходе к их написанию) можно обойтись даже без клиента игры, хватает и обычного питона.
  5. Нашли тоже чем удивить. И, судя по всему, проблему вызывает код плагина снайперского прицела на артиллерии. Без логов питона точно сказать не могу. На всякий случай попробуйте его отключить.
  6. Это называется "утечка памяти". Не используй list для статических контейнеров, для них существует тип tuple. Не используй mutable object в качестве default value. Если сваливать всю сложность в логику, то со временем можно заблудиться в коде. Чем проще логика, тем проще отлаживать программу. А для отладки типов данных существуют unit-тесты.
  7. Да я понял, что ты сделал, я только не понял зачем было переделывать сборщик, если там и так все нормально работало. К тому же практически любые корректировки в процессе сборки делаются с помощью правки файла конфигурации без необходимости править сам скрипт. Не, ну тебе оно, конечно, оттуда виднее, просто вот лично я не вижу какого-то очевидного профита от данных действий, потому, собственно, и возникает извечный русский вопрос :)
  8. Проблема известна и уже висит в списке приоритетных задач. К сожалению, костылями вроде "добавления метра" она полноценно не решается. Там нужно писать специальную логику, которая будет вносить соответствующие поправки в расчеты с учетом расстояния до цели, ее габаритов, а также баллистики снаряда. В противном случае могут быть проблемы, связанные с некорректным отображением маркера орудия в некоторых ситуациях. P.S. А я тем временем убил минут пятнадцать, пытаясь безуспешно выбить из поиска по теме историю обсуждения данной проблемы. Однако, как выяснилось чуть позже, я искал черную кошку в темной комнате, где этой самой кошки никогда не было - данная проблема в этой теме никогда не обсуждалась. Поэтому убедительно прошу не использовать систему личных сообщений для запроса функционала, сообщения об ошибках и тому подобных вещей, если они относятся к релизным версиям модификации и могут быть интересны другим пользователям. Если прямо ну уж очень хочется закостылить - раз, два. В данных строках в конце тупо и незатейливо прибавить к дистанции нужные вам скалярные полтора метра. Но далеко не факт, что все будет нормально работать, и маркер орудия будет отображаться без косяков на разных дистанциях. Я вот только не понял, зачем так извращаться и полностью перебирать систему сборки, если она и без того полностью автоматизирована и к тому же легко конфигурируется? Неужели и правда так сложно просто разобраться с зависимостями?
  9. Да вообще все делается по красоте, просто добавляется что-то вроде (я этот код не тестировал, если что) if os.path.basename(os.getcwdu()) in (u'win32', u'win64'): path = os.path.normpath(os.path.join(os.pardir, path)) и никаких проблем с обратной совместимостью.
  10. Если произойдет неудачное вклинивание другого потока на участке, где изменен рабочий каталог, есть все шансы словить внезапный кластерфак (физический поток в питоне один, а вот ресурс общий). К тому же при постановке на ожидание завершения системного вызова (блокирующие операции ввода-вывода) с очень большой долей вероятности (я бы невероятно удивился, если бы было иначе) GIL будет освобождаться, и, следовательно, захватываться другим потоком.
  11. То есть, по твоему скромному мнению, в подобной ситуации, когда на обновление модификации у автора нет ни времени, ни технической возможности, вместо того, чтобы хоть как-то попытаться хотя бы временно адаптировать (или помочь окружающим это сделать) модификацию под новый клиент, автору будет целесообразнее просто послать всех лесом и уйти в сиреневый туман? Хорошо, спасибо, буду знать. Специально для тебя, и того, кто ставит минусы под моими сообщениями, поясняю по всей видимости до сих пор не понятую вами вещь - продакшн расположен в репозитории, а то, что выкладывается в теме в настоящее время, это хотфиксы. В переводе на понятный русский - это временная заплатка, призванная скомпенсировать проблему до момента, когда она будет надлежащим образом решена при помощи полноценного обновления модификации. Когда будет это обновление - как только [у меня появится время на модификации], так сразу. Недовольные всегда найдутся, что бы ты не делал, как бы ты это не делал, и делал ли бы ты вообще хоть что-то. Так что я уже мало чему удивляюсь. Открою тебе маленькую тайну - далеко не факт, что авторы документации на пакеты модификаций (в которых этот загрузчик вообще вскользь упоминается, ибо весь документ немного о другом), и авторы непосредственно кода загрузчика одни и те же люди, далеко не факт. Это во-первых. А во-вторых, я ориентируюсь исключительно на то, что именно делается, а не на авторитет того, кто это делает. Если я вижу какую-то фигню, я прямо и конструктивно говорю, что это фигня. И мне абсолютно все равно, кто ее автор. Я бы понял, если бы этот загрузчик был чьей-то модификацией, для начинающего мододела (ну или для чисто пробного проекта, когда надо просто что-то по-быстрому проверить) это приемлемый уровень кода. Но для продакшна достаточно крупной компании, это, извините, ни в какие ворота не лезет. Meld + Text Filters. Там изначально есть фильтр для комментариев. Выставить правильно контрольные точки при необходимости и все должно нормально сравниваться.
  12. И это мне говорит человек, который, по всей видимости, тему вообще не читает. Потому как едва ли не каждый, кто подписан на эту тему, знает причину, по которой я последнее время не выкладываю ничего на GitHub - у меня в данный момент просто банально нет ни времени, ни технической возможности полноценно заниматься разработкой, да и заливать в продакшн не проверенный надлежащим образом и хрен знает как собранный код (как это делают многие мои коллеги) мне совесть не позволяет. Похоже кто-то просто очень плохо знаком с внутренностями CPython, раз утверждает подобное. Читай PEP 302, и обрати особое внимание на ресурс, где это опубликовано. Кстати, если ты не в курсе, именно таким образом, через import hook, картошка грузит свои Python модули. Только этот хук реализован на C и подрублен одним концом к ResMgr, вторым к Python. А ты хочешь сказать что это не так? Там сплошные костыли и косяки. Порядок загрузки модулей хрен пойми какой, у автора модификации он может быть один, у пользователей другой. Пользователи кричат, что у них проблемы с совместимостью с какой-то другой модификацией, автор кричит - не воспроизводится. Потому как порядок импорта определяет порядок установки хуков, а некоторые модификации применяют полную перегрузку метода и тем самым выкидывают на мороз все хуки, сделанные до них. Пакетные модули загрузчик грузить не умеет, подхватывать и автоматически компилировать текстовые модули тоже не умеет (даже при том условии что клиент принципиально понимает только скомпилированные файлы, компиляция без проблем делается в реальном времени, там кода на пару строк всего). В динамические модули загрузчик тоже не может, весь код написан хрен пойми как (даже мододел и то наверное лучше напишет), загрузить что-то вне очереди нереально, досрочно выгрузить тоже. А еще в этих исходниках указана версия клиента игры, под которую они собраны. Никто не мешает просто взять распакованные скрипты клиента той версии, скрипты текущей, сделать directory diff в том же meld, пробежаться по ключевым модулям, которые определены в разделе импортов модификации, посмотреть их diff и определить, что именно и как нужно исправить. И это без учета того факта, что я при возможности выкладываю патчи, которые с помощью git apply можно тупо и незатейливо на репозиторий применить, в крайнем случае воспользоваться мозгами и merge tool и замержить все это дело ручками. Если кто-то не умеет пользоваться элементарными инструментами системы контроля версий, то это его личные проблемы. И да, это я еще забыл про подход индуса - просто залить старую версию в новый клиент и править ошибки по мере их появления. Если ты до сих пор еще не понял, данный мод практически никто не пытается реабилитировать не потому, что я как-то криво исходники выкладываю, или информацию зажимаю, а просто потому, что уровень этой модификации существенно превышает средний по больнице сообществу мододелов, и далеко не каждому мододелу под силу понять лежащие в основе модификации механики. А те, кто в состоянии понять и разобраться, либо как и я страдают от дефицита времени на модификации, либо и вовсе уже давным давно забили на модификации вообще.
  13. Индус в сходных условиях, к твоему сведению, вообще вряд ли что-то сможет написать. Потому как работоспособность индусского кода достигается путем многократных попыток его отладки. Х**к, х**к и в продакшн, а куда же еще. Хорошо хоть картошка пока до критической инфраструктуры не добралась. Это как раз ты немного не понял суть моего недовольства. Если на твоих примерах, то это все равно что если бы ты, заезжая в новую квартиру, решил поменять розетку и с удивлением обнаружил, что в электрическом щитке вместо как минимум разделения питания на группы и отдельного автомата на электроплиту все подключено на один хлам-рубильник (даже не автомат), а то и вовсе на скрутку, до кучи залито монтажной пеной (это к тому, что к коду загрузчика вообще не подлезть), да и сам щиток сходу хрен откроешь, потому что кто-то прихватил его сваркой, чтобы щиток внезапно не открывался по причине сломанного замка (использование костылей). Как-бы вроде все работает и свет-то дома есть, но как-бы что-то тут не так... Донатоприемника нет, и вряд ли когда-то будет. Не хочу делать из хобби работу, да и, как показывает практика, деньги портят взаимоотношения.
  14. А ты попробуй обновить модификацию, не имея возможности ее скомпилировать, запустить и, собственно, протестировать (ну к примеру, сидя с мобильника или планшета). Может быть поймешь, в чем прикол :)
  15. Для выпуска хотя бы хотфикса нужно иметь доступ к основному рабочему компу, где есть установленный клиент игры и весь необходимый для запуска сборщика софт. Для нормального обновления модификации (это когда обновление получает версию и публикуется на GitHub) требуется еще и куча времени на полноценное тестирование и работу с git. Если я сижу за компом, на котором вообще ничего этого нет (ну разве что кроме текстового редактора и браузера, как говорится, и на том спасибо), и накатывать все необходимое у меня нет ни возможности, ни желания, то каким образом ты предлагаешь собирать нормальное обновление? В таких условиях diff это максимум, хотя и он генерируется наполовину вручную. В данном конкретном случае diff будет затрагивать сразу кучу файлов, будет длиннее транссибирской магистрали и как следствие с весьма большой долей вероятности будет иметь проблемы в плане инвариативности мержа. При этом все, что требуется сделать, это тупо выполнить найти и заменить все в текстовом редакторе и запустить сборку модификации. Для меня в данном случае гораздо проще по-быстрому написать дикий костыль из кривых импортов код, который просто создаст зеркало нужного мне модуля в старом месте.
×
×
  • Create New...