X-Ray extensions

[Malandrinus 615]

Проект

X-Ray extensions

 

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

Адрес проекта на Google Code

Документация одним файлом в chm формате (зеркало) по состоянию на 15 августа 2013 г. (собрана, отформатирована и скомпилирована @Kontro-zzz).

Версии игры, поддерживаемые на данный момент:
ТЧ (патч 1.0006): xrGame.dll, XR_3DA.exe, xrRender_R1/2
ЧН (патч 10): xrGame.dll, xrRender_R1/2/3
ЗП (патч 1.6.02): xrGame.dll, xrRender_R1/2/3/4

• svn хранилище не содержит оригинальных файлов игры.
• Не забывайте делать резервные копии перед заменой файлов игры!

 

 

Ссылка на адрес нового репозитария: https://github.com/KD87/xray-extensions

Изменено 23 Июня 2016 пользователем Malandrinus

[Malandrinus 615]

Опции, которые задаются при запуске движка. И, по сути, да, которыми выбирается нужный бранч (но внутри одного exe).

Это как? Бранч - это отдельный проект. Собирается отдельно и приводит к созданию отдельной библиотеки.

 

инвентарь ЗП/билд, грубо говоря. Хотя не уверен, что вот этот конкретный случай - именно через опции. Скорее, именно инвентарная dll.

DLL - это тяжёлая артиллерия. Вот рендер вынести в dll - это можно, сетевой сервер, модуль звука - можно. А вот кусок xrGame так просто вынести - ни малейшего смысла нет. Что есть смысл сделать - это вынести весь оконный интерфейс в скрипты, а в движке оставить только базовые классы и контролы + полно и аккуратно экспортировать их скриптовые интерфейсы. Тогда можно будет лепить окна скриптами как душа пожелает. И это вполне реально, как показывает пример полностью написанного скриптами главного меню и многочисленных и довольно сложных оконных наработок в модах.

[abramcumner 1 229]

1. Нет единого и принятого всеми собираемого проекта движка. Т.е. проекты то есть, но вот "единого и принятого всеми" пока нету.

И не нужен. Каждый ведет свой проект. Понравилась фишка - вытаскиваешь к себе из другого проекта.

 

Что в итоге, учитывая уже иные реалии модостроя, приведёт к стагнации проекта (вы просто не дозовётесь никого, чтобы внести даже самую мелкую правку).

Это уже давно обдумано. Потерялись авторы - делаешь форк и спокойно вносишь свою правку. Если авторы появятся и захотят, заберут правку обратно.

[Andrey07071977 18]

Кстати, @abramcumner, ты не в курсе где корректируются тени от зарешеченных ламп, чтоб нормально тени отбрасывали, а не тупо крестик на стене?

[abramcumner 1 229]

@Andrey07071977, неа.

Вроде как надо убрать в коде ограничение на виртуальный радиус ламп(можно в xp-dev поискать коммит по этому ключевому слову), и в модели перенести источник света внутрь лампы.

[RayTwitty 567]

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

Без индивидуальной настройки ламп в СДК (их виртуального радиуса) не имеет смысла. По дефолту там всегда 0.1, а при таком значении тень будет уродливая (если речь идет об аварийной лампе, из-за которой в своё время всё и затевалось). Изменено 2 Февраля 2015 пользователем Shadows

[Malandrinus 615]

@abramcumner, если так подумать, то самом деле вообще не верится в силу сообщества в данном случае. Равно как не видно особенного смысла в буквальном переносе правок из x-ray extensions. В GSC за модуль xrGame отвечал по большей части один человек (Ясенев). Думаю, что один-два грамотных человека потянули бы и поддержку/некое минимальное развитие этого модуля. Но только под конкретный проект. Всё иное обречено на заведомый провал.

 

где корректируются тени от зарешеченных ламп

Суть косяка примерно такая. Когда рендерится карта теней (Shadow Map = SMAP) конкретного источника света, то там задаётся форма усечённой пирамиды проекции, где угол - задаётся собственно углом источника света, дальняя поверхность (far plane) - дальностью источника света, а ближняя (near plane) - это как раз искомый размер, называемый SMAP_near_plane, он же поле virtual size в серверном классе. Тень отбрасывает всё, что попадает внутрь этой пирамиды, и иногда что-то близкое к центру проекции не влазит, что и даёт отсечение части теней. Чтобы это пофиксить, надо уменьшить этот виртуальный радиус.

Ну вот в серверном классе это поле есть, как есть и в acdc, а до источника света оно почему-то не доходит, и там просто ставится число 0.1. Чтобы это пофиксить надо решить две проблемы: (1) в клиентском классе нет поля для хранения этого значения, (2) значение 0.1 вкомпилено в код.

