X-Ray extensions

[Malandrinus 611]

Проект

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

[Andrey07071977 18]

https://xp-dev.com/wiki/210311/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA%20%D0%BF%D1%80%D0%B0%D0%B2%D0%BE%D0%BA%20%D0%B2%20%D0%B4%D0%B2%D0%B8%D0%B6%D0%BA%D0%B5

[RayTwitty 486]

к примеру, я буду доволен как слон, если поимею "предоствращение вылета при невключении ствола в mp_ranks". Уж разжуйте...

На самом деле, даже если ты закоментишь правки в corrections_list, сам код правок всё равно попадет в либу, просто не будет джампов на него (и активации правки). Так что, чтобы полностью исключить лишний код, надо комментить и в xrgame_subs.asm.

 

Если тебе из всех правок нужен только фикс по рангам, то лучше скачай первый пак Cut X-Ray, там есть эта правка отдельно.

http://www.amk-team.ru/forum/index.php?showtopic=10339

Спойлер "Редактирование собранного движка".

 

;слоты (могут потребоваться дополнительные правки инвентарных xml) ;тень ГГ на R2 (требует также включения в рендере)

Слоты и тень актора отключены по умолчанию. Изменено 29 Декабря 2014 пользователем Shadows

[lambdist 14]

Кстати, кто бы из вас мог бы добавить правку движка (полная версия) для мода Fixed Statistics ver.2.0 от kstn в X-Ray Extensions, который исправляет статистику в игре?

[Struck 61]

@lambdist, KD говорил, что она уже давно включена, только не помню в ХЕ или в 1.0007. У меня правда ни там ни там она не работает, спрашивал, "она там есть", спорить смысла не видел. Изменено 2 Января 2015 пользователем Struck

[lambdist 14]

@Struck, я ничего подобного не обнаружил. Искал слова "статистик" и "statistic", но ничего не обнаружил.

[RayTwitty 486]

Искал слова "статистик" и "statistic", но ничего не обнаружил.

В ХЕ вроде подобной правки нет, по крайней мере я точно не добавлял. Поспрашивайте у malandrinus'a и других участников проекта, там некоторые правки ими толком не документировались.

[Notfounded 0]

Здравствуйте. Интересует одна вещь - что происходит с dll после применения к ней diff файла? 

[RayTwitty 486]

http://www.amk-team.ru/forum/index.php?showtopic=10339&p=910319

Составил описание некоторых методов, которые добавляет ХЕ, в частности по game_object... Хотя, с некоторыми функциями даже я не разобрался

 

В частности, методы для инвентарных предметов по созданию источника света (насколько я понял, чтобы создать свечение как от артефакта).

 

create_light01()
destroy_light01()
set_light01_range(float)
set_light01_angle(float)
set_light01_enabled(bool)
set_light01_shadow(bool)
bool get_light01_enabled()
set_light01_pos(vector)
set_light01_color(vector)
set_light01_type(int)

 

Пробовал применять таким образом (смотря на аптечку, которая была на полу):

local obj = level.get_target_obj()
if obj then
	obj:create_light01()
	obj:set_light01_range(5)
	obj:set_light01_angle(120)
	obj:set_light01_enabled(true)
	obj:set_light01_shadow(false)
	obj:set_light01_pos(vector():set(0,0,0))
	obj:set_light01_color(vector():set(1,1,1))
	obj:set_light01_type(12)
	log1("light created")
end

Но после вызова у меня скрипт тупо виснет. Печалька.

 

Да и метод для машин bool get_car_shift() у меня постоянно возвращает фальс (и при движении, и при стоянии на месте).

 

Остальное более менее понятно.

 

upd: 23/01/2015, 17:50

ах да, ещё мифические

uint cast_car()
uint cast_game_object()
uint cast_hud_item()
uint cast_inventory_box()
uint cast_inventory_item()
uint cast_weapon()

Изменено 23 Января 2015 пользователем Shadows

[АRХИТЕКТОР 37]

Интересно, куда пропали три предыдущих поста?

