GPCracker

@vasya-sar, конфиг грузится, критических ошибок нет. Во-первых, советую исправить true на True, на всякий Во-вторых, панель корректировки отключена в настройках gui.xml Все остальное вроде ок. Посмотреть, что загрузилось в конфиг в реалтайме можно через отладчик (WST, Орион) import sys, pprint pprint.pprint(sys.modules['<gui.>mods.<mod_>AdvancedAimingSystem']._config_)В зависимости от того, через какую папку установлен мод нужно выкинуть или раскрыть уголки.Результат высыпется в лог.

LookupError: One or more keys could not be recognized. Дословно: Ошибка поиска: Одна или более клавиш не могут быть распознаны. Вообще советую иногда пользоваться переводчиком для анализа того, что написано в логе. Где-то ошибка в хоткеях, вот и творится жесть. А точнее не где-то, а в файле arcade.xml, <key>Q</key> Посмотри на список хоткеев, который прописан внизу файла (нежданчик), и подумай, что не так :) И проверь чтобы подобных косяков не было в других файлах. Начало лога потерялось.

True пишется в конфиге с большой буквы, как и в питоне. Не знаю, насколько это меняет суть дела, и как это обработает ResMgr, но все же. BBox и BEps вместе включать бессмысленно, только лишний расход вычислительной мощности. Есть косяки в настройке GUI. Значение параметров в секции default должно совпадать с arcade, некритично. И еще. Файлик конфига, что лежит рядом со скриптом, он тоже нужен! По сути он и есть конфиг, просто он "втягивает в себя" содержимое файла root, root затягиевает все остальное. Те override в заголовках секций и есть ссылки на файлы. И что в логах, конфиг грузится?

Они им так эффективно занимаются, что если раньше мод нужно было адаптировать раз в 3-4 патча, а то и реже, сейчас - каждый б****кий патч, который раз в пару месяцев. Не разработкой занимаешься по сути, а адаптацией. Реально выбешивает, если у тебя что-то достаточно сложное.

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

Не пути поменяли, а скрипты упаковали в архив. Пути менеджера ресурсов остались те же, проблема только в том, что через него бинарники читать нельзя, точнее можно, если pyd писать, на питоне не вариант. Поэтому и идут извращения в стиле использования модулей zipfile и zipimport.

Попалась в руки такая игрушка. Что-то как-то немного подзатянуло, вспоминаю С потихоньку, а по ходу еще и схемоту :)

Хотелось бы увидеть логи... уже который раз пишу подобный ответ :)

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

Что есть, то есть. Палка о двух концах. С одной стороны, сгруппировать файлы от одного мода в кучу это хорошо, с другой - в некоторых ситуациях получается такая кракозябра с 4Гб файлами. У WG тоже там не все так просто с оптимизацией загружаемой части клиента при обновлениях. Rdiff или что-то подобное в wgpkg поставляется, ЕМНИП, давно не смотрел. Ну импорт импорту рознь. В чем опасность import math например в exec/eval? Если и лочить импорт, то только на уровне самого импорта. Байт-код как в случае с math, так и в любом другом случае с подобным синтаксисом будет одинаков, разница будет только в аргументах-константах. Тем более что код выполняется в некотором "словаре" - globals() и locals(), которые могут изменяться и вне блока exec/eval.

Я этого не говорил. Я только предположил что такое бессмысленное с моей точки зрения предложение ты внес на обсуждение по причине недостаточного понимания принципов работы "виртуальной машины" питона (или как это правильно называется) в части выполнения байткода и его структуры. Причем только предположил. Зависимости главного пакета... прописаны в самом пакете, так что поправить их с учетом обновы без перекачивания пакета не вариант. Можно прописать в пакет с обновой зависимость от основы/пред.обнов, чтобы они грузились перед. Это как вариант в принципе можно. Обновление основы делать в накопительном режиме, набралось достаточно изменений - замержили в основной пакет. Остается вопрос с версионным контролем. И организацией всего этого дела у автора для эффективной разработки. С учетом возможного наличия или отсутствия VCS.

