GPCracker

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

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

Этот счетчик да, растет, но присваиваться номер должен к конкретному состоянию рабочего каталога. Если ты соберешь старую версию 1в1, то и номер должен быть тем же, поскольку результат один и тот же. Иначе получается что у тебя старая версия новее новой.

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

Значит он в пакетах. Блин, у меня если честно нет желания проводить КМБ, но могу подсказать, где найти информацию - первое - это как всегда гугл, второе - это соседний раздел, посвященный питону и экшнскрипту.

Как по мне, первая часть версии в любой схеме - это цифры через точку. Разделить по первому нецифра-неточка символу, первую часть разделить по точкам, преобразовать в инты и сравнить как кортежи интов в питоне (т.е. так как надо), часть которая буквами после идет - сравнивать как строки. Так будет самым четким образом, поскольку большинство известных и адекватных форматов версий впишутся в данную систему. И не забыть выкинуть первую букву v если она там есть и дальше идут цифры. Ну хотя последнее в принципе опционально. А то сейчас так получается, что адекватно можно сравнивать разве что номера билдов с фиксированным количеством знаков (типа 1325 или 8762 и т.д.), но никак не версии в том формате, который представлен в доке.

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

res/ - для разработчиков. для модов res_mods/<patch>/ и пакетами в mods/<patch>/

Кажется понимаю в чем прикол. Попробую запилить патч, но будет в лучшем случае только со следующей обновой.

1. Следить за своими снарядами. 2. Точно не в эту тему, тут питон курить нужно, и смотреть какие данные от сервака приходят. Если он эту инфу отсылает, то можно и впилить, если нет - ну а как узнать тогда?

Если ты имеешь ввиду дальномер - "автозахват" - это захват при наведении, нажимать ничего не нужно. Для автоприцела хоткеи не меняются. Those files contains mod's settings, or AvatarInputHandler settings, like dynamic camera, camera shaking on hit, etc. Not gun marker calculations, it is outside AvatarInputHandler (classes controlling camera), in VehicleGunRotator (classes controlling gun movement). 0.2.8 Alpha (XModLib v0.1.8) [04.05.2017] - код активации снайперского режима на артиллерии вынесен в отдельный плагин. - добавлена возможность перехода в снайперский режим на артиллерии скроллом. - плагин исправления маркера орудия в снайперском на артиллерии объединен с плагином снайперского режима на артиллерии. - исправлены мелкие баги. - по соображениям безопасности (активация плагина при отсутствии файла конфигурации), плагин SafeShot по умолчанию отключен. - небольшие внутренние структурные изменения. - часть плагинов переименованы. - конфиги плагинов вынесены в отдельные файлы конфигурации. - SafeShot больше не работает в стратегическом режиме прицеливания. Изменения в основном технического плана, структуризация кода, мелкие фиксы и т.д. Серьезно изменен конфиг в связи с выносом конфигурации плагинов в отдельные файлы. В библиотеке (XModLib) изменений нет, но приаттачил на всякий. AdvancedAimingSystem_v0.2.8.zip XModLib_v0.1.8.zip Думаю тут уже всем известно, что без XModLib мод работать не будет.

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

Ну все понятно. Версия внутри репозитория. Соответственно любой билд будет иметь эту версию до ее бампа. З.Ы. Раньше тоже примерно так же делал, но потом понял, что это реально 3,14 по причине возможности разных версий с одним номером, поэтому перешел на git describe. С ним уже такой трюк не прокатывает, и построить таким образом два разных билда с одной версией уже чисто технически не получится.

@Tomas, мне кажется или @Mr 13 не прочь прописать кому-то если и не бан, то РО точно?

Виз из нот а проблем) scripts/client/gui/mods/ в помощь. Папка для питон скриптов. Все остальные ресурсы или перегружают картохины, или подгружаются питон-скриптами/флешками.

Дочитал до 6.3, ржу не могу просто. <face-palm> Тут либо кучу лидирующих нулей писать... либо хэш какой-то упорядоченный.