Правка делается в нескольких местах:
Во-первых, организуется место, где храним данные. Где-то, уже в упор не помню где, увеличивается размер объекта при создании. Кажется это размер объекта источника света, но где это делалось - уже не помню.
Далее в файле hanging_lamp_fix.asm проекта xrGame (врезка CHangingLamp__net_Spawn_fix) значение из серверного объекта копируется в организованное место в клиентском.
Далее уже в рендере в файле light_fix.asm (врезка CLight_Compute_XFORM_and_VIS__compute_xf_spot_fix) заменяется довольно большой кусок, где вместо вкомпилированного 0.1 используется правильное значение.

В сырцах это место находится в файле Light_Render_Direct_ComputeXFS.cpp, функция CLight_Compute_XFORM_and_VIS::compute_xf_spot. Разумеется в сырцах и меньше проблем будет с тем, где хранить данные.
 

[RayTwitty 567]

В 179 ревизии я эту правку кстати немного доделал. В ХЕ по идее, должно всё так же выглядеть, хотя я детально там код не разбирал.

https://xp-dev.com/sc/204486/HEAD/

[НаноБот 746]

Так!

Доработал я правки, за одно и ваши функции доделал, проверка на element == -1, выдаёт вектор равен set(0,0,0). Так же, там есть спецприбор для теста этих функций и геометрией (папка gamedata), прибор можно практически в любом моде использовать, в котором проект X-Ray extensions используется. Настраивается так:

в файл system.ltx, добавить строчку #include "misc\spezpribor.ltx", 

в файл bind_stalker.script добавить строчку bind_pribor.spawn_pribor() в функцию actor_binder:net_spawn(data) в конец перед return true, так же, эту строчку можно в любой другой скрипт добавить, который по инфопоршню срабатывает.

Ссылка не изменилась.

https://yadi.sk/d/IXDVG_nrdQtfV

 

ЗЫ

Теперь скрипт не отваливается, но это не значит что скриптер не должен это(element == -1) не проверять.

Изменено 3 Февраля 2015 пользователем НаноБот

[Notfounded 0]

Возможно ли врезкой в код восстановить анимацию хитов в ТЧ? Говорю восстановить, т.к. в коде самого XrGame видел описание этих анимаций и в билде 3120 они работают (Так же работают и в ЧН/ЗП - при выстреле в НПС он, в зависимости от того, в какую кость попали двигает туловищем, например если в плечо попали то НПС как-бы плечо назад отводит.).

[RayTwitty 567]

@Notfounded, так они есть в ТЧ - стреляем в ногу, НПС немного сгибается или может припасть на колено. Инфа 100%. Изменено 6 Февраля 2015 пользователем Shadows

[Notfounded 0]

, эти есть, я говорил про немного другие, в файле анимаций hit_frontl и похожие, вроде такая там тоже есть, они с 3120 билда появились, но их код в XrGame еще со времен ТЧ заметил. Изменено 6 Февраля 2015 пользователем Notfounded

[qvvxvvq 111]

Эмм. В какой ревизии инерция zoom'а?

[Anonim 680]

@PlayMod, Посмотри в последней 

[qvvxvvq 111]

 

Anonim, Посмотрел, нету   

[Malandrinus 615]

 

 

В какой ревизии инерция zoom'а?

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

[RayTwitty 567]

Эмм. В какой ревизии инерция zoom'а?

Во всех, начиная со 164-ой. Но по умолчанию правка выключена. Изменено 10 Февраля 2015 пользователем Shadows

[User_X.A.R26 261]

@Malandrinus, а вы не записываете изменения в описание ревизии?

[НаноБот 746]

Кстати, когда мои правки добавите в проект? Скриптовые пули уже практически готовы.

[RayTwitty 567]

@НаноБот, добавлю в ближайшее время - сейчас пока не до ХЕ.

[abramcumner 1 229]

@Malandrinus, а вы не записываете изменения в описание ревизии?

Конечно записывают. Malandrinus и предлагал почитать описания ревизий:

надо открыть лог и найти там нужную правку

@abramcumner, если так подумать, то самом деле вообще не верится в силу сообщества в данном случае.

А зачем верить, надо брать и делать самому. Как делали xray-tools, xray-extensions, да и просто моды. А народ подтянется.

 

Но только под конкретный проект. Всё иное обречено на заведомый провал.

Конечно, проект первичен. От него и надо плясать - нужны ли правки движка, какие если нужны. Единственное, что вся разработка должны быть открыта - так и прогресс виден и люди всякого не навыдумывают. Такое у меня сейчас ощущение