Если обфускатор писали не мудаки - быстро надоест. Ничем они не опаснее всего того Г которое юзеры и так из интернета накачать могут. Полагаю с байткодом питона ты абсолютно не знаком. Сложно делить то, что по идее должно быть целым. Да и по идее ты к тому и придешь, что получишь столько же пакетов с 1 файлом :) А что касается деления пакета - это относится к либам общего пользования, чтобы конфликтов не было. Если уж на то пошло, то нужно чтобы поверх пакета можно было делать стандартный оверрайд через рес_модс. Мелкие апдейты - просто несколько оверрайд-файликов, крупные делается правка всего пакета.

Приведение исходника в эквивалентный, но абсолютно не читаемый вид ничем не хуже. Не забываем еще про codeobject. А отрубать exec/eval, которые могут хавать codeobject - это означает практически убить интерактивность питона. Все отладчики сразу умрут, инфа сотка, или будут работать через одно место. Так что отрубить обфускацию нормальными методами не получится. Да, и со статусом разраба WG... Который ему явно админ прописал. Не меньше чем питонист при отладке мода. Запуск - эксепшн - правка - запуск. Не, с тем фактом что ЭЦП будет дико мешать, я с тобой согласен. Только вот касается это вообще всего сообщества, а не только ремоделлеров. Я уже написал пост с перспективами по этому поводу чуть выше. +100500 Который весит пару гигов. Для тех у кого тариф с учетом трафика это просто epic win. Те конфликты (имеются ввиду файл-конфликты), о которых пишет разраб, идут из нескольких вещей на выбор. 1. Картошка написала говнокод (ну или просто не подумали немного), который пропатчить нужным образом кроме как жестким патчем файла нельзя. За примером далеко ходить не буду - scripts/client/common/debug_utils.py - невозможно хуком/подстановкой переключить вывод логов в отладочный (DEV) режим (интересно в основном флешерам - можно использовать флешовый одноименный модуль для логов и отладки). И таких примеров вагон найти можно. 2. Необходимо подключиться именно в момент импорта этого файла, а не позднее (половина пункта относится к 1му, вторая половина - это логгеры, отладчики, реалтайм реплейсоры локализации и т.д. которым нужно загрузиться как можно раньше, и вариант грузиться вместе с модами для них не вариант). 3. Мододел мудак и не знает, что такое хуки и как можно и нужно использовать script/client/<gui/>mods. 4. Речь идет о файлах-ресурсах, т.е. *.xml, *.mo, *.png, *.dds, ... 1, 3 пункты и так понятны 2, та часть что про логгеры и т.д. - обычно люди знают что делают и между собой общаются. 4 - ну тут в любом случае конфликты должен разбирать пользователь. Выбирать что ему важнее, или мержить файлы руками, если это скажем локализация или xml.

А вот таким образом мододелам создается два "забора". В процессе разработки наступает этап тестирования, и что, мододелу на каждый тестовый запуск отправлять мод на подпись? Так это через два патча только мод допилишь. Закрытое/открытое бета-тестирование. В текущем варианте мододелы просто скидывают бету в тему, кто шарит - тестит. Для каждого такого теста получать ЭЦП? Раздача подписей авторам модов - в какой-то степени обруливает забор, но создает другой - новые мододелы вряд ли смогут присоединиться к комьюнити. А делать раздачу свободной - любой читераст берет себе "мододела", анлочит своим сертификатом клиент и катает читы сколько ему влезет. А как отделить человека, который хочет попробовать по гайду сделать свой первый модик, от читераста, который хочет получить свободный доступ на выполнение кода? Никак. Так как своих модов ни у одного, ни у другого пока нет. Это даже не говоря про то, что моды самый простой способ интеграции читов. Но далеко не единственный. Про моды в новой батле я что-то ничего не слышал, а вот про читерастов - еще на стадии теста нового BF1. На стадии теста, Карл! Так что ввод ЭЦП просто создаст заборы, отстрелит пару неопытных разработчиков читов, которые не смогут в обход и все. Читеров, как писали уже выше, и не раз писали, меньше не станет, и отлавливать их нужно именно на сервере. Это есть такое дело. И самое что интересное - после крупных изменений народ-то в основном и отваливается. Случайность? Не думаю... Так их и так уже полный рандом. Некоторых отстреливают, но новые как появлялись, так и появляются. Странная закономерность... То ли народ настолько тупой, что даже после десятка безуспешных попыток все еще пытается пробить головой стену, то ли картоха не учитывает какой-то момент, который ботоводы используют и не палятся на нормальных акках при этом (бот содействует прокачке или что-то типа того)... то ли это картофан сам создает ботов, дабы рандом не выглядел пустым, и банит их потом, чтобы не палиться, когда на кого-то из ботов люди начинают жаловаться. Если стату игроков среднестатистического боя посмотреть, играть умеет 2-3 человека из 15 в команде. Остальные просто мясо, умирают в первые минуты. И кто бы там что не говорил, стата характеризует не человека, а его умение играть. И у большинства игроков это умение отсутствует. Наводит на определенные мысли, как не крути.

