GPCracker

Только если декомпилировать до уровня исходника и замержить, разрешив все возникающие конфликты. Но сомневаюсь, что у среднестатистического пользователя на такое хватит квалификации.

А ты уверен, что твою функцию не считают "крадущей" ссылки? Кто и где ее вызывает? Кстати, нашел еще несколько интересных ссылок по теме (раз, два, три).

@Pavel3333, возвращаясь к твоему вопросу, "stealing reference" and "returning borrowed reference" это исключения, и они прописаны в доках для каждой "исключительной" функции. Есть еще одно простое правило - конструктор никогда не возвращает "borrowed" ссылку - в противном случае объект будет сразу же уничтожен сборщиком мусора. Поэтому если ты создаешь какой-то объект внутри функции - его нужно уничтожить самому, или отдать функции, которая "украдет" ссылку. Если же ты создал объект, скормил его функции, которая ссылку не крадет, а потом он тебе стал не нужен - ты должен его самостоятельно уничтожить. Твой "второй ответ из шапки" как раз и показывает, что в первом ответе в коде про***но уничтожение сразу двух объектов - полученного метода и результата вызова этого метода.

Насколько мне подсказал www.google.com, довольно неплохо процесс работы со ссылками описан здесь. Если максимально сжать написанное, в большинстве случаев функции не крадут право собственности на ссылку, но почти всегда его отдают, если, конечно, не указано иное. Право собственности на ссылку означает, что та функция, которая им обладает, отвечает за вызов Py_DECREF. Единственный вопрос, который пока еще остается открытым, это когда наш уважаемый Павел таки освоит основы использования поисковика, научится читать в оригинале и перестанет задавать бородатые вопросы?

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

Причем тут AttributeError, если речь идет о некорректном типе данных или количестве аргументов? Вообще, все типы ошибок, и что они означают, можно глянуть здесь. В твоем случае правильный тип исключения TypeError.

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

MinimapGunMarkers v0.1.8 (XModLib v0.1.14) [19.05.2018] - незначительные косметические улучшения. - незначительные улучшения в модуле VehicleGunMarkers. Небольшое предварительное техническое обновление. Скачать можно в разделе релизов на GitHub. Ну и как обычно напоминаю, что без XModLib мод работать не будет. MinimapGunMarkers v0.1.9 (XModLib v0.1.15) [19.05.2018] - адаптация под новую версию библиотеки XModLib. - проект переведен на новую архитектуру. - исправлен мелкий баг. Основная часть технического обновления. Главные изменения произошли в библиотеке, поэтому непосредственно по отдельности в патчноут не попали. Также была существенно изменена архитектура модификации, формализованы порядок и условия установки хуков, и хуки плагинов теперь устанавливаются только если плагин был активирован в файлах конфигурации. Сами плагины теперь являются частью основного модуля, поскольку возможность их физического удаления по сути больше не требуется (данный функционал позволяет интегрировать в модификацию нестабильные модули с возможностью их отключения и был перенесен с AdvancedAimingSystem из соображений унификации, но в MinimapGunMarkers [пока] не используется). Также была возвращена проверка версии клиента игры, однако она больше не блокирует запуск модификации, а только выводит вместо обычного сообщения в логе и в ангаре предупреждение о возможных проблемах с совместимостью. Скачать можно в разделе релизов на GitHub. Ну и как обычно напоминаю, что без XModLib мод работать не будет. MinimapGunMarkers v0.1.10 (XModLib v0.1.16) [19.05.2018] - незначительно доработан код сборщика проекта. - проект переведен на новую систему загрузки ActionScript. Вторая часть большого технического обновления. В этой версии была полностью переработана система загрузки ActionScript модулей ("флешек"). Скачать можно в разделе релизов на GitHub. Ну и как обычно напоминаю, что без XModLib мод работать не будет. MinimapGunMarkers v0.1.11 (XModLib v0.1.17) [19.05.2018] - адаптация под новые версии клиента игры и библиотеки XModLib. Незначительное техническое обновление, связанное с изменением поддерживаемой версии клиента игры на более новую. Скачать можно в разделе релизов на GitHub. Ну и как обычно напоминаю, что без XModLib мод работать не будет. MinimapGunMarkers v0.1.12 (XModLib v0.1.18) [19.05.2018] - адаптация под новые версии клиента игры и библиотеки XModLib. Незначительное техническое обновление, связанное с изменением поддерживаемой версии клиента игры на более новую. Скачать можно в разделе релизов на GitHub. Ну и как обычно напоминаю, что без XModLib мод работать не будет. Ключевые слова alpha, beta и release начиная с этой публикации использоваться не будут, при выходе новой версии соответствующие коммиты вероятнее всего будут сливаться в основную ветку (предположительно master, вопрос реструктуризации репозитория пока еще в процессе), а сами файлы будут либо выкладываться в разделе релизов на GitHub, либо прикрепляться в теме к сообщению с патчноутом. Отладочные версии будут просто получать длинные имена, состоящие из базовой версии, количества коммитов поверх базовой версии и короткого идентификатора последнего коммита, и будут собираться из отдельной ветки разработки (предположительно, development или testing). Это последовательное обновление "по частям", первые четыре версии промежуточные, и сделаны в целях поэтапного ввода нового функционала. Наиболее актуальная версия та, у которой номер больше, так было с самого первого релиза, и вряд ли в дальнейшем изменится. Исходя из соображений поддержки, я не планирую держать более одной ветки развития модификации, если не считать ветку разработки, которая так или иначе периодически сливается в основную (изменения из ветки разработки переносятся на основную версию). Опубликованные версии модификации не являются прямым обновлением под текущую версию клиента игры, они лишь содержат в себе примерно те же изменения, которые были сделаны в AdvancedAimingSystem, и поэтому предназначены в первую очередь для устранения расхождения в версиях библиотеки XModLib. Однако, если судить по отсутствию сообщений об ошибках, на текущей версии клиента игры вполне стабильно работают и опубликованные ранее версии, поэтому не вижу серьезных оснований считать, что у опубликованных здесь версий возникнут какие-либо серьезные проблемы в этом плане. Применявшийся ранее хотфикс по сути является исправлением мелкого бага, не проявлявшегося в более ранних версиях, поэтому он был включен в основную ветку начиная с версии v0.1.9. Тем не менее, если в процессе использования будут возникать какие-либо ошибки в работе модификации, просьба сообщать о этом, и прикреплять при этом логи (файл python.log).

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

