beb

Пользуюсь инструментом командной строки https://github.com/hedger/BWXML (соответственно, исходники открыты) "BWXML A tool for unpacking BigWorld compressed data sections to plain XML. Also supports packing XML back to its compressed form." BWXML v1.04 by hedger Usage: bwxml.exe [options] list_of_files_or_directories Allowed options: --help produce help message --pack pack files instead of unpacking --verbose print information about each file --selftest perform reversed operation on produced files --threads arg (=9) sets the size of a worker pool. Default = n_cpu_cores + 1 --input arg input files/directories --output arg (=decrypted/) directory to output files пример использования (распаковка ресурса engine_config.xml в произвольную папку vanilla): md vanilla 2>nul bwxml.exe --i %wot_folder%\res\engine_config.xml --o vanilla

Да, в основном на все хватает трех букв, но не всегда :)

Обновление моей сборки с выходом обновления 1.12.1.1 Версии модификации без XVM с антизум-скриптом: minimapAC_maxi.zip, максимальный игровой размер minimapAC_midi.zip, средний игровой размер, примерно 3/4 от максимального minimapAC_mini.zip, минимальный игровой размер, примерно 1/2 от максимума Версии модификации без XVM и без антизум-скрипта: minimapAC_zoom.zip, зуммируемый размер, примерно 1/3 от максимума Бонус: minimapClear_1-10.zip: все прицелы Minimap_Clear_#1-10.zip (noXVM) из титульного сообщения темы, собранные в пакеты .wotmod minimapXVM_dummy.zip, версия для XVM, которая содержит заглушку, не выводящую практического изображения, и предполагает использование сторонних фигур прицела (в частности из архивов MinimapAimAll_100%, MinimapAimAll_6-8%.zip в титульном сообщении темы) Детализация номенклатуры версий, иллюстрации и архивы доступны в исходном сообщении сборки: по ссылке Статус: актуально для клиента WorldOfTanks 1.12.1.1 @Slava7572, если понравилось, то и славно.

@Slava7572, интересно, какие именно скрины считаются качественными? В Windows я делаю скрины с использованием FastStone Capture, а поскольку она платная, то из ближайших аналогов могу предложить PicPick (бесплатная для домашнего пользования). Главный "секрет" здесь - я всегда сохраняю скрины lossless в .png и никогда в .jpg. Если имеется ввиду коллаж разновидностей прицелов, то он собран в менеджере изображений FastStone Image Viewer, где из клиентских игровых скриншотов были вырезаны куски с миникартой, из них собран коллаж 3х2 с дырками и тенями для красоты, и добавлены надписи. Эта программа бесплатная, считаю ее must have для того, кому хоть раз в жизни довелось просматривать картинки на ПК; она тоже, кстати, сама умеет делать скриншоты, но с чуть менее развернутым функционалом, чем у ее платной родственницы. "Как бы сводная таблица" версий прицелов - это вообще не скриншот, а прямой экспорт в .png страницы из векторного графического редактора, где векторные же фигуры прицелов были собраны специально для этой иллюстративной цели. В игре скриншоты делает сам клиент, я просто нажимаю на конопку PrtSc. Никаких настроек здесь нет, так как никаких пользовательских настроек в отношении скриншотов в клиенте не предусмотрено*. Игровые скриншоты я качественными не считаю, так как, как минимум, в них присутствует искажение цветов. Что касается разрешения игровых скриншотов, то оптимальное разрешение экрана моего ноутбука составляет 1920x1080 и менно такое же установлено в игре, что может способствовать лучшему качеству. *В ресурсах игры (res/engine_config.xml) присутствует возможность попробовать хотя бы поменять .jpg на .png, но пока что я это не тестировал. <screenShot> <extension>jpg</extension> <name>screenshots/shot</name> </screenShot>

Исходный файл модификации minimapEntriesLibrary.swf остается неизменным со времен клиента версии v.1.11.0.0 С выходом грядущего обновления текущие актуальные модификации изменений не требуют, останутся актуальными для клиента: v.1.12.1.0 Для продолжения работы модификаций после обновления достаточно будет переместить файлы в соответствующие новые подпапки mods, res_mods.