Не понял смысла идеи. Вокруг твоего танка математически строится вертикальный цилиндр, луч камеры коллайдится с этим цилиндром, там будет точка прицеливания... радиус цилиндра равен расстоянию до цели. Цилиндр как-бы проходит через танк противника, тем самым при выводе прицела за пределы танка противника расстояние на дальномере будет приближенно равно расстоянию до цели. Конечно методика требует некоторой доработки, но и "релизить" я пока ее не собирался. Погодь, я кажется потихоньку начинаю понимать... ты предлагаешь сделать "пространственный сектор" с центром "стягивающей площади" в координатах цели? То есть ограничить максимальный угол "прицела от цели" в пределах которого будет действовать корректировка? Или что? З.Ы. Подобная методика не поможет победить задир ствола в клинче, но определенный смысл в этом есть, подумаю.

Я в свое время на CDC столько танковал :)

На скрине - стенку представь в середине противника, спроецируй на нее прицел, туда наводится ствол. Поэтому он и задирается. Подумаю над реальным эффектом и реализацией.

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

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

Есть такое, давно, но отключено по дефолту. commonAS/autoAim/... Правда там есть некоторые моменты, из-за которых оно не совсем корректно работает, поэтому в крайнем (последний хотфикс) билде необходимый плагин отсутствует. Ну как-бы картоха против такого упрощения. Так что на свой страх и риск.

Эээ, у меня лично есть некоторые данные, что расчет точки прицеливания осуществляется на клиенте... или картоха пропатчила недавно?

Полагаю, будет более точным сказать что знают единицы, кто с этим непосредственно работает. Правками флешки изменить политику минмакс круга не получится, НЯП, она на питоне. Перекрасить тоже без своей флешки вряд ли получится, т.к. подрубить ColorTransform через DAAPI... Имхо, нереально. Хотя по факту, там достаточно просто прописать getter для объекта маркера и три строки для установки цвета перекраски... Но не факт, что результат будет красиво выглядеть. Там те еще заморочки. Там всего-то прикрутиться на пару функций. Видел где-то попадался пример реализации отдельного серверного... С еврофорума, там не больше 10 строчек, половина импорты. Хотя в принципе, с другой стороны, вполне логичнее держать все в одном месте.

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

Незначительно. Мод не так уж и много съедает. Самые нагруженные - это неточные модули сканера. В соответствующую тему. Есть тут на форуме по соседству. BalCalсMod дальномер ручной, и ЕМНИП есть задержка при исчезновении, не уверен. AAS штука более продвинутая и сложная. Для тех, кто умеет стрелять и понимает, как летит снаряд. В большинстве случаев флаг enable в состоянии False просто не проводит загрузку модуля, соответственно все попытки обратиться к нему в хуках отклюняются простым условием. Модуль дальномера полностью сам по себе отключить нельзя, это основной модуль модификации. Но можно перекрыть ему кислород, отключив корректировку по цели и ручной режим. Если это кому-то интересно, ибо полагаю что большинство ставит модификацию именно из-за дальномера. Флаг activated работает в большинстве случаев внутри самого модуля и может менять состояние в процессе, через обработку нажатий клавиш, хоткей, иными словами меняет состояние activated. В то же время обработка хоткея возможна только при активации enabled соответствующего модуля.

То есть ты предлагаешь отложить команду на выстрел до окончания восроизведения звука? Это идиотизм по причине того, что отрицательно влияет на боевую эффективность. А так вообще из питона любой звук запустить можно.