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

[Kirag 39]

Кое-что по классу patrol, то, что сам понял.

 

C++ class patrol {

const continue = 1;

const custom = 3;

const dummy = -1;

const nearest = 2;

const next = 4;

const start = 0;

const stop = 0;

 

patrol (string);

patrol (string, enum PatrolPathManager::EPatrolStartType);

patrol (string, enum PatrolPathManager::EPatrolStartType, enum PatrolPathManager::EPatrolRouteType);

patrol (string, enum PatrolPathManager::EPatrolStartType, enum PatrolPathManager::EPatrolRouteType, boolean);

patrol (string, enum PatrolPathManager::EPatrolStartType, enum PatrolPathManager::EPatrolRouteType, boolean, number);

 

function level_vertex_id(number) const;

function point(const patrol*, number);

function flag(number, number) const;

function game_vertex_id(number) const;

function flags(number) const;

function name(number) const;

function index(string) const;

function terminal(number) const;

function count() const;

function get_nearest(const vector&) const;

};

 

 

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

 

patrol (string) - создает объект класса.

 

Методы:

 

count() - возвращает количество точек в пути. Аргументов не требуется.

 

name(number) - возвращает строку - название заданной точки пути. Аргумент - номер точки, начиная с 0 (pN:name = ... в алл.спавне).

point(const patrol*, number) - возвращает вектор - координаты заданной точки пути. Аргумент - номер точки, начиная с 0 (pN:position = ... в алл.спавне).

game_vertex_id(number) - возвращает число - гейм вертекс заданной точки пути. Аргумент - номер точки, начиная с 0 (pN:game_vertex_id = ... в алл.спавне).

level_vertex_id(number) - возвращает число - левел вертекс заданной точки пути. Аргумент - номер точки, начиная с 0 (pN:level_vertex_id = ... в алл.спавне).

flags(number) - возвращает объект класса flags16 или flags32 (как их отличить не знаю, методы точно такие же) - флаг данной точки пути (pN:flags = ... в алл.спавне). Аргумент - номер точки, начиная с 0. Значение флага можно узнать методом get() класса flags16 (или flags32)

terminal(number) - возвращает логическое значение - true, если из данной точки нет переходов на другие точки и false, если есть (есть ли pN:links = ... в алл.спавне). Аргумент - номер точки, начиная с 0.

 

flag(number1, number2) - возвращает логическое значение - true, если значение флага в точке number1 равно number2, иначе false. Агрументы: первый - номер точки, второй - число (в оригинальных скриптах почему-то только от 1 до 32). Уверен не до конца.

 

get_nearest(const vector&) - примеров использования нет, предположительно ищет ближайшую к заданным вектором коордтам точку пути. Не проверял.

index(string) - нет ни примеров использования, ни предположений, что это могло бы значить.

 

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

 

patrol (string, enum PatrolPathManager::EPatrolStartType);

patrol (string, enum PatrolPathManager::EPatrolStartType, enum PatrolPathManager::EPatrolRouteType);

patrol (string, enum PatrolPathManager::EPatrolStartType, enum PatrolPathManager::EPatrolRouteType, boolean);

patrol (string, enum PatrolPathManager::EPatrolStartType, enum PatrolPathManager::EPatrolRouteType, boolean, number);

 

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

[Kirag 39]

Garry_Galler,

 

Методы get_linear_vel и get_angular_vel рабочие (для всего шелла - проверено, для отдельного элемента - наверняка то же самое), применяются они так:

 

-- ps - ранее полученная физ. оболочка объекта
lvel = vector()
ps:get_linear_vel(lvel)
avel = vector()
ps:get_angular_vel(avel)
-- дальше с переменными lvel и avel делается все, что нужно

 

 

По поводу практического применения - оба метода используются в нашей с malandrinus-ом "Гравипушке". Линейная скорость - для контроля положения захваченного объекта - как и куда нужно пнуть объект, чтобы он остался в фокусе захвата, обе скорости - для определения факта соударения брошенного объекта - оба вектора при ударе должны заметно измениться.

Изменено 25 Сентября 2010 пользователем Kirag

[Kirag 39]

Такая идея пришла:

Озвучка ведь запускается какой-то функцией. Длительность звукового файла определить реально. В этой же функции запуска озвучки можно добавить строчку, устанавливающую некую глобальную переменную х в time_global() + длительность_озвучки.

И выключить ввод. Как-нибудь так:

 

    local snd = xr_sound.get_safe_sound_object([[файл_озвучки]])
    snd:play_no_feedback(db.actor, sound_object.s2d, 0, vector(), 1.0)
    level.disable_input()
    x = time_global() + snd:length()

 

А в многострадальном апдейте актора добавить проверку, что-то вроде

if x then
    if x <= time_global() then
        x = nil
        level.enable_input()
    end
end

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

 

Whisper Не совсем понял, зачем разбивать фразу НПС, и задерживать вторую половину. Пусть весь текст реплики непися будет сразу, а озвучка пусть идет, как идет. И список ответов ГГ, и файл озвучки определяются единственно фразой НПС, которая в момент запуска озвучки уже известна.

[Kirag 39]

Парсер .xml файлов для использования данных из них в скриптах. Проверено на ТЧ, на ЧН/ЗП - не знаю.

 

К примеру, нужно приаттачить кнопку к окну инвентаря, не куда попало, а, скажем, под пистолетным слотом. Такая "кнопка про пистолеты". Но, модов много, вариантов инвентаря не намного меньше. Каждый раз думать: "Что еще за кнопка посередь шкалы радиации? А-а-а! Тут же в чистой игре пистолет был!" - радости никакой. Каждый раз лазить в xml-ки, искать что и где, вручную менять - тоже приятного мало. Лучше при аттаче кнопки знать, куда ее вешать. Считать данные, как из ltx-а тоже не получается. Получить нужные координаты из класса окна - позицию в ТЧ никак, только размеры, но их мало. В общем, пришлось мудрить...

 

 

