| Предыдущая версия справа и слеваПредыдущая версияСледующая версия | Предыдущая версия |
| scr:events [2024/08/22 18:04] – [Применение] rosarak | scr:events [2024/08/29 03:01] (текущий) – [Описание для скриптов] rosarak |
|---|
| * ''eventName'' - название ивента | * ''eventName'' - название ивента |
| * ''delay'' - задержка в миллисекундах, чувствительна к ''timescale'', отсчёт продолжается и во время загрузочных экранов | * ''delay'' - задержка в миллисекундах, чувствительна к ''timescale'', отсчёт продолжается и во время загрузочных экранов |
| * ''format'' - строка из символов, обозначающих порядок и тип передаваемых аргументов:\\ ''l'' - int или bool, ''f'' - float, ''s'' - string, ''a'' или ''i'' - aref или object, ''e'' - ref | * ''format'' - строка из символов, обозначающих порядок и тип передаваемых аргументов:\\ ''l'' - int или bool, ''f'' - float, ''s'' - string, ''a'' - aref, ''i'' - object, ''e'' - ref((**EvgAnat:** Мой опыт говорит, что ''a'' - это чётко aref; ''i'' - чётко основной объект aka экземпляр класса, к которому обращаются; ''e'' обязательно ставить, если хочешь возвращать значение; в остальном стабильнее со ссылкой на объект работает aref.)) |
| | e обязательно ставить, если хочешь возвращать значение, в остальном стабильнее со ссылкой на объект работает aref |
| * ''arg1'', ''arg2'', ''arg3'', ... - аргументы; типы соответствуют заданному в ''format'' порядку | * ''arg1'', ''arg2'', ''arg3'', ... - аргументы; типы соответствуют заданному в ''format'' порядку |
| Формат и передаваемые аргументы необязательны, можно сделать ивент процедурой, не передавая ничего.\\ **NB**: Отложенные ивенты активируются и после смены локации, но забываются после перезагрузки, если не успели отработать. Это отличает их от стандартных методов отложенного вызова функций (''DoQuestFunctionDelay'', ''LAi_MethodDelay'', ...), которые деактивируются в обоих случаях.\\ | Формат и передаваемые аргументы необязательны, можно сделать ивент процедурой, не передавая ничего.\\ **NB**: Отложенные ивенты активируются и после смены локации, но забываются после перезагрузки, если не успели отработать. Это отличает их от стандартных методов отложенного вызова функций (''DoQuestFunctionDelay'', ''LAi_MethodDelay'', ...), которые деактивируются в обоих случаях.\\ |
| <code c>SetEventHandler(eventName, functionName, int post); | <code c>SetEventHandler(eventName, functionName, int post); |
| SetEventHandlerConst(eventName, functionName, int post); | SetEventHandlerConst(eventName, functionName, int post); |
| DelEventHandler(eventName, functionName);</code> | DelEventHandler(eventName, functionName); |
| Аргумент ''post'' в случае единицы не даёт обработчику включиться сразу, только со следующего кадра((<color red>Уточнить</color>)).\\ Обработчик, активированный через ''SetEventHandlerConst'', будет реагировать на вызов ивента и после перезагрузки, пока не будет отключён через ''DelEventHandler''.\\ При этом обработчик, указанный в ''<color green>#event_handler</color>'', убрать таким способом нельзя. | DelEventHandlerConst(eventName, functionName);</code> |
| | Аргумент ''post'' в случае единицы не даёт обработчику включиться сразу, только со следующего кадра((<color red>Уточнить</color>)).\\ Обработчик, активированный через ''SetEventHandlerConst'', будет реагировать на вызов ивента и после перезагрузки, пока не будет отключён через ''DelEventHandlerConst''.\\ При этом обработчик, указанный в ''<color green>#event_handler</color>'', убрать через ''DelEventHandler'' нельзя. |
| |
| Вместо собственных аргументов обработчики получают их по одному внутри тела с помощью ''GetEventData()'': | Вместо собственных аргументов обработчики получают их по одному внутри тела с помощью ''GetEventData()'': |
| Всякий винконд (win condition - триггер) можно оформить в виде ивента и далее вместо того, чтобы плодить огромное количество атрибутов, достаточно в нужных местах включать и отключать (привязывать/отвязывать) соответствующие обработчики. Тем самым, в отличие от проверки через ''QuestsCheck'', проверка из ивента будет проходить только по целевым условиям. Добавление новых триггеров в этом случае осуществляется значительно проще, чем прописывание дополнительных кейсов в ''ProcessCondition'', а их выбор расширяется до огромного количества всевозможных параметров из движка. Если по квесту для вызова функции предполагается несколько условий, то её можно подключить к нескольким ивентам, проверяя выполнение остальных условий уже внутри самой функции. Когда все проверки пройдены, и соответствующие скрипты отработали, можно по надобности отключить обработчик и, возможно, вновь активировать его в другом месте. | Всякий винконд (win condition - триггер) можно оформить в виде ивента и далее вместо того, чтобы плодить огромное количество атрибутов, достаточно в нужных местах включать и отключать (привязывать/отвязывать) соответствующие обработчики. Тем самым, в отличие от проверки через ''QuestsCheck'', проверка из ивента будет проходить только по целевым условиям. Добавление новых триггеров в этом случае осуществляется значительно проще, чем прописывание дополнительных кейсов в ''ProcessCondition'', а их выбор расширяется до огромного количества всевозможных параметров из движка. Если по квесту для вызова функции предполагается несколько условий, то её можно подключить к нескольким ивентам, проверяя выполнение остальных условий уже внутри самой функции. Когда все проверки пройдены, и соответствующие скрипты отработали, можно по надобности отключить обработчик и, возможно, вновь активировать его в другом месте. |
| |
| С учётом того, что все дополнительные иниты, вроде новых предметов, также можно писать внутри скриптов конкретного квеста, то, обзаведясь необходимым количеством ивент-кондов, можно компактно хранить все скрипты квеста в одной папке, то есть без использования совершенно чудовищных мегафайлов, вроде ''reaction_functions'' и ''quests_reaction''. При этом все диалоги могут подгружать актуальные квестовые ноды через ''loadsegment'', пробегая список активных квестов/событий. | С учётом того, что все дополнительные иниты, вроде новых предметов, также можно писать внутри скриптов конкретного квеста, то, обзаведясь необходимым количеством ивент-кондов, можно компактно хранить все скрипты квеста в одной папке, то есть без использования совершенно чудовищных мегафайлов, вроде ''reaction_functions'' и ''quests_reaction''. При этом диалоги могут подгружать актуальные квестовые ноды через ''loadsegment'', пробегая список активных квестов/событий. |
| |
| Тем самым, разместив скрипты каждого квеста в отдельной папке (полностью или почти полностью), мы приобретаем модульность, позволяющую проще ориентироваться в коде и добавляющую гибкость для модификации игры. Доведя эту систему до ума, можно будет добиться, например, чтобы для активации квеста было достаточно поместить его папку в соответствующий каталог, из которого всё необходимое будет подхватываться скриптами. Отдельные инит-функции могут парсить этот каталог при загрузке игры, а дополнительные правки вне папки квеста можно оформлять в виде инструкций для лончера, который, по сути, станет мод-органайзером. | Тем самым, разместив скрипты каждого квеста в отдельной папке (полностью или почти полностью), мы приобретаем модульность, позволяющую проще ориентироваться в коде и добавляющую гибкость для модификации игры. Доведя эту систему до ума, можно будет добиться, например, чтобы для активации квеста было достаточно поместить его папку в соответствующий каталог, из которого всё необходимое будет подхватываться скриптами. Отдельные инит-функции могут парсить этот каталог при загрузке игры, а дополнительные правки вне папки квеста можно оформлять в виде инструкций для лончера, который, по сути, станет мод-органайзером. |
