RayTwitty

Прям сильно внимательно не слежу, но разве там "вкусовщина" не вырубается либо на этапе препроцессора дефайнами либо в геймдате через конфиг? В секции features или установкой значений по умолчанию по принципу "параметр не прописан - фича не работает".

Так изначально и ХЕ затачивался под этот самый OGSE, тем более что Malandrinus и K.D. оба были в команде OGSE)) И только после того, как в проект начали входить другие люди, в том числе и я, Malandrinus добавил препроцессор для конфигурирования сборок. А я уже настроил сами правки так, что скачав сейчас последнюю версию, мы получаем максимально дефолтную сборку (насколько это возможно) без разных специфических штук, которые работают только на OGSE или где-то еще. Я еще помню, как меня в личке даже обвиняли в ломании обратной совместимости, типа моя деятельность по "унификации" плохо отражается на OGSE-разработке Хотя как показало время, моя тактика была верной, а препроцессор закрыл вопросы с конфигурацией. P.S. Впрочем, я не припомню, чтобы OGSE или правки движка, которые в нем используются были шибко конфигурируемы. Тут уже выше заметили, что статику там вырезали еще до появления исходников) Достаточно бескомпромиссное решение, хотя это был вроде только 2014 год или где-то так.

По-моему изначальная задумка проекта была в том, чтобы перевести один конкретный проект, а именно OGSE/R на исходники вместо движковых правок xray-extensions)) Название движка как бы намекает. А то что со временем он стал конструктором "настрой движок сам" это уже отхождение от изначальной концепции. И то, что они стали еще сильнее отходить уже мало на что влияет. В идеале надо было останавливаться 5 лет назад после переноса последней штуковины из xray-extensions, делать форк и двигаться дальше по принципу "я художник, я так вижу".

Там кстати выше есть мой коммент по поводу вырезания статики) Если кратко - ее очень сложно поддерживать левел дизайнеру, так как процесс настройки освещения там никакой. Плюс у статики как рендера есть целая куча проблем и недоделок еще с оригинала - кривое освещение дин. объектов, воллмарков, травы, воды, тумана и прочее такое. По сути нормально освещается только статическая геометрия статическим же освещением, и то не всегда - тому пример синие кусты на билдолоках. Про кривизну дин. освещения на первом рендере я вообще молчу. Очень много проблем, которые тормозят разработку локаций. Про внутридвижковые проблемы уже сказали в посте на ап про по твоей ссылке. Оставлять первый рендер в 24 году рекомендуется только тем, кто пилит какие-то билдомоды или использует билдовские локации и хочет типа сохранить шарм статики (и при этом знает как со всем этим работать). Во всех остальных случаях - вырезать под корень. Не вижу ничего сложного - git позволяет откатиться на любой коммит и начинать с него. При желании можно сделать форк - как это сделал например я в самом первом репозитории на xp-dev, когда Alpet начал тащить в него NLC-специфичные штуки, которые конечно крутые, но мне были не нужны.

С каких пор отмена абсурда является прогрессом?) Прогресс это следующий этап априори.

Не думаю, что ссылки на группы, "проверки видео Ютуба" и прочее подобное превратят форум в "соседний ресурс". Я вообще про такое даже не знал Хотя, по старой памяти тут много кринжа видел в правилах. Например, тот же запрет на "варез и кряки", не знаю есть ли он до сих пор (специально не смотрел), но по этому правилу можно зачистить форум почти под ноль, ибо все моды сейчас являются взломом (правки движка). Останется разве что Автозона, Новая война и сам АМК мод С таким подходом, конечно ожидать каких-то новых тем и притока юзеров вряд ли можно. Становится вопрос - а нафиг? Может в правилах написано, что нельзя больше одной картинки вставить в пост или картинка должна быть не больше WхH и N кб, а то у людей ведь трафик. А еще лучше вообще это спрятать под спойлер, а лучше сразу под два, для надежности Когда залететь можно от чего угодно... Мне это напомнило историю, как на "соседнем ресурсе" решили запретить эмодзи клоуна

А может ли кто пояснить на счет формата моделей OGF между ТЧ и ЧН/ЗП? В чем конкретно отличие, почему вторые не заводятся в некоторых случаях на первом? 16 битные анимации? Или есть еще разница в форматах? Интересуюсь на тему того, чтобы добавить поддержку в ТЧ.

@Капрал Хикс если имеется ввиду с помощью уже существующих скриптовых хаков - вряд ли, в родительском CWeaponCustomPistol порезали пару методов. Проще реализовать функционал бинокля на классе автомата. Там по сути только регулировка зума и рамочки живых объектов. Зум делается элементарно (e.g. БТР в Shadows Addon), рамочки чуть сложнее. Зато не надо морочить голову с пушками на классе бинокля. Если будут интересовать рамочки, проекция точки в мире на экран тут внизу.

Только для мировой модели объекта - play_cycle. В случае с НПС/монстрами play_cycle практически бесполезен, так как перебивается движком или другими скриптовыми схемами. Подходит по сути только для неживых объектов. Для худа оружия (hud_item) проиграть анимацию на оригинальном движке нельзя.

Прикольная вещь. В 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. Разумеется, для каждой вороны свой экземпляр звукового объекта, ссылка на который сохраняется в биндере.