Справочник по функциям и классам

[Malandrinus 615]

В данной теме собраны сведения по скриптовой модели сталкера: функции и классы, методы и свойства, взаимосвязь классов и последовательность работы с ними, связь работы классов и файлов конфигураций. К наполнению темы приглашаются все желающие.

 

В наполнении темы непосредственно участвовали и существенно мне помогли: @Monnoroch, @Kolmogor, @Unnamed Black Wolf, @меченый(стрелок), @IQDDD, @Kirag, @Taroz, @dan, @7.9, @Garry_Galler, @AKKK1, @Bak и много других людей.

 

Скрытый текст

 

Скрытый текст

класс alife_simulator. Базовые операции с серверными объектами.

Пространства имён. Глобальные функции для большого числа задач.

 

"Создание своего класса" и "Наследование от экспортированных классов". Базовые сведения об объектно-ориентированном программировании для сталкера. Необходимо прочитать, для понимания темы про биндер и некоторых других.

В одном посте:

• Общие слова об архитектуре и скриптовой модели сталкера
• "Класс object_binder" расширение онлайновых объектов, колбеки, сохранение состояния.
• "Класс net_packet"

Регистрация скриптовых классов с помощью object_factory

Серверные классы. Часть 1 Иерархия серверных классов, описание не закончено.

Серверные классы. Часть 2 Картинка структуры наследования и несколько заключительных слов

Клиентские классы

 

Скрытый текст

Класс game_object Интерфейс ко всем онлайновым (клиентским объектам)

Класс hit для нанесения урона скриптом и другая информация (IQDDD)

Некоторая информация по управлению путями патрулирования здесь (Kirag) и здесь (Taroz)

Неполная информация по управлению памятью неписей с примером здесь (Bak)

Физическая оболочка объектов (Garry_Galler)

Пост о выборе (подборе) оружия НПС и стрельбы (*Shoker*)

 

Скрытый текст

Управление заданиями Класс CGameTask и другие вспомогательные классы и функции.

Управление инфопорциями Функции, колбеки, форматы файлов

Список специальных системных инфопорций (Unnamed Black Wolf)

Система профилей и алгоритм генерации имён. Форматы файлов, функции

Дополнительная информация по параметрам профилей terrain_sect (Kolmogor)

Диалоги. Часть 1 Форматы файлов, базовые сведения

Диалоги. Часть 2 Скриптовые диалоги

Диалоги. Часть 3 Тематическая подборка функций управления диалогами

 

Скрытый текст

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

Класс CTime Вспомогательный класс для управления игровым временем

Полезная скриптовая функция с использованием CTime (Garry_Galler)

 

Скрытый текст

class ini_file (меченый(стрелок))

Класс FS и CSavedGameWrapper Бинарный доступ к файлам, в том числе в игровых архивах, управление сохранёнными играми.

Скрипт уровня. Забытая фишка с колбеком на заход на уровень

Класс vector

Некоторая полезная информация о разных вещах (меченый(стрелок))

"Класс render_device" Направление и положение камеры, характеристики экрана, программная пауза игры и др.

Некоторая информация о различиях между ТЧ и ЗП в системе оконных классов и колбеков. (lekzd) Неплохо бы развить эту тему!

Некоторая полезная информация о скриптовых функциях из модуля _g.script. (lekzd) Также требует развития!

Полезные функции для работы с графом игры (Garry_Galler)

В одном посте:

• Класс profile_timer Отладочные измерения скорости работы фрагментов программы
• Класс client_spawn_manager Колбек на выход в онлайн без использования биндера.

Работа с консолью. Класс CConsole

Анимации цвета. Класс color_animator Всякие моргающие элементы в окнах и пр.

Управление постэффектами. Скриптовые постэффекты. Класс effector

Класс sound_object. Проигрывание звуков в игре в произвольном месте, от произвольного объекта, в голове актора. (Shadows)

    Пост удалён автором (прим. Kirgudu)

 

Скрытый текст

Оконные классы

Некоторая общая информация о создании окон

