GPCracker

Соответствующая логика работы обработчика событий клавиатуры прописана здесь. В переводе на понятный русский это означает: модуль AvatarInputHandler клиента игры (он отвечает за прицеливание в игре) запущен, курсор не откреплен (курсор в нормальном состоянии прикреплен к прицелу, то есть при перемещении мыши перемещается и прицел, при зажатии Ctrl он открепляется, прицел больше не реагирует на мышь, появляется значок курсора на экране, и можно взаимодействовать с элементами пользовательского интерфейса; именно поэтому для некоторых [завязанных на AvatarInputHandler] функций и не работают сочетания содержащие Ctrl), режим прицеливания поддерживается (в данном случае сочетание будет работать только если игрок находится в снайперском или аркадном режиме прицеливания), событие (сочетание клавиш) не было обработано (не используется) клиентом игры. Комментарий: для базовых "переключателей" модуля AvatarInputHandler. Причина последнего: выполнение привязанного к событию клавиатуры на уровне модификации действия изменяет состояние модуля AvatarInputHandler (переключает режим прицеливания), выполнение "параллельно" другого действия (например, сброса автоприцела, но это всего лишь частный случай), но уже по инициативе обработчика клавиатуры на стороне клиента игры (внутри самого AvatarInputHandler) может повлечь за собой "параллельный" (в пределах одного интервала обновления) доступ к общим параметрам и тем самым спровоцировать непредсказуемое некорректное поведение (глюк/исключение/вылет с непредсказуемыми характеристиками). Такое явление достаточно вероятно, поскольку часть внутренних параметров AvatarInputHandler обновляется в отложенном режиме с определенными интервалами времени (интервал обновления/пересчета прицела), а базовая обработка событий клавиатуры происходит по факту их возникновения (сразу); таким образом существует крайне высокая вероятность того, что обе команды (команда клиента и команда модификации, в рассматриваемом случае это отключение автоприцела и переключение режима прицеливания) будут выполнены модулем AvatarInputHandler в один и тот же интервал между обновлениями прицела, а если учитывать то, как написан код этого модуля, то вероятность возникновения конфликтной ситуации, с учетом многочисленности и разнообразности привязанных к клавиатуре действий на стороне клиента игры, стоит оценивать как достаточно высокую. Причем в данной ситуации речь идет о глобальном поведении обработчика событий клавиатуры внутри модификации (игнорирование уже обработанных клиентом игры событий), а не о частных случаях вроде назначения отключения автоприцела и переключения режима прицеливания на одно сочетание (событие). Тут стоит принимать во внимание тот факт, что отсутствие конфликта между двумя конкретными действиями в рамках управления модулем AvatarInputHandler не означает отсутствия конфликта между любыми двумя действиями, также необходимо учитывать, что внесение любых изменений со стороны картошки, в том числе и не затрагивающих прямо обработку одной из команд, может повлечь за собой возникновение конфликта там, где его раньше не было (на ровном месте), и при этом сам факт появления такого конфликта будет абсолютно не очевиден при анализе изменений в клиенте игры (применение аналитического подхода к исправлению ошибок будет проблематичным). К тому же, как показывает практика, подобные ситуации крайне сложно отлаживать, потому как при возникновении исключения при отложенной обработке данных в трассировках ошибки почти никогда не содержится информации о том, что стало источником некорректного набора исходных данных (некорректного состояния). В общем, если коротко, в целях предотвращения возникновения проблем по принципу WTF у пользователей, возникающих из-за "с виду правильной, но не очень удачной" конфигурации модификации, а также вопросов в том же самом стиле у меня (и других мододелов, кстати, тоже), на стадии анализа логов питона с целью выяснения причины возникновения исключения (неведомой ошибки, сопровождающейся той самой трассировкой в логах), во всех ситуациях, где модификация меняет состояние AvatarInputHandler тем или иным образом, использование любых обрабатываемых клиентом игры и имеющих отношение к командам для AvatarInputHandler биндов (так называемых "двойных биндов") заблокировано на уровне модификации в рамках глобальной политики обработки событий клавиатуры. Если еще короче, то на всех функциях, которые пинают AvatarInputHandler "на запись" при использовании "двойных биндов" событие клавиатуры обрабатываться со стороны модификации не будет. На текущий момент такими функциями являются Advanced Arty, SPG Sniper Mode, TargetScanner - AutoScan, TargetScanner - ManualOverride, AimCorrection - Target Mode. И собственно, ответ на вполне логичный вопрос, зачем вообще весь этот огромный пост нужен. Затем, чтобы желающие подрубить [себе] возможность использования "двойных биндов" таки имели представление о причинах, по которым данная возможность изначально была заблокирована.

