Malandrinus

Vergas, Это про объектную модель сталкера речь? Это и в самом деле полное убожище. Один только game_object чего стоит. Проблема на проблеме и многие гораздо глубже, нежели просто корявый дизайн объектов. Взять хотя бы вот это разделение на серверные и клиентские объекты. Это лишь верхушка айсберга - следствие крайне неудачного решения делать игру на базе сетевого движка. Впрочем, что толку об этом сейчас говорить?

Vergas, объект не клиентский, а серверный

Новая версия системного плагина для Total Commander-а для распаковки игровых архивов. Прошу любить и жаловать =) Версия 0.0.2 Новое: 1. Видит установку "Зова Припяти" 2. Теперь можно искать файлы, используя встроенный поиск TC (ранее по определённым причинам не работал) 3. Можно посмотреть свойства файла и узнать в каких архивах он содержится в порядке убывания приоритета 4. Все файлы в архиве имеют время, которое равно времени файла-источника Напоминаю, что этот плагин предпочтительней для работы со всем деревом файлов целиком нежели архиваторный, поскольку автоматически учитываются приоритеты архивов. Для работы с отдельными *.db* архивами (в том числе не связанными ни с какой установленной игрой) по прежнему можно использовать архиваторный плагин. Поскольку формат файлов в ЗП по сравнению с ЧН не изменился, то его я не обновлял.

Мой вопрос в сущности примитивнее. Я здесь не пытаюсь сделать какой-либо мод или вообще решить какую-либо практическую задачу. Я хочу разобраться с API игры. Хочу понять, как работают классы "в чистом виде". На данный момент по этому вопросу я всё больше убеждаюсь в том, что механизм управления неписями через метод command и прилагающиеся к нему классы в текущей версии игры просто не задействован. Это немного жаль, поскольку он единственный хоть как-то документирован в доках от билда 1935. Отключён ли этот механизм совершенно наглухо или просто требует каких-то специальных действий по включению - мне неведомо. В буквально нескольких найденных внятных примерах использования упоминаются ещё вызовы метода script, в который передаётся имя файла с чем-то вроде скриптовой схемы. Это именно в этих скриптах встречаются функции main. В релизе от этого и вовсе почти ничего не осталось, а в 1935 ещё таких много, но и там они походу уже не используются. Ещё возможно, что этот механизм (через command) использовался совместно с классом FSM (Finite State Machine), который в релизе остался, но опять же никак не задействован. Сейчас управление персонажами осуществляется через планировщик на основе GOAP (Goal-Oriented Action Planning), и возможно тот старый механизм управления не подходил для этого. Короче, надо использовать отдельные методы, о которых я говорил: set_item, set_sight, set_patrol_path, set_desired_position, set_desired_direction, set_dest_level_vertex_id, set_detail_path_type, set_movement_type, set_path_type, clear_animations, add_animation, play_sound, add_sound, set_mental_state, set_body_state и другие в этом роде. Как я выяснил, на них в общем неписи реагируют. Да, текущая схема их перебивает, но хоть какая-то реакция есть. С документированием этих методов дело обстоит похуже, хотя можно ориентироваться на всё тот-же документ из 1935. Аргументы для создания тех неиспользуемых классов во многом такие же, как и аргументы используемых методов. В общем-то можно всё это расписать, но на эксперименты у меня сейчас времени нет.

DEL Поскольку логика - это механизм достаточно всокоуровневый, то это мне мало что объясняет. Меня интересует, что именно с точки зрения базовых вызовов не даёт им выполнять команды. Ведь что такое логика? Есть эвалуатор (условие) и экшин (действие) для него, так? Условие срабатывает и выполняется его действие. Внутри действия мы и прописываем те элементарные команды, которые заставляют непися бегать, стрелять, кричать и пр. Я посмотрел примеры экшинов и как-то не нашёл специальных действий, которые блокируют выполнение команд, а потом разрешают. Единственно, все реальные действия закопаны глубоко внутри state_mgr. Однако так и не понятно, что же мешает выполнить свои команды со стороны. Опять же я исследовал очередь команд. Она не движется вообще. У меня появляется подозрение, что этот механизм просто не задействован. Я ведь писал, что там есть с одной стороны метод command и прилагающиеся к нему классы, а с другой стороны есть отдельные методы для отдельных частей состояния. Я сейчас пытаюсь найти концы и не могу найти, а где вообще применяется метод command. Зато нахожу применение тех методов из альтернативного набора. DEL