Список методов, XML-тегов и событий для оконных классов (ТЧ/ЧН/ЗП) (Norman Eisenherz)

 

Представление материала в моих статьях оптимизировано для онлайнового просмотра. Если кому не хочется лазить по спойлерам, а нужно просмотреть текст какого-либо поста "потоком", то могу рекомендовать просмотр в режиме "текстовая версия". В этом же режиме удобно сохранять содержимое темы на диск. (прим. Malandrinus)

Изменено 30 Июля пользователем Kirgudu

[7.9 174]

Действительно - - можно писать любые числа - они в роде как пересчитываются в правильные (?) ...

Но! - вот, например, новогодняя аномалия, "32 декабря" называется:

 

(далее: если "set" ... -> то "get" ...)

 

2014,12,32,0,0,0,0 -> 2014,12,32,0,0,0,0

2015,1,1,0,0,0,0 -> 2014,12,32,0,0,0,0

2014,12,33,0,0,0,0 -> 2015,1,2,0,0,0,0

Изменено 22 Июля 2010 пользователем 7.9

[Malandrinus 615]

7.9,

А даты-время, этот класс, обслуживает в пределах с 2000.1.1.0.0.0.0 по 2029.12.31.23.59.59.999

Вроде как с 1/1/1, а не с 2000/1/1. И эта дата + нулевое время соответствует нулевому значению счётчика. Соответственно, если прибавить или отнять такое время (1/1/1-0:0:0:0), то ничего не изменится.

 

Но! - вот, например, новогодняя аномалия, "32 декабря" называется:

Я провёл глобальное сравнение с настоящим календарём. Да, в конце каждого года непременно косяк. Чаще всего в самом деле появляется 32-е декабря. При этом иногда это просто лишний день, иногда он заменяет 1-е января следующего года (а год начинается соответственно со 2-го числа). А иногда косяк не в лишнем дне, а напротив - в отсутствии 31-го декабря.

 

В общем, даже календарь в Зоне аномальный =) Интересно, баг это или пасхалка...

 

[Unnamed Black Wolf 4]

Думаю писали именно 31 января, поэтому и под алкоголем сместилось.... ))))))

А в общем, можно нагородить отдельную проверку с ручным выставлением в случае с 31 январем....

 
(получения дня == 31) and функция or обычная функция. 
-----
if день == 31 then 
код функции 
else 
код функции 
end

Ну к примеру.. А в сете выставить полную дату, ручками....

 

ХЗ, эти великие отмазывальщики, скажут все что угодно.. Но не признаются в кривых руках, и безмозглостью ....

Изменено 23 Июля 2010 пользователем Unnamed Black Wolf

[Malandrinus 615]

Unnamed Black Wolf,

в сущности какая разница, соответствует игровой календарь реальному или нет? Ведь игровое время по-любому отличается от реального. Ну будет в игре лишний/недостающий день, и что с того? Надо только убедиться, что способ расчёта даты в классе CTime соответствует расчёту времени в собственно игровом времени.

[Unnamed Black Wolf 4]

malandrinus, какой ты скучный.. Нет, покритиковать немного.. Повеселится над багом/пасхалкой.... Я вот к примеру до второго третьего, в отключке.. Поэтому не знаю что есть 32 или нет.. Мб календарь в действительности почему-то имеет странные 31-30 дней и за редкостью 29 и в обычностью 28.... А у меня в НГ чудо.

Обидел речью про криворукость и безмоглость? (Как будто сам так не считаешь....)

Ну кстати смотря чем мерить время в сталке, если мне память не изменяет, то в сталке есть и запрос обычного времени.. Которое яко-бы реальное....

Суть вопроса, а что есть реальное? Почему к примеру это все не игра? То так буит весело..... (Бушь отвечать, аргументируй.. Я сперва начну. (Реинкорнация и перерождение это вид сейв/лоад))

[7.9 174]

Темы про общие вопросы программирования не нашёл - спрошу здесь:

 

Почему у меня получаются такие результаты:

8388608 + 2.555 - 8388608 = 3 ;