Очевидных ошибок в изменяемом файле конфигурации при беглом просмотре не увидел. Скорее всего, ошибка как-то проявляется в логах. В общем, как обычно, логи питона в студию.

Ну как бы гит умеет понимать переименования, в том числе и переименования с изменениями, на основе содержимого файлов. К тому же можно включить в конфиге режим игнорирования регистра, причем это можно сделать и для конкретного репозитория, конфигурация которого прописывается в файл .gitconfig, а он попадает под синхронизацию и на GitHub соответственно. А вообще, говорят что в гугле амнистия, проверь, может и тебя разбанили :)

Customization дословно означает "process or result of making something custom". Custom (adjective) - made or done to order for a particular customer. Поэтому более правильный перевод этого слова - персонализация. А применительно к нашей тематике, слова "настройка" и "персонализация" это несколько разные понятия.

Это не "естественно", это "как всегда". В интернете куча примеров на динамический frame rate.

Есть такое... Похоже проблема в том, что Scaleform/WG не поддерживает динамическое изменение frame rate.

Так товарищ вроде как пробовал провернуть сей фокус, но, насколько я понял, не прокатило. Однако я не уверен в правильности его действий. Да и вообще, редактирование файлов клиента игры порождает файловые войны между модификациями. К тому же поддержка таких модификаций требует больше ресурсов, потому как данное действие необходимо проделывать каждый патч, в котором измененный файл был затронут. Так что лично я предпочитаю пользоваться дополнительными скриптами и флешками, которые делают нужную работу с необходимыми классами и объектами в рантайме, если такое возможно, а не редактировать файлы клиента игры. Кстати, @Ekspoint, протестируй скрипт выше, если будет возможность. По идее, если ты решил проблему исключительно изменением частоты кадров, то и мой вариант тоже должен сработать. Ну если, конечно, картошка при написании обвязки Scaleform не принимала участие в турнире рукожопов года

Насколько я помню, @Ekspoint уже отвечал по этому поводу выше, а всякие мелкие улучшения это его тема. Но раз уж многие задаются этим вопросом, а качественно копать клиент умеют лишь единицы, попробую дать более-менее развернутый ответ. Если я правильно копаю, то вот классы, которые отвечают за дамаг-индикаторы (раз, два). И оттуда четко понятно (раз, два, три), что анимация задана с помощью MovieClip, а не tween-скриптов. Изменить продолжительность такой анимации можно либо путем изменения количества кадров, либо путем изменения их частоты (анимация в MovieClip задается последовательностью кадров). Интерфейсом класса изменение количества кадров в рантайме (в процессе выполнения) не предусмотрено. А частота кадров вообще определяется на более высоком уровне. Вывод - изменить продолжительность анимации без костылей или добавления кадров путем редактирования соответствующего swf-файла не получится. Можно, конечно, попробовать применить костыль в виде изменения частоты кадров для всей сцены, используемой дамаг-индикаторами. Но данный подход является по своей сути термоядерным боезарядом, который затрагивает все объекты целевой сцены, поэтому сложно однозначно сказать, что еще будет затронуто такими чрезвычайно глобальными мерами. Нужно цеплять отладчик и проводить инспекцию сцены, но в данный момент у меня нет такой возможности. from gui.Scaleform.daapi.view.battle.shared.indicators import DamageIndicatorMeta def new_DamageIndicatorMeta_init(self, *args, **kwargs): result = old_DamageIndicatorMeta_init(self, *args, **kwargs) self.movie.stage.frameRate = self.movie.stage.frameRate / 2 return result old_DamageIndicatorMeta_init = DamageIndicatorMeta.__init__ DamageIndicatorMeta.__init__ = new_DamageIndicatorMeta_init Приведенный выше прототип кода изменяет частоту кадров сцены, используемой дамаг-индикаторами. Лично я данный код не тестировал, так что в нем могут быть ошибки, да и не факт, что он вообще будет работать. Дополнения и исправления приветствуются.

