Перейти к контенту

Редактирование движка X-Ray


Рекомендуемые сообщения

Всем привет. Движок ЗП.

1. Почему-то при закидывании в мод файла xrEngine.exe из моих исходников столкнулся с проблемой: при вылете игра не закрывается. Тупо зависает и всё, хоть что с ней делай, лечится только выходом из системы/перезагрузкой компа. Очень неудобно, да и не должно быть так, на лицензии у меня всегда вылеты нормально отрабатывали, всё закрывалось. В исходниках экзешника пока что ничего не менял

2. Как редактировать параметры "100 советов по выживанию в зоне" на загрузочном экране? В конфигах чёт нигде нет их параметров, как и параметров самого ЗЭ. После замены текстуры ЗЭ текст стал сливаться, надо бы изменить цвет, да и хотелось бы убрать надпись "100 советов...", и оставить только сами советы. Копался в x_ray.cpp, докопался лишь до инициализации выбора этих советов, но до их параметров чёт не докопался...

Ссылка на комментарий

Здравствуйте. Есть проблема с движком. Пытаюсь собрать 1.0007rc1. Установил Visual Studio 2005, поисправлял в исходниках всякие ошибки путей в инклудах и ещё по мелочи, и всё без проблем собралось! Игра работает как надо. Но мне нужна сборка в моей 2019 студии, в первую очередь чтобы использовать возможности стандарта языка. Начал сборку со стандартом C++14. Это было сплошное мучение с ошибками на каждом шаге. Но в итоге всё преодолел, все ошибки локализировал, исправил, и движок собрался. Но игра вылетает сразу после стартовой заставки. Несколько дней уже сижу в отладчике и пытаюсь понять, что не так. Параллельно я запустил отладку в 2005 студии и сравниваю между студиями значения локальных переменных на каждом шаге отладки в одних и тех местах кода. Всё вроде одинаково, побочные эффекты те же. Но вот проект, который в 2019, доходит до чтения файла "effects_water.s", затем выполняет множество одинаковых с 2005 действий и вызывает функцию luaJIT_run, с этого момента выполнение уходит в черный ящик (не отслеживается), и в файле lfunc.c в функции luaF_findupval вылетает исключение "нарушение доступа чтения". До этого момента с 2005 студией всё было одинаково.

Я долго ковырялся в коде LuaJIT'a. До файла effects_water.s читается несколько других подобных файлов с тем же расширением, и при каждом из них запускается LuaJIT, но функция luaF_findupval вызывается только при effects_water. Я сравнивал, как 2005-я и 2019-я проходят через ту функцию, когда обрабатывается effects_water: на точке останова в luaF_findupval выполнение останавливается трижды. И 2005-я и 2019-я проходят два раза функцию от начала до конца одинаково, но на третий раз у 2019 сильно отличается первый аргумент - lua_State *L. То есть объект по адресу этого указателя имеет другие значения полей. Тут важный момент: этот объект, судя по всему, не должен изменяться - в 2005-й при всех трёх прохождениях через функцию объект неизменен (кроме одного поля-указателя), в 2019 первые два раза он тоже неизменен (кроме того же поля), но на третий shit happens.

CZVgggjYs4I.jpg?size=693x954&quality=96&

Дальнейшая отладка плодов не принесла - отследить, кто и откуда вызывает эту функцию оказалось крайне сложно из-за вычурного кода LuaJIT'a. Кто-нибудь сталкивался с такой проблемой, есть предложения? Очень странно, что проблема кроется в LuaJIT'е, его код я точно не задевал, когда пытался всё скомпилить.

  • Полезно 1
Ссылка на комментарий
27 minutes ago, GeorgyS said:

Пытаюсь собрать 1.0007rc1.

Не нужно, не нужно этого делать. Хочется возиться с исходниками - возьми OGSR. Зачем ходить по давным-давно решенным граблям.

  • Согласен 1
  • Полезно 1
Ссылка на комментарий
1 час назад, dsh сказал:

Не нужно, не нужно этого делать. Хочется возиться с исходниками - возьми OGSR. Зачем ходить по давным-давно решенным граблям.

Спасибо за совет, но я не собираюсь отступать, хочу сам всё сделать с нуля

  • Нравится 1
Ссылка на комментарий
15.02.2022 в 17:43, GeorgyS сказал:

Здравствуйте. Есть проблема с движком. Пытаюсь собрать 1.0007rc1.

Всё таки получилось! :528:Проблема была в оптимизации компилятора. Я её изначально решил убрать, чтобы отслеживать больше локальных переменных в отладке, и таким образом случайно всё починил)

Потом стало вылетать странное исключение во время создания новой игры, решилось оно не менее странным способом: исключение выбрасывала функция из стандартной библиотеки, которая принимала по значению объект и тут же в первой строке его возвращала. Я всего лишь в классе этого объекта явно прописал пустые конструкторы - всё заработало.:pardon:Кстати в проекте оптимизации не было, что придаёт ещё больше странности.