Некоторые моменты относительно сценариев практического применения, включая извлечение полезного содержимого обновления с применением разностных файлов .xdiff рассмотрены здесь: [Решено] Имея разностные файлы .rdiff и/или .xdiff грядущего обновления получить обновленные файлы ресурсов .pkg

@Mixaill, спасибо за подсказку. Теперь мной побежден и .xdiff. .rdiff обрабатывается как показано выше: rdiff.exe patch old.pkg delta.rdiff new.pkg .xdiff обрабатывается следующим образом: xdelta3.exe -d -s old.pkg delta.xdiff new.pkg Пример: имеем в папке клиента игры ресурсы в текущем состоянии: res\packages\gui-part1.pkg res\packages\gui-part2.pkg имеем в грядущем обновлении, среди прочего, в папке клиента игры, предзагруженные разностные файлы, касающиеся указанных ресурсов: updates\wot_1.12.1.2764_ru_pj9v79\wot_1.12.1.21133_1.12.0.21119_client.wgpkg\res\packages\gui-part1.pkg.1.12.1.21133.F28F93AB.xdiff updates\wot_1.12.1.2764_ru_pj9v79\wot_1.12.1.21133_1.12.0.21119_client.wgpkg\res\packages\gui-part2.pkg.1.12.1.21133.7A3317D5.rdiff Имеем цель (здесь и сейчас) получить ресурсы gui-part1.pkg и gui-part2.pkg в том состоянии, какое бы оно было (фактически будет), когда обновление будет применено. Для этого берем текущие (прежние) ресурсы (gui-part1.pkg и gui-part2.pkg) , применяем к ним разностные файлы .rdiff и .xdiff, и получаем ресурсы gui-part1-uptated.pkg и gui-part2-uptated.pkg уже в обновленном состоянии (здесь и сейчас, не дожидаясь дня, когда обновление будет официально развернутно клиентом). Для реализации обозначенной выше цели используем команды в синтаксисе: для .rdiff, следующего типа: rdiff.exe patch gui-part2.pkg gui-part2.rdiff gui-part2-uptated.pkg для .xdiff, следующего типа: xdelta3.exe -d -s gui-part1.pkg gui-part1.xdiff gui-part1-uptated.pkg Вопрос: а зачем это надо? Ответ: кому надо, тот поймет*. *Как вариант: Вы делаете какой-то мод, зависимый от состояния ресурсов клиента. При этом уже сейчас у вас на руках предзагруженные обновления и есть время, на то, чтобы в них ковыряться. Но когда обновление будет развернуто официально, то времени у вас не будет. Если с выходом новой версии эти ресурсы обновляются, вам придется для сохранения работоспособности мода пересобрать его на основе обновленных ресурсов. Указанным образом вы можете обо всем таком узнать заранее, и сделать соответствующие выводы и действия (если ресурсы изменились). Либо не делать ничего (или делать что-то другое на ваш вкус), если обновление интересующие вас ресурсы не затрагивает. Примечания: Внутри OpenWG.WoT.Patcher от @Mixaill находится rdiff.exe более свежей версии, чем по моей ссылке в первом сообщении (rdiff-2.0.3-win64 vs rdiff-2.0.2-win64), поэтому я предпочитаю теперь использовать его (плюс, как бонус для меня, этот rdiff еще и имеет меньший размер, и не включает четырех внешних библиотек) На счет xdelta3.exe у меня пока нет понимания, в чем разница версии в OpenWG.WoT.Patcher и, например, доступных здесь: http://xdelta.org В любом, и в том, и в другом, и в третьем, и в четвертом случаях, - в интересующих меня сценариях применения утилит, результат их работы не отличается По всей видимости, для серьезных мододелов и исследователей OpenWG.WoT.Patcher является незаменимым инструментом, но таким мелким копошителям как я, рассматриваемый здесь точечный подход дает существенные преимущеста. Я, ради интереса, попробовал и то, и это, для своих целей, и для использования OpenWG.WoT.Patcher мне потребовалось создать несколько копий клиентов, многие десятки гигабайт места и десятки минут ковровой обработки, тогда как точечный подход дает весьма осязаемую экономию во всем таком, тем, для кого это имеет видимое значение. И еще один плюс - при точечном подходе не потребуется установки dotnet-runtime-5.0.0-win-x64, все что нужно - две утилиты, rdiff.exe (85.7kB) и xdelta3.exe (602.7kB)

