Объекты вместо массивов

[Wilem82 15]

Ввиду ограничения связанного с использованием массивов описанного в http://www.koreanrandom.com/forum/topic/34680-config-override/?do=findComment&comment=354370, приводящему к затиранию непричастных к нужным изменениям данных, есть предложение заместо массивов использовать объекты. Пример:

 

было

 

"textFields": [

  { "name": "vehicle name", ... },

  { "name": "player name", ... }

]

 

стало

 

"textFields": {

  "vehicleName": { ... },

  "playerName": { ... }

}

 

что позволит в пользовательском написать:

 

"textFields": {

  "vehicleName": {

    "shadow": { ... }

  }

}

 

на случай если всего лишь надо подкорректировать shadow в названии танка по-умолчанию.

 

Мне видится это и правильнее и проще, чем пытаться придумать алгоритм слияния массивов или синтаксис для изменения массива по индексу, например:

 

"textFields[0]": {

  "shadow": { ... }

}

 

Т.к. при перестановке элементов внутри массива в системной конфигурации, пользовательские изменения вдруг начнут менять не то, что предполагалось. Кроме того, появятся ошибки типа index out of bounds, плюс это не очень интуитивно понятно и т.д.

 

При этом если есть задача очистить системный textFields от всех полей (что бы тут же добавить только нужные пользователю), можно ввести что-нибудь на подобии "$ref", например "$ref": { "path": "" } что будет означать "не надо производить слияние с уже существующими полями объекта из системных настроек". Ну то есть пустое значение path это такое магическое значение.

[sirmax 5,499]

Основная проблема в этом подходе - это придумывать названия. Хотя, вроде это вполне решаемо.

Я подумаю, если получится сделать поддержку одновременно и массивов, и объектов, то будет смысл сделать.

[Wilem82 15]

Основная проблема в этом подходе - это придумывать названия. Хотя, вроде это вполне решаемо.

Я подумаю, если получится сделать поддержку одновременно и массивов, и объектов, то будет смысл сделать.

 

А можно на эту же тему как-нибудь сделать, что бы нестандартные топовые элементы (обычно "def", "defaultItem") имели глобальную видимость? Например, что бы из пользовательского конфига сослаться на def.enemySpottedMarker в default/playersPanel.xc из другого файла (myconfig/playersPanel.xc в общем-то).

Edited October 7, 2016 by Wilem82

[Kapany3uk 948]

А можно на эту же тему как-нибудь сделать, что бы нестандартные топовые элементы (обычно "def", "defaultItem") имели глобальную видимость? Например, что бы из пользовательского конфига сослаться на def.enemySpottedMarker в default/playersPanel.xc из другого файла.

поддержу.

имхо "отключение" def от основного конфига не имеет практического значения. в тех же *temlates лишние пару десятков строк кода (три-четыре "пробных" поля) разве могут оказать сильное влияние на память и скорость?

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

[demon2597 5,468]

сокращением пользовательского кода до минимума значимых параметров с загрузкой всего остального из "вшитого" дефолта

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

Edited October 7, 2016 by demon2597