Jump to content
Korean Random

GPCracker

User
  • Content Count

    2826
  • Joined

  • Last visited

  • Days Won

    61

GPCracker last won the day on April 25

GPCracker had the most liked content!

Community Reputation

2076 ⭐⭐⭐⭐⭐

4 Followers

About GPCracker

  • Rank
    Piranhas Team
  • Birthday 11/05/1994

Basic information

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

Recent Profile Visitors

24779 profile views
  1. Тсс, не пали контору :) Ну а если серьезно, то при активной корректировке дальномера используется текущее расстояние до танка противника (или заданное вручную расстояние), а все препятствия между камерой игрока (точка игрового пространства, откуда игрок смотрит в большой мир) и танком противника игнорируются. Данный подход позволяет решить "проблему угла" - при выезде из-за близко расположенного к игроку укрытия и стрельбе по удаленной цели при прохождении прицелом визуальной границы между близким и удаленным объектами происходит резкое увеличение расчетного расстояния дальномера, и орудию требуется некоторое время на нормализацию по высоте. Если же игрок попытается выстрелить до того, как орудие поднимется на нужный угол вертикальной наводки, то вместо нормального (ожидаемого игроком) выстрела происходит так называемый недолет. При активной автоматической корректировке на дальномере всегда выставлено правильное расстояние, и никаких "нормализаций угла наведения орудия" при выезде из-за укрытия не происходит. Что же до продемонстрированного в ролике трюка, то это своего рода unexpected but useful behavior (неожиданное, но весьма интересное поведение). Keep calm! It's not a bug, it's a feature!
  2. В баллистическом (вид от траектории) режиме прицеливания корректировка не работает (вне зависимости от того, какой вид используется - стандартный перспективный или дополнительный ортогональный). На данный момент она не реализована в принципе (там просто стоит заглушка, которая ничего не делает), по причине отсутствия реальной необходимости в ее [корректировки] наличии, а равно как и четкого понимания, что и как именно необходимо корректировать. Если ты реально гуру и понимаешь, как модификация работает с математической точки зрения (как осуществляются расчеты при корректировке прицеливания), и имеешь четкое понимание, что именно, в каких ситуациях, при каких условиях, а, самое главное, как и зачем нужно корректировать в этом режиме прицеливания, или хотя бы можешь нормально описать (картинки приветствуются) те ситуации, в которых в этом режиме прицеливания наведение фактически осуществляется не туда, куда игрок в действительности хочет прицелиться, и при этом погрешность получается весьма существенной (что приводит к частым неслучайным промахам), you are welcome, ну то есть пиши, обсудим.
  3. Предлагаю для всех типов данных и контейнеров обдуманно и осознанно выбирать базовые типы. Везде и всегда. Предлагаю посмотреть как это реализовано у меня - в код модификации вшита базовая структура файла конфигурации, в ней для каждого параметра прописаны типы данных и значения по умолчанию. В процессе чтения файла конфигурации происходит автоматическое преобразование полученных из файла сырых данных в целевой объект данных в соответствии с указанным в базовой структуре типом, определяющим характер и последовательность преобразований. К примеру, так в базовой структуре конфигурации выглядит сочетание клавиш, так оно прописано в файлах конфигурации, в конечной рабочей конфигурации параметр является экземпляром вот этого класса, а вот, собственно, цепочка преобразования (раз, два). А вот как выглядит проверка и что происходит на самом деле. Еще немного магии происходит здесь и здесь. В результате проверки получается обработчик, который и управляет конечным значением параметра. Параметр switch определяет, в каком режиме работает сочетание - переключатель (каждое нажатие инициирует переключение статуса на противоположное) или кнопка (активный статус только при удержании в нажатом положении). Параметр invert инвертирует push-событие клавиатуры - переключатель срабатывает на отпускание основной клавиши сочетания, а кнопка возвращает неактивный статус при удержании клавиши в нажатом положении (для примера). Параметр repeat включает обработку повторов при длительном удержании клавиши в нажатом положении, практически никогда не используется. Чтение локализованных текстовых шаблонов с макросами реализовано аналогичным образом - так описан шаблон в базовой структуре конфигурации, а так он выглядит в файлах конфигурации (это ссылка на файл локализации). Полную цепочку преобразований при необходимости отследишь самостоятельно. Вот так скромно и неприметно выглядит форматирование текстового шаблона в коде модификации, а вот что происходит на самом деле. Думаю в качестве примера по переносу сложности из логики в данные вполне пойдет. Что касается кода в классах (типах) данных - он пишется один раз, отлаживается в модульном режиме, после чего про внутренности можно вообще забыть, особенно если при разработке модуля были предусмотрены все возможные (адекватные и логичные, естественно) варианты его использования, и вероятность возникновения необходимости добавления дополнительного функционала минимальна. Так что у меня уже давным-давно металл автоматически конвертируется в танки, причем тихо, скромно, неприметно и практически беспалевно. Могу лишь настоятельно посоветовать прочитать внимательно предоставленные ранее материалы еще раз с самого начала. Хотя ладно, пожалуй немного упрощу тебе задачу. Хуки - это интерфейс, а модули и классы - это движок. Разделяй и властвуй. А при отладке некоторых модулей (при правильном подходе к их написанию) можно обойтись даже без клиента игры, хватает и обычного питона.
  4. Нашли тоже чем удивить. И, судя по всему, проблему вызывает код плагина снайперского прицела на артиллерии. Без логов питона точно сказать не могу. На всякий случай попробуйте его отключить.
  5. Это называется "утечка памяти". Не используй list для статических контейнеров, для них существует тип tuple. Не используй mutable object в качестве default value. Если сваливать всю сложность в логику, то со временем можно заблудиться в коде. Чем проще логика, тем проще отлаживать программу. А для отладки типов данных существуют unit-тесты.
  6. Да я понял, что ты сделал, я только не понял зачем было переделывать сборщик, если там и так все нормально работало. К тому же практически любые корректировки в процессе сборки делаются с помощью правки файла конфигурации без необходимости править сам скрипт. Не, ну тебе оно, конечно, оттуда виднее, просто вот лично я не вижу какого-то очевидного профита от данных действий, потому, собственно, и возникает извечный русский вопрос :)
  7. Проблема известна и уже висит в списке приоритетных задач. К сожалению, костылями вроде "добавления метра" она полноценно не решается. Там нужно писать специальную логику, которая будет вносить соответствующие поправки в расчеты с учетом расстояния до цели, ее габаритов, а также баллистики снаряда. В противном случае могут быть проблемы, связанные с некорректным отображением маркера орудия в некоторых ситуациях. P.S. А я тем временем убил минут пятнадцать, пытаясь безуспешно выбить из поиска по теме историю обсуждения данной проблемы. Однако, как выяснилось чуть позже, я искал черную кошку в темной комнате, где этой самой кошки никогда не было - данная проблема в этой теме никогда не обсуждалась. Поэтому убедительно прошу не использовать систему личных сообщений для запроса функционала, сообщения об ошибках и тому подобных вещей, если они относятся к релизным версиям модификации и могут быть интересны другим пользователям. Если прямо ну уж очень хочется закостылить - раз, два. В данных строках в конце тупо и незатейливо прибавить к дистанции нужные вам скалярные полтора метра. Но далеко не факт, что все будет нормально работать, и маркер орудия будет отображаться без косяков на разных дистанциях. Я вот только не понял, зачем так извращаться и полностью перебирать систему сборки, если она и без того полностью автоматизирована и к тому же легко конфигурируется? Неужели и правда так сложно просто разобраться с зависимостями?
  8. Да вообще все делается по красоте, просто добавляется что-то вроде (я этот код не тестировал, если что) if os.path.basename(os.getcwdu()) in (u'win32', u'win64'): path = os.path.normpath(os.path.join(os.pardir, path)) и никаких проблем с обратной совместимостью.
  9. Если произойдет неудачное вклинивание другого потока на участке, где изменен рабочий каталог, есть все шансы словить внезапный кластерфак (физический поток в питоне один, а вот ресурс общий). К тому же при постановке на ожидание завершения системного вызова (блокирующие операции ввода-вывода) с очень большой долей вероятности (я бы невероятно удивился, если бы было иначе) GIL будет освобождаться, и, следовательно, захватываться другим потоком.
  10. То есть, по твоему скромному мнению, в подобной ситуации, когда на обновление модификации у автора нет ни времени, ни технической возможности, вместо того, чтобы хоть как-то попытаться хотя бы временно адаптировать (или помочь окружающим это сделать) модификацию под новый клиент, автору будет целесообразнее просто послать всех лесом и уйти в сиреневый туман? Хорошо, спасибо, буду знать. Специально для тебя, и того, кто ставит минусы под моими сообщениями, поясняю по всей видимости до сих пор не понятую вами вещь - продакшн расположен в репозитории, а то, что выкладывается в теме в настоящее время, это хотфиксы. В переводе на понятный русский - это временная заплатка, призванная скомпенсировать проблему до момента, когда она будет надлежащим образом решена при помощи полноценного обновления модификации. Когда будет это обновление - как только [у меня появится время на модификации], так сразу. Недовольные всегда найдутся, что бы ты не делал, как бы ты это не делал, и делал ли бы ты вообще хоть что-то. Так что я уже мало чему удивляюсь. Открою тебе маленькую тайну - далеко не факт, что авторы документации на пакеты модификаций (в которых этот загрузчик вообще вскользь упоминается, ибо весь документ немного о другом), и авторы непосредственно кода загрузчика одни и те же люди, далеко не факт. Это во-первых. А во-вторых, я ориентируюсь исключительно на то, что именно делается, а не на авторитет того, кто это делает. Если я вижу какую-то фигню, я прямо и конструктивно говорю, что это фигня. И мне абсолютно все равно, кто ее автор. Я бы понял, если бы этот загрузчик был чьей-то модификацией, для начинающего мододела (ну или для чисто пробного проекта, когда надо просто что-то по-быстрому проверить) это приемлемый уровень кода. Но для продакшна достаточно крупной компании, это, извините, ни в какие ворота не лезет. Meld + Text Filters. Там изначально есть фильтр для комментариев. Выставить правильно контрольные точки при необходимости и все должно нормально сравниваться.
  11. И это мне говорит человек, который, по всей видимости, тему вообще не читает. Потому как едва ли не каждый, кто подписан на эту тему, знает причину, по которой я последнее время не выкладываю ничего на GitHub - у меня в данный момент просто банально нет ни времени, ни технической возможности полноценно заниматься разработкой, да и заливать в продакшн не проверенный надлежащим образом и хрен знает как собранный код (как это делают многие мои коллеги) мне совесть не позволяет. Похоже кто-то просто очень плохо знаком с внутренностями CPython, раз утверждает подобное. Читай PEP 302, и обрати особое внимание на ресурс, где это опубликовано. Кстати, если ты не в курсе, именно таким образом, через import hook, картошка грузит свои Python модули. Только этот хук реализован на C и подрублен одним концом к ResMgr, вторым к Python. А ты хочешь сказать что это не так? Там сплошные костыли и косяки. Порядок загрузки модулей хрен пойми какой, у автора модификации он может быть один, у пользователей другой. Пользователи кричат, что у них проблемы с совместимостью с какой-то другой модификацией, автор кричит - не воспроизводится. Потому как порядок импорта определяет порядок установки хуков, а некоторые модификации применяют полную перегрузку метода и тем самым выкидывают на мороз все хуки, сделанные до них. Пакетные модули загрузчик грузить не умеет, подхватывать и автоматически компилировать текстовые модули тоже не умеет (даже при том условии что клиент принципиально понимает только скомпилированные файлы, компиляция без проблем делается в реальном времени, там кода на пару строк всего). В динамические модули загрузчик тоже не может, весь код написан хрен пойми как (даже мододел и то наверное лучше напишет), загрузить что-то вне очереди нереально, досрочно выгрузить тоже. А еще в этих исходниках указана версия клиента игры, под которую они собраны. Никто не мешает просто взять распакованные скрипты клиента той версии, скрипты текущей, сделать directory diff в том же meld, пробежаться по ключевым модулям, которые определены в разделе импортов модификации, посмотреть их diff и определить, что именно и как нужно исправить. И это без учета того факта, что я при возможности выкладываю патчи, которые с помощью git apply можно тупо и незатейливо на репозиторий применить, в крайнем случае воспользоваться мозгами и merge tool и замержить все это дело ручками. Если кто-то не умеет пользоваться элементарными инструментами системы контроля версий, то это его личные проблемы. И да, это я еще забыл про подход индуса - просто залить старую версию в новый клиент и править ошибки по мере их появления. Если ты до сих пор еще не понял, данный мод практически никто не пытается реабилитировать не потому, что я как-то криво исходники выкладываю, или информацию зажимаю, а просто потому, что уровень этой модификации существенно превышает средний по больнице сообществу мододелов, и далеко не каждому мододелу под силу понять лежащие в основе модификации механики. А те, кто в состоянии понять и разобраться, либо как и я страдают от дефицита времени на модификации, либо и вовсе уже давным давно забили на модификации вообще.
  12. Индус в сходных условиях, к твоему сведению, вообще вряд ли что-то сможет написать. Потому как работоспособность индусского кода достигается путем многократных попыток его отладки. Х**к, х**к и в продакшн, а куда же еще. Хорошо хоть картошка пока до критической инфраструктуры не добралась. Это как раз ты немного не понял суть моего недовольства. Если на твоих примерах, то это все равно что если бы ты, заезжая в новую квартиру, решил поменять розетку и с удивлением обнаружил, что в электрическом щитке вместо как минимум разделения питания на группы и отдельного автомата на электроплиту все подключено на один хлам-рубильник (даже не автомат), а то и вовсе на скрутку, до кучи залито монтажной пеной (это к тому, что к коду загрузчика вообще не подлезть), да и сам щиток сходу хрен откроешь, потому что кто-то прихватил его сваркой, чтобы щиток внезапно не открывался по причине сломанного замка (использование костылей). Как-бы вроде все работает и свет-то дома есть, но как-бы что-то тут не так... Донатоприемника нет, и вряд ли когда-то будет. Не хочу делать из хобби работу, да и, как показывает практика, деньги портят взаимоотношения.
  13. А ты попробуй обновить модификацию, не имея возможности ее скомпилировать, запустить и, собственно, протестировать (ну к примеру, сидя с мобильника или планшета). Может быть поймешь, в чем прикол :)
  14. Для выпуска хотя бы хотфикса нужно иметь доступ к основному рабочему компу, где есть установленный клиент игры и весь необходимый для запуска сборщика софт. Для нормального обновления модификации (это когда обновление получает версию и публикуется на GitHub) требуется еще и куча времени на полноценное тестирование и работу с git. Если я сижу за компом, на котором вообще ничего этого нет (ну разве что кроме текстового редактора и браузера, как говорится, и на том спасибо), и накатывать все необходимое у меня нет ни возможности, ни желания, то каким образом ты предлагаешь собирать нормальное обновление? В таких условиях diff это максимум, хотя и он генерируется наполовину вручную. В данном конкретном случае diff будет затрагивать сразу кучу файлов, будет длиннее транссибирской магистрали и как следствие с весьма большой долей вероятности будет иметь проблемы в плане инвариативности мержа. При этом все, что требуется сделать, это тупо выполнить найти и заменить все в текстовом редакторе и запустить сборку модификации. Для меня в данном случае гораздо проще по-быстрому написать дикий костыль из кривых импортов код, который просто создаст зеркало нужного мне модуля в старом месте.
  15. Судя по всему, автор загрузчика скриптов - набранный по объявлению индус, работающий за еду. Работать с кодом загрузчика абсолютно невозможно, не помогают ни прямые руки, ни даже костыли-велосипеды. Проект Advanced Script Loader (Community Edition), заменяющий scripts/client/gui/mods/__init__.pyc, напрашивается сам собой. Неплохо бы еще собрать код для автоматической генерации файла scripts/client/game.pyc для работы с некоторыми особо специфичными вещами. Жаль что на все это пока что совсем нет времени. В общем, моя попытка номер пять два. modname = 'AvatarInputHandler.aih_constants' constmod = __import__('sys').modules.setdefault(modname, __import__('imp').new_module(modname)) constmod.__file__ = __file__; constmod.__package__ = modname.rpartition('.')[0] tuple(__import__('itertools').starmap(constmod.__dict__.setdefault, __import__('aih_constants').__dict__.viewitems())) __import__('gui.mods.mod_advancedaimingsystem') Действия те же. Имя файла mod_AasFixLegacyImports.py (хотя оно может быть [почти] любым, так как используется принцип второй попытки импорта). На ошибки первой попытки импорта можно не обращать особого внимания.
×
×
  • Create New...