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

[UnLoaded 313]

Попытался восстановить все, связанное с сытостью: чтоб она влияла на здоровье и выносливость ГГ и чтоб этот параметр у артефактов заработал. Вроде все получилось, но кроме одного - не могу восстановить св-во 'satiety' для game_object, чтоб можно было получить скриптово значение db.actor.satiety. В процессе ковыряния выяснил, что обработка самой сытости происходит в CActorCondition::UpdateSatiety()(xrGame\ActorCondition.cpp) и хранится в переменной m_fSatiety, а значение, которое выводится через db.actor.satiety читается из переменной с таким-же именем m_fSatiety класса CEntityCondition(xrGame\EntityCondition.cpp). Там этой переменной в конструкторе класса тупо присваивается значение

m_fSatiety = 1.f;

а затем это значение транслируется ф-цией

IC float GetSatiety() const { return m_fSatiety; }

этого-же класса. Т.е. в игре значение db.actor.satiety всегда равно 1.0. Подскажите как эти значения "поженить", не могу разобраться пока, как эти классы между собой взаимодействуют.

Изменено 3 Января 2017 пользователем UnLoaded

[Kondr48 314]

m_fSatiety -=	m_fV_Satiety*
						k*
						m_fDeltaTime;

UnLoaded, так вот же на апдейте m_fSatiety изменяется с течением времени. И в этой переменной текущее значение сытости и хранится. С чего Вы взяли, что это значение всегда равно 1.0?

В 7 патче KD давно сделал и это работает  :

.property("satiety",				&CScriptGameObject::GetSatiety,			&CScriptGameObject::SetSatiety)	// KD	

---

Стоп... Изменяется она только в CActorCondition... Но в любом случае, получение и изменение сытости у меня работает через db.actor.satiety.

Изменено 4 Января 2017 пользователем Kondr48

[UnLoaded 313]

С чего Вы взяли, что это значение всегда равно 1.0?

Проблема решена, а дело было в том, что в CActorCondition(xrGame\ActorCondition.h) было объявление переменной float m_fSatiety;, которое перекрывало доступ к такой-же переменной класса CEntityCondition(xrGame\EntityCondition.h). Следовательно, всегда читалось не измененное значение этой переменной. Убрал m_fSatiety из CActorCondition - и все заработало.

 

Теперь следующая проблема: пытаюсь добавить в движок новый инвентарный объект. Решил делать по подобию броников, и пошел от class_registrator.script поиском. Дошел до класса class CCustomOutfit: public CInventoryItemObject..., который видимо является базовым классом для всех остальных броников. Собственно создал все новые классы для объекта по образу и подобию. Собственно что-то получилось: предмет можно заспавнить в инвентарь\на местность, можно выбросить\подобрать. Но решил проверить по внимательнее, и обнаружил следующее:

в class_registrator.script для объекта прописано

cs_register(object_factory, "CNewObjectTest",  "se_item.se_newobj", "E_NEW_OBJ", "new_obj_s")

в se_item.script добавил по аналогии новый класс, и для проверки в function se_newobj:on_register() поставил выдачу сообщения. И такая-же выдача сообщения уже была добавлена в тот-же метод класса se_outfit. И получилось у меня, что при создании объекта(спавн в инвентарь ГГ) у меня сообщение приходит из класса se_outfit ! Подумал сразу, что где-то ошибся, когда копипастил из классов броников в новые классы, перепроверил все 2 раза - нет, все нормально, путаницы нигде нет. Собственно нужна подсказка, куда смотреть, что проверять ?

Изменено 4 Января 2017 пользователем UnLoaded

[Zander_driver 10 334]

 

 

перепроверил все 2 раза - нет, все нормально, путаницы нигде нет. Собственно нужна подсказка, куда смотреть, что проверять ?

Где-то таки есть не замеченная путаница. Иначе такого быть не может)

[UnLoaded 313]

 

 

Иначе такого быть не может)

Верю...

Может, кто нить, кто уже успешно добавлял новый объект в движок, накидает цепочку действий ? Я бы сверился, вдруг что увижу...

[UnLoaded 313]

Сделал список моих действий по добавлению объекта в игру, может увидит кто ошибку:

