GPCracker

Дословно. Версия библиотеки не соответствует данной версии приложения (мода). Либа не той версии. Порядок обновы: Находим последний полный релиз, который я кидал (он не в шапке), на него накатываем этот патч.

Поддерживать два проекта всегда сложнее, чем один. Для меня гораздо легче и проще добавить функционал и параметр в конфиг, чем держать параллельно два проекта. А прикинь таких хотелок 10+ будет, и каждому свою сборку? Если бы речь шла о "собрал-забыл", тогда еще возможно, и то не факт. Но в мод постоянно вносятся изменения - новый функционал, фиксы под картошку и т.д. Обновить и протестировать один проект и обновить несколько... Чувствуешь разницу? В случае с конфигом, вы сами задаете себе нужную конфигурацию, как хотите, тем самым вы получаете возможность кастомизации, а я не занимаюсь выполнением лишней работы. Вообще я таки стараюсь выносить наиболее важные параметры в конфиг. Если там чего-то не хватает в конфиге - пишите, обсудим, если предложение будет толковым - постараюсь добавить. Но заниматься кастомными сборками исполняемого файла я не буду. Таки поколдовал немного с маркером орудия. "Провалы" по идее должны пропасть. Тестим, и главное - внимательно смотрим в логи. Я тут просто параллельно вношу патчи в общие классы флешки, при работе над MGM, поэтому может быть некоторое рассогласование между питоном и флешкой. AdvancedAimingSystem.zip

Мод нужен в основном тем, кто стреляет с больших расстояний/бревнометов с медленными снарядами. Т.е. профильные ПТ-воды, "отстрельщики наглых ЛТ" ну и водители КВ-2-подобных танков. На тяжах от него не так уж и много пользы, ибо прицел почти всегда на противнике. Фичу верну обратно однозначно, но пока на это не так уж и много времени.

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

Есть такое дело. Как только выкатишь стейбл - сразу такая тишина наступает...

1. Мод лежит на гитхабе. Причем в промышленной конфигурации, за исключением пары файлов, которые на билд особо не влияют. Единственно, в репо нет бинарников утилиты gettext для сборки локализации, но их я могу тебе в ЛС скинуть, если вариант просто убрать файл локализации из конфига билда тебе не подходит. Берешь и собираешь себе что тебе нужно. 2. Автозахват и коробки используются исключительно для внутренних алгоритмов. И оно опять же, все отключаемое. И отключено по дефолту. Из того, что может каким-то образом попадать под известный список - это только взаимодействие с автоприцелом на уровне подстановки цели. И оно тоже отключено по дефолту. Все остальное не имеет к списку никакого отношения. 3. Что касается инфы насчет системы "античита" - они бы с ботами сначала разобрались, и полагаю именно это они и будут делать в первую очередь, если эта инфа не очередная "утка", которую кто-то "неаккуратно" слил, а вододелы подхватили. 4. Если инфа реально правдоподобна, то в соответствующем разделе оф. форума будет список километра на три с пометкой "запрещенные моды". Пока в таких списках от силы человек 5, и то тех, кто жестко спалился на видео/реплеях с читами.

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

В отладчике добавил по приколу одному танчику новый маркер... Вполне себе ничего смотрится. З.Ы. Обратите внимание на зеленый уголок камеры игрока :) Скрин

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