Ты где откопал такого динозавра? Они разве еще не вымерли? Кстати, наверное будет в тему :)

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

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

Видимо ты не совсем внимательно читал. Ибо внимательный бы заметил, что компилятор съедает константные инструкции даже на нулевом уровне оптимизации, на последующих он начинает сжирать часть функций (как именно он выбирает, что ему сожрать, а что нет, я пока не разобрался толком). Говнокодеру с оптимизацией неправильно выбранных алгоритмов он конечно не поможет, а вот грамотному программисту может серьезно упростить жизнь, ибо делает написание кода более удобным за счет эффективной оптимизации разнообразного сахара. Если продолжить написанное ранее, оптимизация по скорости работы это в первую очередь оптимизация алгоритма. Алгоритма, Паша! Не языка программирования, не процесса компиляции этого в исполняемый код. Алгоритма. Проблема скорости работы кода на 90%, если не более, лежит именно в алгоритмах. Потому как большая часть всех тормозов - это либо неправильно выбранный алгоритм (когда можно сделать существенно проще, и при этом корректно будут выполняться все возможные кейсы), либо ограничения самого алгоритма (к примеру, людям не известны способы организации сортировки со сложностью быстрее O(n), и то это только для самого лучшего случая). И именно поэтому нужно в первую очередь анализировать написанный тобой алгоритм на предмет нецелесообразных вычислений, а уже только потом пытаться оптимизировать процесс выполнения этого алгоритма. Если брать пример, что называется, на месте, то текущая проблема с медленной загрузкой связана именно с ненужными вычислениями, но никак не с тем, что компилятор что-то там неэффективно компилирует.

@StranikS_Scan, @Pavel3333, когда-то давно я от скуки сидел гуглил, уже правда не помню что, но наткнулся на это. Весьма интересный материал, я бы сказал.

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

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

Ну так бы сразу и сказал. А то я уж было подумал, что ты не знаешь про репозиторий :)

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

А в чем собственно проблема? Репозиторий лежит здесь.

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

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

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

Не могу не вспомнить тот бородатый анекдот... "А вы сколько раз перезагружали?" :)

Питон-лог из сообщения с модулем SafeShot никак не связан. Это баг в панели сведения, где-то очень глубоко зарытый, скорее всего в скриптах картошки... и кажется, это уже репортилось. Что насчет блокировки выстрелов по различным объектам, не являющимся танками (если речь идет о причине блокировки waste shot), то это в принципе вполне ожидаемое поведение, потому как определить, является ли подобный объект враждебным, дружественным или нейтральным, и вообще может ли он являться приемлемой целью, заранее (до появления очередного нестандартного режима боев) невозможно, в силу нестандартности этого объекта (можно только анализировать скрипты и добавлять подобное поведение по факту добавления картошкой новых режимов, и потом чистить хвосты после удаления из клиента этих режимов), поэтому все нестандартные объекты (не танки) просто игнорируются со всеми вытекающими последствиями. Данная мера исключительно временная, подобные правки в конфиге делаются для отключения тех модулей модификации, которые картошка сломала с выходом очередного обновления. Сам я в эту игру уже почти полтора года (если даже не больше) не играю, и в силу ограниченности в свободном времени, которое я могу использовать для работы над модификациями, публикую обновления под новые версии клиента по мере возможности, поэтому за последние несколько версий модификация была нужным образом доработана, и те модули, в которых после очередного патча начали появляться ошибки, можно просто отключить через файлы конфигурации.

@vasya-sar, относительно выхода обновления совместимости, какие-либо конкретные временные рамки назвать затрудняюсь, поскольку со свободным временем сейчас сложно, и существенная его часть уходит на анализ изменений в клиенте, но в общем и целом пакет изменений практически готов, однако там не хватает одного фрагмента, который сейчас активно проверяется.