в class_registrator.script

cs_register(object_factory, "CNewObjectTest",  "se_item.se_newobj", ("E_NEWOBJ"), "new_obj_s")

в se_item.script

class "se_newobj" (cse_alife_item_custom_newobj)
function se_newobj:__init(section) super(section)
end
..... далее все как у других классов

в bind_newobj.script

function init(obj)
     local new_binder = newobj_binder(obj)
     obj:bind_object(new_binder)
end

class "newobj_binder" (object_binder)
function newobj_binder:__init(obj) super(obj)
     ......
end
..... далее все как у других классов

в конфиге предмета:

[newobj_base]
GroupControlSection = spawn_group
discovery_dependency = 
class = E_NEWOBJ
cform = skeleton
full_icon_name = npc_icon_newobj
slot = 11
script_binding = bind_newobj.init

additional_inventory_weight = 0
additional_inventory_weight2 = 0

;----------------------------
[newobj_test1]:newobj_base
.... далее все как обычно

Теперь движок:

файл xrGame\object_factory_register.cpp

# include "NewObjectTest.h"
....
ADD(CNewObjectTest, CSE_ALifeItemNewObjectTest, CLSID_E_NEWOBJ, "new_obj");
....
ADD(CNewObjectTest, CSE_ALifeItemNewObjectTest, TEXT2CLSID("E_NEWOBJ"), "new_obj_s");

файл xrGame\clsid_game.h

#define CLSID_E_NEWOBJ MK_CLSID('E','Q','_','N','E','W','O','B')

файл xrGame\xrServer_Objects_ALife_Items.h

SERVER_ENTITY_DECLARE_BEGIN( CSE_ALifeItemNewObjectTest, CSE_ALifeItem)
     u32 m_ef_equipment_type;
     CSE_ALifeItemNewObjectTest(LPCSTR caSection);
     virtual ~ CSE_ALifeItemNewObjectTest();
     virtual u32 ef_equipment_type() const;
     virtual BOOL Net_Relevant();
SERVER_ENTITY_DECLARE_END
add_to_type_list( CSE_ALifeItemNewObjectTest)
#define script_type_list save_type_list( CSE_ALifeItemNewObjectTest)

файл xrGame\xrServer_Objects_ALife_Items.cpp

CSE_ALifeItemNewObjectTest::CSE_ALifeItemNewObjectTest(LPCSTR caSection) : CSE_ALifeItem(caSection)
{
     m_ef_equipment_type = pSettings->r_u32(caSection, "ef_equipment_type");
}
CSE_ALifeItemNewObjectTest::~CSE_ALifeItemNewObjectTest()
{
}
.... далее все как у других классов

файл xrGame\xrServer_Objects_ALife_Items_script2.cpp

void CSE_ALifeItemNewObjectTest::script_register(lua_State *L)
{
     module(L)[
          luabind_class_item1(
               CSE_ALifeItemNewObjectTest,
               "cse_alife_item_custom_newobj",
               CSE_ALifeItem
          )
     ];
}

далее уже класс CNewObjectTest, но его весь приводить не буду, много там тексту - содран с класса броников, что не нужно убрано, оставлено пока основное. Для теста добавлял вывод сообщения в лог в конструкторы CSE_ALifeItemNewObjectTest и CNewObjectTest, и соответственно в такие-же классы броников. При создании объекта(спавн в инв. ГГ) - в логе сообщения из классов броников, а из нового класса нет. При этом объект можно выбросить и снова взять, вылетов вроде нет.

 

Изменено 5 Января 2017 пользователем UnLoaded

[Eugen81 1 008]

@UnLoaded

#define CLSID_E_NEWOBJ MK_CLSID('E','Q','_','N','E','W','O','B') -- 'J' не хватает?

[Kondr48 314]

