RayTwitty

Прикольная вещь. В Anomaly есть подобный функционал, может понравятся какие-то идеи для реализации. Нечто подобное и у меня есть, но оно как и в случае с Anomaly прибито гвоздями к движку https://disk.yandex.ru/i/wV90IqHxeH_H8Q

@Colder function read_list(section, ini) if not ini then ini = system_ini() end local t = {} for i = 0, ini:line_count(section) - 1 do local result, id, value = ini:r_line(section, i, "", "") if result then t[id] = value end end return t end local t = read_list("item", ini_file("items\\settings\\txr_list.ltx")) ключи таблицы - твои предметы

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

Понадобилось тут разобраться с поворотом объектов. Оказывается есть целых 3 ключевых понятия: direction, angle и rotation. С последними двумя все просто, углы поворота над плоскостью, первый в радианах, второй в градусах (именно это значение мы видим в SDK). А вот первое - это направление в диапазоне от -1 до 1. Набросал функции получения direction имея angle/rotation, которые должны работать по идее даже в оригинале (где имеется полурабочий класс матрицы, но его достаточно): function angle_to_direction(angle) local m = matrix() m:setXYZ(angle.x, angle.y, angle.z) return m.k end function rotation_to_direction(angle) local m = matrix() m:setXYZ(utils.deg2rad(angle.x), utils.deg2rad(angle.y), utils.deg2rad(angle.z)) return m.k end А вот чтобы обратно получить angle/rotation имея direction, нужно, как я понял получить доступ к матрице трансформации объекта (XFORM), применив к нему getXYZ (ну или getHPB). Прав ли я в рассуждениях и что такое на самом деле direction? Направление относительно чего? P.S. Частично угол поворота можно восстановить при помощи методов вектора getH и getP, но только yaw и pitch.

Разве что спавнить с каким-то интервалом по времени невидимый батон и съедать его по-тихому. P.S. Только сейчас заметил пост выше))

@wdfgosdgf https://xray-engine.org/index.php?title=Класс_sound_object Автоматическое изменение позиции звука не реализовано, нужно делать ручками. В твоем случае надо подвязаться на апдейт биндера вороны и обновлять позицию звука через метод set_position. Разумеется, для каждой вороны свой экземпляр звукового объекта, ссылка на который сохраняется в биндере.

Плавно статик не убрать этой функцией. Обычно такое пишется отдельно, когда на апдейте меняется альфа канал. Но если не хочется писать много когда, можно попробовать создать статик с "fade out" анимацией, в конце которой он будет удален. Атрибут ttl задает время в секундах, через которое статик будет удален. По идее он должен быть равен длине анимации. <hud_curse_1_end x="0" y="0" width="1024" height="1024" complex_mode="1" light_anim="FADE_OUT" la_alpha="1" la_text="1" la_cyclic="0" ttl="5"> <texture>ui\ui_curse_1</texture> </hud_curse_1_end> В момент, когда нужно "плавно" убрать статик, сначала удаляем постоянный. get_hud():RemoveCustomStatic("hud_curse_1") get_hud():AddCustomStatic("hud_curse_1_end", true) Возможно правда в момент подмены он на один кадр пропадет, не знаю. Но малой кровью только так.

Пример тут в двух словах не получится привести. Могу как вариант посоветовать посмотреть Shadows Addon, там есть биндер автомобилей (sa_cars.script) и сохранение/загрузка топлива (se_car.script). Но если у тебя кастомный движок типа OGSR, то нафиг это все надо - сделай себе форк и добавь необходимые параметры прямо в движок.

Состояние предмета и патроны меняются в процессе эксплуатации, поэтому они изначально сохранялись. Все остальное нет смысла сохранять, потому что оно не меняется и просто читается каждый раз из конфига. Соответственно, если нужно сохранять новые данные, то это нужно писать отдельно либо в движке, либо в скриптах. В скриптах это достаточно хлопотно, слишком много телодвижений - под каждый класс свой биндер и тоже самое в se_ скриптах. Нет, экземпляр биндера создается для каждого объекта отдельно, в том и смысл))) Биндер физ. объектов я привел в пример как тот, который можно взять за основу. По-нормальному конечно, для артов нужен свой биндер, для оружия свой и т.д. У всех объектов же разные параметры.

Нужно создать биндер для оружия (по аналогии с физ. объектами например), подключить его в базовой секции в конфигах (если есть, иначе во всех секциях по отдельности), получать на net_spawn серверный объект и смотреть, сохранена ли там стоимость. Если да, то менять (восстанавливать) ее твоим способом через свойство cost для клиентского объекта. Соответственно при первом изменении свойства, менять также значение и в серверном объекте по аналогии. Серверный объект это "слепок" клиентского/онлайного, в котором сохраняются данные. Тебе надо следить за тем, чтобы данные были одинаковы. Проще по-моему двиг поправить, добавив там в общую кучу сохранение cost))

В нем есть свойство alcohol, там все проще. В АМК скорее всего считали сколько раз выпили водку (использовали предмет) и параллельно рассчитывали опьянение на апдейте, повторяя то, что делает движок внутри. Ну я бы так наверно сделал, если нет возможности движок поправить.

Просто факт опьянения или степень опьянения? Если первое - можно попробовать отследить наличие эффектора. Если второе, то тут сложнее и костыли. Вроде в АМК моде была алкогольная зависимость, можно посмотреть как там сделали. P.S. А, на чистом движке эффектор тоже не получить никак, так что только костыли выдумывать. @666Ian значение надо сохранить в серверном объекте в se_item.script, найдя нужный тебе класс оружия. После чего загрузить и выставить это значение при входе оружия в онлайн (на net_spawn или на первом апдейте).

https://github.com/alex-narrator/xp-dev_xray/commit/97a51a06f90739270cc7db4114e1afbc30ecbb32#diff-6274cd9e797038834b6fd70946f7e52f049327e19f10df236496235958590739 По-моему вот. По ссылке должен открываться конкретный участок кода, но у меня не работает почему-то (индусы похоже опять поломали якори). Если что, файл xray/xr_3da/xrRender_R2/r2_rendertarget_phase_scene.cpp. Дефайны для шейдеров чуть выше в xray/xr_3da/xrRender_R2/r2.cpp - поиском по странице "USE_SOFT_WATER". Правда саншафтов там нет, но делается по аналогии с токеном на выбор качества. P.S. Вроде для некоторых реализаций саншафтов надо еще экзешник править, чтобы менять интенсивность через консоль. Должно быть в каком-нибудь OGSR-движке и аналогах. Или можно забить и в шейдере константу бахнуть.

Значит никому кроме тебя она была не нужна. Да и за 8 лет как лежат исходники в сети, уже можно не то что перенести что-угодно, но и самому написать что-угодно. Например визуальный апгрейд оружия на 3D модели как в Escape From Tarkov.

А с чего ты взял, что она мне нужна была? Мне в свое время хватило собственной скриптовой "аля ЗП". И в данном случае брешишь ты, на ТЧ апгрейды перетаскивали как минимум в LA DC.