@STREJlA, Вообще, подходов к реализации многих вещей в настоящее время существует два. Первый - это городить систему хуков и логики для анализа того, что с этих хуков приходит. В настоящее время наиболее популярный подход. Достоинства - простота кода, отсутствие классов и необходимости сложного анализа кода картохи. Минусы - сильно проседает на сложных проектах. Второй появился не так давно, после того, как картоха поняла, что первый метод ведет за собой кучу различных перекрестных костылей, вроде того, что ты скинул, когда связываются несвязанные вещи для получения результата, и они стали систематизировать код. В частности, от системы прямого обращения к объектам (раньше в файлах обработчика техники можно было увидеть обращения к миникарте, например), в особенности к элементам графического интерфейса, они перешли на систему событий, когда существует объект, который инициирует события (g_sessionProvider), и к которому обращаются различные источники событий (Arena), и объекты, которых это событие интересует, на него подписываются (GUI). Второй подход состоит в том, что ты создаешь свой обработчик, и "аккуратно подкидываешь" его в систему картохи. Он как-бы становится полноценной частью системы. По факту, хуки идут только на месте этого самого "подброса". Все остальное делают за тебя скрипты WG - вызывают методы твоего объекта при возникновении внешних событий. А уже в своих методах ты эти события обрабатываешь, как тебе нужно. В большинстве случаев, при правильном подходе, все необходимые события ты получаешь, и количество необходимых хуков и перекрестных костылей резко падает практически до нуля. Плюсы второго подхода - он более аккуратный и красивый, ни с кем не конфликтует, поскольку ты ничего не патчишь (хуки на добавление в список твоих элементов не в счет, они прозрачные), и требуется значительно меньше различной логики. Минусы - из-за большого количества необходимой обвязки увеличивается немного количество кода (однако его логика несколько упрощается), большое использование классов и других, не совсем понятных новичкам программирования вещей. Можно привести достаточно простое сравнение. Скажем, нужно добавить танку возможность стрелять ПТУРами. Первый способ - это навесить ПТУРы в отдельных контейнерах на башню. Просто, но не очень практично, они там как-бы немного лишние. Второй способ - это стрельба ПТУРами из пушки (как делают почти все отечественные современные танки). Основная сложность - это сама ПТУР, зато в остальном - это как-бы такая же часть боекомплекта, как и остальные снаряды. Как-бы решили задачу добавлением нового снаряда в боекомплект, не перепиливая при этом систему. Не в названиях ивента, а в имени переменной. Что эта переменная глобальная и содержит уникальный экземпляр объекта.

Типичный пример кода на костылях. Список участников боя берется из арены, но перехват события осуществляется в GUI. Это в стиле "подождем очередь в булочной, но закупаться пойдем в мясную лавку". Если информация берется из арены, то и хук надо ставить там же, на отработку получения этой самой информации. Либо вообще на более высокий уровень идти, там приходят уже распределенные ивенты (например, g_sessionProvider). Арена - это достаточно низкий уровень. Но на высоких уровнях требуется классовая организация кода. В частности, через g_sessionProvider добавляется листенер-объект/класс, уже не помню, через который можно получать события на арене. Выделяешь ли ты свой код в функцию - это особого значения не имеет. Многие подходы сами по себе дикие костыли.