Наконец отстрелялся, игра работает

  • Нравится 2
Ссылка на комментарий

Здравствуйте. А с чем в теории может быть связана некая тормознутость при наборе букв в консоли на движке, собранном на основе  исходников 10007? Это как если в винде в настройке клавиатуры сдвинуть регуляторы скорости ввода влево.

Ссылка на комментарий

В общем, наклепал вот такой код:

Скрытый текст
void CUIRelationsWnd::Init()
{
	CUIXml							xml;
	xml.Load						(CONFIG_PATH, UI_PATH, PDA_RELATIONS_XML);
	VERIFY							(hint_wnd);

	CUIXmlInit::InitWindow			(xml, "main_wnd", 0, this);
	
	m_background				= UIHelper::CreateFrameWindow(xml, "background", this);
	
	m_btn_to_text				= UIHelper::Create3tButton( xml, "btn_to_text", this );
	AddCallback					(m_btn_to_text, BUTTON_CLICKED, CUIWndCallback::void_function(this, &CUIRelationsWnd::Button_clicked));

	m_tab						= UIHelper::CreateStatic(xml, "tab", this);
	m_tab_caption				= UIHelper::CreateStatic(xml, "tab:caption", m_tab);
	
	u32 c_width = 65;
	u32 c_height = 35;
	
	Fvector2 ipos;
	ipos.x = 45;
	Fvector2 kpos;
	
	for ( u32 i = 0; i < 10; ++i )
	{
		ipos.x = ipos.x + c_width;
		CUITextWnd* iobj = UIHelper::CreateTextWnd(xml,"tab:faction",m_tab);
		ipos.y = 65;
		iobj->SetWndPos(ipos);
		iobj->SetText(CStringTable().translate(communities[i]).c_str());

		ipos.y = 60;
		for ( u32 k = 0; k < 10; ++k )
		{
			ipos.y = ipos.y + c_height;
			if (i == 1) {
				CUITextWnd* kobj = UIHelper::CreateTextWnd( xml, "tab:faction", m_tab );
				kpos = ipos;
				kpos.x = kpos.x-5-(c_width*2);
				kobj->SetWndPos(kpos);
				if (k > 0) 
					kobj->SetText(CStringTable().translate(communities[k]).c_str());
				else
					kobj->SetText(CStringTable().translate("ui_st_reputation").c_str());
			}
			m_relations[i][k] = UIHelper::CreateTextWnd( xml,"tab:cell",m_tab);
			m_relations[i][k] ->SetWndPos(ipos);
		}

	}

}

 

но почему-то из-за него происходит следующее: первый раз игра запускается и загружается норм, но при закрытии игры происходит вылет. После этого вылета появляется вылет при загрузке игры. После второго вылета всё вновь норм загружается, и так по кругу. Лог таков:

Скрытый текст

stack trace:

0023:00B7AFCF xrCore.dll, xrMemory::mem_alloc()
0023:04971725 xrXMLParser.dll, CXml::correct_file_name()
 
[error][       8]    : Недостаточно ресурсов памяти для обработки этой команды.

Так понимаю - вылет по памяти. Мб можно как-то скомпановать этот код, или исправить что-то. Потому что происходят такие себе дела:az1000106:

Ссылка на комментарий

@Ghilli ,

начать с этого: \xrGame\ai\stalker\ai_stalker_fire.cpp (void CAI_Stalker::Hit).

 

 

Мне же интересно, что делает это кусок кода:

Скрытый текст
	if(eacFirstEye == cam_active)
	{
		xrXRC xrc;
		xrc.box_options(0);
		xrc.box_query(Level().ObjectSpace.GetStaticModel(), point, Fvector().set(VIEWPORT_NEAR,VIEWPORT_NEAR,VIEWPORT_NEAR) );
		u32 tri_count = xrc.r_count();
		if (tri_count)
		{
			_viewport_near = 0.01f;
		}
		else
		{
			xr_vector<ISpatial*> ISpatialResult;
			g_SpatialSpacePhysic->q_box(ISpatialResult, 0, STYPE_PHYSIC, point, Fvector().set(VIEWPORT_NEAR,VIEWPORT_NEAR,VIEWPORT_NEAR));
			for (u32 o_it=0; o_it<ISpatialResult.size(); o_it++)
			{
				CPHShell* pCPHS = smart_cast<CPHShell*>(ISpatialResult[o_it]);
				if (pCPHS)
				{
					_viewport_near = 0.01f;
					break;
				}
			}
		}
	}

 

из оригинального ТЧ 1.0007rc1 под vs2019: https://github.com/mortany/xray/blob/master/trunk/xr_3da/xrGame/ActorCameras.cpp#L227

 

