<if объект in категория>

Добавил пользовательские категории. Пока они задаются для объектов в поле "суффикс редактора" в виде

((код

какой-то текст@[категория][категория][категория] и так далее
))

С помощью директивы <list> можно перебрать все объекты в категории, а с помощью директивы <if> проверить, относится ли объект к категории.

Предназначение категорий - сужение области данных при формировании БД.

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

prog добавил:
ScorpioT1000:

<if объект in категория>

увы, я не могу полностью контролировать синтаксис т.к. пользуюсь уже готовой библиотекой компиляции шаблонов FreeMarker
но можно ввести собственную директиву (разница только в том что это будет не if, а, например, check)

ну тогда
<if in(объект, категория)>

ScorpioT1000 добавил:
кароче надо чтобы было максимально просто

ScorpioT1000 добавил:
prog, отключать все это надо для кода. для обработки всё должно быть включено

ScorpioT1000, для кода есть категории, а вот обработка карты с 100500 видами декораций, которые нафиг не нужны в БД это гарантированная возможность пойти выпить чаю пока оно все обработается. (утрирую, конечно, но задержка всеравно ощутимая). Да и память не бесконечная - я бы предпочел чтобы у меня была возможность отключить загрузку всех не категоризованных объектов в случае когда, например, объектов несколько сотен, а то и тысяч, а в базу пойдет только небольшая их часть.

Максимально просто это то как есть сейчас - объект.категория

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

ScorpioT1000 добавил:
слушай, а может категории сделать наоборот, снаружи?

items.I001.Name ?

ScorpioT1000, ну до конфига еще далеко - я пока на функциональных элементах сосредоточен в основном.

По поводу времени и места в памяти - это надо проверять на разных наборах данных. Я проверял только на искусственно созданных файлах данных с огромным количеством объектов и на практически пустых картах. В первом случае задержка ощутима, во втором - вообще не заметна. И да, на одном наборе данных мне удалось довести утилиту до того что ей не хватило памяти (по умолчанию памяти java получает достаточно мало), но это решается настройками при запуске утилиты.

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

((код

<list категория1 as i>
${категория2.i} обработается как попытка получить объект с кодом "i", а не тот что записан в переменную i
</list>
))
Чтобы обеспечить доступ к переменной i мне придется добавить ссылку на верхний узел структуры данных, как минимум, в категории. Это совсем не то, чего бы мне хотелось.

Как вариант - собственная директива вида

((код

<check объект is категория>
</check>
))
Но меня устраивает и <if объект.категория> все-же категория это свойство объекта (по сути категории это списки тегов), а создание коллекций, соответствующих категориям, это всего-навсего способ без извращений пройтись циклом по всем объектам категории, не перебирая все объекты в памяти.

Кстати, конструкция ${объект.категория} не вернет ничего ценного - если объект принадлежит к категории, то вернется ссылка на сам этот объект, а если не принадлежит, то null - эта конструкция только для условий.
Таким образом ${A000.abilities.name} вернет название способности A000, а ${A000.units.name} вернет пустое место.

Ну и пара слов по конфигам - заставить бы мапмейкеров делать отдельную папку под каждую карту в разработке. Это решило бы множество проблем.

не is, а in, потомучто он не наследуется, а находится внутри, иначе называй тогда unit/item итп, без окончаний, учите грамматику и логику =)

Ну и пара слов по конфигам - заставить бы мапмейкеров делать отдельную папку под каждую карту в разработке. Это решило бы множество проблем.

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

ScorpioT1000, да какая мне разница сейчас - я написал первое что пришло в голову, просто в качестве примера того как может выглядеть директива)

С архивом карты через сторонние утилиты работать не удобно.

Проанализировал перспективы хранения дополнительных данных в архиве карты. Для этого придется добавлять файл в список импорта (благо, программно я это делать умею) или допиливать гримору так чтобы в ней был хук на момент перед открытием карты редактором (ну не нашел я там такого). Почему? Да потому что ВЕ при сохранении выпилит все ненужное по его мнению из архива, а значит положить то мы туда файл можем, а вот достать его при следующем сохранении - фиг.

Вывод - пилить список импорта. Побочный эффект - все служебные файлы будут видны в списке импорта.

Вторая проблема - чтобы успешно пользоваться шаблонами карту нужно будет открыть, сохранить и открыть еще раз чтобы в РО отобразились шаблоны. После этого карту нельзя закрывать, иначе вновь придется открыть, сохранить и переоткрыть заново. Это необходимо чтобы ВЕ подгрузил в память нужный файл строк, а именно тот что с шаблонами.

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

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

Путей ускорения работы с кодом карты я вижу два

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

Тот вариант, который используется сейчас хорош для маленьких карт и для карт, основная масса кода которых вынесена во внешние файлы с помощью cjass.

а скомпилированный подставлять только по команде и при запуске тестирования карты.

ага и кто юзает эту кнопку? тока синглплеерные нищеброды?

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

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

prog, ну, например для кампании что ? ладно я могу подстроить так, чтобы жнгп думал, что я рассматриваю карту, а не кампанию. Но как быть с кнопкой тест? Это усложнит задачу... предлагаю рассмотреть другие варианты.

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

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

Примерно 4 секунды на 100кб данных плюс 300кб текста это не очень много, но необходимо исследовать как это значение масштабируется при увеличении объема данных. Причем большая часть времени, кстати, уходит на расшифровку данных по объектам, а не на обработку текста.