[SoC] Ковыряемся в файлах

[Malandrinus 615]

Monnoroch,

ну хорошо, не в большинстве случаев, а иногда (предыдущий пост поправил). Вроде бы nil в с точки зрения Lua должен быть не значением, а его отсутствием. Поэтому вызов функции fun(nil) вроде как эквивалентен вызову fun(), но так ли происходит всегда, я не знаю.

Но такие случаи я точно встречал. К примеру вызов level.object_by_id(nil), как и без аргумента возвращает объект с нулевым идентификатором, т.е. актора.

А вызов alife():object(nil) приводит к вылету. А вызов db.actor:object(nil), который вроде как должен вернуть объект по индексу, возвращает вместо этого число 0.

В итоге, ситуация еще хуже, поскольку реакция функций игры на вызов без аргумента (или с nil) попросту непредсказуемая.

Так что мой предыдущий спич полностью остаётся в силе =)

[Malandrinus 615]

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

По мне так достаточно знать имя уровня+координаты,чтобы однозначно определить точку спавна.

Другое название этой сетки - сетка навигации. Ещё название - AI-сетка, что по сути одно и тоже, поскольку весь AI так или иначе связан с перемещениями.

Проще всего понять, на что похожа сетка уровня (граф навигации уровня), если эту сетку как-то визуализировать. Есть для этого тулза, созданная IG-2007.

Но я попробую словами...

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

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

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

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

 

Глобальный или оффлайновый граф, как ясно из его названия, нужен для навигации в оффлайне. Он уже больше похож на граф. На уровень таких узлов может быть что-то около пары сотен. Навигация в оффлайне в том числе допускает и перемещение между уровнями. Непись, которому сказали идти на узел глобального графа, находящийся на другом уровне, сначала строит свой путь по локальной сетке уровня до подходящего геймвертекса, дойдя до него - переходит в оффлайн и дальше уже перемещается по глобальному графу на нужный уровень.

 

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

 

[Malandrinus 615]

artefact_position_offset = .. смещение относительно центра аномалии, на котором будут спавница арты

в acdc есть целая секция на предмет координат создаваемых артов. Точки из этой секции вообще где-то используются?

[Malandrinus 615]

n6260,

такая утилита для перехвата нажатий есть и очень давно. Сделана неким заграничным камрадом. Найти у себя не смог =(

[Malandrinus 615]

Monnoroch,

нет, там принцип такой, что ловились нажатия клавиш в системе вообще и писались в некий *.ltx . А оттуда по апдейту актора ловились в скриптах. Вот только не могу у себя найти эту утилитку. Давно было.

[Malandrinus 615]

Starter,

по изменению fov ловишь момент прицеливания и дальше рисуешь на худе нужные бантики.

 

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

 

Ray,

что ты имеешь в виду под "базовыми скриптами"?

Изменено 18 Января 2010 пользователем malandrinus

[Malandrinus 615]

те, которые они сами написали и повесили на эти кнопки

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

Что касается ПНВ, то я сам не знаю, как именно это отловить. Функции с vision как правило относятся к управлению зрением неписей. Вообще для управления актором функций довольно мало. В принципе это понять можно, актор же управляется непосредственно игроком, а не скриптами. Кроме того, прослеживается принцип минимализма. Разработчики экспортировали только то, что нужно было им.

[Malandrinus 615]

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

[Malandrinus 615]

где на АМК тема с компасом

Не это случайно?

 

[Malandrinus 615]

Hagard, Ray,

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

[Malandrinus 615]

у меня в таблицу как значения строковых индексов пишутся тексты - каждый в среднем по 250 символов.

Ой смотри, весь нетпакет - 8 кб. А в акторовском ещё всего до фига. Какую-то сомнительную идею ты пытаешься реализовать.

 

Всю таблицу надо сохранить и все тексты записать в нет-пакет - если каждый текст сохранять в отдельный пакет то он запишется?

Данные не в нетпакете хранятся, а в объекте.

 

и кто-нить может дать пример функций сохранения и загрузки трехуровневых таблиц?

Какая разница, два уровня или десять? Главное, читать в том же порядке, что и записывал. Перед записью переменного числа элементов записываешь их количество. Вот и все секреты.

 

А можно делать сохранение и загрузку не в биндере эктора, а в своем биндере?

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

Хм. Дарю идею. Сам как-то хотел сделать, но руки не доходят. Можно завести специальных объектов, которые никак в игре не участвуют, а используются только для хранения данных. Такие можно сделать на связке cse_alife_object - CGameObject. А может это был cse_alife_dynamic_object, не помню точно какой объект был минимально создаваемым. Запретить переход в онлайн, по созданию объект регистрировать, при недостаче места создавать новый, наращивая таким образом объём хранимых данных.

Будет отличная альтернатива пстору актора.

 

[Malandrinus 615]

Garry_Galler,

я имел в виду сомнительность с технической точки зрения =) Что-то явно не так, если каждая строка занимает по четверть килобайта. Даже теоретически их можно в этом случае записать всего около 30-и. Может записывать не в виде строк, а виде бинарных данных? Может что-то можно не записывать, а хранить постоянно в конфигах? Например часто можно вместо строк записывать их номера. А многие данные можно получить на ходу из других. Например по id объекта можно получить его имя, описание и пр. Значит всё это можно не хранить, а сохранить только id (два байта).

 

