запилил проход циклом шаблона по списку всех юнитов/способностей/предметов (позже допилю все остальные типы)

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

((код

<list units as x>
${x} ${x.umvs}
</list>
))

Вместо x можно выбрать любое имя - по сути это локальная переменная, видимая только внутри директивы перечисления. Через x можно обращаться ко всем полям, доступным и через конструкцию ${равкод объекта.равкод поля}.

На данный момент доступно всего три коллекции объектов - units, items, ability, позже будут доступны buffs, destructables, doodads, upgrades

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

Предположительно это будет выглядеть так:

• объекты которые подлежат считыванию в память отмечаются добавлением save к полю "суффикс редактора" и становятся доступны для подстановки в шаблоны.
• вводятся кастомные категории объектов, которые задаются по тому-же принципу - имя категории
• в шаблон добавляется возможность проверить относится ли объект к той или иной категории

prog добавил:
Есть желающие потестить сырую версию? (в приват)

Кароче перемещаю в барахолку =) т.к. продукт уже пишется, и есть что потестить

Тогда надо бы первый пост подправить, наверно. Этим и займусь.

Стоит ли выкладывать тут бету?

Слушай, оно работает даже, щщикарно!)

только я не смог сделать h001.Name

Шаблон потеряется если переоткрыть карту - это пока в разработке. Поэтому тестировать я предпочитаю в коде.

нет поля Name - его равкод anam. кроме того есть небольшая проблема - ссылаться на текстовые поля из других текстовых полей пока не стоит - они сохраняются в TRIGSTR, а значит подставлена будет надпись TRIGSTR_xxx - это еще надо допилить.

Даешь пример вобщем

че за равкод anam? неинтуитивно, даешь нормальные названия)

ScorpioT1000, эти равкоды можно посмотреть в JNGP для каждого поля. Для часто используемых полей я планировал ввести синонимы, но можно и для всех сделать, только это нужно доставать slk-таблицы и названия полей из архива игры.

Пример запилю как только доведу до ума первое сообщение в теме.

Добавил файл alias.txt, в котором можно указать синонимы для равкодов полей. Пригодится тем, кто не любит работать непосредственно с равкодами полей.

prog, ты бы сделал самые нужные алиасы, или лучше вобще всех полей, это же не проблема для препроцессинга на современных компах?

ScorpioT1000, со временем сделаю, но не зашивать же их прямо в код)
На самом деле эти алиасы это жуткое надувательство - они ложатся в Map<String,String> и при обращению к полю на одном из этапов проводится поиск соответствия в этом мапе, если есть - оттуда достается равкод и используется дальше вместо алиаса. Побочный эффект - алиас не может быть использован если надо напрямую обратиться к полю определенного уровня способности, более того, все уровневые (те что могут иметь более одного уровня) поля вообще недоступны через алиасы на данный момент, даже если у способности только один уровень. Частично это решается добавлением возможности пройти циклом по всем уровням способности, частично - введением возможности обратиться напрямую к уровню с помощью конструкции ${A000.getLevel(1).равкод поля} вместо текущей ${A000.РавкодУровень}, в которой невозможно использовать алиасы. Ну и сделать видимыми поля первого уровня в области видимости нулевого уровня.

Уровневые поля первого уровня теперь доступны и как поля нулевого уровня (при обращении к полю без указания уровня, например) - теперь они доступны и через алиасы (синонимы). Также теперь возможен проход циклом по всем уровням кроме нулевого:
<list A000.levels as level>
${level} выдаст номер уровня ${level.поле} выдаст значение поля на этом уровне
</list>

В ближайшее время добавлю конструкцию ${A000.getLevel(1).равкод поля}. Также возможно введение конструкции ${A000.x.равкод поля} где x - целое число.

prog, отлично
но я бы не писал getLevel... както длинно, мб A000.L1.Name ? (ну если сделаешь алиасы, а я всеми руками голосую за это, т.к. интуитивнее)

ScorpioT1000 добавил:

${A000.x.равкод поля} где x - целое число.

это левел? тогда еще лучше =)

ScorpioT1000, алиасы я буду заполнять по мере наличия свободного времени
да, x это левел, но и конструкция с getLevel, на мой взгляд, должна иметь право на жизнь. Ну или мне придется извратиться чтобы переменные верхнего уровня были доступны и тут.

например для конструкции вида

((код

<list ability as a>
<list 4..6 as i>
${a.i.поле}
</list>
</list>
))
с getLevel проблем нет - это функция и компилятор шаблонов понимает что в качестве параметра могут быть переданы переменные, а вот с такой конструкцией могут возникнуть проблемы.

prog, так конечно оставь её тоже, какраз для таких вещей.

нашел еще одно решение, на котором скорее всего и остановлюсь - это конструкция вида
${A000[level].Name}
т.е. обращение к способности, как к массиву

prog, а что делать с общими полями в таком случае? если обратиться без кв скобок, это будет работать?

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

Появилась у меня безумная идея - ввести категории объектов.
Принцип простой - пишем в поле с описанием для редактора после #save категории в виде [категория1][категория2] и так далее. Потом эти категории можно использовать в условиях

((код

<if A000.категория>
содержимое этого блока будет выведено только если способность A000 относится к категории "категория"
</if>
))

А может и в качестве коллекций для перечисления.

((код

<list категория as data>
${data} выведет равкоды всех объектов в категории
</list>
))

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

я бы предложил сделать так, чтобы категорией был не какойто код, а дамми-объект, как я описывал выше итем-сет и итемы для него

ScorpioT1000, зачем плодить даммики, если можно вписать строку в описание?

UPD:

Добавил в структуру данных понятие категорий. Теперь тип объекта является категорией. Также теперь для всех типов объектов доступно перечисление в цикле - каждой категории соответствует коллекция объектов. Более того, категории задаются динамически - осталось реализовать только механизм присвоения объекту категорий на основании данных из РО - на данный момент категории присваиваются только на основании того, из какого файла был получен объект.

Автоматически присваиваемые категории:
-units
-items
-abilities
-buffs
-upgrades
-destructables
-decorations

Каждую из этих категорий можно использовать в качестве коллекции для директивы <list> (старые коллекции объектов, не основанные на категориях, были удалены)

Сейчас думаю над способом проверки из шаблона принадлежности объекта к категории.
Временное решение:

((код

<if объект.категория>
</if>
))
Побочный эффект такого решения - категории не должны совпадать с равкодами и синонимами полей.