sirmax

Нужно z-order правильно выставить. Лучше всего поместить MovieClip на _root (holder) с глубиной менее statictocForm (главное найти пустое место, чтобы не затереть что-то), на котором уже размещать необходимые текстовые поля. Скрывать не надо, надо именно через z-order делать. В первом приближении ок, тут больше не ко мне вопрос, а к авторам конфигов, которые это использовать будут.

ок

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

Я не против. Только кто сделает? :)

Мне не принципиально, это надо в теме по дефолтному конфигу будет спросить. Я бы делал в одном файле.

Обычно для подстановки значений макросов используется функция Macros.Format(), но у тебя частный случай только с глобальными макросами, поэтому более подходящий метод - Macros.FormatGlobalStringValue(), который не требует имени игрока. Хотя тут могут быть нюансы в реализации, например, может потребоваться объект "options" с дополнительными данными, или имя текущего игрока, чтобы по нему получить информацию о танке и т.д. Это все по ходу будет видно.

Все равно не понял. Самое близкое - это то, как сделаны текстовые поля в миникарте. Тут надо сделать так же: { ... "formats": [ ${ "minimapLabelsTemplates.xc":"def.vehicleSpotted" }, ${ "minimapLabelsTemplates.xc":"def.nickSpotted" }, ${ "minimapLabelsTemplates.xc":"def.vtypeLost" }, ${ "minimapLabelsTemplates.xc":"def.vehicleLost" }, ${ "minimapLabelsTemplates.xc":"def.nickLost" }, ${ "minimapLabelsTemplates.xc":"def.vtypeDead" } ] } // Definitions // Шаблоны "def": { // Fields default format // Формат поля по умолчанию "defaultItem": { "enabled": true, "shadow": { "distance": 0, "angle": 45, "color": "0x000000", "alpha": 80, "blur": 2, "strength": 4 }, "alpha": 100, "x": 0, "y": 0, "width": 100, "height": 40, "align": "left", "valign": "top", "antiAliasType": "normal", "bgColor": null, "borderColor": null }, // Vehicle type, visible // Тип техники, видимый "vtypeSpotted": { "$ref": { "path":"def.defaultItem" }, "format": "<font size='13' color='{{.minimap.labelsData.colors.dot.{{sys-color-key}}}}'>{{.minimap.labelsData.vtype.{{vtype-key}}}}</font>", "align": "center", "valign": "center" }, ... И не надо называть это "виджетами" - у тебя это простые текстовые поля, а виджет - это более широкий функционал. Виджет - это самостоятельный контрол, такой как миникарта, полоса захвата, дебаг панель и т.д. Мне уже страшно. Ты уверен, что понимаешь задачу, и можешь ее сделать?

хз

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

Что-то ты какого-то мусора нагенерил. Я поотменял все реквесты, состоящие из одного перевода строки в конце файла. Не надо такое отправлять. Так же отменил реквест, где ты английскую "m" на русскую "м" заменил. Лучше сначала тут спросил бы.

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

Лучше идеи сначала обсудить тут, а то может реализация оказаться не подходящей. Про JSONX не понял, покажи на примере.

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

Да, типа того. Как extraFields в ушах и на миникарте, только для _root. Я для подобных целей хотел сделать виджеты, но на них уже который год времени нет. Остатки кода все еще лежат тут: \src\xvm-as2\src\com\xvm\Components\Widgets.

И это правильно. Это тот же самый шрифт, только его алиас для встроенного шрифта, соответственно, на него не влияют системные настройки.

часы не стоит трогать

Macros.as :)

Да. в хитлоге можно посмотреть как получить разрешение экрана: private function createControl() { //Logger.add("HitLog::createControl()"); Cmd.getScreenSize(this, createControl2); } private function createControl2(size) { //Logger.add("HitLog::createControl2()"); var sz = JSONx.parse(size); var x = this.x >= 0 ? this.x : sz[0] + this.x; var y = this.y >= 0 ? this.y : sz[1] + this.y; ... хотя, по-хорошему, это все давно отрефакторить, так как сделано криво. там же и выравнивание можно посмотреть как сделано

Лучше кидать textfield на _root, и делать координаты относительно 0,0. Так же добавить пару опций для выравнивания по горизонтали и по вертикали. Например, ZoomIndicator в _root создается.

Зачем?

Закидали, потому что некому делать. Если бы я делал, то не так, а через глобальные макросы. Но так как сейчас - лучше, чем ничего. По логике тут вообще много чего нужно делать, начиная выноса в макросы и отдельной секции с глобальными текстовыми полями, со всеми фишками extraFields. Только я как представляю этот гемор, сразу забиваю. Там вроде как не сложно, но много рутины. На сайте же, кмк, достаточно одной галочки "Шансы в бою". Где отображать - это уже ближе к конфигу.

Еще неплохо было бы сделать настройку шрифта и тени, как у других текстовых полей.

Что мешает самому поправить и сделать pull-request?

Должно работать, если там вообще работают макросы статистики. В macros.txt этот момент как-то упущен.

Думаю, seriych сможет объяснить. :)