Пытаюсь разобраться со скриптовым управлением сталкерами. Для этого есть набор классов: anim - хранит параметры анимации look - параметры направления и способа "глядения" move - параметры пути перемещения object - параметры объекта, который держит в руках сталкер и что с ним делаем particle - партиклы sound - озвучка act - команды для монстров cond - условия окончания действия все эти объекты объединяются в одну, с помощью класса entity_action. Получается полное описание состояния: идёт туда-то, смотрит туда-то и так-то, держит в руках ствол и стреляет из него, отыгрываются партиклы и что-то там ещё звучит при этом. Затем полученный объект типа entity_action указывается в методе command класса game_object. При этом команда ставится в очередь. Размер очереди можно посмотреть методом action_count, а обнулить очередь можно методом reset_action_queue. По моему разумению действия в очереди должны выполняться последовательно. Есть ещё методы класса game_object, которые вроде как позволяют по отдельности менять все эти части состояния: set_item - для установки предмета set_sight - куда смотрим set_patrol_path - путь add_animation - анимация play_sound, add_sound - звук партиклы можно проигрывать отдельным объектом. Вроде как всё понятно. Создаются объекты, вылетов нет (значит находит звуки, пути и анимацию). Устанавливаю действия, очередь растёт, можно очистить. Всё работает. Вот только неписи ноль внимания на все эти действия =) Я так понимаю, их что-то держит. Знает, кто-нибудь в чём здесь дело?

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

Мне почему-то всегда казалось, что тот, кто учится, должен тратить больше времени, чем тот, кто учит. Тем не менее, периодически возникают люди, которые более или менее настойчиво (а иногда даже в ультимативной форме) желают в качестве помощи непременно готовый код. И искренне недоумевают при этом, ну почему никто не хочет им помогать =)

Этого никто и не говорит. Просто к примеру, вот ты задал вопрос "как поставить метку". Тебе дали функцию. Ты тут же спрашиваешь "а как убрать?". Между тем, ответ на второй вопрос нетрудно найти самому. В примере от Gonarh есть использование вот такой функции: level.map_add_object_spot() Тебе дали наводку, так попробуй её использовать: смотришь в lua_help.script, там рядом в том же списке есть и функция map_remove_object_spot. Это хорошо, для этого даже есть уже специальные темы. Так что welcome!

Попробуем приступить к game_object. Это класс для доступа к онлайновым (клиентским) объектам. Причём один класс является интерфейсом для совершенно разных объектов. Разработчики не придумали ничего лучше, как взять и объединить в одном классе все интерфейсы всех клиентских объектов: актора, сталкеров, монстров, физических объектов, автомобилей и лампочек, вообще всех. Более странного и вообще говоря уродливого объектно-ориентированного дизайна я ещё не видел. Во-первых, класс вышел совершенно необозримым - три сотни методов! Во-вторых, вызов не подходящего метода для произвольно взятого объекта приводит к совершенно непредсказуемым результатам. В лучшем случае не будет ничего, а чаще всего - будет вылет, причём обычно без лога. Наконец, описание этого класса в lua_help совершенно невнятное (как впрочем и всех остальных классов): типы возвращаемых значений опущены, типы входных аргументов указаны не всегда, а о назначении большинства методов можно только гадать. Предлагаю несколько более внятное описание. Источником информации служил в первую очередь документ из билда 1935, где описаны (весьма лаконично) многие методы этого класса. Во вторую очередь использована отладочная информация из мультиплеерных билдов, что позволило довольно точно восстановить типы аргументов и возвращаемых значений. Для некоторых функций имеются описания, полученные либо мной лично либо подсмотренные на форумах. Так что предлагаю рассматривать всё это как плод коллективного творчества. Пара замечаний: 1. Информация по-любому неполная. Многие (скорее даже большинство) методы не описаны, хотя типы аргументов и возвращаемых значений имеются полностью. 2. Вследствие большого объёма причёсывать сил не осталось, так что выкладываю как есть. В некоторых местах осталась информация стороннего характера - сравнение с ранними билдами, внутренние названия функций и некоторые мои собственные домыслы. 3. Я перетасовал список методов с целью их осмысленной группировки "по родству". Очевидно, что мог и заблуждаться насчёт "родства" методов, так что смотрите в оба. 4. Поскольку описание не закончено, то предлагаю всем поучаствовать в завершении этого этапа.