Уже устал долбиться в стену, не понимая что происходит, прошу помощи  Занялся я детекторами ЧН/ЗП, примерно представляю как оно там работает, начал "перенос" функционала на ТЧ и завис еще в начале. Удалил все в классе детектора что было, начинаю постепенно делать свое. Пока - примитив. Показать худ и три анимации, собственно idle, draw, holster. Вылетов нет, детектор прекрасно спавнится, но нет худа вообще. Т.е. все сообщения в лог выводятся (накидал в те участки кода, где должны воспроизводится анимации) а самого худа нет. Будто он не рисуется. Думаю, где-то проглядел, что худ надо "нарисовать", но не могу найти где. В классе артефактов ничего подобного не нашел (смотрел его, так как худ самый простой). Очень надеюсь на подсказку чего искать.

#pragma once

#include "hud_item_object.h"

class CCustomDetector :		public CHudItemObject {
private:
	typedef			CHudItemObject	inherited;
public:
					CCustomDetector		();
	virtual			~CCustomDetector	();

	virtual void					Load							(LPCSTR section);
	
	virtual BOOL					net_Spawn						(CSE_Abstract* DC);
	virtual void					net_Destroy						();

	virtual void					OnH_A_Chield					();
	virtual void					OnH_B_Independent				(bool just_before_destroy);
	
	virtual void					UpdateCL						();
	virtual void					shedule_Update					(u32 dt);	

	virtual void					Hide				();
	virtual void					Show				();
	//инициализация если вещь в активном слоте или спрятана на OnH_B_Chield
	virtual void			OnActiveItem();
	virtual void			OnHiddenItem();
	virtual void			        renderable_Render();
	virtual void					OnStateSwitch		(u32 S);
	virtual void					OnAnimationEnd		(u32 state);

	virtual	void					UpdateXForm			();

		enum EDETHudStates {
		eIdle		= 0,
		eShowing,
		eHiding,
		eHidden,
	};

protected:
	
	MotionSVec						m_anim_idle;
	MotionSVec						m_anim_show;
	MotionSVec						m_anim_hide;
};
 

 

 

#include "stdafx.h"
#include "customdetector.h"
#include "hudmanager.h"
#include "inventory.h"

CCustomDetector::CCustomDetector() 
{
	SetSlot (DETECTOR_SLOT);
}

CCustomDetector::~CCustomDetector() 
{

}

void CCustomDetector::Load(LPCSTR section) 
{
	inherited::Load			(section);
	
	R_ASSERT			(m_pHUD);
	animGet				(m_anim_idle,					pSettings->r_string(*hud_sect,"anim_idle"));
	animGet				(m_anim_hide,					pSettings->r_string(*hud_sect,"anim_hide"));
	animGet				(m_anim_show,					pSettings->r_string(*hud_sect,"anim_show"));
}

BOOL CCustomDetector::net_Spawn(CSE_Abstract* DC) 
{
	BOOL result = inherited::net_Spawn(DC);
	SetState					(eHidden);
	return result;	
}

void CCustomDetector::net_Destroy() 
{
	inherited::net_Destroy		();
}

void CCustomDetector::OnH_A_Chield() 
{
	inherited::OnH_A_Chield		();
}

void CCustomDetector::OnH_B_Independent(bool just_before_destroy) 
{
	inherited::OnH_B_Independent(just_before_destroy);

	if (m_pHUD)
		m_pHUD->Hide();
}

void CCustomDetector::OnActiveItem()
{
	inherited::OnActiveItem();
	//если мы занружаемся и оружие было в руках
	SetState(eIdle);
	SetNextState(eIdle);
	if (m_pHUD) m_pHUD->Show();
}

void CCustomDetector::OnHiddenItem()
{
	inherited::OnHiddenItem();
	if (m_pHUD)	m_pHUD->Hide();
	SetState(eHidden);
	SetNextState(eHidden);
}

void CCustomDetector::UpdateCL() 
{
	inherited::UpdateCL			();
}

void CCustomDetector::shedule_Update		(u32 dt) 
{
	inherited::shedule_Update		(dt);
}

#include "inventoryOwner.h"
#include "Entity_alive.h"

