Config override

[Wilem82 15]

Возможно ли сделать частичное переопределение полей в конфиге? Например,

 

configs/xvm/xvm.xc:

 

${"default/@xvm.xc":"."},
${"wilem-override/playersPanel.xc":"playersPanel"}

 

В default/ строго то что из поставки.

 

В wilem-override/playersPanel.xc:

 

 

{

  "vicon": {
    "alpha": 100,
    "x": 40,
    "y": 10,
    "align": "center",
    "valign": "center",
    "bindToIcon": true,
    "format": "{{.playersPanel.vtypez.{{vtype-key}}}}",
    "shadow": { "distance": 0, "angle": 45, "color": "0x000000", "alpha": 80, "blur": 2, "strength": 4 }
  },
  "playersPanel": {
    "vtypez": {
      "HT":  "<font face='xvm' size='20' color='#D358F7' alpha='{{alive?#FF|#80}}'>?</font>",
      "MT":  "<font face='xvm' size='20' color='#58ACFA' alpha='{{alive?#FF|#80}}'>;</font>",
      "LT":  "<font face='xvm' size='20' color='#F5DA81' alpha='{{alive?#FF|#80}}'>:</font>",
      "TD":  "<font face='xvm' size='20' color='#8258FA' alpha='{{alive?#FF|#80}}'>.</font>",
      "SPG": "<font face='xvm' size='20' color='#FE2E2E' alpha='{{alive?#FF|#80}}'>-</font>"
    },
    "medium2": {
      "enabled": true,
      "extraFieldsLeft": [
        ${"vicon"}
      ],
      "extraFieldsRight": [
        ${"vicon"},
        ${"enemySpottedMarker"}
      ]
    },
  }
}

 

То есть в wilem-override/playersPanel.xc специально не задаются куча необходимых полей и предполагается, что они возьмутся из default/.

 

Сейчас xvm ругается, что после

 

${"default/@xvm.xc":"."}

 

должен быть конец файла. Видимо потому, что default/@xvm.xc представляет собой топовый объект в JSON-е, а второго рута быть не может. Можно ли это как-то обойти, по-другому сделать? Своими силами не удаётся.

 

Изначально задача переопределить только несколько полей в отдельной директории, что бы после каждого обновления xvm не ломались скопи-пасченые конфиги.

[Yupi 505]

@Wilem82, ты можешь вообще сделать свой конфиг, например /res_mods/configs/xvm/Wilem82/, в котором прописать только свои "оверрайды", и сослаться только на него из /res_mods/configs/xvm/xvm.xc

 

Ссылаться при этом на дефолт вообще не надо. Если поля нет в твоём конфиге, оно будет взято из вшитого конфига, который полностью такой же как и дефолт.

[Wilem82 15]

@Wilem82, ты можешь вообще сделать свой конфиг, например /res_mods/configs/xvm/Wilem82/, в котором прописать только свои "оверрайды", и сослаться только на него из /res_mods/configs/xvm/xvm.xc

 

Ссылаться при этом на дефолт вообще не надо. Если поля нет в твоём конфиге, оно будет взято из вшитого конфига, который полностью такой же как и дефолт.

 

В самом деле. Оказалось всё просто, спасибо.

 

Правда, с ограничением. Например, если мой playersPanel.xc ссылается на ${"enemySpottedMarker"} а его в моём нет, хотя он есть в default - не работает. То есть эту секцию надо продублировать.

[konrad509 445]

Wilem82, сделайте свой конфиг как TwoPizza предложил и не создавайте проблемов там где их нет..

 

 

если мой playersPanel.xc ссылается на ${"enemySpottedMarker"} а его в моём нет, хотя он есть в default - не работает.

в этом случае конфиг сломается и XVM загрузить встроенный конфиг

Edited September 20, 2016 by konrad509

[Yupi 505]

Правда, с ограничением. Например, если мой playersPanel.xc ссылается на ${"enemySpottedMarker"} а его в моём нет, хотя он есть в default - не работает. То есть эту секцию надо продублировать.

Не вижу в этом "ограничения". Зачем ссылаться на то, чего нет? Он ведь автоматически и без ссылки подхватывается из встроенного. В чём ограничение?

[Wilem82 15]

Не вижу в этом "ограничения". Зачем ссылаться на то, чего нет? Он ведь автоматически и без ссылки подхватывается из встроенного. В чём ограничение?

 

Например, если нужно добавить новое поле в pp/medium2/extraFieldsRight. Получается:

 

// ...

"extraFieldsRight": [

  ${"нечто_моё"}

]

 

и лампочки там уже не будет, т.к. массив переопределяется полностью. А в оригинале там, среди прочего, ещё и ${"enemySpottedMarker"}. Соответственно, если хочется и своё добавить и лампочку оставить, надо указывать:

 

"extraFieldsRight": [

  ${"нечто_моё"},

  ${"enemySpottedMarker"}

]

 

