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

[Malandrinus 615]

IQDDD,

Возможно, что движок тупо отсчитывает от данного в вертекса в таком-то направлении такое-то расстояние и выбирает ближайший к получившейся точке level vertex.

Так и есть. Я подробно алгоритм поиска вертекса не исследовал, но вроде как координата Y (вертикальная) игнорируется. Кроме того, если под точкой сетки нет, то всё равно возвращается какой-то вертекс, ближайший или нет - не знаю.

В ЗП, кстати, есть функция, которая просто возвращает вертекс по координатам без всей этой возни со стартовым вертексом, направлением и расстоянием. Хотя знак равенства между этими функциями я бы не ставил. Если думать о том, как этот алгоритм может быть реализован, то можно прийти в выводу, что функция эта весьма затратная, поскольку вертексов может быть под миллион и больше. vertex_in_direction возможно ищёт от текущего и на этом экономит, а как работает та функция из ЗП - могу только догадываться.

 

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

 

[Malandrinus 615]

Kolmogor,

Левел-вертекс ищется двоичным поиском - поэтому на миллионе вертексов итераций будет максимум 20 Причем в самих итерациях только сравнение и все.

Так что функция получается быстрая - собственно такой формат аи-сетки для этого и делали

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

 

IQDDD,

А какой это "такой формат аи-сетки"?

Там просто линейный массив из всех узлов. Каждый узел представляет собой два целых числа - это так хранятся координаты в упакованном виде. Смысл в том, что вся сетка вписана в прямоугольный параллелепипед (бокс по-простому). На высоту даётся 2 байта, т.е. по высоте имеется ровно 65536 уровней, соответственно, разрешение сетки по высоте определяется как <высота бокса> / 65536. По X и Z задаётся примерно постоянный шаг (что-то около 0.25 игровых метра, хотя вроде это можно менять). Соответственно, может быть Nx = <сторона по X> / 0.25 и Nz = <сторона по Z> / 0.25 возможных координат по каждой оси, а всего Nx * Nz, но не больше, чем влазит в 24 разряда. Теперь обе координаты X и Z пакуются в одно целое в 24 бита. Дальше все эти элементы - упакованная Y и XZ, дополнительная информация по укрытиям и привязке к узлам графа - всё сохраняется в виде линейного массива в файлах. По всей видимости ещё и отсортировано заранее.

 

И что значит двоичный поиск?

Двоичный поиск

 

 

Byurrer,

да с xml то это понятно, но нужна сама начинка ПДА!

Всё это внутри движка.

[Malandrinus 615]

_Призрак_,

есть ли функция закрытия/открытия инвенторя(пда)?

вроде нет.

AKKK1,

Возможно-ли чисто теоритически построение 3D АИ-сетки?

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

Изменено 19 Января 2011 пользователем kokkai

[Malandrinus 615]

Stalk15,

да, там какие-то проблемы. Причём, у меня дежа-вю, что как-то работало, но все поздние попытки были неудачными. В итоге, чтобы сместить партикл я просто создавал объект в новом месте, а старый удалял. Но он при этом некрасиво моргает.

 

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

[Malandrinus 615]

Функции can_switch_online/offline по идее определяют возможность перехода в онлайн/оффлайн самого объекта. Как это будет в данном случае влиять на неписей, приписанных к смарту, понятия не имею.

[Malandrinus 615]

RvP,

То что это float было важно для С++, в сткЛуа все числа являются float-ами

Это в Lua всё одного типа, а при передаче внутрь происходит преобразование в указанный тип C/C++. Т.е. при описании я давал тип аргументов и возвращаемых значений самих движковых функций. Это важно для того, чтобы вы понимали, какой именно природы должны быть аргументы и что именно ожидать в качестве результата функции.

 