Ремонт "поврежденных" частей модификаций однозначно планируется, причем в первоочередном порядке. Вопрос лишь в том, когда я смогу добраться до разработки, пока что в лучшем случае получается лишь читать сообщения на форуме, иногда отвечать на них.

Дело в том, что функция корректировки маркера орудия базируется на внедрении дополнительного коллижн-теста, который прерывает выполнение расчета ожидаемой траектории снаряда на необходимом удалении от опорной точки системы корректировки прицеливания (создается "виртуальная стенка"), и тем самым исправляет "провал маркера орудия". Но код клиента игры в настоящий момент написан таким образом, что интегрировать необходимый дополнительный код без костылей и велосипедов не представляется возможным. И отчасти именно из-за наличия "неправильного" кода данный функционал периодически ломается при обновлениях, потому собственно и вынесен в отдельный дополнительный модуль.

@Beliy.IV, это Python-код. Самый простой вариант его собрать для игры - взять из соседней темы PjOrion. Можно сделать и через чистый Python, скачать который можно с официального сайта (нужен Python 2.7), но там будет несколько больше операций. Результат - это два файла, один текстовый (mod_coolmod.py), с приведенным выше содержимым (кстати, после shared точка лишняя), другой скомпилированный двоичный (mod_coolmod.pyс). Второй нужно закинуть в scripts/client/gui/mods/ (через res_mods или пакеты значения не имеет) и перезапустить игру. Вообще, в отладочном режиме клиент и обычные текстовые файлы с кодом (*.py) импортировать может, без предварительной компиляции, но для того чтобы заставить его это делать на пользовательском клиенте, нужно опять же залезть в питон, а возможно даже не только в питон. P.S. Частота кадров для SWF-файла не имеет значение, если сам индикатор не является кадровым MovieClip (анимация задана скриптами), а также в случаях, когда значение частоты кадров переопределяется извне (например, из питона).

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

Переименовать мод все равно что переименовать судно... ну ты понял. Такой вариант изначально не рассматривается. А специально для особо подозрительных, в описании модификации сделаны соответствующие пометки. Вообще, я планирую немного откорректировать шапку, примерно до уровня, как сейчас оформлена тема с Minimap Gun Markers, немного упростить некоторые вещи, добавить несколько анимированных картинок, поясняющих принцип работы (часть из них уже публиковалась в теме, но их нужно немного доработать), чтобы всякие мимокрокодилы особо не агрились.

Забей в поиск по теме слово "ответ", найди относящиеся к твоему вопросу посты, перейди по ссылке и почитай всю окрестную переписку. Узнаешь много интересного. А если коротко, то персонал Центра Поддержки Пользователей это походу сплошь юристы-гуманитарии, которые в технической части вопроса разбираются на уровне "сравнить слова из описания модификации с описанием запрещенного функционала", поскольку их основная задача это ответить пользователю так, чтобы их компанию потом за этот ответ не натянули (с юридической точки зрения) как ту сову на глобус.

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

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

Как будто это не портал модов, а портал косяков. Добавить Боба Марли и вообще красота и гармония будет :)

Ох... Господа, вам еще не надоело биться головой об стену? Занялись бы чем-нибудь полезным, что-ли.

Нужно смотреть, в каких файлах оно лежит, и с какими модами вероятнее всего будет конфликтовать твой мод, и уже на основании этих аналитических данных делать вывод, насколько приемлемо использовать установку по типу "замена файла локализации". Иных путей внести изменения в локализацию лично мне пока не известно, есть конечно определенные мысли, но проверить их пока что нет возможности.