I am monitoring all changes to python script and I didn't detect any valuable changes to crosshairs and gun marker algorithms. Maybe they just made gun marker more smooth to hide bouncing... But problem with aiming was not fixed... and I doubt it would ever be. Zoom does not have effect on problem, it may only make it more visible. When aiming correction is engaged or disengaged, there is a transition process, and gun marker may bounce a little. As it does on ANY significant DISTANCE CHANGE (when you move crosshairs from close object to far or vice versa). Like it happens on hill edge, or tank in front of the sky. Mod aim correction blocks instant distance change when you aim a tank, so tank in front of the sky is not a problem as long as correction is working. But it does not affect any static scenes in automatic mode (only with manual control) as it reacts only on tanks. Maybe I should say again, but gun marker bouncing is not the root cause of the problem. Aiming system structure and its instant and significant distance changes are. The aiming system is designed to free the player from ballistic fall calculations, like snipers do. They set up corrections (not sure if it is a right word) in their scopes on gravity and wind. There are no wind in WoT, but gravity still exists. As WoT is a casual game, aiming system use another approach to free the player from some sort of gravity corrections in scope - they use automatic distance calculation, which let players just aim and shoot. But when distance suffers instant and significant change (like hill edge, tank in front of the far sky) gun should be moved up or down to fit new aiming distance. This process is not instant, and this move is called as transition process. This is the real reason of gun marker bouncing.

У Юры устаревший фикс, я не знаю какого ******** он его не удалил при релизе пакетов. Я ему уже написал в соответствующую тему. Печалька однако. Как-бы понятно, что оно грузится в самом начале, я просто описал идею. В лоб реализовать не получится, понятное дело, м.б. есть какие-то красивые способы, например как-то обозначить алгоритм приведения авторской версии к сравниваемому типу (к тому же int, например) внутри пакета. Или еще как-то реализовать возможность обозначить, как сравнивать версии для однотипных пакетов. Потому как написать универсальный алгоритм сравнения, применимый для всех схем нумерации версий, вряд ли получится, а принимать какую-то одну - это серьезное ограничение для мододелов, если учитывать что даже в "точечном" варианте версия может иметь вид v0.2.7-8-gdee9a3b (git describe), или подобный в других сиcтемах контроля версий. Не говоря уже про схемы с датой в качестве версии и т.д. Ну как-бы тут да, вполне логично, для этого этот файлик в общем-то и нужен. Проблема в том, как сравнивать версии. Универсального компаратора написать не получится. Сравнивать строки некорректно, ибо 0.10.0 явно не меньше 0.9.0, а строки сравниваются посимвольно. Т.е. 1 < 9.

В нем проблема.

Попробуй удалить на время и потестить.

@Polyacov_Yury, тебе не кажется, что фикс для переводов, что в этом файле залит, немного (я бы сказал даже 3,14 как) устарел с момента ввода пакетов? Вместо него все фиксится пакетом net.openwg.vfsgettext_1.0.0.wotmod! Total Commander Но для таких целей лично я давно использую meld.

Реплейсор от Юры стоит?

Нет. Самый прикол в том, что все работает. Только что запустил реплей с твоим пакетом и net.openwg.vfsgettext_1.0.0.wotmod

Тут все очевидно. Изменен один путь (папка). Поэтому изменения в __init__.pyc. Не представлено содержимое meta.xml. Варианта 3. 1. Кто-то либо Юра, либо Poliroid накосячили с названием пакета - версией (если в метафайле версия не совпадает). 2. У Юры измененный пакет, кастомно собранный, пропатченный, сырой и т.д. 3. Poliroid сделал то, чего делать нельзя, т.е. выкинул в релиз два билда с одной версией. З.Ы. Юра, между id и версией должно быть нижнее подчеркивание, а не точка. Читай доку.

Так в том-то и прикол, что пакеты, согласно доке, сортируются по значению id, если оно одинаковое - то как понять, в каком порядке (между собой) будут загружены пакеты? Ведь в данный момент все по сути упирается в реализацию сортировки? Данный момент имеет довольно-таки важное значение, поскольку пакетом с тем же id может идти обновление/микропатч для какого-то тяжелого мода (например, пакета шкурок), где в целях экономии места присутствуют только измененные этим патчем файлы. И в таком случае именно от порядка загрузки зависит конечный результат. В идеале конечно было бы неплохо, если бы подобный конфликт с порядком загрузки решался внутри пакета, к примеру пакет объявляет некоторый интерфейс для сравнения версий (питоновская функция, например), и если обнаруживается такая ситуация (несколько пакетов с одинаковыми id), загрузчик вызывает эту функцию, передает ей список имеющихся версий, функция возвращает необходимую последовательность загрузки (тот же список версий, но упорядоченный), в принципе может даже что-то выкинуть из загрузки вообще.