[НаноБот 706]

Вот мои поделки в проекте.

https://yadi.sk/d/IXDVG_nrdQtfV

Пару функций по проверки геометрии.

 

 

local shootfactor = level.get_tri_shootfactor(nil, element) -- первый параметр строка, не используется
0.0 - не пробиваемый
1.0 - полностью пробиваемый (пуля пролетает без задержки)
и
local flags = level.get_tri_flags(element)
Использования
Это в _G.script или начало скрипта
local mtlFlags = {
flBreakable = 1, -- 0 разрушаемый
-- flShootable0 = 2, -- 1 простреливаемый, движком не используется (использовался наверно в старых билдах)
flBounceable = 4, -- 2 Может ли пуля нерикошетить? (0 - рикошетит, 1 - нерикошетит)
flSkidmark = 8, -- 3 Оставляет ли тормозной след?
flBloodmark = 16, -- 4 оставляет ли кровь?
flClimable = 32, -- 5 невидимая лестница
-- flWalkOn = 64, -- 6 obsolette
flPassable = 128, -- 7 проходимый для физ. объектов
flDynamic = 256, -- 8 динамический объект
flLiquid = 512, -- 9 жидкость (вода)
flSuppressShadows = 1024, -- 10 заглушает тени
flSuppressWallmarks = 2048, -- 11 заглушает отметены от пуль
flActorObstacle = 4096, -- 12 препятствие (силовое поле) для актора

flInjurious = 268435456, -- 28 flInjurious = fInjuriousSpeed > 0.f -- отбирает ли здоровье? (аномалия "тополиный пух")
flShootable = 536870912, -- 29 непростреливаемый
flTransparent = 1073741824, -- 30 непрозрачный
flSlowDown = 2147483648 -- 31 flSlowDown = (fFlotationFactor<1.f) -- замедление движение
} -- 0 - false (нет), 1 - true (да)
Далее сама проверка
local flags = level.get_tri_flags(element)
if bit_and(flags, mtlFlags.flBounceable) ~= 0 then -- пуля не рикошетит
else -- пуля рикошетит
end

 

Всё работает, проверил не раз.

Не туда запостил, надо в X-Ray extensions

[RayTwitty 486]

@НаноБот, если никаких изменений/дополнений по этим правкам не планируется, могу добавить в проект.

[НаноБот 706]

НаноБот, если никаких изменений/дополнений по этим правкам не планируется, могу добавить в проект.

 

В принципе правки полностью готовы к употреблению. Хорошо бы сделать функцию ввода-вывода PERFORM_EXPORT_LEVEL__FLOAT__INT. Но и так сойдёт.

 

ЗЫ

Ах да, возможно надо оснастить функцию защитой, если element == -1, а то скрипт как правило отваливается, правда скрипт сам за этим должен следить.

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

[Desertir 202]

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

[RayTwitty 486]

Хорошо бы сделать функцию ввода-вывода PERFORM_EXPORT_LEVEL__FLOAT__INT. Но и так сойдёт.

В level нет подходящего прототипа, так что никак.

 

Ах да, возможно надо оснастить функцию защитой, если element == -1, а то скрипт как правило отваливается

Ну, пофиксь и потом сюда кинь код правок или в лс - залью.

[Malandrinus 611]

 

 

у нас есть исходники, скажите, почему правки не осуществляются в них?

Могу сходу назвать несколько причин:
1. Нет единого и принятого всеми собираемого проекта движка. Т.е. проекты то есть, но вот "единого и принятого всеми" пока нету.
2. Даже если бы и был, то собирать проект - это действие на порядок более сложное, чем собрать бинарную правку. И долгое. Даже и тут не все окучили, что уж говорить про установку студии, всех библиотек, возни с конфигурациями и т.п.
3. Ряд правок неочевидны с точки зрения исходников. Авторов некоторых уже не найти, и каждый автор знает только свои правки, а насчёт остальных ещё надо разбираться, что они означают и как их воспроизвести. Хуже того, изрядную часть правок попросту нет смысла воспроизводить в исходниках. Это касается даже примитивного экспорта, который здесь делался часто весьма уродливо: не в том классе/пространстве имён, где следовало бы, с использованием странного списка аргументов или передачи аргументов и результатов через одно место. Т.е. не только соответствующую правку в исходниках надо будет делать иначе, но и совместимость с существующими скриптами неизбежно порушится.
4. Все тормозят же =)

