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.

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

Ради интереса, посмотрел. Нет, с текущими правками XE реально новые кнопки в меню не добавить, можно лишь подвязаться на уже созданные bind-ы. Нечто подобное сделали в OGSE, добавив консольные команды "ogse_", в которых записан номер клавиши из таблицы DIK_keys. Далее в скрипте ogse_rebind_key.script они туда-сюда их перебиндивают в зависимости от ситуации. Другое дело, а зачем все эти сложности, когда у нас есть целая куча bind-ов мультиплеера, на которые в сингле можно повесить что-угодно и назначать клавиши из меню. Можно же прописать в настройках нечто подобное: <command id="kb_use_vodka" exe="vote"/> и проверять в скрипте dik == bind_to_dik(key_bindings.kVOTE) использование условной "водки" по аналогии с аптечками и бинтами.

Возможно, когда предметов больше одного, по одним и тем же координатам их оказывается несколько, и при удалении первого гарантированно есть еще второй. В общем случае, по идее в одной ячейке может быть только один предмет. А когда у нас предмет 0х0, то их может быть бесконечно много, что уже выглядит как косяк с точки зрения системы. Почему тогда в ТЧ это работает?.. Нужно смотреть все цепочки вызовов, что откуда вызывается, в том числе GetItemPos.

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

Спустя 12 лет тема вновь открыта. Не вдаваясь в причины закрытия, можно сказать, что они давно неактуальны, да и люди, которые этому способствовали уже ушли с форума. Нет, разработка мода не возобновлена. 1.3.5 стала последней версией, в которой было сделано все, что тогда планировалось. Цель открытия темы - обновить ее до актуального состояния на момент выхода последней версии. Так как эта тема является по сути истоком появления DMX MOD (в отличии от других ресурсов, где все эти годы был представлен мод), то она имеет определенную историческую, если так можно сказать, ценность. И поэтому оставлять ее в полузаброшенном состоянии было бы неправильным. Теперь немного хронологии и статистики: 26.06.2011 - релиз версии 1.3.4 15.07.2011 - закрытие темы 08.06.2012 - релиз версии 1.3.5 на всех площадках кроме АМК 04.09.2012 - релиз обновленной версии 1.3.5 на "сталкерском" торренте - из основных изменений: реализация смены предметов в слотах на манер ЗП, инсталлятор, исправление ошибок (подробно об изменениях) 10.10.2012 - переезд на более стабильный RuTracker (раздается по сей день), добавлена правка вылета "global_wnd" 10.09.2021 - внесены правки в интерфейс нового раздела КПК "Функции" и несколько других исправлений (подробно об изменениях) 28.09.2021 - обновлена раздача, инсталлятор и readme-файлы, добавлен постер мода С момента выхода версии 1.3.5 в 2012 году, торрент с модом был скачен более 20.000 раз. Параллельно с DMX MOD в те годы разрабатывался также Shadows Addon - мод совершенно другой, "билдоориентированной" направленности, который, к слову совсем недавно также получил обновление Скриншот из Shadows Addon В свою очередь, из Shadows Addon в отдельный мод отделился, пока еще не вышедший Phantoms Zone, но это уже совсем другая история P.S. Пользуясь случаем, хотелось бы спросить - возможно у кого-то из старожил осталась версия DMX MOD под номером 1.1? Собираю архив версий, есть все кроме этой. Был бы очень благодарен.

Там на самом деле все просто - есть блоки условия { ... }, есть блоки действия % ... %. В них участвуют инфопоршены и вызовы lua-функций. В остальных случаях переходы между секциями схем. Основные события перечислены в xr_logic.script, по типу on_actor_inside, другие параметры может добавлять каждая отдельная схема. Событие on_info по сути является апдейтом в скрипте, поэтому в нем можно проверять вообще что угодно, хотя название может вводить в заблуждение, я сперва думал что оно обрабатывается только при получении объектом/актором инфопоршена. Чтобы выключить логику для объекта, достаточно перейти в секцию nil, при этом саму секцию указывать не нужно, система поймет. Есть еще всякие нюансы, типа передачи параметров в функции при помощи разделителя ":", передачи параметров в схему перед разделителем "|", но это уже дебри и разбираются в каждой конкретной схеме по мере надобности.

on_actor_inside = {+esc_novice_ex4r_sr} sr_cutscene %+kura2% "Если актор внутри зоны и если получено инфо esc_novice_ex4r_sr, то переходим в секцию логики sr_cutscene и выдаем инфо kura2". Изучи синтаксис логики.

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

А почему бы не сделать итерацию по всем скриптам и не присоединять автоматически те, у которых есть функция-маркер - init (или лучше другое уникальное название, чтобы не пересекалось с ванилью)? Ведь прописывание чего-то куда-либо это всегда узкое место, постоянно забываешь прописать, потом убрать, да и немного ломает совместимость между обновлениями или аддонами, а это как я понимаю одна из основных идей подобным систем.

Если не сработал оригинальный облет камеры при эквивалентной логике, значит что-то сломано в скриптах. Сбегай на Агропром, проверь как там работает, чтобы уже точно знать. А вообще, смотри схему sr_cutscene.script. Для ее работы все рестрикторы с логикой должны быть зарегистрированы в таблице, после чего они обновляются из биндера актора. Возможно в bind_stalker.script выпилен вызов bind_restrictor.actor_update(delta), не знаю, тут гадание на кофейной гуще.