Уж такие то вещи надо самостоятельно находить. Переводишь на английский слово "деньги", смотришь в lua_help.script... Неужели так сложно?

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

Статья здесь, но она тебе не поможет. В самом Lua есть средства для исследования стека. Расположены они в пространстве имён debug, но в ТЧ не экспортированы =( Так что отлаживаем дедовскими способами, ручками заводим служебные переменные и ручками же их меняем при каждом вызове.

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

Вот такой биндер (файл bind_ammo.script): function init(obj) local new_binder = ammo_binder(obj) obj:bind_object(new_binder) end class "ammo_binder" (object_binder) function ammo_binder:__init(obj) super(obj) end function ammo_binder:net_spawn(data) get_console():execute("ammo_binder:net_spawn") if not object_binder.net_spawn(self, data) then return false end return true end function ammo_binder:net_destroy() get_console():execute("ammo_binder:net_destroy") object_binder.net_destroy(self) end например для патронов от обреза прописываем в секцию ammo_12x70_buck в файле config\weapons\weapons.ltx строку script_binding = bind_ammo.init Смотрим, что получилось: При заряжании обреза нового объекта не возникает (нет события net_spawn). Если пачка заканчивается, то она исчезает (идёт событие net_destroy). Когда разряжаем, то если можно добавить патроны в существующую пачку, то нового объекта не возникает. Если нельзя (например таких патронов в инвентаре нет), то возникает новый объект. Удаления вообще нет, что означает, что объекта, соответствующего патронам в стволе, и не было вовсе.

Monnoroch, В сомнение ты меня ввёл... не знаю =) Сейчас проверить не могу, но это несложно сделать. Прицепи биндер к патронам и проверь, появляется ли новая пачка при заряжании пустого ствола. Скорее всего не появится.

Monnoroch, Вроде как патроны в стволе - это не объект, а просто характеристика ствола. Нет там пачки вообще.

В моей подписи программа "Редактор иконок инвентаря "

Monnoroch, попробуй исследовать ситуацию примерно так. local con = get_console() if state_lib then con:execute(type(state_lib)) if state_lib.states then con:execute(type(state_lib.states)) if state_lib.states[state_name] then con:execute(type(state_lib.states[state_name])) if state_lib.states[state_name].movement then con:execute(type(state_lib.states[state_name].movement)) end end end end это странно, но я не могу найти ни одного скрипта, где бы создавалась переменная state_lib. Ни в АМК, ни в оригинале. Судя по всему, это глобальная таблица, но в _g.script такой нет. Кто её создаёт, неясно. Сам движок создаёт? Странно это всё. Добавлено через 2 мин.: Блин, вот я тупой. Это ж не таблица, а скрипт. Добавлено через 10 мин.: тогда остаётся только один вариант - state_name не соответствует ни одному из тех значений, что прописаны в скрипте state_lib. его и надо проверять

Это единственный способ. И чем он тебе не угодил?

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

Kolmogor, В этом случае вроде бы другая ошибка, что-то вроде "attempt to index global 'sobj' (a nil value)" Может, sobj как-то получился не серверным объектом? Monnoroch, что выдаёт type(sobj)?

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

Monnoroch, Ну не знаю... А локация пути и непися совпадают?