sirmax

КТТС же

не прокатит, так как {{c:system}} подставит значение цвета, а не название ключа. Можно, конечно, сделать ключи по значениям, но это криво, и сломается, если кто-то цвета изменит. Можно сделать макрос со значением ключа ("ally_alive", ...), и подставлять его через {{.}}, но я не смог придумать ему название, поэтому сделал так. :)

Будем затачивать.

ок А как через {{.}} сделать? Готово. "labels"/"data" можно выносить в любое другое место, пока что из "labels" только "fields" используется, возможно в будущем еще добавятся общие параметры.

Тогда надо держать данные рядом с тем блоком, где они используются. Если бы "labels" не стал массивом, было бы логично в него запихнуть. Можно переделать, но тогда надо будет добавлять еще один уровень для полей, что-то типа: "labels": { "data": { }, "fields": [ ] } Правда в этом случае "data" будет дублироваться в minimapAlt, что тоже не очень хорошо, хотя и не критично.

Не знаю, что-то типа data, или shared?

Займешься? В принципе, сейчас конфиг такой, как я планировал, так что можно его уже причесывать. {{c:system:path}} тоже, наверно, надо будет убрать и заменить на {{.}} - это будет то же самое по производительности.

а он вроде не нужен - на него ссылки в {{,}} создаются. Вообще, мне этот labels_data не нравится. Наверно надо выделить структуры для макроса {{.}} вообще в отдельный файл.

Да я и сам пока не понял :) Хочу производительность померять. Я ж написал, что сломано. Стабильный бранч - wot-0.9.10

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

нужен реплей

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

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

да, именно так, потому что массив.

да без всех - никто, будет просто игнорироваться. Кстати, убираются параметры: "revealedEnabled": true, "lostEnemyEnabled": true, потому что они теперь управляются через флаги И макрос {{vehicle-class}} тоже можно убирать, похоже.

В принципе, можно обойтись и одним полем: "formats": [ { "flags": [ "ally", "squad", "player", "enemy", "teamKiller", "lost", "spotted", "alive", "dead" ], ... } ] При этом, логика такая: Если не указаны "ally", "squad", "player", "enemy", "teamKiller", то они не используются. Если не указаны "lost" и "spotted", то используются оба - и "lost", и "spotted" Если не указаны "alive", "dead", то используются оба - и "alive", и "dead" ЗЫ: Мне "revealed" не нравится, может лучше использовать "spotted"? Или может есть какой-то еще устоявшийся термин? Ну тут порядок уже не важен - он останется как есть сейчас.

да и +/- парсить сложнее. ну, например, будет одинаковое поле для всех, которое использует системные цвета: "format": "<font color='{{c:system}}'>{{vehicle}}</font>" Просто до этого такой возможности не было, вот и не использовали. А вот это аргумент. Может действительно tk в режимы запихнуть, тогда все нормально получается. Только в этом случае придется делить режимы и состояния: "formats": [ { "modes": [ "ally", "squad", "player", "enemy", "teamKiller" ], "states": { "lost": false, "alive": false }, ... } ]

На самом деле, у нас тут есть 4 режима: player, ally, squad, enemy, и 3 флага состояний: lost, teamKiller, alive если их разделить на два поля, то можно применить два разных формата: "formats": [ { "modes": [ "ally", "squad", "player", "enemy" ], "states": { "teamKiller": false }, // lost и alive = true + false ... } ] все логично - мы задаем значение для любого состояния живой/мертвый, чтобы не дублировать поле.

а только мертвый?

Может что-то вроде "Активные" или "Незавершенные"? Добавил фильтр "Незавершенные"

не надо копипастить :) адекват - тоже не идеальный вариант

адекват - прикольно :) но опять же не интуитивно. проще, наверно, сделать TK/notTK.

допустим, для "lost" есть уже антоним - "revealed", а вот что придумать для "teamKiller"? "normal" как-то не в тему.

Ну например, с флагом dead можно задать только два состояния: 1. "ally" - союзник и живой, и мертвый 2. "ally,dead" - союзник мертвый чтобы отдельно выделить живого, нужен или еще один флаг, или третье состояние для флага dead. Например, можно так: ally => "flags": { "ally": 1, "dead": 0 }, ally,alive => "flags": { "ally": 1, "dead": 2 }, ally,dead => "flags": { "ally": 1, "dead": 1 } но это не удобно и не интуитивно в принципе, можно null использовать, тогда можно типом bool обойтись: ally => "flags": { "ally": true }, ally,alive => "flags": { "ally": true, "dead": false }, ally,dead => "flags": { "ally": true, "dead": true } если же вводить отдельные флаги, получится что-то вроде: ally => "flags": "ally", ally,alive => "flags": "ally,alive", ally,dead => "flags": "ally,dead" но надо придумать противоположные флаги для tk и lost еще один вариант записи флагов: ally => "flags": [ "ally" ], ally,alive => "flags": [ "ally", "alive" ], ally,dead => "flags": [ "ally", "dead" ] так синтаксис получается более строгий, и его легче парсить, но, возможно, менее удобно настраивать. Если придумать противоположные флаги для tk и lost, то мне больше всего нравится последний вариант.

When WG will provide us the correct data, we'll recalculate users with wrong stats. I cannot say you the exact date, it is not depending from us.