[Malandrinus 615]

Garry_Galler,

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

Мне просто интересно, что же там такое сохраняется такого размера. Не мог бы привести пример одного твоего сохраняемого сообщения?

[Malandrinus 615]

Garry_Galler,

уф... ну давай поговорим о базовых понятиях ООП.

 

То, что написано в файле биндера и то, что указывается в секции - это класс. Класс - это не объект, это описание объекта, тип, если угодно (хотя здесь это не совсем тип). Когда создаётся онлайновый объект, то создаётся объект класса. И к онлайновому объекту прицеплен именно объект. Потому кстати и биндер (binder), что от слова bind (привязывать, присоединять). Ещё раз: у каждого клиентского объекта свой объект биндера, даже если эти объекты одного класса.

С точки зрения синтаксиса дилемма "один класс / много объектов" решается просто. У каждого метода есть скрытый первый аргумент self, в котором методу передаётся ссылка на конкретный объект. Таким образом один и тот-же метод может обслуживать множество объектов. Это достаточно типичный подход, используемый в большинстве современных языков.

Таким образом self - это всегда текущий объект биндера. self.object - это соответственно клиентский объект, к которому этот биндер прицеплен.

 

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

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

 

По поводу стиля сохранения. Таки желательно придерживаться верной стратегии:

1. Сохранять минимум информации

2. Сохранять там, где надо.

По первому пункту самая общая рекомендация - избегайте избыточности. Если конкретнее:

- если есть строка, выбираемая из заранее известного набора, то лучше сохранять её номер, а не целиком строку

- если можно что-то вычислить на основе другого, то лучше вычислить

- для логических переменных можно использовать двоичные флажки

Отдельного разговора заслуживают строки. Вообще нужда сохранять именно строки возникает не так уж часто. Между тем, как я заметил, народ почему-то весьма злоупотребляет строками. Как-то видел сохранение массива с переводом его в строку вида "a,b,c,d", сохранением в виде строки, а при чтении элементы распарсивались обратно. Ужас! Нет как правило никакой необходимости сохранять не строковые данные в виде текста. Они при этом занимают больше места и тратится существенно больше времени. Особенно при чтении как в случае с массивом выше, где фактически использовались регулярные выражения (!). Дополнительная неприятность - что место под хранение нужно заранее непредсказуемого размера, что делает невозможным предварительную оценку свободного места в буфере.

 

Насчёт второго пункта соображения простые. Если данные относятся к конкретному объекту, то в нём и надо сохранять ("в его биндере"). Точнее здесь не скажешь. В конкретном случае надо включать мозг и думать, где и как сохранить.

 

[Malandrinus 615]

дайте полный список гейм\левел вертексов всех уровней

Про список геймвертексов я здесь писал. Или, как верно говорят, используй ggtool.pl. Левелвертексы можно для текущего уровня перебрать с помошью функции level.vertex_position(i). только так не узнать, сколько их, и это только для текущего. Можно пробежаться по уровням и перебирать до вылета.

Если совсем сильно надо, то смотрим исходники Бардака, и разбираем ручками файл level.ai нужного уровня.

Только в самом деле зачем нужен список из миллионов левелвертексов? Кроме того, от мода к моду списки гейм и левел вертексов меняются.

 

P.S.: Комрады, а зацените, какая нынче мОлодежь пошла. Не как узнать, не какой функцией, не где посмотреть... Дай ему, вынь да положь =)

 

[Malandrinus 615]

Типс срабатывает да только дважды - два идентичных сообщения.

Все это "висит" на апдейте...

Интересно, почему так? Реально выдаётся при следующем апдейте?

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

[Malandrinus 615]

вот как мне отформатировать строку

Было бы там чего изучать, особенно для вывода строк.

text = string.format("%s %s %s %s %s.%s.", obj_name, verb, adjective, substantive, str, habar)

 

Вылетает на охранении 50-го мессиджа

Не могу понять почему меня не срабатывает проверка

Стоит проверка на запас в 180 байт. Потом пишутся все данные функцией taynik_rnd.message_save. Ты бы привёл её код, а то так не понять. Что за число 180? Какое отношение имеет к записываемым данным? Где твои 45-50 сообщений?

[Malandrinus 615]

Garry_Galler,

Но сейчас понял что это как то не то -- надо получать точный размер того что придется записать

Правильно. Ещё вариант, проверять оставшееся место перед каждым оператором записи.

 

вопрос не по теме - как подключать в SCITE библиотеку классов?
вроде require (classlib") - только куда это вписать и надо ли модуль создавать...и саму библиотечку куда лучше положить.

Вписать в начале головного модуля. Библиотеку клади рядом с выполняемым файлом. А что за классы? Luabind же в SCITE недоступен.

[Malandrinus 615]

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

Приведи ссылку плиз.

 

[Malandrinus 615]

и вообще зачем тут return?

Зачем здесь функция вообще? release либо удалит либо вылетит, так что что-то там возвращать смысла нет.

 

В С++ даже есть специальная функция strcmp для сравнения именно строк, а не их адресов.

Здесь более уместны аналогии с STL. Там строки - это объекты класса и сравниваются по содержимому.