Jump to content
Korean Random
ribbed

Mod packages / Пакеты модов

Recommended Posts

Я конечно не гуру, но как насчёт пошагового сравнения разделов номера патча то есть разделитель точка ведь. Пример 0.9.17.1  0.9.18.0 - видно что сначала сравнить 1 и 0 после сравнивать 17 и 18 после сравнить 9 и 9 после сравнить 0 и 0 иметь временную переменную которая будет получать значение 0 или 1 после сравнения, в данном случае на сравнение 17 и 18 она получит 1 что соответствует что номер патча2 больше чем номер патча 1 и после при сравнение 9 и 9 не поменяется =)

 

Ну и тогда в выше указанном примере 10 больше 9 будет получатся =)

 

Второй вариант преобразовывать номер патча в цифровой эквивалент 0.10.0 превратиться в 0100 а 0.9..0 превратиться в 090 видно что 100 больше 90 =)

 

не уверен или это нужно, - я сейчас делаю так =) русский клиент, ( можно любой другой и на форуме попросить папку text из русского закинутьв  рес модс) - после беру файлик ХМЛ который прописывает доп сервера в лобби выбора серверов и могу заходить таким образом на любой сервер =) ХМЛ файл взял из темы на танковом форуме "помагатор" мод называется =)

А раньше помнится тоже мучался с локалз и через батники запускал разные сервера =)

Собственно сам ХМЛ приложил можете скачать глянуть =) это именно то что стандартно в клиенте должно быть =) просто и понятно =)

я уже сделал все что нужно было

спс им Polyacov_Yury, GPCracker

 

и вот нов мультиклиент MultiLogin.wotmod, и res_mods\0.9.18.0 \ scripts_config.xml

и text wotmod

 

аа народ вопрос  scripts_config.xml можно поместить в mods\0.9.18.0 или  в wotmod  ?

Edited by angelsoft
  • Downvote 1

Share this post


Link to post

Short link
Share on other sites

Я конечно не гуру, но как насчёт пошагового сравнения разделов номера патча то есть разделитель точка ведь. Пример 0.9.17.1  0.9.18.0 - видно что сначала сравнить 1 и 0 после сравнивать 17 и 18 после сравнить 9 и 9 после сравнить 0 и 0 иметь временную переменную которая будет получать значение 0 или 1 после сравнения, в данном случае на сравнение 17 и 18 она получит 1 что соответствует что номер патча2 больше чем номер патча 1 и после при сравнение 9 и 9 не поменяется =)

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

А то сейчас так получается, что адекватно можно сравнивать разве что номера билдов с фиксированным количеством знаков (типа 1325 или 8762 и т.д.), но никак не версии в том формате, который представлен в доке.

  • Upvote 1

Share this post


Link to post

Short link
Share on other sites

А то сейчас так получается, что адекватно можно сравнивать разве что номера билдов с фиксированным количеством знаков (типа 1325 или 8762 и т.д.), но никак не версии в том формате, который представлен в доке.

 

В реальности именно так и нуно. Должен быть внутренний порядковый номер типа uint и должна быть внешняя версия типа "High.Low.Release.Build". Например, 12047 и ''1.0.0.47". Первая для внутренних механизмов, вторая чисто для информации.

Share this post


Link to post

Short link
Share on other sites

В реальности именно так и нуно. Должен быть внутренний порядковый номер типа uint и должна быть внешняя версия типа "High.Low.Release.Build". Например, 12047 и ''1.0.0.47". Первая для внутренних механизмов, вторая чисто для информации.

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

Тут еще прикол-то самый в том, что картоха сама привела формат версий в качестве примера, который они же не умеют нормально сравнивать.

Edited by GPCracker

Share this post


Link to post

Short link
Share on other sites

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

Тут еще прикол-то самый в том, что картоха сама привела формат версий в качестве примера, который они же не умеют нормально сравнивать.

 

Внутренний счётчик не обратим, он только растёт, ни каких "нужных" номеров не должно быть.

Share this post


Link to post

Short link
Share on other sites

Внутренний счётчик не обратим, он только растёт, ни каких "нужных" номеров не должно быть.

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

Share this post


Link to post

Short link
Share on other sites

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

 

Она не будет старой, это новый билд. То что ты в нем вернул код идентичный тому каков он был когда-то - не играет роли. Я не очень понимаю зачем ты внутренний счетчик версий/сборки пытаешься превратить в хэш проекта. Для чего? Хэш - всегда и был хэшем. При этом не понятно для чего он тебе нужен в качестве версии?

Share this post


Link to post

Short link
Share on other sites