Обновление моей сборки Версии модификации без XVM с антизум-скриптом и без антизум-скрипта: Прицелы по форме и цвету: Окружные: minimapACCL: CircusLime; в цвете Lime #00ff00 minimapACCA: CircusAqua; в цвете Aqua #00ffff Прямоугольные: minimapACQL: QuadroLime; в цвете Lime #00ff00 minimapACQA: QuadroAqua; в цвете Aqua #00ffff Прямоугольно-окружные: minimapACXL: XcrossLime; в цвете Lime #00ff00 minimapACXA: XcrossAqua; в цвете Aqua #00ffff По размеру и zoom: maxi: maximum, максимальный игровой размер, с антизум-скриптом midi: medium, средний размер, примерно 3/4 от максимального, с антизум-скриптом mini: minimal, минимальный размер, примерно 1/2 от максимума, с антизум-скриптом zoom: zoomable, зуммируемые, примерно 1/3 от максимума, без антизум-скрипта Прицелы в размерах maxi, midi, mini поставляются с отключенным зумом, который убирается антизум-скриптом от Ekspoint: mod_minimap_not_zoom_strategic.pyc Чтобы вернуть зум необходимо удалить указанный скрипт, но при этом потребуется особая пропорциональная прорисовка фигуры прицела в соответствии с механикой обработки в клиенте. Прицелы со специально подготовленными фигурами для использования без антизум-скрипта собраны в подмножестве zoom Бонус: minimapClear_1-10.zip: все прицелы Minimap_Clear_#1-10.zip (noXVM) из титульного сообщения темы, собранные в пакеты .wotmod minimapXVM_dummy.zip, версия для XVM, которая содержит заглушку, не выводящую практической картинки, и предполагает использование сторонних изображений прицела (в частности из архивов MinimapAimAll_100%, MinimapAimAll_6-8%.zip в титульном сообщении темы) Установка: Модификации без XVM, собранные в пакеты, предполагают размещение файла .wotmod из архивов minimap*.zip в актуальной подпапке игры mods\x.xx.x.x\ Модификация для XVM предполагает размещение содержимого из архива minimapXVM_dummy.zip в актуальной подпапке игры res_mods\x.xx.x.x\ Иллюстрации и архивы: прилагаются Исходное сообщение сборки: сообщение по ссылке Статус: актуально для клиента WorldOfTanks 1.12.0.0, 1.12.1.0 Пример работы мода без антизум-скрипта: minimapAC_mini.zip minimapAC_maxi.zip minimapAC_midi.zip minimapAC_zoom.zip minimapClear_1-10.zip minimapXVM_dummy.zip

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