0.123456789 * 1000 / 1000 = 0.1234567835927 ?

 

В документации написано, что числа в Луа "с плавающей точкой и двойной точности".

Что сделать что-бы так не было? Почему предел 2^23?

 

 

 

 

===========================

 

ЗЫ:

Unnamed Black Wolf-у

по самому луа, у меня все в порядке выдает....

Я про Луа в Сталкере имел в виду.

Изменено 23 Июля 2010 пользователем 7.9

[Unnamed Black Wolf 4]

по самому луа, у меня все в порядке выдает....

[AK74 4]

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

Почему у меня получаются такие результаты:

8388608 + 2.555 - 8388608 = 3 ;

Смахивает на округление. Попробуйте заменить 2.555 на 2.355.

Получится 2?

 

0.123456789 * 1000 / 1000 = 0.1234567835927 ?

Похожие баги я встречал у компиляторов Си, первой половины 80-х, и у SuperCalc-а (был такой предок у Exel).

 

В документации написано, что числа в Луа "с плавающей точкой и двойной точности".

Что сделать что-бы так не было? Почему предел 2^23?

Не понял, что не так? 2^23 не нравится? А почему?

 

[7.9 174]

для AK74

Понятно, что всё это - округление, только вот - не ожидал я его так быстро. Было-бы 2^25 - я бы может ничего и не заметил. Числа двойной точности с плавающей точкой - это 15 (или 16?) десятичных разрядов, а тут... даже не половина.В принципе - не проблема - пока обошёлся...

Изменено 23 Июля 2010 пользователем 7.9

[AK74 4]

А вот тут уже я завис, что значит "округление, только вот - не ожидал я его так быстро"?

Поясните, плз.

По идеи, округление "наступает" тогда, когда Вы его вызываете в явном или не явном виде.

 

ЗЫ. Вообще-то мне тоже показалась странным такой формат представления чисел, ведь по идеи

двойная точность раньше была: 1 знаковый бит, 11 бит -экспонента и 52 бита - мантиса, если склероз меня не подводит.

 

[7.9 174]

... что значит "округление, только вот - не ожидал я его так быстро"? Поясните, плз.

Просто, я его (автоматического округления) вообще не ожидал - если-бы была двойная точность, как в стандарте, я бы никогда с этим не столкнулся. Я думал: в XRay-е стандартный формат числа Луа, оказалось - это не так.

 

ЗЫ:

Наверное для производительности разрядность порезали.

Изменено 24 Июля 2010 пользователем 7.9

[AK74 4]

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

При этом, компилятор сам генерировал код, отбрасывающий дробную часть числа, перед присваиванием.

Может и здесь так же?

[Monnoroch 6]

AK74, "код, отбрасывающий дробную часть числа" это и есть преобразование форматов.

 

Добавлено через 1 мин.:

Кстати интересно - читал я, что все числа в ЛУА - double, но каким тогда образом отрабатывают циклы?

Видимо есть таки целые.Должны быть.

[AK74 4]

2 Monnoroch

А где я говорил обратное?

Я говорил о том, что преобразование типов данных может быть явным(Паскаль/Делфи), и может быть не явным (в PHP можно значение можно присвоить и вовсе строковой переменной).

 

Что касается double в циклах, если каждый раз происходит изврат с преобразование типов данных, да еще в нестандартный для сопроцессора формат, а потом из него уже в стандартный double, потом инкремент, а потом обратно преобразования!

Не-е-е-е, вряд ли, ну не дебилы же они.

Тут в чем-то другом собака порылась.

[Malandrinus 615]

Ох, развели флуд в теме...

 

Сначала по CTime. На самом деле совершенно фиолетово, правильно ли он считает даты или нет по совершенно банальной причине. В сталкере время не может быть больше чем стартовое время + 2^32 миллисекунд, что соответствует примерно 49 дням. По истечении этого времени счётчик отмотается на ноль и время изменится на стартовое. Дата никогда не дойдет до проблемного конца 12-го месяца.

 