Скорее всего, опять имеет место легаси-код. И да, вспомни как было с обновлением боевого интерфейса на ActionScript 3... сколько там легаси висело в клиенте? А как насчет этого, этого и этого? А теперь заглядываем сюда... А потом сюда. И в итоге попадаем... в никуда. Мне не удалось найти в питоне установку хэндлов для этих команд ExternalInterface. Полагаю, они отлавливаются и обрабатываются на уровне си. З.Ы. Возможно, я скинул тебе что-то полезное :)

Подобные перекосы скорее всего временные, ибо такие масштабные миграции чаще всего проводятся по частям, и в течении некоторого времени в клиенте остается легаси-код. Такое уже не раз было, внимательные эту тенденцию давно заметили. Ты не забывай, что в питоне генерируются только те тексты, которые через питон форматируются. Для всего остального есть константы и локализация на уровне DAAPI, и не всегда эти константы прописаны в питоне (могут быть исключительно флешовые). На самом деле не стоит забывать про то, что локализованные строки это в первую очередь файлы, и, соответственно, операции ввода-вывода, которые имеют способность подвешивать поток. Так что вывод модуля gettext в си вполне оправдан. Что касается прослойки i18n, то в свете локализации на уровне DAAPI она превращается в ненужную (с точки зрения разработчиков игры) короткую петлю в питон и обратно, которая только жрет лишние ресурсы, создает лишний код, так еще и GIL просит. Я уже написал чуть выше про легаси-код. А вот такая фигня реально бесит. У них там творится какой-то ад в плане разработки. И, полагаю, так сделали потому, что из-за большого количества факапов тамошние бакланы не успевали настучать/отдебажить свой мега-микро-патч своим кривым клювом к тесту или к релизу, поэтому его одобрили на мерж только в самый последний момент, когда релизная ветка уже висела в зафиксированном состоянии (когда началось предрелизное тестирование, и из изменений допускаются только исправления критических багов).

Я в курсе, и там ошибки нет. Написано именно то, что подразумевалось. Написать на Python с дополнительными декларациями от Cython (собственно, я упростил до "написать на Cython"), чтобы код в функциях можно было спокойно вывести из-под GIL. Потом собрать с помощью Cython в сишный модуль и закомпилить с питоновскими хедерами. Проблема тут именно в питоновских хедерах, именно с ними связано 99% геморроя во всем этом деле.

Походу я опять что-то пропустил... Но насчет того, что такая прекрасная обнова ****** как вовремя, это ты прям в точку сказал - я вообще через пару дней неизвестно пока насколько могу уйти в оффлайн (уезжаю в другой город), по крайней мере с возможностью работы над модами ожидаются определенные весьма существенные сложности, даже если и удастся запилить там себе интернет. Видимо, тем, что это, во-первых, относительно медленно получается, ибо строк на старте игры нужно локализовать достаточно много, или оно будет тормозить в процессе, во-вторых, немного нелогично, ибо локализация используется в си-части игры, неявно линкуется на питон-модуль из си-модуля, а потом через питон снова на си выруливает, особенно учитывая что есть варианты gettext для си, в-третьих, это пресловутый GIL который вешает все остальные питон-потоки, пока работает локализатор, что не есть круто. На самом деле, изменение вполне логичное, проблема в том, что запилено все как обычно (почему-то я в этом не сомневаюсь даже) через одно известное место. Ну а по-другому по сути никак. Не влезая в питон, ты не сделаешь возможность рулить этим из питона без диких костылей и велосипедов, а влазить в питон... читай выше. На самом деле pyd не такая большая проблема, если разработчики вернут обратно экспорты питоновских функций в exe. В таком раскладе тебе нужно будет просто найти нужную сигнатуру для хука в си, а весь код можно будет просто на Cython написать, по сути тот же питон, только с дополнительными директивами.

Если взялся обвинять - железные доказательства в студию. В противном случае это может расцениваться как клевета. Со всеми вытекающими.

Мне кажется, или самое время призвать сюда @Mr 13... Ибо если общение начинается с бездоказательных оскорблений, ничем хорошим оно точно не закончится.