NazarPunk, я пока не планирую включать в состав сборщика какие бы то ни было инструменты для скачивания - это выходит за скоп задач которые должен решать сборщик - как по мне, это задача для внешних подключаемых модулей. А вот по поводу упрощенного импорта надо подумать - какой-нибудь merge-скрипт в состав FlyData вполне может зайти. Да и генерация объектов в РО из кода - тоже потенциальная работа для FlyData, заявленая в возможных фичах для новой версии.

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

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

Фича, которая будет возможна за счет интеграции с FlyData или другими инструментами парсинга данных в карте

• автоматическая генерация списка переменных для всех юнитов стоящих на карте
• добавление этого списка в автоподстановку в IDE
• регенерация участка кода, отвечающего за создание юнитов и запись их в переменные чтобы гарантировать что все используемые юниты с карты были занесены в соответствующие переменные
• отсутствие необходимости явно указать через Гуи на юнита прежде чем его переменную можно будет использовать

Также, эта фича может быть расширена на разрушаемые объекты, но тут нужно осторожно, чтобы все не упало из-за деревьев.

NazarPunk, в первом релизе, да еще и в моей реализации - нет, точно не буду тратить на это время. Но взять тот способ которым ты пользовался у себя и адаптировать его к этому сборщику - дело пяти минут, причем без перекомпиляции самого сборщика, только поправить Lua скрипты.

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

А если просто речь об одновременной работе в IDE и WE, то тут все на том-же уровне, что и в предыдущем компиляторе Lua - пока не нужно модифицировать файлы в исходной карте, можно одновременно работать и там и там, но если нужно применить какие-то изменения которые должен увидеть редактор, то редактор придется закрыть, применить изменения и открыть заново.

Выложил план дальнейших действий

Фактически, это то самое обновление, в котором компилятор будет оторван от плагина в вс-коде и переведен на работу с билд-скриптом. Но с нюансами.