Можно получить из указанного файла только данные из конкретного тега. Тег в файле должен существовать и быть единственным. Вызов:

parse_xml.teg(filename,tegname)

Возвращает таблицу.

 

Парсер также может разобрать весь указанный файл .xml. Также он поступит, если при попытке разобрать тег имя тега tegname не указано. Здесь уже нет требования на уникальность тегов. Повторяющиеся теги заносятся в таблицу с номерами 1..N в порядке следования в файле. Вызов:

parse_xml.file(filename)

Возвращает таблицу.

 

Имя файла filename задается относительно папки config, задавать его лучше в двойных квадратных скобках - [[ui\inventory_new.xml]], тогда точно сожрет. Имя тега - обычная строка.

Проверял выборочно, но вроде бы жрет все xml-ки

 

Функция print_table(table,table_name,mode)

Сбрасывает в лог содержимое таблицы table. Название таблицы для лога - table_name или "table", если не задано.

Параметр mode имеет два осмысленных значения: "key" - в лог выводится только список полей, "val" - только значения. Во всех остальных случаях выводится "поле = значение"

Подавилось пока только на таблице db.storage - в поле actions с ключами что-то не то, похоже, не числа и не строки.

 

Функция long_string_to_table(string,string_name)

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

 

Обе функции для тестового вывода информации.

 

 

 

 

 

Ссылка: parse_xml.script

[Kirag 39]

Artos

Спасибо за подсказку, недоглядел.

 

Файл поправил и перезалил : parse_xml.script

[Kirag 39]

По поводу >>класса FS<<

Как уже malandrinus упомниал, что не все гладко с открытием файла на чтение. По моим экспериментам выходит так, что открыть файл мало, с собственно прочтением тоже не все просто.

function read_ltx(filename)
    local fs = getFS()
    local inv_ltx = nil
    if filename then
        inv_ltx = fs:exist("$game_config$",filename)
    end
    if not inv_ltx then
        qqq("Parse_ltx: file "..tostring(filename).." not exist")
        return nil
    end
    local abs_name = inv_ltx.name
        qqq("abs_name = "..abs_name,1)
    local size = inv_ltx.size_real
        qqq("size = "..tostring(size),1)
    local r = fs:r_open(abs_name)
    r:r_seek(0)
        qqq("after r_seek(0)")
    local str = r:r_stringZ()
        qqq("after r_stringZ")
    if r:r_tell() > size then
        str = string.sub(str,1,size)
    end
    local str_del = str
-- дальше чищу от хлама, не суть
    return str_del
end

qqq - безобидный вывод в лог

 

 

Файл класс FS видит в любом случае - неважно, распакован ли он в геймдату, или остался в игровом архиве. Полное имя файла (abs_name) всегда пишется d:\games\и т.д., размер считается (не знаю уж, насколько правильно, но все-таки). Файл открывается на чтение в любом случае - метка "after r_seek(0)" в логе присутствует, вылетов не было.

 

Проблемы начинаются при попытке прочесть содержимое файла:

local str = r:r_stringZ()

Если файл распакован в геймдату, то все прекрасно читается, в лог идет метка "after r_stringZ", и программа работает дальше. Если файл в архиве, игра с 99% вероятности виснет (иногда, без видимых причин, все-таки прочитывает), и последняя метка в логе - "after r_seek(0)"

 

Не пойму только, это в принципе такое ограничение, или я что-то неправильно делаю...

 

 

Изменено 14 Августа 2011 пользователем Kirag

[Kirag 39]

malandrinus,Artos, спасибо за подсказки

 

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

 

По большому счету нужно начиная с system.ltx выбирать из текста файла секции и инклуды, с каждым инклудом процедуру повторять. В каком виде при этом содержимое файла - не так важно, лишь бы читалось. В случае с парсером XML метод r_stringZ читал до конца файла, плюс иногда чуть-чуть мусора, который я обрезал по размеру.

 

Но с запакованным LTX-ом номер не удался, подозреваю, из-за того, что символ NULL не находит и читает строку, пока не повиснет...

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

 

 

[Kirag 39]

Artos

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

 

Кстати, не знаю, с чего я вбил себе в голову, что символ NULL = конец файла. В парсере XML мусор регулярно читается, может, я и в этом не прав...

 

 

 

[Kirag 39]

Кстати, об update-пакете. Считать данные оттуда - без вопросов, а вот получалось ли у кого-нибудь данные туда результативно записать?

Допустим, спавн оружия. В state-пакет вписываю, что надо, и спавнится с нужным визуалом, типом-количеством патронов и т.д. - все прекрасно работает. Пытаюсь одновременно в update-пакет прописать тот же updgrenade_mode - толку ноль, все равно спавнится в обычном режиме, с выкл подстволом. Режим стрельбы тоже только по умолчанию, что бы не вписывал. Причем сразу после записи (в тот же момент времени) пытался update-пакет считать снова - вроде все и прекрасно записалось, да только толку с того ноль - на состоянии оружия не отражается.

Может, с update-пакетом надо как-то по-другому работать, чем со state-пакетом?

 

P.S. В корректности разбора update-пакета полностью уверен, учитывал и класс оружия, и порядок следования данных, результаты чтения тоже вполне ожидаемые.

 

Artos

Попробую с НПС. Хотя, у них же еще и state-здоровье есть, непонятно, которое из них срабатывает...

Изменено 14 Октября 2011 пользователем Kirag