Центральный маркер и маркер орудия? Их фигуры во флешках arcadeCrosshair.swf и sniperCrosshair.swf, упакованных внутри .wotmod, вроде как представлены векторными SVG картинками. Я попробовал извлечь первую попавшуюся картинку, перерисовать ее так, чтобы в том же габарите полотна фигуры было полезное изображение меньшего размера. То есть, если менять картинки по Replace не меняя их габаритные параметры (bounds) (в том числе, не используя Replace - Update bounds), то вроде как должно работать без особых проблем. Программы: Извлечение и замена картинок во флешках .swf: JPEXS Free Flash Decompiler https://github.com/jindrapetrik/jpexs-decompiler/releases Редактирование SVG: векторные графические графические редакторы, но можно обойтись любым текстовым редактором* и гуглом о синтаксисе фигур, а также онлайн редактором типа https://svgedit.netlify.app/editor/index.html Упаковка обратное в .wotmod, при желании: 7zip, с параметрами (почти как я использую, синтаксис .cmd файла Windows): 7z.exe a name.wotmod res -tzip -mx0 -aoa -mmt -ssw -stl -ssp -y где важны (обязательны) опции архивации (иначе клиент не примет пакет): -tzip -- zip архив -mx0 -- архив без сжатия, ну и имена: name.wotmod -- имя пакета .wotmod res -- корневая папка с подлежащими упаковке ресурсами, структурированными по образу и подобию имеющихся .wotmod, например, по образу одного из них полным содержимым будет res\gui\flash\sniperCrosshair.swf, другого, - res\gui\flash\arcadeCrosshair.swf (в данном случае, кстати, обе флешки можно вполне собрать в один общий .wotmod) * Например, код SVG картинки "DefineShape4(2)" из arcadeCrosshair.swf на замену исходной может выглядеть вот так (по отношению к исходной, диаметр внешней окружности уменьшен до 12*2=24 px и составляет примерно 2/3 от исходного, без заливки, при заданной толщине линии величиной в 2.0 px в цвете black, а центральная точка по диаметру уменьшена с 4px до 1.5*2=3 px, что составляет 3/4 от исходного, с заливкой в цвете black; при этом исходный размер полотна 36.0x36.0 px оставлен без изменений): <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg height="36.0px" width="36.0px" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <g class="layer"> <circle id="outer" cx="18" cy="18" r="12" fill="none" stroke="black" stroke-width="2.0px"/> <circle id="inner" cx="18" cy="18" r="1.5" fill="black" stroke="none" stroke-width="0px"/> </g> </svg> Итог манипуляций: была исходная картинка: (png иллюстрация), 2_src.svg стала картинка на замену: (png иллюстрация), 2_new.svg