Она не будет старой, это новый билд.

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

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

Share this post


Link to post

Short link
Share on other sites

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

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

 

Зачем ты мне это рассказываешь? Я не это спрашивал у тебя в посте выше. Там аж два вопроса тебе. И честно говоря я первый раз вижу человека, у которого новые билды не являются более свежими чем предыдущие. Но это не суть. Вопрос был за внутренний счётчик.

Edited by StranikS_Scan

Share this post


Link to post

Short link
Share on other sites

Я не это спрашивал у тебя в посте выше. Там аж два вопроса тебе.

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

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

Share this post


Link to post

Short link
Share on other sites

 

 

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

 

Какой билдер? У тебя как с чтением? Где тут билдер?

 

В реальности именно так и нуно. Должен быть внутренний порядковый номер типа uint и должна быть внешняя версия типа "High.Low.Release.Build". Например, 12047 и ''1.0.0.47". Первая для внутренних механизмов, вторая чисто для информации.

 

И таки расскажи мне почему надо сравнивать именно "версии" в черте каком текстовом формате, а не внутренний инт-итератор?

  • Downvote 2

Share this post


Link to post

Short link
Share on other sites

The English translation of the document v0.4 attached to the first post. Please feel free to share it with English-speaking mod creators.

  • Upvote 3

Share this post


Link to post

Short link
Share on other sites

@ribbed, у меня вопрос. У меня пользователи все время спрашивают, что такое .wotmod, куда его класть, чем открывать... Может, спустя много времени после их ввода, таки запилите новость на портале?)

 

 

UPD. Обнаружил, что если папка разбита по двум разным пакетам без каких-либо конфликтов, ResMgr.openSection(папка_на_уровень_выше).keys() возвращает ее имя дважды. Это как вообще можно объяснить?

Edited by Polyacov_Yury

Share this post


Link to post

Short link
Share on other sites

UPD. Обнаружил, что если папка разбита по двум разным пакетам без каких-либо конфликтов, ResMgr.openSection(папка_на_уровень_выше).keys() возвращает ее имя дважды. Это как вообще можно объяснить?

 

Это не баг, а фича (отображаются все подмонтированные каталоги).

И вообще, RTFM, там это учли, (отрывок из 8.1.2) :)

for name in folder.keys():             
    if name not in result:                 
        result.append(name) 
Edited by Mixaill

Share this post


Link to post

Short link
Share on other sites

@ribbed, у меня вопрос. У меня пользователи все время спрашивают, что такое .wotmod, куда его класть, чем открывать... Может, спустя много времени после их ввода, таки запилите новость на портале?)

Не, новости на портале не будет. Это фича чисто для мододелов, а портал ориентирован на обычных игроков.

 

Ты можешь сам отвечать, что да как или давать ссылку на эту тему. Это ж не секретная инфа.

  • Upvote 2

Share this post


Link to post

Short link
Share on other sites

Здравствуйте. Я хочу поменять иконки танков на свои, подскажите пожалуйста по какому адресу запаковать файлы battleAtlas.xml и BattleAtlas.png?  Раньше эти файлы я копировал по адресу res_mods\0.9.X\gui\flash\atlases\battleAtlas.  Я так понимаю, сейчас за иконки техники отвечает файл battleAtlas.wotmod? Спасибо.

Share this post


Link to post

Short link
Share on other sites

Privet,

 

A suggestion for future improvements:

 

To solve conflicts with known mods, meta.xml could contain fields like "load-after" and "load-before" with a mod_id

 

load_order.xml is nice, but cannot be distributed with a single mod. It is useful only for big modpacks.

 

Example:

<loadAfter>
  <mod_id>com.modxvm.xfw</mod_id>
</loadAfter>

<loadBefore>
  <mod_id>some.other.mod1</mod_id>
  <mod_id>some.other.mod2</mod_id>
</loadBefore>

Cheers,

  • Upvote 1

Share this post


Link to post

Short link
Share on other sites

 

 

To solve conflicts with known mods, meta.xml could contain fields like "load-after" and "load-before" with a mod_id

and who do you think will determine the order of loading mods?

Share this post


Link to post

Short link
Share on other sites

To solve conflicts with known mods, meta.xml could contain fields like "load-after" and "load-before" with a mod_id

Imagine that there is 4 mods A, B, C, D. C requests loading after A but before B. D requests after B but before A. We stuck into situation that could not be resolved. In scale of many mods installed, with many load dependencies, conflict checking becomes a quite complex task.

Hovewer, a "dependecy" section (mods required for correct operation) in package meta file would be good enough.

Share this post


Link to post

Short link
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...