GPCracker

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

Было бы все так просто... Для тех, кто понимает в ActionScript :) P.S. Этот класс отвечает за загрузку атласов у картошки.

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

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

Все как обычно, ничего нового, картошка как всегда в своем репертуаре. Ну и по традиции просим логи в студию.

По моим скромным подсчетам, причины [предположительно] примерно следующие. При компиляции всего этого во флешку это проблема с кучей ассетов, с которыми нужно как-то работать и находить при необходимости нужные, заменять, ... Это не очень удобно. Атлас же собирается относительно простой тулзой (причем субъективно существенно быстрее флешки) из некоторого количества картинок-исходников, и для смены картинок флешку пересобирать смысла не имеет (разграничение для системы версионного контроля). Во-вторых, ассеты привязаны к одной флешке, либо создают балласт в нескольких, а это размер и время на загрузку флешки, плюс заюзать картинку из другой флешки не так-то просто. Атлас же однократно грузится одной большой картинкой, при необходимости из него клонируется кусочек уже на уровне ActionScript, причем это может сделать любая флешка, менеджер атласов доступен на верхнем уровне. Ну и возможно как побочное явление, более удобно для мододелов, все-же пересобрать атлас проще, чем флешку, к тому же это можно еще и автоматизировать. Варианта два. Первый - скрипт автоматической пересборки атласа с заменой картинок, кидающий результат в res_mods. Второй - перехват на уровне констант Python или ActionScript (с последним требуется много магии, заклинаний и танцев с бубном), с перенаправлением на другой атлас (свой атлас), насчет этого варианта я не уверен, что имя атласа можно указывать в константах (при этом менять оригинальные файлы игры не потребуется, однако потребуется как минимум питон-скрипт, как максимум питон-скрипт-загрузчик плюс дополнительная флешка с кодом). Ну не считая варианта дать юзеру исходники для замен и компилятор атласов в зубы и отправить вносить модификации вручную (но тут еще некислый геморрой с пакетами выплывает). Ну а что тут еще можно сказать... Куча мест, где конфликты между модами разрулить проблематично, без применения тяжелой артиллерии и специальных средств.

https://bitbucket.org/XVM/xfw.native/src/d86921fd9469574541498ab8cf92d99882faf4f7/LICENSE.md?at=default&fileviewer=file-view-default

@StranikS_Scan, довольно интересный материал, почитаю на досуге :)

Какой-то слишком RARный для такого дела формат :) А если серьезно - там формат все-таки ZIP.

Ну а что, бинарный формат версий вполне себе неплох :)

Навести курсор на нужную панель, кликнуть правой кнопкой мышки и воспользоваться пунктом "скрыть" в контекстном меню. Либо через конфиг, как предложил @Scharfhobel чуть выше. Нужный пункт в файлах конфигурации зависит от того, что именно имеется в виду. Хотя в принципе весь подобный функционал по умолчанию всегда выключен. Начиная с этой самой версии была обновлена архитектура модификации и код плагинов был интегрирован в основной модуль, управление их исполнением осуществляется через параметры enabled в основных секциях соответствующих файлов конфигурации. Затрудняюсь сходу ответить на данный вопрос, нужно внимательно разбирать код картошки. Функция получения данных объявлена здесь. Сервер все равно должен присылать какие-то данные, в противном случае "серверное сведение" просто не будет работать. Скорее всего это server current aiming factor, но могу ошибаться, конечно.

AdvancedAimingSystem v0.2.18 (XModLib v0.1.18) [19.04.2018] - адаптация под новые версии клиента игры и библиотеки XModLib. В этом обновлении были исправлены основные ошибки, которые появились с выходом последнего большого патча клиента игры. В целом, если судить по отзывам группы тестирования, модификация работает относительно стабильно, однако все еще изредка проявляются различные мелкие баги, поэтому просьба сообщать обо всех пойманных исключениях, которые могут быть связаны с работой модификации. Скачать можно в разделе релизов на GitHub. Ну и как обычно напоминаю, что без XModLib мод работать не будет.

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

Проблема не в том, что строчки лишние, а в том, что файл неправильно декодируется. @Spectr20, попробуй разобрать другой утилитой, тем же wottools например.

@Spectr20, в указанном файле явно какая-то ошибка, скорее всего из-за неверного декодирования. Traceback (most recent call last): File "scripts/client/game.py", line 131, in init File "scripts/common/items/__init__.py", line 263, in init File "scripts/common/items/vehicles.py", line 262, in init File "scripts/common/items/vehicles.py", line 2634, in customization20 File "scripts/common/items/readers/c11n_readers.py", line 253, in readCustomizationCacheFromXml File "scripts/common/items/readers/c11n_readers.py", line 240, in __readItemFolder File "scripts/common/items/readers/c11n_readers.py", line 276, in _readItems File "scripts/common/items/_xml.py", line 78, in raiseWrongSection File "scripts/common/items/_xml.py", line 74, in raiseWrongXml Exception: error in 'camouflages/list.xml': subsection 'china:Ch05_T34_254' is missing or wrong Кстати, исходный файл какого размера? Вполне возможно, что там используется расширенное поле для указания длины, или что-то в этом роде.

