GPCracker

Может тебе еще автоматический декомпилер написать? Для того и шифруют, чтобы нубы не читали. Если сильно надо, используй мозги и дизассемблер. В Орионе он есть) По этой теме даже темка есть на этом форуме.

Обновил до версии 0.0.2 Beta - мод полностью пересобран - добавлены специальные параметры для продвинутых пользователей (управление задержкой инжекта, игнор версии клиента и т.д.) - описание параметров конфигурации теперь в самом файле конфигурации - изменены имена некоторых параметров конфигурации. - со старым файлом конфигурации мод работать не будет (либо будет работать некорректно) - адаптация под версию клиента 0.9.3

Уничтожение незасвеченной цели (ручной захват) может не обрабатываться... На ручной захват таймаут автосброса не распространяется. Надо будет проверить, EDMX только обновлю сначала... Надо будет переименовать параметр, поскольку он действует только на ручной захват. Для автозахвата параметр отдельный. С автолоком не все так просто. Дистанция вычисляется при запросе точки прицеливания в зависимости от расстояния стрелок-цель. Поэтому при стрельбе по движущейся цели возможно не совсем полное сведения, хотя где-то слышал что при перемещении ствола вверх-вниз сведение не теряется. Плюс возможно некоторое понижение точности за счет некоторого рассинхрона клиент-сервер. Надо будет проверить. По крайней мере светляков на КВ2 с дистанции 200+ сношу без проблем :) Причина по которой был добавлен аркадный режим мода - артиллерия. По умолчанию у нее снайперского нет :( Вопрос с этим решил (на 0.9.2 норм работало). Поэтому и отключил аркадный. Если честно, с аркадным режимом изначально была проблема. Не программная, чисто геометрическая. В снайперском режиме камера находится в танке, поэтому все работает нормально. Зум - это реально зум, камера все равно в танке. Дистанция от камеры до цели и от танка до цели - одно и то же. А вот в аркадном все по-другому. Там камера висит в воздухе танк внизу, цель - 3 точка. При изменении зума в аркадном режиме камера перемещается. Или когда что-то закрывает обзор, она подкатывается ближе. В пред. версиях был реальзован расчет расстояния от танка, в связи с чем маркер "зависал в воздухе" - находился на прямой, соединяющей стрелка и цель (камера то сверху). Если реализовывать отсчет от камеры, возникает проблема зума: при изменении точки отсчета расстояние остается постоянным, в камере все выглядит нормально, но, например, при откате камеры назад (зум аут) танк начинает стрелять в воздух, а не в цель. Реализовать не проблема, просто пока нет идей как грамотно компенсировать зум в аркадном режиме.

Попробуем пофиксить для релиза.

Обновлено до версии 0.0.3 Beta - адаптация под версию клиента 0.9.3 (тестирование).

Мод работает только с той версией клиента, под которую скомпилирован (просит обновиться). Обновление будет где-то через неделю, возможно даже раньше (если в клиенте ничего сильно не поменяли). Перед релизом мода надо с ним немного покатать, потестить. P.S. Как раз качаю релиз... Upd. Хм... Похоже что разрабы что-то поломали в библиотеке GUI, поскольку все надписи резко стали белыми, и сделать их цветными не получается. Параметр colour меняется, а цвет нет((. М.б. пофиксят когда-нибудь. Upd 2. Выкладываю альфу. Текст цветной или весь белый? Сбрасывается ли цель при ее уничтожении? Появляются ли в логе какие-либо ошибки, связанные с AASMX? Advanced Aiming System.zip - Мод полностью пересобран (тестировался под 0.9.2, под 0.9.3 критических несовместимостей пока не выявлено) - Добавлен снайперский режим для артиллерии - Аркадный режим мода отключен (возможно будет после доработки) - Добавлены специальные параметры для продвинутых пользователей (управление задержкой инжекта, игнор версии клиента и т.д.) - Описание параметров конфигурации теперь в самом файле конфигурации - Изменена обработка текстовых макросов - Изменена логика работы "горячих клавиш" - Со старым файлом конфигурации мод работать не будет (либо будет работать некорректно)

Обновлено до версии 0.0.2 Beta - исправлено исчезновение маркеров баз (тест).

А что там абсолютно новый движок? Кстати, '_BWp' это что за модуль такой? Ни разу не встречал...

Дословная расшифровка: если имя модуля равно 'mods.' + (полный путь к файлу разбить в список по прямому слэшу, взять последний элемент, его разбить по точке в список взять первый элемент (иными словами имя файла без расширения))Это проверка на исполнение в качестве игрового модуля. Когда файл исполняется как отдельная программа, а не импортируется, __name__ = '__main__'. Честно говоря, не самый универсальный вариант. Правильнее будет подобную проверку проводить через try: import BigWorld except ImportError: raise Exception('Module must be used in game')

Ну оно показывает, только не совсем так, как хотелось бы... Маркеры стволов оказываются над маркерами техники... Пофиксил уже эту проблему... покатаю немного, если все норм, выложу) Upd. рррр.... Именные слои перемещать нельзя, XVM ломается... Видимо все привязано к определенным слоям на уровне флэша. Ну ладно, попробуем по-другому... И блин все собрано на системе костыли-велосипеды, хрен подлезешь все сыпаться начинает... Upd 2. Аккуратно подвинуть (сжать) существующие слои не вариант, падает XVM, причём это сказывается только на нем, игра при таких перестановках работает нормально. Пока ничего работоспособного (с точки зрения XVM), кроме как накладывать маркеры сверху, придумать не удается. Хорошо что они хотя бы полупрозрачные)

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

Нет там никаких подмен классов. Хуки на методах Vehicle.startVisual; Vehicle.stopVisual; Vehicle._Vehicle__onVehicleDeath; game.handleKeyEvent; А те 3 класса, что там присутствуют, реализованы для упрощенного управления маркерами на миникарте. Видимо, не до конца дочитал... Скорее всего происходит совпадение слоев отметок баз и маркеров. А на одном слое не может быть более одного элемента. Покопаю скрипты zIndexManager, посмотрю что и как. М.б. поможет изменение zIndexDelta до -200. Тут не так все просто, миникарта (основа) на С написана. Чтоб понять, почему так, нужна секция displayFilters полностью. Возможно, такое происходит из-за того, что либо техника проходит через другой активный фильтр, либо в пред. бою (на момент выхода из боя) фильтр был активирован. Не исключен так же вариант, что указанная комбинация была нажата например в ангаре (надо будет перенести точку установки хука, куда-нить поближе к AvatarInputHandler). По крайней мере, установка activated = False при просмотре реплея дает ожидаемый результат, изначально маркеры отсутствуют. Upd. Вот диапазоны zIndex для "родных маркеров" Позиции баз начинаются с 0. _BACK_ICONS_RANGE = (25, 49) _DEAD_VEHICLE_RANGE = (50, 99) _VEHICLE_RANGE = (101, 150) _FIXED_INDEXES = {CAMERA_NORMAL: 100, 'self': 151, CAMERA_STRATEGIC: 152, 'cell': 153, CAMERA_VIDEO: 160} При zIndexDelta = -100 маркеры стволов попадают на слои маркеров баз, маркеры баз удаляются... При -200 zIndex уходит в минус, маркеры накладываются сверху. Почему, непонятно, скорее всего С шалит.) Попробую поменять эти константы, и запихнуть диапазон где-то 50 слоев между DEAD_VEHICLE_RANGE и VEHICLE_RANGE. Скорее всего, у миникарты минимум 256 слоев, а используется только 160. Жаль что раньше эти константы на глаза не попадались...