Теперь по числам. Выглядит так, что в сталкере разработчики изменили дефолтовое представление чисел с double на float. Прежде чем паниковать давайте разберёмся немного в основах.

 

Во-первых, а что собственно плохого в использовании числа с плавающей запятой (в смысле, что плохого в использовании его как универсального типа "для всего")? Разработчики Lua и здесь не отошли от принципа "ничего лишнего". Может они переусердствовали?

 

К примеру, бытует следующее правило - числа с плавающей запятой нельзя сравнивать на равенство. Это верно, спорить не буду, но с некоторыми оговорками. Почему, собственно, нельзя? Ответ - из-за ошибок округления. Ну а если их нет? Число с плавающей запятой содержит в себе как подмножество некоторый непрерывный диапазон целых чисел (т.е. подмножество целых чисел, которые могут быть представлены этим типом гораздо больше, чем этот диапазон, но за пределами диапазона между числами уже будут разрывы, и корректность целочисленных сложений будет нарушена). Пока мы ведём вычисления в пределах этого диапазона и не используем операций, которые могут привести к появлению дробных чисел (деление, к примеру), то число будет оставаться целым, информация теряться не будет и в частности не будет никаких проблем с точным сравнением чисел на равенство.

 

Диапазон этот определяется размером мантиссы и не столь уж он и маленький. В частности у double мантисса занимает 52 бита + знаковый бит, т.е. в сумме 53 бита. Это, между прочим, позволяет представить больше целых чисел, нежели обычным типом int языка C/C++, в котором на большинстве архитектур 32 бита. Да, при выходе за этот диапазон арифметика ведёт себя не так, как целочисленная арифметика СИ. Ну и что? Не выходите за диапазон и всё. При выходе за допустимый диапазон любая машинная арифметика будет вести себя ненормально. То, что мы привыкли к одному способу ненормальности не означает, что так должно быть везде. Все прочие особенности и ограничения, связанные с этим представлением, также не вызывают особенных проблем. Как правило, в скриптовых языках применение целых типов ограничено всевозможными счётчиками в циклах и подсчётом количества чего-либо. Операция деления при этом является попросту излишней. Если вдруг до зарезу надо, то просто не забудьте про необходимость использовать явно функцию округления. Дело привычки опять же.

 

Второй вопрос, насколько плохо урезание дефолтового типа с double до float? Оценим без лишних эмоций. Тип float имеет мантиссу в 23 бита + 1 знаковый. Диапазон целых чисел, которые могут храниться без потери точности составляет +/- 16777216 (16 миллионов).

Давайте вспомним, что в игре может существовать всего 65534 объекта. И даже количество вертексов уровня (самая многочисленная сущность в игре) не превышает обычно полутора-двух миллионов. Так что с учётом тех потребностей, которые обычно возникают в скриптовании в этой игре, тип float выглядит вполне достаточным. По скорости же работы float на 32-х разрядной архитектуре существенно быстрее, чем double. С точки зрения собственно вычислений с плавающей запятой, то тут тоже всё нормально. В игровой математике нет необходимости в повышенной точности, зато есть необходимость в скорости. Ну и про память не забываем.

 

Теперь я кстати понял, почему у меня возникали проблемы со старшими битами при использовании функций побитовых операций (bit_and, bit_or, bit_xor). Сами то функции работают нормально, но вот маску можно задать не любую. Хотя опять же, в игре не используются флажки разрядности больше 16 бит, так что и с этим проблем никаких.

[Malandrinus 615]

Завершаем диалоги. В последней части подробно рассмотрены функции и методы, так или иначе относящиеся к диалогам: инициирование, завершение, блокирование/разблокирование и т.д.

 

 

Здесь опишу россыпью разные функции, имеющие отношение к управлению диалогами.

 

Скриптовый старт разговора. Для этого есть метод run_talk_dialog класса game_object. Применим только к актору:

db.actor:run_talk_dialog(npc)

где npc - собеседник, с которым надо начать разговор.

