Инструментарий для мододелов

[AK74 4]

Доброго всем времени суток.

2 _Призрак_ и TREWKO

Что касается редактора спавна и интегрированного acdc, имхо, сделать по уму - нереаль это.

Во первых, в спавне помимо свойств предметов еще и "географические данные" (координаты, вертексы, дирекшон) нужны.

Глупый вопрос:"Откуда их взять?" Тут два пути: юзер вбивает их сам или "учить" редактор понимать графику, чтобы можно было заспавнить предмет как в SDK?

Во вторых, мало того что acdc будет разным для каждой стандартной версии игры (ТЧ/ЧН,ЗП). А если в мод были добавлены дополнительные предметы, подключены новые локации и пр? Откуда интегрированному acdc взять данные об этих изменениях, для корректной распаковки all.spawn?

 

ЗЫ. TREWKO, Вы для какой-то одной версии игры планируете свой редактор или для всех (ТЧ/ЧН,ЗП)?

Удачи.

[AK74 4]

ACDC написан на Perl, а спавны больше похожи на ini-файлы.

Но не в этом суть, постом выше я пытался объяснить что встроенный acdc потеряет гибкость, т.е любая попытка добавить новую локу/предмет/монстра/пр будет обречена на провал.

Если только добавить возможность работы с внешним референсным файлом, в который юзеры будут добавлять свои фишки?

Имхо, овчинка выделки не стоит. Впрочем, решать Вам.

 

Что касается скриптов, изменений в языке скриптов вроде и нет, но есть существенные изменения в классах(точнее их свойствах,методах) см. ветку "Справочник по функциям и классам". И если не затачивать редактор под какую-то конкретную версию игры, то это тоже придется учитывать.

 

ЗЫ. Может стоит расширить функционал редактора?

Например, такой сценарий работы:

1. В начале, юзер выбирает тип игры (ТЧ/ЧН/ЗП), затем задает путь к существующей геймдате.

Редактор анализирует использующиеся файлы, на предмет регистрации пользовательских функций (родные функции для этой версии игры он ведь и так знает), проводит их проверку их синтаксиса, допустимости параметров и пр, В общем все то, что делают современные языки программирования.

2. Также было бы полезно позаимствовать всплывающие предложения вариантов окончания, после того как юзер введет первые буквы имени функции/метода. Не помню как эта фитча называется. Наберите в Делфи Form1. , подождите пол-секунды.и поймете про что я пытаюсь сказать.

3. Ввести кнопку "Проверка". Выполняет те же функции что и кнопки Compile/Build в Делфи, но без генерации бинарных файлов, конечно.

Зачем, думаю, объяснять не нужно.

4. Добавить кнопку "Сгенерировать". По нажатию на эту кнопку, запрашивается папка, в которую копируются все новые файлы и файлы имеющие отличия от стандартных, для этой версии игры.

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

А так получится: Проверил-Сгенерировал-Отсылай. В моде останутся лишь логические ошибки.

5. В справке, вместо lua_help, лучше бы разместить информацию камрада malandrinus, из шапки в ветке "Справочник по функциям и классам".

Если он конечно не будет против.

Думаю, модмейкеры будут довольны результатами Вашей работы.

Удачи.

 

[AK74 4]

TREWKO

1. Это вроде как в Делфи: в каком-нибудь файле, в интерфейсе Вы декларируете функцию. В проекте, Вы подключаете этот файл и соответственно

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

2. Удачи.

3. Не только проверка скриптов, но и проверка наличия всех вызываемых файлов (конфигов и пр).

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

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

Если распихивать все потом ручками, то будет шанс напортачить.

5. Имхо, help, нет необходимости выбирать/настраивать, так как работа камрада malandrinus, грубо говоря, есть lua_help, только более разжеванный

и дополненный. Кому нужна будет куцая версия справки, если есть более детальный вариант?

Изменено 29 Августа 2010 пользователем AK74