Использование колобков, там где они не нужны - зло. Подвязывайся на ивенты. Колобки - типичные грабли новичков. Результат - падение ФПС вследствие выполнения кода, когда его выполнение не требуется. Используй события. З.Ы. Колобок - это обратный вызов функции с задержкой. Колобок всегда идет в отдельном внутреннем потоке, поэтому используется либо для задержек (в том числе callback loop, использование которого и есть зло), либо для выноса выполнения функции за пределы текущего кода (нулевая задержка), т.е. когда выполнение функции сейчас вызовет нежелательную задержку. Подробнее в доках к движку игры есть. Эти доки уже неоднократно выкладывались тут (на форуме). Хукнуть соответствующий метод. BigWorld.player() в ангаре это экземпляр класса Account, в бою - PlayerAvatar, файл Avatar.py. Все методы, которые отвечают за старт боя, есть там. Дальше все зависит от того, на каком этапе инициализации тебе нужно выполнить свою функцию. Вообще, тот или иной мод к чему-то привязывается. Соответственно, туда и надо ставить хуки. В точку непосредственного взаимодействия с игрой. Это наиболее эффективный подход к реализации, и наименее затратный по вспомогательному, не типовому коду. Хуки надо ставить на классы. На объекты их поставить нужен скилл и хорошее знание питона, в частности дескрипторов. Далеко не самая простая для понимания тема. Да и особого смысла ставить хуки на объекты нет, ибо изменения чаще всего носят классовый характер, да и большая часть классов существует в одном экземпляре. Примеры можно посмотреть в открытых модах. В принципе, код моих модов есть на гитхабе, но для новичка он будет слишком сложным для понимания, ибо там большой акцент сделан на автоматизацию/упрощение некоторых вещей при разработке, структуризацию, частично в оптимизацию выполнения и конфигурируемость, а не на минимальное количество строк и простоту кода. Для новичков лучше браться за что-то попроще. Где-то валялась папка с декомпилированными исходниками времен 13/14 годов, но в настоящее время очень многое, из того, что там есть, уже не актуально. Да и необходимость что-то декомпилить последние год/полтора в принципе отсутствует, ибо около половины модов - это такой говнокод, что даже обезьяна, ИМХО, напишет лучше (сказывается тот факт, что очень редко какой мододел является опытным программистом), и гораздо проще (при наличии скилла и знании повадок программистов картохи) найти нужный код в клиенте игры, чем пытаться понять, что там в моде сообразили ножноклавишным методом. А большая часть того, что написано адекватно, лежит на гитхабе/битбакете, ибо более-менее адекватный код не так стремно туда заливать. Поэтому если хочешь примеров - рекомендую поискать по темам в разделе модов те, что хостятся на гитхабе/битбакете, ибо там примеры будут наиболее актуальны на текущий момент.

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

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

В общем, просьба к тем, кто не против оказать несложную поддержку в разработке мода. Нужны картинки, которые подставляются вместо оригинального маркера орудия камеры. Раньше во флешку, сейчас в атлас. Наиболее интересные варианты могут попасть в релиз :) А так вообще пока играюсь с графикой, потом потихоньку буду писать обработчик событий миникарты. Формат PNG 32 бита, в общем, тот же что и у атласов картохи. Прозрачность поддерживается, само собой. В идеале готовый элемент для внедрения в картошкин атлас. Хотя я все равно поля обрежу, для оптимизации, у меня тут своя графическая система, так сказать, делаю что хочу :) С масштабированием элементов миникарты еще до конца не разобрался, но насколько я понял, масштаб должен быть примерно такой же, как и у оригинального уголка в атласе сейчас (эквивалентная по размерам картинка будет эквивалентной и на миникарте). У картохи вся графика написана в спрайтах, а не в классах, поэтому немного проблематично копать флешку. Но по крайней мере свои маркеры с блекджеком и шлюхами со своей графикой, на своем персональном слое я уже в принципе сделал. Осталось перегнать код и тестового в релизный и дописать Python - часть, которая будет этими маркерами рулить, т.е. еще где-то половину мода.

В разработке пока другой проект, вот и притихло... Тут по сути остались мелкие баги и так, отполировать чего по мелочи.

Почитал тему, но так честно говоря и не понял, что конкретно ты хочешь сделать с чатом...

loadView

Автоматик билдер решает проблему. Он сразу соберет правильный архив, который остается только выложить :) Я тоже раньше собирал все руками. Потом надоело, написал скриптик. Теперь просто дабл-клик по скрипту и архив с модом готов, все файлы лежат где положено. Потому как номер версии получается уже после сборки, а его нужно добавить внутрь... Кстати, посмотри как у меня в AAS реализовано, может и для тебя прокатит. Там есть специальный код для сборки и перед компиляцией он заменяет макрос на значение этого макроса, подгружаемое из специального файла, которое обновляется после каждого билда. Номер версии вписывается руками, номер билда инкрементируется автоматом. В репо этого файла нет, поэтому сборки от юзеров автоматом кастомные. Таймстамп тоже можно добавить аналогичным образом (замена макроса), хотя интереснее будет его читать из самого файла, он прибит в заголовке PYC, и содержит дату модификации исходника. Это сделано для того, чтобы компилятор при каждом запуске пересобирал только измененные исходники. Но никто не запрещает его юзать в своих целях. Единственно, придется немного поднапрячься, т.к. придется подключить ResMgr для определения локации файла, но там ничего сложного по сути. Билдер есть тут и тут (разные версии для разных проектов, как собирается PYC - состав - можно глянуть там же). Код для резолва путей в системе картохи по значению __file__ скрипта есть тут.