Говорить можно со сталкерами и торговцами, из которых в игре есть только Сидор. Разговор можно начать только если собеседник находится на расстоянии не больше трёх метров от актора. Если точнее, то можно попытаться вызвать её и на больших расстояниях. Что-то при этом происходит: появляется мышь, отключается движение актора и он начинает смотреть на "собеседника" даже при том, что окна разговора нет. Такое ощущение, что просто безбожно глючит. Проверка допустимого расстояния перед началом остаётся таким образом на совести скриптёра. Расстояние в 3 метра никакими настройками не изменить, похоже вшито прямо в код движка. Вероятно, если найти и пропатчить это значение, то можно в каком-то смысле вернуть утраченную возможность общаться "через сталкерскую сеть".

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

 

Параметр need_osoznanie_mode в секции персонажа позволяет избежать ограничения в 3 метра на возможность начать разговор. Однако при этом окно разговора показывается не полностью. Отсутствуют окна с иконками собеседников и окно чата. Есть только нижняя часть - окно выбора варианта ответа или диалога. Фактически, это превращает окно общения в своеобразное диалоговое окно для выбора одного из нескольких вариантов. Это используется в игре для предоставления Меченому выбора - присоединяться к О-Сознанию или нет. В принципе ничто не мешает использовать это как-то иначе.

 

Прервать разговор можно вызвав метод stop_talk для каждого из собеседников. Этот метод используется в специальном диалоге актора, который прописывается каждому NPC. Там есть скриптовое действие, которое выглядит так:

function break_dialog(first_speaker, second_speaker, id)
	first_speaker:stop_talk()
	second_speaker:stop_talk()
end

 

Ничто не мешает сделать это в любой другой момент.

 

Из режима разговора можно скриптами переключиться в режим торговли с помощью метода switch_to_trade. Это метод только для актора:

db.actor:switch_to_trade()

Есть и обратный метод switch_to_talk, но он не работает. Т.е. он реально ничего не делает. Там по коду стоит ret и ничего больше. Так что переключиться обратно из торговли в режим разговора можно только закрыв окно мышкой.

 

// включение/отключение возможности говорить работает только для NPC.

void enable_talk(); // включить возможность говорить

void disable_talk(); // отключить возможность говорить

bool is_talk_enabled(); // возможность говорить

void stop_talk(); // остановить разговор

bool is_talking(); // состояние разговора

Функция is_talking должна возвращать true во время разговора. У меня были случаи, когда она почему-то не срабатывала. Зато железно срабатывают служебные инфопорции на открытие закрытие окна разговора.

Смежные методы для активации окна торговли

void enable_trade(); // даёт возможность торговать

// торговлю можно запустить если enable_trade() включено у обоих собеседников

void disable_trade(); // отключить торговлю

bool is_trade_enabled(); // состояние возможности торговать

 

Функция give_talk_message позволяет в процессе разговора вывести в окно чата сообщение с иконкой. Описание функции:

void give_talk_message(string text, // текст сообшения 
                       string texture_name, // файл с текстурой иконок
                       Frect tex_rect, // прямоугольник иконки в этом файле
                       string templ_name); // имя шаблона

 

Шаблоны содержатся в XML файле "config\ui\talk.xml" или "config\ui\talk_16.xml" (второй, видимо, для широких мониторов)

В оригинальной игре есть три шаблона: "iconed_answer_item", "actor_answer_item" и "iconed_trade_info". Если не задать никакой, то используется "iconed_answer_item". В принципе, ничто не мешает добавить в этот файл свои шаблоны. Можно поменять размеры иконки и свойства текста.

Предназначение этой функции в оригинальной игре - вывод дополнительных строк в диалоге при реализации динамического списка предлагаемых квестов. Как всегда, извращённый разум модостроителя может найти ей и иные применения. К примеру, если убрать иконку и сделать текст надписи похожим на текст основного чата, то можно с помощью тега action и этой функции частично реализовать функциональность отсутствующего в ТЧ тега script_text.

 

Функции, работающие только для неписей:

void set_start_dialog(string <dialog_id>) // установка приветственного диалога NPC