Уже говорил, но повторюсь. Из-за того, что функции движковые, но используется из Lua, выходит по-нормальному описание типов не дать. Названия типов и классов в большинстве случаев изменены, поэтому не будет никакого смысла указывать реальный движковый тип, поскольку большинству это ни о чём не скажет и только запутает. Кроме того, не все понятия С/С++ имеют внятный эквивалент в Lua. К примеру ссылки/указатели всяко преобразуются в просто ссылку Lua. Или скажем строковому типу Lua string, в С++ соответствует три разных типа С++ да ещё с вариациями указатель/ссылка, ну и т.д.

 

По этой причине принятый язык описания - это "псевдо C/C++", т.е. нечто в стиле С++, но строго стандарту языка не соответствующее. Для тех же строк для простоты указывается просто тип Lua string без лишних заморок с указателями/ссылками. Это вероятно может запутать или вызывать раздражение у пуристов, но в оригинале в lua_help.script было ещё хуже.

[Malandrinus 615]

strelok200,

Как через скрипт выдать инфопорцию скажем после смерти сталкера?

Также, как и до смерти. Почитай статью про game_object. Там есть функция для этого.

[Malandrinus 615]

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

[Malandrinus 615]

Логика работает только в онлайне, а здесь нужно в оффлайне. Так что не годится.

[Malandrinus 615]

Полтергейст,

Он есть, просто не экспортирован в скрипты. У негo конфиговое имя сета II_DOC и скриптовое clsid.obj_document. Т.е. создать такой объект можно.

[Malandrinus 615]

Полтергейст,

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

 

Большую часть сказанного я кстати рассказывал в статье про object_factory.

[Malandrinus 615]

Полтергейст,

Оказывается, в классе cse_alife_monster_base есть поле m_smart_terrain_id, но оно не экспортировано.

Это поле есть в классе cse_alife_monster_abstract, который является базовым для всех монстров и людей. Таким образом, это поле есть во всех унаследованных и в том числе в cse_alife_monster_base, который является базовым только для монстров. Конечно не надо пытаться создавать своё поле с таким же именем.

Хм. Похоже моё описание в этой теме устарело. Я там написал, что это поле есть начиная с ЧН, но оно есть и в ТЧ, просто не используется и не документировано.

Изменено 20 Марта 2011 пользователем malandrinus

[Malandrinus 615]

Полтергейст,

насчёт перегрузки клиентских классов. Похоже, это всё-таки возможно. Есть такой файлик - ce_switcher.script. Там наглядно показано, как это делается.

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

 

Да и если посмотреть повнимательней, то этот сет (O_SWITCH) в игре не используется. Сет есть, секция есть, а объекта такого нет. Возможно, остался рудимент от старых времён, а сейчас попросту никто не заморачивается с выпиливанием мусора. Впрочем, в ЧН убрали секцию, а в ЗП уже и сет убрали, и остался, не понять зачем, только файлик скрипта. Так что он нерабочий и никогда рабочим не был.

 

Я должен заметить, что особенно в ТЧ имеется довольно много нерабочих фрагментов и файлов.

Во-первых, на каком-то этапе сильно поменяли скриптовую модель в целом. Надо ведь понимать, что то, что мы сейчас воспринимаем как данность, для разрабов таковым не было. Они же это придумывали. Поэтому многие вещи менялись, переписывались, а в скриптах оставался старый хлам и остатки от экспериментов. От той эпохи кое-где остались функции main, которые вроде как должны выполняться автоматически, а кое-где они даже работают, как например в скриптах уровня. От того же времени в модуле _g.script остался класс FSM - скриптовый конечный автомат, который должен был управлять неписями. В старом варианте некоторые классы были более навороченные, как к примеру vector и matrix, которые вполне годились для нормальных вычислений векторной алгебры. Сейчас вектор урезан очень сильно и позволяет только ограниченное подмножество операций. От матрицы вообще остался жалкий огрызок, по сути только хранилище для чисел. Был класс скриптового постэффекта (собственно и остался), а потом видимо его внесли в движок, и теперь постэффекты можно делать двумя способами, хотя скриптовый в игре не используется. Думаю, можно и ещё примеров набрать.