Вот оптимизированный и улучшенный мод

Это официальная тема модификации. This is official topic of the modification. Убедительная просьба не публиковать тестовые сборки (все что не в шапке) за пределами темы. Please do not repost any testing assembly (located not in the first post) elsewhere except this topic. Маркеры направления орудий на миникарте / Minimap Gun Markers Версия клиента: 1.0.0.1 Версия мода: 0.1.12 Автор: GPCracker Описание: Модификация отображает направление орудий техники специальными маркерами на миникарте в соответствии с настройками в файле конфигурации. Принцип действия: Для игрока существует так называемая "зона отрисовки" - область вокруг некоторой центральной точки (обычно это координаты самого игрока), в которой игрок может видеть союзную и вражескую технику. Всей техники вне этой области, а также незасвеченных танков, для игрового клиента попросту не существует, а значит и информацию о том, куда развернуто орудие, получать просто неоткуда. Что касается отображения маркеров на миникарте, то для всех танков союзников, а также для засвеченных противников, кто находится вне зоны отрисовки, информация о двухмерных координатах на карте передается через отдельный канал связи и пригодна только для отображения обычного маркера на миникарте. Что же касается артиллерии, то для нее в артиллерийском режиме зона отрисовки прикрепляется не к танку, а к прицелу, что позволяет ей видеть технику на другом конце карты... но при этом она не получает информацию о технике рядом с ней. Именно это является причиной пропадания маркеров стоящей рядом с вами союзной артиллерии. Таким образом, маркеры орудий могут быть отображены только для засвеченной техники и только в зоне отрисовки игрока. Установка модификации: Стандартная. Распаковать архив с файлами модификации в папку mods в корневой папке клиента игры. Однако при распаковке необходимо учитывать, что номер версии клиента в архиве может отличаться от актуального, поскольку архивы обновляются только в тех случаях, когда для корректной работы модификации требуется обновление совместимости (иными словами, когда в содержащиеся в архивах файлы вносятся какие-либо изменения). Пользовательские сборки: При необходимости, на свой страх и риск, вы можете собрать модификацию вручную из исходников, опубликованных на GitHub. Данная процедура требует некоторого опыта в работе со скриптами, а также наличия дополнительного программного обеспечения, и подходит только для опытных пользователей. Отчеты об ошибках и добавление функционала: Публикация в данной теме отчетов об ошибках категорически приветствуется, поскольку этим вы помогаете улучшить мод и сделать его более стабильным. Однако подобные сообщения должны соответствовать следующим требованиям. Необходимо указать используемую версию модификации. Сообщение должно содержать подробное описание возникшей ошибки. Сообщение должно содержать последовательность выполненных действий. К сообщению необходимо прикрепить необходимую отладочную информацию (логи). Если ошибка проявляется визуально, к сообщению необходимо прикреплять скриншоты. Все сообщения, не содержащие минимально необходимой информации, будут игнорироваться. Под отладочной информацией (логами) подразумевается файл python.log, расположенный в корневой папке клиента игры. В зависимости от характера ошибки минимально необходимый набор информации может отличаться, но первые два пункта являются обязательными в любом случае. Если вы хотите предложить добавление какого-то дополнительного функционала, в первую очередь стоит убедиться в том, что его не интегрировали ранее и не "забыли" включить в конфиге. Автор не занимается интеграцией в модификацию дополнений, которые можно однозначно охарактеризовать, как функционал для ведения нечестной игры, вносящий в нее серьезный дисбаланс или предоставляющий чрезмерные преимущества игроку. Тестовые версии модификации: В некоторых случаях бывает необходимо привлечение аудитории для проведения тестирования нового функционала либо отдельной версии модификации. В таких случаях создаются специальные тестовые сборки. Их публикация осуществляется исключительно в теме, поскольку предназначены они только для пользователей, регулярно читающих тему, и в шапку темы они загружаться не будут. Редактирование файла конфигурации: Файл конфигурации имеет несколько специфичную кодировку (UTF-8 w/o BOM), поэтому его нельзя редактировать стандартным блокнотом Windows (если вы сохраните этот файл, он будет сохранен в другой кодировке, что сделает его чтение внутри игры невозможным). Для редактирования этого файла нужно использовать профессиональные текстовые редакторы, например Notepad++ или Sublime Text. Работа на общем тесте (World of Tanks Common Test): Автор не занимается сборкой отдельных версий модификации под общий тест. Однако в некоторых случаях возможна публикация необходимых правок в отдельных ветках репозитория. Если данные правки будут актуальны к моменту релиза, они будут интегрированы в основную ветку. Тем не менее, при необходимости вы можете самостоятельно собрать модификацию из соответствующей ветки. Скриншоты модификации: Благодарности: @Xotabych, @Ekspoint, @Slava7572, а также всем, кто принимает участие в тестировании и публикует информативные багрепорты.