void restore_default_start_dialog() // восстановление диалога, заданного в профиле персонажа

void get_start_dialog() // функция по смыслу должна возвращать строку - имя стартового диалога, но на самом деле не делает ничего.

 

Изменённое имя стартового диалога запоминается и при загрузке восстанавливается.

 

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

 

 

В заключение диалогов немного рассуждений о стратегии построения динамических диалогов. Под динамическими я разумею такие диалоги, где что-то меняется в зависимости от ситуации (к примеру, в зависимости от ранее сказанного). Менять в принципе хотелось бы граф фраз и текст фраз. Если вы ещё не забыли, то напоминаю, что невозможно изменить полный граф отдельно взятого диалога. Надеюсь, вы также не забыли, чем отличается диалог от разговора. Кроме того, очевидно для NPC и для актора подходы к реализации динамических диалогов могут отличаться.

 

Начнём с NPC. Допустим, актор сказал некую фразу, и надо, чтобы ответ зависел от того, что было сказано, и вообще от текущих игровых обстоятельств любого свойства. Большим преимуществом является то, что вне зависимости от способа генерации ответа это происходит невидимо для актора. В любом случае виден будет только результат - сказанная фраза. Это существенно расширяет арсенал подходов к решению данной задачи.

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

Второй подход подразумевает всего одну исходящую ветку графа, но при этом текст ответа должен так или иначе генерироваться "на лету". Собственно, именно для этого есть тег script_text, который был в ранних билдах, был убран в релизе ТЧ и опять появился в ЧН/ЗП. С помощью этого тега можно задать функцию, а в ней уже по обстоятельствам сгенерировать текст ответа. Увы, в ТЧ это не работает, а этот движок пока является наиболее актуальным. Выкрутиться из положения можно с помощью функции give_talk_message. Можно задать основной текст ответа пустым, задать тег action, а в нём вызвать эту функцию для вывода произвольного текста. Надо только подрихтовать шаблон для этой функции так, чтобы её вывод был похож на основной текст чата.

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

 

Для актора всё и сложнее и проще. Проще, поскольку как правило от актора и не требуется большой вариабельности в ответах: да/нет, спасибо/до свидания, т.е. ведущая роль принадлежит NPC. Сложнее потому, что для актора не всё из сказанного ранее работает. Отличие ответа актора от ответа NPC в том, что игрок выбирает ответ. При этом есть текст, который виден в окне выбора ответа и есть текст, который появится в окне списка сказанных фраз. Функция из тега script_text устанавливает и тот и другой текст, но под ТЧ это работать не будет. give_talk_message никак не меняет текст в окне выбора. Более того, не получится сделать текст фразы пустым, как это можно было сделать для фразы NPC. Дело в том, что пустая фраза будет просто пропущена движком. Если же задать текст фразы, то в окне чата появится этот текст и то, что выведет give_talk_message, в придачу. Ясно, что далеко не во всех случаях это будет приемлемо.

Возможный, хотя тоже ограниченный, подход может быть такой. Можно после фразы NPC завершать диалог. При этом окно разговора переходит в режим выбора другого диалога. Но внешне это практически никак не отличается от режима выбора фразы. Однако, при этом появляется дополнительная возможность в виде атрибута диалога caption, который может маскировать первую фразу диалога. Фраза при этом может быть и пустая, что даёт возможность сгенерировать её текст целиком с помощью give_talk_message. Выбор фразы при таком подходе будет осуществляться с помощью выбора диалога. Ясно, что придётся выкручиваться с заголовками диалогов (как бы фразами), делая их максимально универсальными. Например, сделать заголовок диалога "назвать свою цену", а уже в сказанной фразе показать собственно цену, которая будет сгенерирована на лету.

 

Изменено 29 Июля пользователем Kirgudu

[Malandrinus 615]

Скрытый текст

Есть такая штука "анимация цвета". Это просто заданная во времени последовательность изменения цвета, которой сопоставлен некоторый текстовый идентификатор - имя. Эти анимации живут в файле lanims.xr. Редактировать их можно с помощью редактора уровней из официального SDK.