Долго искал причину этого бага (всё из-за: _viewport_near = 0.01f;): https://www.youtube.com/playlist?list=PLNqMq1ELaaezZ_tM-nDFEjBmvaDUrhrtc

 

Заменил значение в 2-х строчках на 0.2f, как в дефайне VIEWPORT_NEAR, и глюки пропали, но всегда есть сомнения, починил одно - сломал другое.

 

В слитых исходниках за 2002 / 2007, в истории правок этого файла: 

9 Oct 2006 (этого блока ещё нет): https://github.com/ixray-team/xray-vss-archive/blob/267da766e8d90ed97268f32fc5a6704a667ff0a7/xr_3da/xrGame/ActorCameras.cpp#L229

14 Oct 2006 (уже частично есть): https://github.com/ixray-team/xray-vss-archive/blob/89ff124d62a040316956f63212ed9c7d418c10d2/xr_3da/xrGame/ActorCameras.cpp#L225

 

Чуть выше, в этом же файле:

Скрытый текст
	// Smooth out stair step ups
	if ((character_physics_support()->movement()->Environment()==peOnGround) && (flCurrentPlayerY-fPrevCamPos>0)){

Возможно ошибка, т.к. только здесь ==peOnGround, а в остальном коде ==CPHMovementControl::peOnGround, да и в ЗП также.

 

Ссылка на комментарий
5 hours ago, h0N0r said:

Мне же интересно, что делает это кусок кода:

Судя по всему - это такая реализация псевдо коллизии камеры. Если коробка вокруг камеры пересекается с чем-нибудь, со стеной например, то эта коробка принудительно уменьшается, что бы камера не заглядывала за стену. Я назвал это псевдо потому, что в ЗП это реализовано в рамках физики, т.е. коробка по настоящему взаимодействует с препятствиями.

  • Полезно 1
Ссылка на комментарий
08.07.2022 в 15:24, dsh сказал:

Судя по всему - это такая реализация псевдо коллизии камеры.

Так и есть, после правок - частичное проникновение за геометрию, но только при наклонах. Вспомнил, в ЗП бывает крутанёшь камеру (чуток или на 180) и можно увидеть мерцающий nosun.

Ссылка на комментарий

@macron ,

случайно нашёл (пока искал причину бага выше):

Скрытый текст
\xr_3da\xrGame\CarCameras.cpp

bool CCar::HUDView() const		
{
	// не считать режимом худа, если в тачке от 1-го лица
	return FALSE; //active_camera->tag==ectFirst;
}
...

void	CCar::OnCameraChange		(int type)
{
	if(Owner())
	{
		if	(type==ectFirst)
		{
			// Не скрывать игрока от 1-го лица
			Owner()->setVisible(TRUE); // FALSE
		}
		else if(active_camera->tag==ectFirst)
		{
			Owner()->setVisible(TRUE);
		}
	}
	...
}

 

И нужно менять анимации, а то одна рука на руле, другая, типа, с волыной. В stalker_animation.omf есть нормальные.

 

  • Спасибо 1
Ссылка на комментарий

Приветствую, надеюсь сюда попал. Какие правки отвечают за добавление в STCoP шейдера models_collimator и/или base_lplanes_fft и связан ли он со вторым вьюпортом? Хоть убейте, не найду ни одного упоминания. Вот например функция из папки shaders в base_lplanes_fft эта как вообще работает? И как они этот шейдер в SDK запихивали? Ну бог с SDK, что такое isCollimatorActive вообще, там ни одного слова collimator в движке нет даже. Или я не туда смотрю? 

Скрытый текст

    if(isCollimatorActive())
    {
        return  half4    (t_base.r,t_base.g,t_base.b,t_base.a * I.c0.a);
    }
    else
    {
        return  half4    (t_base.r,t_base.g,t_base.b,t_base.a * 0.0f);
    }

 

Изменено пользователем Last_Dawn
Ссылка на комментарий
4 часа назад, Last_Dawn сказал:

что такое isCollimatorActive вообще, там ни одного слова collimator в движке нет даже.

Я не спец по шейдерам, но у меня даже в том-же  base_lplanes_fft.ps есть такой кусок кода...

uniform	float4		m_hud_params;	// zoom_rotate_factor, secondVP_zoom_factor, NULL, NULL

inline bool isCollimatorActive()
{
	return (m_hud_params.z == 1.f);
}

Отсюда видно что isCollimatorActive это просто функция которая возвращает true если m_hud_params.z = 1.f, иначе false. А вот уже m_hud_params экспортируется в шейдеры откуда-то из движка, это точно. Откуда точно не помню. Насчет второго вьюпорта, не думаю что этот шейдер как-то с ним связан.

  • Спасибо 1
Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...