void CCustomDetector::UpdateXForm()
{
	if (Device.dwFrame!=dwXF_Frame)
	{
		dwXF_Frame			= Device.dwFrame;

		if (0==H_Parent())	return;

		// Get access to entity and its visual
		CEntityAlive*		E		= smart_cast<CEntityAlive*>(H_Parent());
        
		if(!E)				return	;

		const CInventoryOwner	*parent = smart_cast<const CInventoryOwner*>(E);
		if (parent && parent->use_simplified_visual())
			return;

		VERIFY				(E);
		CKinematics*		V		= smart_cast<CKinematics*>	(E->Visual());
		VERIFY				(V);

		// Get matrices
		int					boneL,boneR,boneR2;
		E->g_WeaponBones	(boneL,boneR,boneR2);

		boneL = boneR2;

		V->CalculateBones	();
		Fmatrix& mL			= V->LL_GetTransform(u16(boneL));
		Fmatrix& mR			= V->LL_GetTransform(u16(boneR));

		// Calculate
		Fmatrix				mRes;
		Fvector				R,D,N;
		D.sub				(mL.c,mR.c);	D.normalize_safe();
		R.crossproduct		(mR.j,D);		R.normalize_safe();
		N.crossproduct		(D,R);			N.normalize_safe();
		mRes.set			(R,N,D,mR.c);
		mRes.mulA_43		(E->XFORM());
//		UpdatePosition		(mRes);
		XFORM().mul			(mRes,offset());
	}
}

void CCustomDetector::Hide()
{
	SwitchState(eHiding);
}

void CCustomDetector::Show()
{
	SwitchState(eShowing);
}

void CCustomDetector::OnStateSwitch(u32 S)
{
	inherited::OnStateSwitch	(S);
	switch(S){
	case eShowing:
		{
			 m_pHUD->animPlay(random_anim(m_anim_show),		FALSE, this, S);
			 Msg("Достаем детектор");
		}break;
	case eHiding:
		{
			 m_pHUD->animPlay(random_anim(m_anim_hide),		FALSE, this, S);
			 Msg("Прячем детектор");
		}break;
	case eIdle:
		{
		if (m_anim_idle.size())
			 m_pHUD->animPlay(random_anim(m_anim_idle),		FALSE, NULL, eIdle);
			 Msg("Держим в руке детектор");
		}break;
	};
}

void CCustomDetector::renderable_Render()
{
	inherited::renderable_Render();
}

void CCustomDetector::OnAnimationEnd(u32 state)
{
	inherited::OnAnimationEnd	(state);
	switch(state)
	{
	case eShowing:
		{
			SwitchState					(eIdle);
		} break;
	}
} 

 

 

Изменено 5 Января 2017 пользователем Kondr48

[UnLoaded 313]

Кто нить может пояснить работу ф-ции CWeaponMagazined::UnloadMagazine ? Что в ней и как происходит...

[Bak 755]

@UnLoaded, Сначала чистится магазин, попутно запоминая сколько и каких патронов там было.

Затем эти патроны суются в пачку, имеющуюся в инвентаре, а если там не хватает места - спавнится новая.

Вот и всё собственно.

[Карлан 1 049]

@Eugen81, нет, там не в этом дело.

 

@Kondr48, можешь рассказать конечную цель? Ты что-то свое делаешь или просто переносишь? Когда-то давно меня просили помочь перенести детекторы из ЗП на ТЧ, абсолютно точно помню, что брал код целиком, конечно какие-то сопутствующие правки приходилось вносить, добавлять какие-то функции и классы, но в целом код брался as is. Ничего не выдумывалось, если ты переносишь, то почему не идешь простым путем (полным копированием)? По твоему коду, мне так точно, нужно пробовать завести твой код, чтобы что-то сказать по существу, а что-то вот так сказать у меня опыта не хватает.

 

@UnLoaded, сытость да, в оригинале нужно доделывать. Я переписал несколько формул и вроде еще какой-то параметр добавлял, давно было, не помню. Единственное чего мне не хватило духу сделать, это аппроксимацию изменения здоровья в зависимости от сытости. Возможно попрошу реализовать какую-то общую формулу, которая будет усреднять значения, и перевяжу сытость со многими другими параметрами. Если ты сможешь написать что-то такое, то будет отлично!

[UnLoaded 313]

 

 

нет, там не в этом дело.

Оно понятно, вот знать бы в чем ? Уж очень хочется новые предметы в игре...

 

 

это аппроксимацию изменения здоровья в зависимости от сытости.

Давай более простыми словами - что именно хочется ?

 

 

