Malandrinus

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

Комрады, вы чего взъелись? Если человек делал всё по той статье, на которую сылку привёл, то собственно нового непися он сделал с помощью acdc.

XMK, Да ладно, может он исправился =) Вот даже в нужную тему написал. Кроме координат надо ещё менять левел и гейм вертексы. Таки придётся тебе скрипт для снятия координат ставить =)

Monnoroch, А если в качестве эксперимента попробовать несколько раз увеличить на 1 процент? Может меняется, но просто округляется при выводе.

метод explode()

Там есть ещё набор этих функций, где в качестве аргумента не объект а вектор function set_sight(enum SightManager::ESightType, const vector*, number); function set_sight(enum SightManager::ESightType, const vector&, boolean); function set_sight(enum SightManager::ESightType, const vector*); SightManager::ESightType - это вероятно как смотреть, или как интерпретировать другие аргументы. это вот такое перечисление enum SightManager::ESightType { eSightTypeCurrentDirection, //0 eSightTypePathDirection, //1 eSightTypeDirection, //2 eSightTypePosition, //3 eSightTypeObject, //4 - не экспортирована eSightTypeCover, //5 eSightTypeSearch, //6 eSightTypeLookOver, //7 - не экспортирована eSightTypeCoverLookOver, //8 - не экспортирована eSightTypeFireObject, //9 - не экспортирована eSightTypeFirePosition, //10 eSightTypeDummy, }; Эти константы экспортированы через класс look. look.cur_dir -- eSightTypeCurrentDirection look.path_dir --eSightTypePathDirection look.direction --eSightTypeDirection look.point --eSightTypePosition look.danger --eSightTypeCover look.search --eSightTypeSearch look.fire_point --eSightTypeFirePosition Как видно, именованные константы заведены не для всех элементов этого перечисления. Для 4,7,8,9 именованных констант нет. Можно конечно и просто указать их как цифры при вызове функции, но что будет неизвестно.

npc:set_sight(object_he_looks_at) npc и object_he_looks_at - это game_object Я когда экспериментировал с этим методом, то находил всех сталкеров на уровне и заставлял смотреть на меня. Забавно было. Выполняешь скрипт, и все неписи как по команде плавно впериваются в тебя, а потом через несколько секунд плавно отворачиваются. Видимо текущая схема заставляет.

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

function look_pos(npc, heli) local bullet_speed = system_ini():r_float(obj2:active_item():section(),"bullet_speed") local heli_speed_vec = heli:get_helicopter():GetCurrVelocityVec() local heli_speed = heli_speed_vec:magnitude() local dist = vector():sub(heli:position(), npc:position()):magnitude() local dt = dist/bullet_speed return heli:position():mad(heli_speed_vec, dt) end Есть и более точный алгоритм, но более затратный. А зачем тебе это всё? Тоже об этом думал? =) В принципе реализуемо, парящие предметы уже есть. Вот спасибо огромное. Правда одного этого не хватило, пришлось ещё и размер его уменьшать раз в 50. После этого действительно точка получилась.

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

А если не секрет, то что вообще вычисляется? не понятно, какая функция возвращает nil? там надо сделать так: ... newpos:mad(obj:position(),obj:get_helicopter():GetCurrVelocityVec():normalize(), delda_s) return newpos end Кроме того, может сработать и другой вариант mad. который вроде как возвращает значение return obj:position():mad(obj:get_helicopter():GetCurrVelocityVec():normalize(), delda_s) Но в последнем я не уверен. Сталкера под рукой нет, проверить не могу. Gonarh, добавлю насчёт левел вертексов. Если у тебя есть номер левел вертекса, то он годится только для того уровня, на котором получен. Т.е. левел вертекс с номером например 123 может быть на любом уровне. Поэтому вопрос о получении номера или имени уровня по левел вертексу в принципе не стоит. Это всегда текущий уровень. Ну а гейм вертекс получить или перебором (что вообще-то не сложно, поскольку гейм вертексов относительно немного - единицы сотен на каждый уровень) либо как я выше предложил, с распаковкой game.graph.