Я раскопал немало скриптов. Как я понял game.pyc это главный или по крайней мере не самый последний скрипт. Там (вроде как) я видел парсинг аргументов командной строки (поищи тотал коммандером фалик с sys.argv). Для запуска клиента в режиме отладки. Дополнительные сообщения в лог, как я понял, особо не разбирался. Может реально что интересное найдешь) По поводу того, как дебажат в WG - у них есть специальный клиент походу. Насчет эксепшена во флэше - кажется я видел пару раз какой-то подозрительный вывод от Питона. Насчет связи питона и флэша - есть статья на хабре... DAAPI кажется или что-то подобное. Вот недавно Орион появился, теперь дебажить базовые функции проще. А раньше по хардкору спец. файл с реакцией на хоткей и выводом в лог, иногда на экран.

По поводу питона: python.log - это файл ввода-вывода питона, то есть то что в обычном режиме пишется в консоль, в игре пишется туда.:) По поводу отладки кода (питон). На сегодняшний день я знаю два способа отладки. Непосредственное тестирование мода (файл мода закидывается в папку с модами, не забыть загрузчик). Эффективно на стадии финального тестирования и отладки. Второй - использовать PjOrion (одна из закрепленных тем в разделе файлов), удобно для проверки работоспособности отдельных функций. Некоторые функции можно проверять в реплее (некоторые базовые даже в ангаре), некоторые придется проверять в реальном бою. Насчет перезапуска клиента - ну с этим ничего не поделаешь, при отладке отдельных функций можно выкрутиться иногда, при отладке мода в целом без этого не обойтись.