А это уже ссылка несуществующий в текущем конфиге путь. Так понимаю, пути в ${"..."} ищутся только в текущем файле, без учёта внутренней дефолтной конфигурации xvm (а там этот путь есть). Правда, не пробовал через макрос, да и не знаю можно ли так - {{.enemySpottedMarker}}.

 

Кстати, то же ограничение у "$ref". Если в объекте на который ссылается $ref есть массив, то в этот массив нельзя добавить элемент, только перезаписать массив полностью. Или я не понял, как это сделать.

[konrad509 445]

не понимаю вас...

 

Например, если нужно добавить новое поле в pp/medium2/extraFieldsRight. Получается:

 

// ...

"extraFieldsRight": [

  ${"нечто_моё"}

]

 

и лампочки там уже не будет...

если удалите ${"enemySpottedMarker"} то и не будет... это очевидно

 

Соответственно, если хочется и своё добавить и лампочку оставить, надо указывать:

"extraFieldsRight": [
  ${"нечто_моё"},

  ${"enemySpottedMarker"}
]

А это уже ссылка несуществующий в текущем конфиге путь.

если секцие нечто_моё и enemySpottedMarker присутствуют в конфиге, то всё ок

но если одной из них или всех нет, то

Зачем ссылаться на то, чего нет?

Edited September 20, 2016 by konrad509

[Wilem82 15]

не понимаю вас...

 

если удалите ${"enemySpottedMarker"} то и не будет... это очевидно

 

если секцие нечто_моё и enemySpottedMarker присутствуют в конфиге, то всё ок

но если одной из них или всех нет, то

 

Речь про то, что enemySpottedMarker есть во внутренней конфигурации xvm, которая по-умолчанию. А сослаться на это не получается, надо у себя дублировать.

[konrad509 445]

нет никакого дублирования...

 

если в файле xvm.xc укажете путь к конфигу, то XVM загрузится этот конфиг, а не внутренний и в этом случае встроенный конфиг вас вообще не интересует..

 

бывают ситуации, когда XVM загружается части встроенного конфига, но это разные ситуации

может быть кто-то объяснит вам это лучше

Edited September 21, 2016 by konrad509

[Wilem82 15]

бывают ситуации, когда XVM загружается части встроенного конфига, но это разные ситуации

 

 

Именно это и нужно - по-максимому загружать встроенный.

 

 

если в файле xvm.xc укажете путь к конфигу, то XVM загрузится этот конфиг, а не внутренний и в этом случае встроенный конфиг вас вообще не интересует..

 

 

Нужен встроенный.

 

Попробую объяснить с начала.

 

Задача: составить собственные конфиги таким образом, что бы при обновлении xvm в существующих собственных конфигах было минимум конфликтов с новыми конфигами xvm в новой его версии, а также что бы в собственных конфигах было минимум устаревающей после обновлений версии xvm информации.

 

Решение №1.

 

Полностью скопировать default/ и там делать свои правки.  Самый плохой вариант, потому что когда в default/ в следующей версии что-то поменяют, то в скопированном этого по определению не будет. Получается конфигурация xvm обновляется, а скопированная - только устаревает. И нужно прикладывать кучу усилий что бы между обновлениями переносить изменения из default/ в скопированное.

 

Решение №2.

 

Воспользоваться тем, что xvm внутри себя (в коде) и так хранит default/ и в собственных конфигах можно переопределить только нужные ключи. Например, если меня устраивает дефолтная конфигурация но я только хочу включить autoReloadConfig, то создаю на диске конфиг из одной строчки, где это включается. Всё. Все остальные настройки у меня всегда последней версии, потому что они берутся из настроек xvm по-умолчанию. Не из директории default/, а из того что xvm и так хранит у себя в коде.

 

Так вот в этом подходе есть ограничения.

 

Ограничение A.

 

Например, хочу я добавить собственное поле в playersPanel/medium2/extraFieldsRight. Значение этого ключа - это массив, то есть [ a, b, c ]. В настройках xvm по-умолчанию там уже есть элементы. Несколько или один - не знаю, подробно не изучал, но там точно есть лампочка засвета, и выглядит в дефолтах это так (поскольку директория configs/xvm/default/ скорее всего является отражением настроек по-умолчанию внутри самого xvm, то можно этим пользоваться что бы понять какие у него собственно умолчания):

 