и перевяжу сытость со многими другими параметрами.

С какими ? В исходнике, она и так связана со здоровьем и выносливостью(или сила, как там обозвали). Ну можно еще с кровотечением связать - я не медик, но допускаю что может быть зависимость заживления ран от сытости\голода.

 

 

Затем эти патроны суются в пачку, имеющуюся в инвентаре, а если там не хватает места - спавнится новая.

Воо! А то я не мог догнать, что делает:

CWeaponAmmo *l_pA = smart_cast<CWeaponAmmo*>(m_pCurrentInventory->GetAny(l_it->first));

[Kondr48 314]

можешь рассказать конечную цель? Ты что-то свое делаешь или просто переносишь?

Переношу. Да, сам функционал детекторов он и будет браться практически ai is, согласен. Но слишком много там сейчас того, что мне не потребуется на данном этапе, вроде совместных пистолетов и детекторов и т. п. Начал я именно так, чтобы понять как именно создать свой класс предмета с худом, не наследуя от оружия (оружейный функционал мне там не нужен) а худ нужен не только даже для детекторов. Просто на этих детекторах я начал "учиться" так скажем. Цель сейчас у меня просто заставить детекторы тупо показать худ. Больше ничего  . Когда он заработает, остальной функционал я постепенно перенесу именно "как есть".

Изменено 6 Января 2017 пользователем Kondr48

[UnLoaded 313]

Подскажите, плз, как имея ID объекта получить его инвентарь, как СInventory(или как правильнее будет).

[UnLoaded 313]

Бывает иногда такая ситуация, что при открытии инвентаря, оружие не прячется. И затем, при манипуляциях в открытом инвентаре, происходит "самовольная" перезарядка оружия, если оно было разряжено. Если я правильно понимаю, перезарядка происходит по нажатию левой кнопы мыша, что при активном оружии означает выстрел и вызывает перезарядку. Но тогда почему, при последующих, после перезарядки, нажатиях ЛКМ оружие не стреляет ? Или перезарядка происходит по иной причине ? Кто нить пытался разобраться с этим багом на уровне движка(исходников) ?

[GROM_27 1]

Всем привет! В файле corrections_list есть такие строчки

 

;0x10204311 5 ;CInventory__Init__ отключение худа слотов
;0x1042AA44 5 ;память под объект CInventory
;0x1042B8A8 5 ;память под объект CInventory
;0x10206C02 3 ;количество слотов в xr_vector_CInventorySlot_xalloc_CInventorySlot____resize
;0x10206C1F 5 ;количество слотов в xr_vector_CInventorySlot_xalloc_CInventorySlot____resize
;0x10206C35 6 ;количество слотов в xr_vector_CInventorySlot_xalloc_CInventorySlot____resize
;0x10206951 6 ;количество слотов в CInventory__SetSlotsBlocked

 

Кто-нибудь может подробнее объяснить что это за значения и особенно про количество слотов?

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

[dsh 3 824]

Кто-нибудь может рассказать историю коллбека 153. Вызывается при получении неписем хита и после него выполняется какая-то обработка этого хита. Чем этот коллбек отличается от стандартного и что там происходит?

[Malandrinus 615]

@dsh,

цитирую из лога

+ коллбек (153 для НПС) на хит от НПС. Передается вредитель. set_int_arg0(1) для того, что НПС проигнорировал хит от вредителя.

Там есть ещё колбек 152 на событие "прехит", с помощью которого можно сделать всё тоже самое. В частности, в огсе через 152 сделаны иммунитеты актору и игнор дружественного огня неписями.

[dsh 3 824]

@Malandrinus, так вот мне и не понятно, зачем сделан 153, при наличии стандартного callback.hit и 152-го?

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

[Malandrinus 615]

@dsh,

разные авторы правок. Колбек 153 был добавлен позднее. Возможно, его автор не вполне был в курсе всех возможностях колбека 152. С документацией в этом проекте всегда было туго.

 

На мой взгляд колбек 152 покрывает большую часть возможных нужд, поскольку даёт доступ к полной структуре хита, включая адресата, типы пули и пр. Достаточно подробный пример использования можно найти в огсе.