Я тебе хочу сказать, что при записи реплея записывается точка прицеливания. Ее нужно получать через replayctrl. Точку наведения камеры при просмотре реплея можно получить через aim. Точные имена методов и классов посмотреть пока не могу. А точка маркера рассчитывается с использованием баллистики и turretYaw & gunPitch. Это в файле gunRotator.pyc кажется. Просто я не совсем понимаю, какую точку прицеливания ты хочешь получить: игровую (в бою) или наведение просмотровой камеры в реплее...

Раскапывай иерархию классов и наследование. Есть два метода подхвата этой точки - через модуль aim (луч из центра камеры) и из реплея (сохраненная камера) (replayctrl если не ошибаюсь). Тебе нужно не на автовыбор системы полагаться, а на нужный модуль напрямую. Копай что выполняется по твоему запросу.

Коллижн тест вертикальная прямая. Пересечение только с искомым танком. Возвращается точку пересечения или None. Для проверки третьей координаты (высоты) берёшь ещё горизонталь. Копай collideVehicles или collideEntities точное название метода не помню.

А я про неё и не забывал.) Будет комп и время - буду тестить альфу. Пока на очереди ещё обновления (местами не маленькие) на AASMX и EDMX. В каком порядке буду разгребать, пока не знаю.

Проверю. По крайней мере я не помню, чтобы интегрировались какие-то действия на уничтожение техники. Конфиг (одноименный XML файлик) для этих целей и придуман) Там у всех GUI элементов есть параметр position. Он и определяет положение на экране. В 1 посте вроде все параметры описаны.

Определил причину просадки fps, проанализировал скрипт миникарты. Просадку скорее всего получится устранить через привязку к эвентам отрисовки/исчезновения техники, но пока ничего не обещаю, "низкоуровневые" функции тестить надо...

М.б. дело в скорости воспроизведения...

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

Тут без сервера никак... А написание логики на сервер это уже не только питон, а еще и SQL, м.б. еще что-то. Написать клиентское окно это малая часть проекта.