2018-04-20 08:19:00.938: ERROR: Traceback (most recent call last): 2018-04-20 08:19:00.938: ERROR: File "scripts/client/vehicle_systems/CompoundAppearance.py", line 1099, in __onPeriodicTimer 2018-04-20 08:19:00.938: ERROR: File "scripts/client/vehicle_systems/components/siegeEffectsController.py", line 56, in tick 2018-04-20 08:19:00.938: ERROR: TypeError: 'NoneType' object does not support item assignment Эта ошибка встречается более десятка раз. Других исключений при беглом просмотре не увидел.

fixGunMarker выключен во всех режимах? Остальной мусор это косяки картошки, насколько мне известно.

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

Речь идет об AdvancedAimingSystem.

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

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

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

С этим борюсь я, выпуская обновления совместимости для работы с новыми версиями библиотеки. Но IRL все пошло немного не по плану, и выпустить это обновление для MinimapGunMarkers сразу после выпуска обновленной версии AdvancedAimingSystem не получилось. Потом картошка подкинула еще дополнительного счастья в виде новых коллайдов, которое я до сих пор выгребаю ситечком. Как минимум, основной задачей на данный момент является выпуск более-менее стабильного обновления совместимости для AdvancedAimingSystem, хотя бы в формате хотфикса. С динамическими коллайдами творятся адские вещи, мало того, что коллайды стали крашиться в потоках, так еще и вываливается куча непредсказуемых фантомных ошибок, которые возникают и исчезают неведомым магическим образом (фантомные ошибки - это такие ошибки, которые невозможно предсказуемо воспроизвести). Собственно, что касается одновременного использования MinimapGunMarkers и AdvancedAimingSystem, варианта сейчас два. Или использовать пока что-то одно, или накатывать фиксы / отключать забагованный функционал для legacy версии AdvancedAimingSystem (v0.2.13), она как раз использует XModLib v0.1.13.

Согласно таблице ASCII, если судить по документации, в том-то как-бы и дело. >>> sorted(['0.01.17-000-5a852716', '0.01.17-000-5ad18616', '0.01.13-000-59eddcfc']) ['0.01.13-000-59eddcfc', '0.01.17-000-5a852716', '0.01.17-000-5ad18616'] А если сравнивать вручную, то символ 3 меньше символа 7, поэтому 0.01.13-000-59eddcfc будет первым, что, собственно, и происходит. А вот если сравнивать дальше, то начинается неведомая хрень. Символ 8 меньше символа d, но несмотря на это 0.01.17-000-5ad18616 почему-то грузится раньше. Информация специально для Юры. Последний набор символов - это закодированный в hex timestamp времени сборки. И насколько я понимаю, реализация сравнения строк на Python описана здесь, и она не особо отличается от алгоритма работы strcmp.

Все пакеты, находящиеся в каталоге <каталог_WoT>/mods/<версия_WoT>/, сортируются по значениям узлов <id> и <version> в файле meta.xml и загружаются по порядку. В случае отсутствия файла meta.xml внутри пакета, в качестве идентификатора пакета будет использовано имя файла. При наличии узла <id> в файле meta.xml, имя файла пакета не влияет на порядок загрузки. Пакеты, у которых <id> совпадает, считаются разными версиями или частями одной и той же модификации, и конфликты между ними также не учитываются. Данные пакеты загружаются в порядке увеличения версии, которая хранится в узле <version>. Версии пакетов сравниваются посимвольно согласно таблице ASCII. Поведение аналогично функции strcmp(). В каталоге три пакета: GPCracker.XModLib_v0.1.13.wotmod (<id>GPCracker.XModLib</id><version>0.01.13-000-59eddcfc</version>) GPCracker.XModLib_v0.1.17.wotmod (<id>GPCracker.XModLib</id><version>0.01.17-000-5a852716</version>) GPCracker.XModLib_v0.1.17-dirty.wotmod (<id>GPCracker.XModLib</id><version>0.01.17-000-5ad18616</version>) Согласно документации, пакеты должны быть отсортированы и загружены в приведенном выше порядке. Однако в логах порядок загрузки получается следующий: 2018-04-14 12:54:31.694: INFO: [PY_DEBUG] Mod package 'd:/wingames/world of tanks/mods/1.0.0.1/gpcracker.xmodlib_v0.1.13.wotmod' loaded 2018-04-14 12:54:31.694: INFO: [PY_DEBUG] Mod package 'd:/wingames/world of tanks/mods/1.0.0.1/gpcracker.xmodlib_v0.1.17-dirty.wotmod' loaded 2018-04-14 12:54:31.694: INFO: [PY_DEBUG] Mod package 'd:/wingames/world of tanks/mods/1.0.0.1/gpcracker.xmodlib_v0.1.17.wotmod' loaded Судя по тому, что вылета с конфликтом не происходит, meta.xml скорее всего таки подтягивается, но сортировка как-то странно себя ведет. @ribbed @Finister @Darth_Abaddon