Во-вторых, движок делали разные люди в разное время, а скрипты писали ещё другие люди (и похоже в гораздо большем количестве) и также в очень разное время. У меня есть очень стойкое ощущение, что все эти люди жили в каких-то параллельных мирах. Особенно в ТЧ заметно, что скриптёры попросту не знают, как пользоваться некоторыми классами движка (хотя бы вектором, даже в его урезанном варианте). Более того, они и просто с Lua были не в ладах, судя по убогой реализации некоторых функций. При этом часть кода явно была написана людьми определённо понимающими. С чем это связано, сложно сказать. Может сказалась текучка кадров, или учились на ходу.

Наконец, я почти на 99% уверен, что у разработчиков попросту нет документации на свой собственный движок. Сообществу так и не дали описания скриптовой части. Точнее дали, но это по большей части описание той первой реализации, про которую см. выше. Мы думаем, что они жлобятся, но что более вероятно - что это на самом деле всё, что у них есть. По славной традиции постсовковой разработки документацию пишет разработчик (всем известный документ написан Ясеневым). Потом начался бардак и раздрай и на документацию забили. Я практически уверен, что последние скриптёры просто смотрели в исходники, и это и была вся их документация. Ко всему, похоже и на любую систему в скриптах забили. Разрабы просто стали добавлять экспортированные функции по запросу скриптёров. Это видно по некоторым высказываниям на выложенной wiki разработчиков образца 2004 г.

 

Так что относитесь критически особенно к тому, что можно найти в ТЧ. Там многое реально не работает.

 

Изменено 20 Апреля 2011 пользователем malandrinus

[Malandrinus 615]

Ранее здесь был разговор по поводу игрового счётчика времени. Колмогор был совершенно прав, а я ошибался. Счётчик времени в движке на самом деле 64-х разрядный и с ним как таковым проблем нет. Заворачивание даты у меня происходило в искусственном эксперименте, когда я выкручивал таймфактор на 20000 и без промежуточных перезагрузок крутил время. При этом действительно происходит заворачивание счётчика примерно через игровой месяц, но на практике такая ситуация не возникает.

 

Однако проблема есть с функцией game.time(), которая возвращает только младшие 32 разряда от этого счётчика. Эта функция используется повсеместно и соответственно через игровой месяц от начала игры начинает выдавать совершенно неправильное значение (и это никак не исправить). Используется она достаточно много где. В принципе, если вместо неё использовать game.get_game_time() и класс CTime, то проблем быть не должно.

[Malandrinus 615]

Так к сожалению нельзя "остановить скрипт", что нужно в данном случае. И опасаюсь, что эта задача нерешаемая. "Остановить" скрипт можно только поставив на бесконечный цикл. Но как в этом случае узнать, когда выходить? И будет ли в этом случае отыгрываться звук? В общем приличных вариантов решения задачи не вижу.

[Malandrinus 615]

Пока ты крутишь цикл, время будет стоять на месте.

[Malandrinus 615]

Народ, у вас интересное обсуждение, но мне же придётся его потереть как оффтоп. Жалко ведь! Так что идите вы... в ковырялку.

[Malandrinus 615]

Real Wolf

Однако новые данные не сохраняются.

Часом не в онлайне пытался это делать?

[Malandrinus 615]

Real Wolf,

перечитываю твой предыдущий пост и никак не могу понять, что именно ты пытаешься сделать. Какие такие новые данные? Что за новый размер? Такое ощущение, что ты какой-то ересью пытаешься заниматься. Показал бы код что-ли. Только не здесь. Запости вопрос в ковырялке.

[Malandrinus 615]

Desertir,

а для чего класс то предназначен и что вообще с ним делать? Из поста совершенно не ясно.