GPCracker

Может ты пакет просто неправильно собираешь?

@angelsoft, ответил в твоей теме. Загляни в paths.xml. Там с появлением пакетов появился дополнительный пункт. Неспроста однако :) Интуиция мне подсказывает, что пока оно в таком виде, и paths.xml доступен, можно хоть 10 своих папок добавить.

Первое, с чем тебе стоит разобраться - это виртуальная файловая система. Изначально, в ней работают все ресурсы, кроме текстов. Т.е. если ты добавляешь в res_mods какой-то файл, то он либо добавляется к VFS, либо переопределяет файл из res или res/packages/*. За последовательность поиска файла по папкам отвечает paths.xml из корневого каталога игры. Файл в VFS есть первый найденный файл по paths, либо если не найден, тогда считается несуществующим. С текстами другая тема. Там так не прокатывает, поскольку gettext не понимает VFS. Поэтому существует такой файлик .text_locator, который и определяет каталог реальной файловой системы, откуда грузить файлы. Именно поэтому приходится копировать текстовые файлы в res_mods перед переопределением одного из них. С VFS такой необходимости нет. Пакет работает по принципу чтения двоичных данных через утилиты доступа к VFS (ResMgr) и конструированию объекта перевода вручную. Т.е. он переопределяет код загрузки, создавая в игре возможность грузить тексты с помощью VFS. Пакеты являются одним из элементов VFS. Т.е. установка данного пакета (net.openwg.vfsgettext_1.0.0.wotmod), во-первых, убирает необходимость копировать тексты, во-вторых, дает возможность подгружать их из пакетов. Поскольку папка res внутри пакета эквивалентна res_mods/<patch>, соответственно дополнительные текстовые файлы, которые раньше лежали в res_mods/<patch>/text/lc_messages, нужно положить по пути res/text/lc_messages. Копировать файлы, которые не были изменены внутри мода, не требуется. З.Ы. Учись читать документацию. Там все подробно написано. По части ResMgr - есть документация на BigWorld. Большинство функций и методов ResMgr (да и движка игры вообще) там расписаны.

subprocess powershell заменить на вызовы shutil.* и os.* - более питоновский и более дружественный к другим ОС метод. 7-zip можно нормально стартануть и через subprocess. Копирование из питона конечно не огонь, но тоже строки в 3 через shutil glob и еще один-два стандартных модуля можно сделать. os.path.exists заменить на более конкретные isdir, isfile. Ну а так все остальное достаточно специфично под проект. З.Ы. У меня проект собирается примерно так. Кода конечно много, но почти универсальная штука, хавает питон, флешки (проекты FlashDevelop), ресурсы, атласы, локализацию, может собирать несколько пакетов и все пакует в один релизный архив. Причем на линуксе тоже норм работает.

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

Большинство модов основано на питон-скриптах. Вот и думай :)

Here is a guide describing bases of DAAPI. It is on Russian, but maybe you could understand or translate it.

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

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

Есть мододелы, которые это как-то делают. Если сильно захотеть, то можно узнать как (по секрету: на форуме есть гайды), а если не за просто так, то м.б. и под ключ сделают. Это тебе не в танчики играть. Тут не все так просто, как ты хочешь. Гайды есть, но думать все равно придется.

@ribbed, хотелось бы увидеть пояснение по части разрешения конфликта между пакетами с одинаковым id и разной версией, в особенности насчет версии, учитывается ли она при разрешении конфликта, если да, то по какому алгоритму происходит сравнение и есть ли какие-либо требования к формату версии пакета? И как в случае такого конфликта будет построена структура виртуальной файловой системы? Отвечал же уже. В другой теме (p.s. читать далее от поста по ссылке). Зачем дублировать вопрос? В надежде что на него быстрее ответят?

1. Да 2. Да

Он выпилил снап. Читай внимательно что написано в шапке его темы на форуме EU кластера.

res/text/lc_messages внутри пакета плюс vfs_gettext для работы файлов локализации изнутри пакетов. Там в доках есть ссылка. .text_locator и остальные файлы копировать не нужно. Этот пакет сам находит нужный файл согласно приоритету директорий vfs. P.S. Плохо читал доки. Там все подробно написано.

@spoter, что насчет шуток, честно говоря не думал насчет того, что это прикол, скорее просто поправили код а условие убрать забыли, ибо сам часто пишу что-то вроде return vehicle.position if vehicle is not None else Noneчто по сути аналогичноif vehicle is not None: return vehicle.position return None # иногда специально так пишу, чтобы было понятно что функция возвращает значение, и в данном случае это None, т.е. что это функция, а не процедура, хотя чисто технически достаточно просто return. На компиляцию это не влияет, байт-код будет одинаковым.Ну а так над любителями покопипастить код норм тема поржать... То-то они (многие) код любят шифровать - чтобы не спалили :)

@spoter, решил посмотреть, о чем там оптимизация автоприцела... раз уж тут народ заинтересовался запрещенностью мода. Что-то как-то больно замутно написал условия мин-макс для выбора цели... полностью разобрать не могу, но так понимаю выбирается ближайшая по углу и наиболее близкая по расстоянию? Да, и проверка на скрытость цели (коллижн-тест) весьма странная. Дело в том, что vehicle.position, ЕМНИП, это точка под танком... Или я ошибаюсь? З.Ы. Инструкция return result if result is not None else Noneпросто убила :) З.Ы.Ы. Мод с захватом за препятствием относится к запрещенке. Я так понимаю, что catchHiddenTarget нужен для обхода определения "захват за препятствием" картохи... или идея в этом другая? Однако как ни крути, одиночный коллижн-тест не критерий, поскольку танк - это объемный объект а не математическая точка, так что с целью обхода картохиных правил для "снапа" нужно писать более интересные и сложные алгоритмы.

А логи где?

Для того, чтобы добавить свою панельку/окно в бою/ангаре ничего патчить не нужно. Патчить придется только если будешь что-то сильно менять, например дамаг-панель. А все элементы как правило вынесены в отдельные флешки. Т.е. в большинстве случаев патчить достаточно только их. И установка какой-то дамаг панели подразумевает, что других дамаг-панелей вместе с первой устанавливать не будут. К тому же, никто не отменял такую вещь как прототипы, через которые можно немного пропатчить класс, по крайней мере, метод/атрибут добавить точно можно. Потомка (child) тоже без проблем можно добавить по нужному индексу. Спрайт с картинкой можно подцепить через получение потомка по имени/индексу и переопределить ему графику в реалтайме... или просто удалить и на его место воткнуть свой. Получить battlePage из другой флешки? Давно уже делают, battleFlash от GambitER'а тому пример. У флешек общая среда выполнения в игре, а значит любая подключенная к системе флешка видит все доступные классы и объекты. Ну да, грубо как в питоне хук не поставишь, и к приватному атрибуту не подлезешь. Но все равно в реалтайме патчить тоже можно. Да, придется напрячь немного мозг, почитать документацию более внимательно, но большинство вещей можно в принципе сделать без непосредственной модификации флешек. Тут другой вопрос, что нехилая часть модов делается наспех левой ногой, отсюда и конфликты. Ну еще конфликты бывают когда моды пытаются сделать одно и то же, но на свой лад... тут 90% это два разных мода с одной и той же задачей (две разные дамаг-панели например), остальные 10% решаются через конфиг, или написать автору чтобы добавил в конфиг дисейбл этой фичи, чтобы не возникало конфликта / решил конфликт иным способом. Так что при более-менее грамотном подходе к структуре и алгоритмам в модах проблемы конфликта на переопределение файла сводятся почти к нулю. Что касается шкурок - да, тут есть некоторая проблема в том, что из-за приличного их веса разработка и тестирование пакетами не удобна. Но никто особо не мешает дебажить через res_mods, а результат собирать в пакеты. Тут по большому счету решают скрипты автоматизации сборки. Так работает сборка XVM например, запускаешь один файлик и он делает за тебя всю работу. Мне для сборки своих модов тоже достаточно запустить один файлик, подождать 5сек максимум и из папки результатов сборки можно забрать еще теплый собранный пакет для тестирования, в другой папке уже лежит готовый архив со всеми нужными конфигами, метафайлами и т.д. Проблема только в том, чтобы грамотно написать скрипт. Пока конечно пакетная система еще немного сыровата, чтобы на нее можно было полностью все перевести, еще не все допилено как нужно, но как по мне, сама по себе идея заменить кучу раскиданных по папке res_mods файлов одним вполне себе неплохая. Что касаемо моей позиции в вопросе насчет пакетов - я за то, чтобы остались оба способа подключения модов. Через пакеты удобно ставить многофайловые моды без запоминания что где и от чего и что в случае чего удалять нужно, проще обновлять (не нужно вычищать хвосты перед установкой, а достаточно просто удалить один файл и заменить его более новым), а через res_mods можно удобно пропатчить (переопределить) файл в пакете, не редактируя сам пакет, т.е. применить точечный пользовательский патч, который нормально переносит обновы от автора мода, главное следить за изменениями в файле, который патчится (не нужно при этом каждый раз править пакет, а файл править нужно только если автор мода его при обнове изменил). Так например можно закинуть какую-то свою шкурку на отдельный танк поверх пакета со шкурками.

Изначально патчить игровые файлы это неправильное решение, и пользоваться им необходимо только при реальном отсутствии других вариантов. Потому что это 100% конфликт в любом случае, неважно пакетами грузится или нет, и какой это вообще файл, хоть флешка, хоть питон, или даже текстовый. Для приведения двух таких модов под общий знаменатель придется редактировать этот файл, выполнять т.н. merge. Не делайте так (избегайте прямых патчей файлов), ищите альтернативные способы выполнить нужный патч. Исключение - это полные моды каких-то панелей, которые подразумевают что другие подобные моды ставить явно лишнее. Тем более что сейчас система во многом устроена так, что через питон сейчас можно подменить конкретные классы в некоторых случаях, например на миникарте можно создавать свои маркеры, как и маркеры техники, достаточно просто унаследовать нужный класс, прописать свою графику, скомпилить свою флешку с external, и в питоне подкинуть вместо стандартной ссылки ссылку на свой класс, ну и не забыть перед этим загрузить флешку, например через вьюшку-лоадер или библиотекой подсунуть (тоже финт в питоне). Так делает например XVM, так же работает мой мод Minimap Gun Markers.

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

Любишь ты костыли, Юра. Если честно, я не помаю, какое значение имеет название пакета? Если значение имеет только то, что из него загружается. Или ты пакеты при помощи скриптов внутри пакета патчишь? У меня вообще версия пишется автоматически через git describe в имя пакета и файлы метаданных при сборке. Во-первых, это, блин, удобно, т.к. версия прописывается автоматом где нужно и вычисляется тоже автоматом; во-вторых, никаких на**** файлов с номером версии и коммитов в стиле "version bump" (особенно когда забыл его прописать и в релиз улетела новая сборка со старым номером версии - вообще огонь), просто проставляешь теги в репозитории и все (учитывая что на гитхабе релизы тоже привязаны на теги); в-третьих, учит не делать такую вещь как билд теста/релиза с "грязного каталога", ибо номер версии будет "немного некрасивый" (потому как потом сиди и вспоминай, в каком состоянии и с какими правками собирался данный билд) или по крайней мере видно, что собрано по-быстрому; в-четвертых, существовать разных сборок с одной и той же версией чисто технически не может, за исключением двух билдов с грязного каталога поверх одного и того же коммита, т.е. "неправильных" билдов. Про версию в доках ничего не прописано, как и не прописано требований к формату версии и алгоритма их сравнения.

0.1.2 Alpha (XModLib v0.1.8) [01.05.2017] - модификация обновлена для поддержания совместимости с новыми версиями клиента игры и библиотеки. - применено накопительное обновление, перенесены улучшения кода из AdvancedAimingSystem. - осуществлен перевод модификации в пакеты, плагины вынесены в отдельные файлы и пакеты соответственно, управлять ими теперь еще проще. Обновлены пути к файлам конфигурации и ресурсам модификации, также значительно изменен и оптимизирован под новую схему скрипт сборки. Второй пункт повлек за собой довольно существенные изменения. Поскольку при нажатии Ctrl открепляется курсор, все сочетания с этой клавишей работать не будут. Часть комбинаций по непонятным причинам тоже не работает, скорее всего перехватывается чем-то еще внутри скриптов картохи и до обработчика не доходит. MinimapGunMarkers_v0.1.2.zip XModLib_v0.1.8.zip Думаю тут уже всем известно, что без XModLib мод работать не будет.

ЕМНИП, принцип отрисовки этого маркера такой же, как и других маркеров на миникарте. Можно просто через скрипты заоверрайдить отрисовку... или просто поменять класс маркера на свой с блекджеком и ***, определив его через стороннюю флешку (ака хитрый финт ушами). Правда не понятно, как такой финт будет работать с XVM (если они тоже патчат этот маркер - то будет конфликт).Пример, как такое сделать, есть в XVM и в моем моде на маркеры орудий на миникарте (ссылка в подписи). Upd. Так что совместно с XVM только если через XVM. Отдельно можно запилить свой класс для камеры и отрубить ресайз. Upd. А вот и класс этого маркера.

Мод переехал в пакеты. Архив содержит пакеты основного мода, пакеты плагинов и конфиги. Скачанный архив нужно распаковывать в <WorldOfTanks>/mods.

Ну тут как-бы: 1. Эти самые наглые читеры походу донатят на порядок больше деток, а смысл трогать дойную корову? Цель игры - поднять бабла, а не забанить читеров. Картошка и не напрягалась на тему читеров, пока не поднялся хайп. Пока читер донатит больше, чем вырастет донат от его бана, трогать его экономически не выгодно. 2. Наверняка авторы платных сборок далеко не идиоты, чтобы отдавать/продавать их для анализа WG... Или хотя бы используют более-менее адекватные методы защиты. 3. Давно уже заметил, еще только когда начинал заниматься модами и собственно исследовал (ну типа качал и декомпилил) моды, написанные до этого, что с "ломаными мегачитами" в комплекте очень часто идет "подозрительный аттач", от которого антивирус беситься начинает. Жадные малолетние школьники в поисках халявы - хорошая ЦА для всяких вирусописателей - ведь против человеческого фактора не поможет никакая защита и никакой антивирус, главное не забыть написать, что тут вирусов нет, отключите антивирус, чтобы не мешал устанавливать :) 4. Тут стоит заметить, что число халявщиков всегда больше, чем число платежеспособных граждан... так что те самые школьнички наверняка составляют большинство читеров, а следовательно и приоритет на их бан куда выше... Тем более, что читеров полностью всех забанить не получится, а вот ухудшить доступность читов для широких масс - это уже прогресс. Что легче установить или удалить - один файл-пакет, или кучу разбросанных по папке res_mods, особенно когда они никак не промаркированы, что от какого мода?