В скриптах эти анимации практически не используются. В основном их назначение - всякие помаргивания текста и окон. Для этого есть атрибуты тега в XML файлах для создания окна статика (CUIStatic): light_anim, la_cyclic, la_text, la_texture, la_alpha, xform_anim, xform_anim_cyclic. Может и ещё где используются. Со стороны скриптов имеется простой класс для доступа к этим анимациям (точнее к их данным).

 

Скрытый текст

class color_animator {
    color_animator(string <имя>); // конструктор

    void load(string <имя>); // перезагрузить анимацию
    int length(); // получить длину анимации в миллисекундах
    fcolor* calculate(float t); // Получить цвет в указанное время. Время в секундах
};

 

Конструктор, как и для большинства других классов, представляет собой глобальную функцию. Аргумент - имя анимации.

Остальное самоочевидно. Метод calculate возвращает вычисленный цвет для заданного времени. Значения за пределами времени, возвращаемого функцией length, вычисляются так, как если бы анимация повторялась бесконечно. Т.е. в каком-то смысле анимация зацикленная. "В каком-то смысле" потому, что никакой анимации как таковой нет, есть только её данные.

В оригинальной игре класс color_animator практически не используется. Единственный пример использования имеется в модуле level_psy_antenna.script, который вроде как отвечает за набор спецэффектов на уровне с выжигателем. Но я так и не понял, где же этот модуль задействован. Напрямую нигде не упоминается. Либо это старый и неиспользуемый мусор, и эффекты на упомянутом уровне организуются как-то иначе, либо его вызов организуется как-то хитро, к примеру имя модуля составляется по ходу выполнения. Как бы то ни было, этот модуль имеется даже в ЗП, где уж точно никак не используется.

Класс color_animator там задействован для динамического управления какими-то параметрами скриптового постэффекта.

 

 

Скрытый текст

Не используется нигде, кроме как в color_animator, где является по сути просто носителем 4-х значений.

class fcolor {
    fcolor();
    
    float a;
    float r;
    float b;
    float g;

    void set(DWORD);
    void set(const fcolor&);
    void set(float r, float g, float b, float a); // аргументы в диапазоне 0.0 - 1.0
};

 

Примеры использования:

local c = fcolor()

c:set(0.1, 0.2, 0.3, 0.4)

c:set(GetARGB(12, 34, 56, 78))

local a = c.a

local r = c.r

 

 

 

Изменено 29 Июля пользователем Kirgudu

[dimos 10]

malandrinus, есть ли связь между story_ids из lua_help.script и game_story_ids.ltx из папки config? Если есть, то какая? По идее, достаточно задать нужный sid в game_story_ids.ltx, но...

[Malandrinus 615]

dimos,

связь самая непосредственная. Естественно, надо прописать story_id в game_story_ids.ltx, и после этого он появляется под прописанным именем в классе story_ids. Через этот класс-перечисление можно обращаться к новому story_id по имени, а не использовать малопонятную цифру.

[Malandrinus 615]

Как-то постил в одной из тем эту информацию, но потом сам уже с трудом нашёл, так что повторяю здесь. Имеется возможность выполнить некий код по факту появления ГГ на произвольном уровне. Для этого в файле level.ltx конкретного уровня надо создать секцию [level_script], если её там уже нет, и прописать там список выполняемых скриптов уровня:

[level_script]
script= <имя модуля 1>,<имя модуля 2>,<имя модуля 3>

Обращаю внимание, что в отличие от большинства случаев здесь указывается не имя функции, а имя файла, т.е. несколько имён. При появлении актора на уровне эти файлы выполняются, что означает из компиляцию и выполнение всего, что находится в глобальной области. Также выполняется функция main, которая должна быть в каждом из этих файлов.

В релизной версии игры эта техника не используется вообще. Некоторое упоминание ещё было в ранних билдах и то в виде закомментированных параметров. Несмотря на это фишка вполне рабочая.