1. Делать флешку нормально. 2. Прикрутиться к сеттингам нужного пакета и бизнес хендлера. Флешка сама прогрузится, когда нужно. Это если по науке делать. Если по простому, как все привыкли, костылями и велосипедами - то да, ловишь эвенты на загрузку одной из ключевых вьюшек, от которой ты пляшешь, и грузишься сразу после нее. Все остальное побоку, если ты его не трогаешь. Насчет проверки - включаешь дебаг режим. log_level 1 сто раз уже обсуждалось. Игра начинает с**ть отладочными логами. Там есть типа View added to container или что-то типа того. Ну или просто графику дорисовать, чтобы видно было.

Не, все через питон ходит все равно. В AS лезть смысла нет, если ты интерфейсы пилить не собираешься. А вот в обработчики заглянуть стоит.

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

Вот чего-чего, а там я точно ничего не затираю. Я туда вообще не лезу.

2016-10-07 22:44:24.267: ERROR: Traceback (most recent call last): 2016-10-07 22:44:24.268: ERROR: File "scripts/client/vehicle_systems/components/engine_state.py", line 114, in __startEngineFunc 2016-10-07 22:44:24.268: ERROR: TypeError: 'NoneType' object is not callable Непонятная ошибка, скорее всего косяк картохи. 2016-10-07 22:45:32.746: INFO: [sOUND_ERROR] Sound fail: 1479439024 - ErrorCode: 15 Косяки в озвучке, нужно обновить что-то однозначно. 2016-10-08 00:07:37.023: WARNING: [warning] (scripts/client/AvatarInputHandler/AimingSystems/ArcadeAimingSystem.py, 197): Invalid arg for acos: -1.000000; distanceFromFocus: 35.000000, dir: (-0.517151, 0.132767, -0.454243) Ну это уже который год... А вот и самое интересное. 2016-10-09 21:33:34.789: ERROR: Traceback (most recent call last): 2016-10-09 21:33:34.789: ERROR: File "scripts/client/gui/battle_control/arena_info/listeners.py", line 481, in __loadSpaceCallback 2016-10-09 21:33:34.789: ERROR: File "scripts/client/gui/battle_control/arena_info/listeners.py", line 516, in __onSpaceLoadCompleted 2016-10-09 21:33:34.789: ERROR: File "scripts/client/gui/battle_control/arena_info/listeners.py", line 102, in _invokeListenersMethod 2016-10-09 21:33:34.789: ERROR: File "scripts/client/gui/battle_control/controllers/arena_load_ctrl.py", line 28, in spaceLoadCompleted 2016-10-09 21:33:34.789: ERROR: File "scripts/client/Avatar.py", line 697, in onSpaceLoaded 2016-10-09 21:33:34.790: ERROR: File "scripts/client/Avatar.py", line 2733, in __onInitStepCompleted 2016-10-09 21:33:34.790: ERROR: File "battle_controller.py", line 120, in new__startGUI 2016-10-09 21:33:34.790: ERROR: File "mod_GunConstraints.py", line 184, in newAfterCreate 2016-10-09 21:33:34.790: ERROR: File "scripts/client/Avatar.py", line 2844, in __startGUI 2016-10-09 21:33:34.790: ERROR: File "scripts/client/AvatarInputHandler/__init__.py", line 504, in start 2016-10-09 21:33:34.790: ERROR: File "scripts/client/AvatarInputHandler/control_modes.py", line 729, in create 2016-10-09 21:33:34.790: ERROR: File "scripts/client/AvatarInputHandler/control_modes.py", line 208, in create 2016-10-09 21:33:34.790: ERROR: File "mod_DispersionCircle", line 1, in new_create 2016-10-09 21:33:34.790: ERROR: AttributeError: _SuperGunMarker instance has no attribute '_SuperGunMarker__gm3' Близко, но рейзится из файла картохи, скорее всего вытекает из предыдущей. 2016-10-09 21:33:34.909: ERROR: Traceback (most recent call last): 2016-10-09 21:33:34.909: ERROR: File "scripts/client/helpers/CallbackDelayer.py", line 58, in __funcWrapper 2016-10-09 21:33:34.909: ERROR: File "scripts/client/VehicleGunRotator.py", line 1327, in __update 2016-10-09 21:33:34.909: ERROR: File "scripts/client/AvatarInputHandler/__init__.py", line 362, in getDesiredShotPoint 2016-10-09 21:33:34.909: ERROR: File "source/XModLib/HookUtils.py", line 50, in __call__ 2016-10-09 21:33:34.909: ERROR: File "AdvancedAimingSystem.py", line 1454, in new_ArcadeControlMode_getDesiredShotPoint 2016-10-09 21:33:34.909: ERROR: File "scripts/client/AvatarInputHandler/control_modes.py", line 276, in getDesiredShotPoint 2016-10-09 21:33:34.909: ERROR: AssertionError Ну и кинетический флуд пошел... 2016-10-09 21:34:40.311: ERROR: Traceback (most recent call last): 2016-10-09 21:34:40.311: ERROR: File "scripts/client/Avatar.py", line 1926, in showTracer 2016-10-09 21:34:40.311: ERROR: File "scripts/client/ProjectileMover.py", line 102, in add 2016-10-09 21:34:40.311: ERROR: File "scripts/client/ProjectileMover.py", line 17, in ownVehicleGunPositionGetter 2016-10-09 21:34:40.311: ERROR: AttributeError: 'NoneType' object has no attribute 'compoundModel' Еще кинетический флуд... 2016-10-09 21:36:33.313: ERROR: Traceback (most recent call last): 2016-10-09 21:36:33.313: ERROR: File "mods/xfw/python/xfw/events.py", line 54, in __event_handler 2016-10-09 21:36:33.313: ERROR: File "scripts/client/Avatar.py", line 1232, in vehicle_onEnterWorld 2016-10-09 21:36:33.314: ERROR: File "scripts/client/Avatar.py", line 1239, in __startVehicleVisual 2016-10-09 21:36:33.314: ERROR: File "source/XModLib/HookUtils.py", line 44, in __call__ 2016-10-09 21:36:33.314: ERROR: File "scripts/client/Vehicle.py", line 758, in startVisual 2016-10-09 21:36:33.314: ERROR: File "scripts/client/vehicle_systems/appearance_cache.py", line 215, in getAppearance 2016-10-09 21:36:33.314: ERROR: File "scripts/client/vehicle_systems/appearance_cache.py", line 109, in getAppearance 2016-10-09 21:36:33.315: ERROR: File "scripts/client/vehicle_systems/appearance_cache.py", line 133, in constructAppearance 2016-10-09 21:36:33.315: ERROR: File "scripts/client/vehicle_systems/CompoundAppearance.py", line 660, in start 2016-10-09 21:36:33.315: ERROR: KeyError: 'py_resource: Requested resource not found in resources list: ussr:R61_Object252'

AAS вносит изменения только в расчет точки прицеливания. В маркер орудия изменения не вносились. Что патчится в DC я не в курсе. Если загрузка подвисает, но вылета не происходит - значит в логах наверняка что-то есть. В студию, пожалуйста python.log.