В связи с запланированным обновлением Fly Data Processor, возникла необходимость обновить и сборщик карты, чтобы было кому автоматически запускать Fly Data Processor.
А чтобы обновить сборщик карты не рискуя нарваться на еще одну полную его переделку - полезно сперва определиться со спецификацией. О чем, собственно, этот пост.
Хотя мой вариант с собранным lua позволит каждому настраивать сборщик по вкусу.
Ты утомил меня уже немного, если честно, с этим вопросом. Я не собираюсь этого делать по одной простой причине - зачем мне собирать "lua.exe", если я подключаю "lua.dll"?
Я привык пилить свои идеи методом наращивания фич (или как он там правильно называется), это позволяет получать своевременный фидбек и концетрироваться на том, что реально нужно пользователям (если конечно они догадаются сообщить об этом в комментариях). Свой дешовый собранный на коленке сборщик я пилил по тем же принципам. И им хотябы на данный момент можно стабильно пользоваться.
Хоть и дураку понятно, что пилить в одиночку это глупо, долго и невыгодно (если ты конечно не Кодзима гений разработки), но я прискорбно замечаю тенденцию об отсутствии коллаборации. Хотя уже кучу людей пилят свои сборщики, парсят файлы и занимаются другой полезной деятельностью (куча конечно маленькая, но она есть).
Может и правда начать с минимального функционала, сохраняя совместимость со стандартным эдитором и понемногу его расширять в зависимости от потреностей? Хотя мой вариант с собранным lua позволит каждому настраивать сборщик по вкусу.
NazarPunk, перечитай план в посте)
Сейчас привязка к IDE запланирована на уровне заворачивания в плагин который просто передает правильные параметры. Ну и запуск игры удобнее через плагин реализовать т.к. можно отслеживать запущенный ранее процесс и при необходимости убивать его. Сам сборщик полностью независим от IDE. Весь процесс сборки по плану контролируется билд-скриптом на Lua, в котором можно что угодно делать.
По поводу "засунуть в SDK" - у меня нет идеи и ставить я её ради этого не планирую - если найдешь мне спецификацию для этого, подумаю как получить нужный результат. В теории, это должно быть реально, но, скорее всего, не нужно на практике, да и будет вызывать проблемы т.к. функции из сборщика будут перетекать в подсказки к коду карты, хотя в коде карты эти функции не должны быть доступны.
По поводу "сборки в составе Lua" - все с точностью до наоборот - Lua включается в состав сборщика в виде dll. Сборщик не изображает из себя дистрибутив луа и, в принципе, не должен этого делать т.к. он является не универсальным дистрибутивом луа, а выполняет строго специализированную задачу, пользуясь Lua.
Пока, наверно, самый перспективный "дешевый" способ интеграции этого сборщика в идею может выглядеть так:
Проект форматируется в соответствии с требованиями сборщика (или генерится конфиг соответствующий текущей структуре проекта).
Сборщик ставится либо локально в каждый проект либо глобально один раз, от этого зависят только пути.
В проект добавляются конфиги и скрипты сборки, соответствующие требованиям проекта.
На каждую таску сборщика создаются отдельные исполняемые Lua-врапперы, которые и вызываются из идеи. Внутри этих скриптов, по факту, только запуск исполняемого файла сборщика с передачей ему параметра, определяющего какую таску выполнить. Примеры тасок "собрать код карты", "собрать карту полностью", "сгенерировать данные РО из кода", "собрать карту в релизном режиме со всеми оптимизаторами", "собрать карту в режиме совместимости с WE".
При работе в идее запускается на выполнение в стандартном Lua соответствующий Lua-враппер над сборщиком, а сборщик дальше уже самостоятельно выполняет свой Lua скрипт сборки проекта на своей копии Lua.
BLOG-PROG
Комментарии проекта Эксперименты в Пустоте
О том как пеоны к конкурсу качались
Отредактирован prog
[Lua] Спецификация модульного сборщика карты
дешовыйсобранный на коленке сборщик я пилил по тем же принципам. И им хотябы на данный момент можно стабильно пользоваться.Кодзимагений разработки), но я прискорбно замечаю тенденцию об отсутствии коллаборации. Хотя уже кучу людей пилят свои сборщики, парсят файлы и занимаются другой полезной деятельностью (куча конечно маленькая, но она есть).Отредактирован nazarpunk
Отредактирован prog
Сейчас привязка к IDE запланирована на уровне заворачивания в плагин который просто передает правильные параметры. Ну и запуск игры удобнее через плагин реализовать т.к. можно отслеживать запущенный ранее процесс и при необходимости убивать его. Сам сборщик полностью независим от IDE. Весь процесс сборки по плану контролируется билд-скриптом на Lua, в котором можно что угодно делать.