Некоторые нюансы при финальной сборке.

[Didgik]

Делал финальную сборку, столкнулся с нюансами.

1. Самое неприятное. Кнопка Delete при открытом окне сборки работает и может незаметно удалить что нибудь в проекте.

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

2. Сборка релиз добавляет папку plugins общим весом 73М с плагинами FbxExporter, FbxImporter, GLTFImporter и UsdExchanger. Судя по названиям, в релизном билде они не нужны, мало того там же есть файлы pdb.

3. В настройках включен Delete Unused Assets. Проект у меня самый простой и используются ноды которые добавляются в коде, и  они в релиз не вошли и ничего не работало. Понятно, что их надо включать в таблицу Принудительно включены, но делать это очень неудобно. Хорошо, у меня их два. Былоб неплохо перетаскивать нужные ноды из ассетбраузера в таблицу или в самом ассетбраузере помечать как нужные. Сходу не нашел такую возможность. Или я что-то делаю не так? Можно, конечно, в мире размещать сразу, но я пока не знаю, как удобнее. Не люблю плодить сущности )

[arizmenda]

Здравствуйте.

Спасибо за обратную связь.

1. Да, это действительно не очень удобно. Мы завели тикет во внутреннем трекере задач и обсудим с командой, как лучше это исправить.
    
2. Здесь ситуация немного сложнее. Build Tool сам по себе не может определить, какие плагины реально используются проектом. Он берет список подключенных плагинов из .project и включает их в сборку. Например, если проект использует модули Unigine::Import или Unigine::Export в логике, то им как раз необходимы соответствующие import/export-плагины. Поэтому автоматически исключать их нельзя - это может привести к неработоспособному билду. При этом сама идея сделать Build Tool более гибким и дать пользователю больше возможностей по настройке состава сборки выглядит разумной. На этот счет мы тоже завели внутренний тикет.
    
3. Сейчас можем порекомендовать два варианта:

• использовать специальный .prop-файл, в который добавляются .node и другие ресурсы, которые должны гарантированно попасть в сборку. Мы сами используем именно этот подход в проектах: этот файл становится общей точкой синхронизации между программистами и художниками, при этом система поиска зависимостей продолжает работать корректно;
• либо создать отдельную папку и добавить ее в Force-Include List. Однако этот способ рискованый - со временем такая папка обычно превращается в свалку файлов, который становится сложно поддерживать в актуальном состоянии.

[Didgik]

А где можно прочитать про такую работу со специальным .prop-файлом?

А то есть сценарий работы, для меня конечно гипотетический, но тем не менее.

Выпускам большую игру на 1Гб, в ней условно game.exe, cure.ung и data.ung как раз на 1 Гб. Дальше нам надо выпустить патч, оптимальнее всего заменить game.exe и дописать небольшой data1.ung с новыми/измененными ассетами, и со временем, когда накопится достаточно много изменений, можно обновить целиком и опять будет три файла game.exe, cure.ung и data.ung. Как я понимаю, как раз специальным .prop-файлом этого можно добиться, но ручками жонглировать ассетами между data?

[arizmenda]

К сожалению, официальной документации по такому сценарию сейчас нет.

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

Что касается патчей с несколькими .ung, то .prop эту задачу не решает. Он только управляет тем, какие ресурсы попадут в сборку.

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