По п.1 могу добавить, что проблема с единым проектом обязательно выйдет в политико-организационную плоскость. Здесь, как верно было замечено, каждая правка носит опциональный характер: хочешь используй, хочешь нет. Если будет единый проект с исходниками, то там правки имеют более перманентный характер. Иными словами, вот кто-то что-то внёс - уже не уберёшь без отката репозитария. Учитывая, мягко говоря, разную квалификацию модостроительной публики это приведёт к разным эксцессам, что в итоге вынудит ограничить доступ только узкому кругу людей. Что в итоге, учитывая уже иные реалии модостроя, приведёт к стагнации проекта (вы просто не дозовётесь никого, чтобы внести даже самую мелкую правку).
 

[RayTwitty 486]

@Malandrinus, в любом случае, придется делать под каждый мод свой бранч, ибо всё универсализировать нельзя, да оно и не нужно. Яркий пример - текущее, вроде как "общепринятое" репо на xp-dev - там сделан огромный экспорт всего и вся в скрипты, хотя по моему мнению, очень много можно делать прямо в движке, не парясь с экспортом.

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

[Dennis_Chikin 3 658]

Э-эээ, ну вообще-то опции не помогут, нет ?

А вообще я чем дальше, тем больше хочу success storyes тех, кто уже собирал. Как долго, какие проблемы, можно ли вынести "вариабельные" куски вот в те же dll ?

[RayTwitty 486]

Э-эээ, ну вообще-то опции не помогут, нет ?

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

 

тем больше хочу success storyes тех, кто уже собирал. Как долго, какие проблемы, можно ли вынести "вариабельные" куски вот в те же dll ?

Если речь о ХЕ - то вроде бы никаких проблем нет. По умолчанию, все правки, которые требуют вмешательство в геймдату я отключил. Остальные - экспорт в скрипты и правки аля "прятать оружие в машине". Хотя, её бы тоже надо отключить по умолчанию, ибо вырезается фича "стрельбы с одной руки"... Изменено 2 Февраля 2015 пользователем Shadows

[Malandrinus 611]

 

 

OGSE 655 скриптов

Замечу не без гордости, что на самом деле около 420-и. Я своей рукой поубивал почти 300 мусорных скриптов.

 

Насчёт сборки исходников. Ну конечно так и надо, кто бы спорил. Но я выше перечислил причины, почему этого не происходит. Если сообщество сможет эти проблемы преодолеть, да и здорово! Но я думаю, что сможет далеко не сразу, особенно по п.1 и дополнению к п.1.

[Dennis_Chikin 3 658]

2 Shadows: это я тут флужу потихоньку , поскольку имею в виду как раз сборку из исходников.

 

То есть, что имею в виду:

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

 

Прятать оружие - это типичная опция. Или конфиг.

Вот кстати да, конфиги тоже ни кто не отменял, и поведение движка ими задавать - почему бы нет.

 

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

 

P.S. Да, понимаю, что работа сильно на любителя и не на один день.

 

 

"Это как" - это вот так же, как делался софт единым исполняемым файлом для разных процессоров. Где запускалось для минимального случая в семействе (80286, скажем), проверялось, а потом использовались куски с разными наборами команд и разным функционалом.

 

Могу согласиться, что это - извращение, но не то, что "не может быть, по тому что в гугле написано". Впрочем, да, согласен, перебор в том смысле, что вряд-ли кто озадачится ТАКИМ.

 

P.P.S. И, да, наверное, действительно разумнее подумать о вынесении всякого разного в скрипты.

Изменено 2 Февраля 2015 пользователем Dennis_Chikin