Всем привет. Давно и долгое время безуспешно пытался сделать свой прицел без антизум скрипта. Проблема здесь в том, что картинка фигуры прицела в ресурсах клиента - простой зеленый квадрат (конкретно, сейчас размером 60.60х60.60 пикселей, в цвете #84dd58 Soft green), - в игре сильно деформируется по высоте и ширине. Имея в качестве исходника пустой квадрат такие манипуляции можно проводить как угодно, без особого вреда для пользователя (квадрат, прямоугольник, да какая разница). Если же наполнять фигуру прицела всякими крестиками, ноликами и черточками, как в данной теме, то в игре без антизум скрипта картинка превратится в нечто косо-ужасное. Со временем у меня все-таки получилось нарисовать прицел с учетом данных деформаций. Идея в следующем: Клиент в игре превращает исходный квадрат в уменьшенный прямоугольник с неким конечным фактором соотношения сторон (ширина к высоте), который, к примеру, у меня составляет примерно 1.77:1. Далее возможно представить, в каком конечном виде хотелось бы видеть "идеальный прямоугольный прицел" с учетом указанного соотношения. Затем в пределах доступного поля 60.60х60.60 пикселей можно нарисовать картинку так, чтобы относительно горизонтальных все элементы по вертикали были больше чем в воображенном идеале с учетом фактора (то есть, в моем случае, больше в указанные 1.77 раз). Получившимся на первый взгляд ужасом заменяем родной квадрат во флешке, отдаем последнюю клиенту, запускаем и видим в игре тот самый "желанный идеал". Алгоритм можно упростить следующим образом (в этом случае, правда, легко потерять часть полезного пространства по ширине): рисуем идеальную симметричную фигуру прицела, вписываемую в квадрат 60.60х60.60 пикселей. сжимаем фигуру по ширине с учетом фактора соотношения (в моем случае 1.77:1) имеем свой "идеальный прицел" Если для создания требуемой фигуры использовать какие-то продвинутые графические редакторы, растр (при этом последний также можно впихнуть во флешку вместо вектора напрямую), то дело это не сильно сложное, под силу любому пользователю. Я же создаю нативные векторные SVG в текстовом редакторе (из принципа любви к получаемому при этом чистому компактному, читаемому человеком коду SVG), но соответствующие операции с более или менее продвинутой графикой (например, включающей дуги, окружности, диагонали, то есть - хоть что-то отличное от ортогонально ориентированных линий) при этом довольно трудоемки. Так или иначе, с месяц назад сделал себе простой прицел прямоугольного типа (QL, QA). На мой вкус, получилось вполне приемлемо (см. скриншоты из песочницы, прилагаемые к данному сообщению; для сравнения также дан скриншот, как при этом выглядит скармливаемый клиенту SVG в исходном виде) Сегодня руки дошли до более сложных окружных (CL, CA) и прямоугольно-окружных версий (XL, XA). Кому интересно, пробуйте. В приложении в архивах - модификации в исполнении без XVM и без антизум скрипта трех типов в двух цветах, - версий (в моей номенклатуре) CL (CircusLime), CA (CircusAqua), QL (QuadroLime), QA (QuadroAqua), XL (XcrossLime), XA (XcrossAqua): а) в пакетах wotmod для размещения в mods minimapACCLz.wotmod.zip, minimapACCAz.wotmod.zip, minimapACQAz.wotmod.zip, minimapACQLz.wotmod.zip, minimapACXAz.wotmod.zip, minimapACXLz.wotmod.zip б) просто флешки, для размещения в res_mods minimapACCAz_res_mods.zip, minimapACQAz_res_mods.zip, minimapACQLz_res_mods.zip, minimapACCLz_res_mods.zip, minimapACXLz_res_mods.zip, minimapACXAz_res_mods.zip NB Наблюдаемый в моем случае фактор 1.77:1 подозрительно корреспондирует с пропорциями экрана моего же ноутбука: 1920х1080 >> 1920/1080=1.77(7), и соответственно может быть зависимым от разрешения в игре для конкретного пользователя, и если это так, и если соотношение сторон у пользователя сильно отлично от моего, - то что-то может пойти не так, или не очень так :) Впрочем, есть мнение, что указанные пропорции довольно типичны для существенной части современных дисплеев.

@night_dragon_on , понял спасибо. Я глянул, файл без этого параметра стал у меня быть 2021-03-03. Ок, возвратился, значит возвратился.

У вас отлично, а у меня что-то пошло не так. В кой-то веки решил сыграть пару боев, но не могу управлять танком, два боя подвел команду... Не успел дописать, и запостить логи, а теперь кажется и смысла уже нет, - вроде как разобрался. Дело оказалось в параметре extendedZoom.json, который я чуть выше сам тут и упоминал: "sniper": { "startZoom": Получается, что когда писал предыдущее сообщение, ориентировался на extendedZoom.json из авторского архива мода, а у меня в моем extendedZoom.json этого параметра вообще не оказалось. По ходу вернул параметр, и вроде как заработало, управление вернулось. Но этот же параметр у меня не зря пропадал, не просто так? Если мне не изменяет память, с выходом 1.12.0.0 он же на самом деле был выведен из extendedZoom.json, а теперь вернулся? Или у меня крыша едет?

@viking999 Так вы зум не отключаете, а задаете невалидный параметр .json. Значение null здесь применимо только к параметру ниже ("startZoom").

@Ekspoint, спасибо! @all, все вариации мода с обновленным антизум-скриптом: minimapAC.zip minimapClear_01-10_wotmod.zip minimapClear_XVM.zip

Не без труда нашел подходящий для теста реплей и протестировал в вариациях. Результаты следующие: 001-004: без антизум-скрипта: смещение прицела на миникарте не происходит, как и заявлялось выше. 005-008: с прежним антизум-скриптом: наблюдается смещение прицела на миникарте (хотя у меня и не такое большое, как в примерах выше). 009-012: с обновленным антизум-скриптом: прицел на миникарте не смещается. Таким образом, обновление антизум-скрипта решает возникшую проблему. Никогда такого не было, но опять ВГ умудрились что-то поломать что-то стабильно работающее, как этот скрипт, выдержавший пять лет без изменений, полжизни игры. @Ekspoint, вопрос, а можно для этой темы вновь сделать антизум-скрипт, как ранее было, не привязанный к ekspointCore? 001-004: 005-008: 009-012:

А кто-то уже разобрался, какое функциональные состояния отражает каждая из этих трех лампочек? Раньше у меня за это отвечал pmod с настройками ниже и там было все ясно, { "battleGui": { "detectionState": { "enable": true, "position": [-3, 2], "size": [24, 24], "texts": { "notDetected": "<font size='24' color='#8c8c8c'>*</font>", "missing": "<font size='24' color='#ff0000'>*</font>", "detected": "<font size='24' color='#00ff00'>*</font>", "dead": "<font size='24' color='#0d0d0d'>*</font>" } } } } По логике: guiControlsBattle_25.png - светится сейчас (самая яркая, с ореолом) guiControlsBattle_29.png - светился, но сейчас не в свете guiControlsBattle_31.png - еще не светился (серая) Я бы переделал эти картинки под себя, а то уж клиентские больно невразумительные на мой вкус. Edit: Нашел актуальный реплей, и на первый взгляд получается пока вроде бы так: - только что застветился (эта лампа включается лишь на миг, почти сразу же она сменяется следующей) - светится сейчас - ранее светился, но сейчас не в свете ничего (ни какой лампы) - еще (никогда) не светился

@Ekspoint, с выходом 1.12.0.0 на этой странице пошли сообщения о некорректном отображении прицела на миникарте: раз, два (иллюстрированное), три. Суть вопроса в том, что, как видно на скриншотах, в режиме вида от траектории (по клавише G) отображение фигуры прицеливания на миникарте ощутимо отлично (на скриншотах - примерно на два квадрата ближе) от того места, куда фактически прицелился игрок. Далее, исходя из сообщения @Arni Ex, "Это скрипт ломает отображение. Играю без скрипта - правильно отображается." Пока не было возможности проверить, что это действительно влияние антизум-скрипта mod_minimap_not_zoom_strategic.pyc, либо пинг или какая-то свежая ошибка в клиенте. @vitamin111, можете выложить здесь этот реплей?

@vitamin111, @HepBoB_He_OcTaJIoCb(RooF_), @Arni Ex, теперь ясно, спасибо. Только не знаю, можно ли будет что-то с этим сделать. В данной теме фигурирует давняя версия антизум-скрипта Ekspoint mod_minimap_not_zoom_strategic (дата компиляции файла 2016-08-18 20:22:36), которая не привязана к ekspointCore. В самостоятельном моде Ekspoint Скрипт отключающий зум арт-прицела на мinimap антизум-скрипт привязан к ekspointCore (без него работать не будет): INFO: [ekspointCore] No module named ekspointCore INFO: Error in module 'gui.mods.mod_minimap_not_zoom_strategic': name 'hookMethod' is not defined Насколько могу судить, в самом моде Ekspoint скрипт тоже давно не менялся (до недавнего времени долгое время обнаруживался файл скомпилированный 2018-02-04 03:26:56). С выходом же клиента 1.12.0.0 в моде Ekspoint скрипт явно каким-то образом обновился и дата компиляции теперь 2021-01-27 11:17:31. Интересно было бы посмотреть, наблюдается ли рассматриваемый дефект с обновленным антизум-модом Ekspoint.

@Tony Meduza, там нечему под 1.12 обновляться. Мод работоспособен (см. мое предпредыдущее сообщение здесь). Что касается антизум скрипта, то до недавнего времени еще работал. Edit: протестировал - и сейчас антизум скрипт работает.

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

@kochansv pmod. pmod.json ${"single.json"} single.json { "battleGui": { "enable": true, "teamHealth": { "enable": true, "skin": "minimal", "displayMainGun": true, "displayDamage": true, "texts": { // Кастомизация текстовых полей // minimal "averageDamageBad": "Средний урон: {{averageDamage}}", "averageDamageGood": "Средний урон: <font color='#A9FD00'>+{{averageDamage}}</font>", "mainGunProcess": "Основной калибр: {{mainGun}}", "mainGunAchived": "Основной калибр: <font color='#A9FD00'>+{{mainGun}}</font>" } } } } Ключевые опции: "enable": true, "skin": "minimal", "displayMainGun": true, "displayDamage": true (по умолчанию там все выключено). Текстовые поля Damage и mainGun можете подправить на свой вкус, а также перенастроить по образу и подобию вариантов, имеющихся в авторском .json Edit: Рекомендуемые равноценные источники: https://wgmods.net/50/ http://forum.worldoftanks.ru/index.php?/topic/1172523- (ведет на тот же wgmods.net) https://protanki.tv/mods/battle_mod/pmod https://lebwa.tv/lebwa-team/modpack-lebwa-team Сам pmod внутри везде одинаковый, но с выходом очередного патча выбор источника определится тем, где мод раньше обновится (wgmods.net обычно запаздывает).

@sergei66284, если идти по аналогии и смотреть иные моды данного источника, то найдутся такие варианты макросов вывода названия техники: {name-tank} - название танка {short-name-tank} - короткое название танка {vehicle} - танк Скорее всего эти макросы модоспецифичны, и не универсальны, то есть не подходят для других модов. Попробовать, конечно, можно, но маловероятно, что сработает.

Что имеется ввиду под [А-образным] прицелом? Индикатор орудия (gun marker), центральный (central marker), и то и другое? (Conditional) Gun Markers A-shaped I (with armor penetration indicator), A-shaped II (with load indicator), A-shaped III A-shaped IV (with armor penetration indicator), A-shaped V (with load indicator), A-shaped VI Aimpoint I (with armor penetration indicator), Aimpoint II (with load indicator), Aimpoint III Crosshair I (with armor penetration indicator), Crosshair II (with load indicator), Crosshair III O-shaped I (with armor penetration indicator), O-shaped II (with load indicator), O-shaped III Central Markers A-shaped I, A-shaped II, A-shaped III, A-shaped IV, A-shaped V Aimpoint I, Aimpoint II Crosshair I, Crosshair II I-shaped O-shaped I, O-shaped II T-shaped V-shaped Gun Markers находятся в ресурсе: <wot_folder>\res\packages\gui-part1.pkg\gui\flash\crosshairControls.swf Central Markers находятся в ресурсах: <wot_folder>\res\packages\gui-part2.pkg\gui\flash\arcadeCrosshair.swf <wot_folder>\res\packages\gui-part2.pkg\gui\flash\sniperCrosshair.swf Если не менять размеры, то прицелы можно легко изменить, как, например, я описал в теме Colourblind - Better Penetration Indicator на европейском форуме: http://forum.worldoftanks.eu/index.php?/topic/764554-colourblind-better-penetration-indicator/ Если же размеры менять, то я здесь не знаю пока. Поменять их на основе простых утилит можно, но уже не так просто, и как поведет себя такой прицел в игре, я еще не испытывал. В упомянутой теме сегодня как раз всплыл вопрос по размерам, может быть кто что и подскажет.

Исходный файл модификации остается неизменным со времен клиента версии v.1.11.0.0: md5:9a097c6554f205fc67340d7053b9fc59 *res\packages\gui-part1.pkg\gui\flash\minimapEntriesLibrary.swf Мод текущих сборок актуален для грядущего обновления клиента: v.1.12.0.0 Для продолжения работы мода: В случае пакетной сборки достаточно будет переместить избранный .wotmod файл в папку: <папка_игры>\mods\1.12.0.0 В случае авторской сборки от @Dark__Messiah новая папка для размещения будет: <папка_игры>\res_mods\1.12.0.0