Да, походу никак до этих свойств не добраться. Сейчас сам внимание обратил, что пакет всегда начинается уже с cse_alife_object. Наверное, в этом есть смысл. Там такие свойства, что менять их весьма чревато. game_point() выдаёт "глобальные" координаты, т.е. координаты точки не на уровне, а с учётом расположения уровня относительно остальных. Толку с этих координат мало, поскольку все без исключения остальные координаты - это локальные координаты внутри уровня. Если сравнивать с координатами на уровне, то надо использовать level_point. У меня такое предложение по вычислению gvid. Есть game.graph, в котором всё есть вся необходимая информация. Его можно распаковать в фармат ini/ltx файла с помощью утилитки xiani. Тогда, из игры нужную информацию можно получать с помощью класса ini_file. Для разовых действий типа спавна вполне сгодится, и главное - абсолютно надёжно. Ну если вылетит с нулевой скоростью, то плюхнется на землю прямо перед носом стреляющего =) Хотя это в реальности. В игре возможно и в самом деле начинает с нулевой. mad не возвращает значение, а меняет значение вектора, для которого вызывается. Поэтому return newpos И ещё мне думается, что вот это local a = system_ini():r_float(obj2:active_item():section(),"bullet_speed") лучше бы сделать один раз где-нибудь заранее. Очень сильно подсадит производительность

операция mad(pos, dir, dist) - это комбинация pos + dir*dist При умножении единичного вектора скорости на 5 получается вектор, длина которого 5, а направление совпадает со старым вектором скорости. Он добавляется к позиции. Это разве не то, что надо? Вот только вопрос, что будет, если скорость будет нулевая. Полагаю, это стоит проверять отдельно

вроде так, с небольшой поправкой (я там ранее сам недопонял) newpos:mad(obj:position(),obj:get_helicopter():GetCurrVelocityVec():normalize(), 5) Надо ещё было привести вектор скорости к единичному.

Не очень понятен вопрос. Есть такое значение в пакете, это вектор. При чтении из пакета читаешь: local dir = paket:r_vec3() потом при упаковке обратно записываешь, что тебе надо dir:set(<нужное мне направление>) paket:w_vec3(dir) Как-то так...

А нет там у тебя заначки с большим числом патронов? Такие фризы возникают, когда такая заначка переходит в онлайн. вроде бы так local newpos = vector() newpos:mad(pos, dir, dist) -- pos,dir - векторы, dist - может быть число и вектор, в данном случае число

А если так? device().cam_dir

Попробовал поубивать неписей kill-ом. Ствол улетает по любому. Не помню уже где это было, но просто врезался в зрительную память момент, когда непись от выстрела ГГ улетел, а на его месте возник ствол, причём выше, чем его непись держал и при этом перпендикулярно взгляду ГГ (а до этого был направлен на него, т.е. был параллелен взгляду). ЗЫ Я окончательно запутался, договорились мы или нет. Впрочем, не так уж это и важно. ragdoll физика в сталкере не настолько проработана. Кое-какой реализм обеспечивает и ладно. Стоит ли ломать копья на эту тему?

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

Я добавил level_changer, доспавнил его функцией create(<номер>) и ничего мне за это не было =) Если кому это надо, то добавлю вот что. Я делал тестовый объект на кордоне, и сначала попробовал добавить секцию в файл для кордона. Выяснил, сколько всего объектов, сделал секцию с номером, на один большим... У меня заспавнился не тот. Начал выяснять, откуда он взялся, и понял, что это последний объект из последнего уровня (ящик какой-то). Тогда я просто добавил новый объект в конец последнего уровня, и все получилось. Мораль, номер объекта из all.spawn - это просто его номер в порядке компиляции. Зачем acdc разбирает объекты по уровням, не знаю. Но на мой взгляд, после этого они перетасованы. Если каждый раз начинать игру заново, то это и без разницы. Но если мы хотим использовать пересобранный all.spawn не начиная игру заново, то видимо acdc не годится.

когда смотришь на объект, то на нём подсвечивается его имя.

Monnoroch, а объект подсвечивается, как оружие, или нет?

Monnoroch, смысл моих слов был "невозможно оставить оружие в руках неписей при том, что его там и не было" В чём я не прав?

Несколько уточнений: Файл all.spawn можно дописывать, добавляя туда дополнительные точки переходов. Вопреки распространённому мнению, новую игру при этом начинать не надо. Вроде как это метод, обратный name. Т.е. по имени точки возвращает её номер. Это такие же конструкторы, как и patrol с одним только именем пути. Просто у них ещё есть дополнительные аргументы. И, как мне думается, за само движение отвечает класс entity_action, которому передаётся объект класса move, у которого patrol - это аргумент. Короче, копать и копать ещё, но начало неплохое. Там глядишь, и разберёмся, как свои скриптовые схемы ваять.

Если честно, не понял, что именно из сказанного мной неправда.