{

  "def": {

    // Enemy spotted status marker.

    // Маркер статуса засвета противника.

    "enemySpottedMarker": {

      // Opacity percentage of spotted markers in the panels. 0 - transparent (disabled) ... 100 - opaque.

      // Прозрачность в процентах маркеров засвета в ушах. 0 - полностью прозрачные (отключены), 100 - не прозрачные.

      "alpha": "{{a:spotted}}",

      // x position.

      // положение по горизонтали.

      "x": 88,

      // y position.

      // положение по вертикали.

      "y": 1,

      // Horizontal alignment

      // Выравнивание по горизонтали

      "align": "center",

      // true - x position is binded to vehicle icon, false - binded to edge of the screen.

      // true - положение по горизонтали отсчитывается от иконки танка, false - от края экрана.

      "bindToIcon": true,

      // enemy spotted status marker format.

      // формат маркера статуса засвета.

      "format": "<font color='{{c:spotted}}'>{{spotted}}</font>",

      // shadow (see below).

      // настройки тени (см. ниже).

      "shadow": {}

    },

    // ...

  },

  // ...

  "playersPanel": {

    // ...

    "medium2": {

      // ...

      // Set of formats for right panel (extended format supported, see above)

      // Набор форматов для правой панели (поддерживается расширенный формат, см. выше)

      "extraFieldsRight": [

        ${"def.hpBarBg"},

        ${"def.hpBar"},

        ${"def.hp"},

        ${"def.clanIcon"},

        ${"def.xvmUserMarker"},

        ${"def.enemySpottedMarker"}

      ]

    }

}

 

То есть видно, что в extraFieldsRight по-умолчанию куча элементов. У меня задача добавить свой элемент, оставить лампочку (enemySpottedMarker) а остальное всё убрать. Пишу у себя в конфиге:

 

// ...

"extraFieldsRight": [

  ${"нечто_своё"},

  ${"def.enemySpottedMarker"} // <-- ровно так, как это в конфигурации по-умолчанию

]

 

Так вот ссылка на ${"def.enemySpottedMarker"} не сработает:

 

JSONxLoaderException: Bad reference: ${"res_mods/configs/xvm\wilem\playersPanel.xc": "def.enemySpottedMarker"} in "res_mods/configs/xvm\wilem\playersPanel.xc:playersPanel/medium2/extraFieldsRight[1]"

Object "./" has no key "def"

 

потому что этой секции нет у меня в конфиге. Она есть в конфигурации по-умолчанию. А у меня - нет. Поэтому её приходится полностью дублировать без каких-либо изменений, что нарушает изначальный тезис о том, что у себя в конфиге я добавляю только то, что отличается от конфигурации по-умолчанию. Секция ${"def.enemySpottedMarker"} - не отличается, тем не менее мне приходится её дублировать просто что бы она была, без этого ничего не заработает.

 

Ограничение B.

 

При слиянии объектов массивы полностью перезаписываются, то есть в них слияния не происходит.

 

Пример:

 

"defaultItem": {

  "keyA": 1,

  "keyB": [

    { "a": 1, "b": 2 },

    { "b": 3, "c": 4 },

    { "d": 5, "e": 6 }

  ]

}

 

"itemA": {

  "$ref": { "path": "defaultItem" },

  "keyB": [ ... ] // (1)

}

 

(1) -- вот здесь нет никакой возможности изменить внутренности существующих уже в этом массиве элементов.  Например, нельзя сказать что внутри { "a": 1, "b": 2 } добавь ещё "c": 3 или во втором элементе измени c=4 на c=999.

 

В чём это выражается на практике? Ну например в маркерах:

 

https://github.com/wilem82/wotconfig/blob/master/configs/xvm/wilem/markers.xc#L108

 

Тут видно, что внутри ally/alive и для normal и для extended используется одно и то же, только различается поле format. В одном случае {{vehicle}}, в другом {{hp}}. Если бы можно было точечно менять содержимое существующих массивов (которые берутся из $ref), это можно было бы упростить, получилось бы что-то вроде:

 

"normal": {

  "$ref": { "path": "def.normal" },

  "textFields[0]": {

      "format": "{{vehicle}}",

      "shadow": { "color": "0x003300" }

  }

},

"extended": {

  "$ref": { "path": "def.normal" },

  "textFields[0]": {

      "format": "{{hp}}",

      "shadow": { "color": "0x003300" }

  }

}

 

То есть в каждом случае минус лишний $ref, соответственно и саму секцию def/textField тоже можно удалить.

 

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

 

"defaultItem": {

  "keyA": 1,

  "keyB": [

    { "a": 1, "b": 2 },

    { "b": 3, "c": 4 },

    { "d": 5, "e": 6 }

  ]

}

 

То сейчас единственный способ изменить содержимое второго элемента это сделать:

 

"itemA": {

  "$ref": { "path": "defaultItem" },

  "keyB": [

     { "a": 1, "b": 2 },

     { "b": 3, "c": 999 }, <-- "c": 4 изменили на "c": 999

     { "d": 5, "e": 6 }

   ]

}

 

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

 

 

Надеюсь, так понятно.

 

На всякий случай: речь не о том, что xvm плохой и нужно срочно кинуться добавлять новые фичи, xvm - офигенный. Речь исключительно о том, что есть некоторые ограничения, и поскольку мне сказали что их нет - я попытался объяснить что они всё-таки есть, и в чём именно заключаются и как это практически влияет на составление собственных конфигов.

[konrad509 445]

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

поэтому, лично для меня эта тема закончена..