Fatal error....error about xray-16

[avoitishin]

Yes I am aware of this but since its very rare so I ignored it. Its a byproduct of removing bug trap and I will fix it sometime soon.

[BeaconDev]

I'm getting this too, quite frequently actually. Seems like it always gives a stack trace: error in the log too, so I can't even really figure out what's wrong.

Most recently, this was the stack trace, I can't fathom what it is.

stack trace:

0023:0028C084 xrCore.dll, CInifile::r_s16()
stack trace:

0023:0028C084 xrCore.dll, CInifile::r_s16()

Is it possible we can upgrade the priority on this? With some recent changes I've made the game is now unplayable as this crash happens a lot, and since it leaves no useful error log when it does this I can't troubleshoot.

[BeaconDev]

It's definitely the custom binaries, it doesn't happen with the originals. Would be great to get it sorted.

[avoitishin]

Do you have steps to reproduce? I didn't get this error in a while

p.s. you can also uncomment //# define USE_BUG_TRAP in xrDebugNew.cpp to get vanilla error handling back if this is really that critical for you

[revolucas]

I have no issues with it either and I crash quite frequently. Only rarely does it say "Critical Error" which then you have to open task manager and terminate xrEngine. But even so it is still much faster than having bugtrap enabled and sometimes with bugtrap you can't even open task manager because the screen locks.

[BeaconDev]

I can't reproduce it, it's totally random when playing.

The problem for me is not the infinite-looping-ness of it, that's solved by an (annoying, granted) task manager hard close (which I'm very familiar with), it's that the crash just doesn't happen without the custom bins.

[Highflex]

BeaconDev, can you describe the situation/scene before crashing? You say its random, so no pattern or specific area?

I have been experimenting with the debug binaries, besides being very slow i was able to step through code in visual studio which allowed me to understand some systems much better.

[BeaconDev]

Like I said, it's totally random as far as I can tell. I'll do some testing now and see if I can get it to happen again.

[Highflex]

Okay, i have been running this branch for some weeks with different mods to check stability, so far Misery/Arsenal and Complete did not crash once on me.

[avoitishin]

@Highflex you can step through code with release binaries as well :). If some functions get inlined/optimized you can wrap it with below to temporarily disable optimization:

#pragma optimize( "", off )
.
.
.
#pragma optimize( "", on )

[Highflex]

Just tried that out, works good :) thanks for the hint,

i tend to step through code quite often, as this is a massive codebase it helps understanding some parts.

[revolucas]

I think there is confusion here. Whatever is causing your crash may not be related to the disabled bug trap feature. All this feature does is removes bugtrap, the side effect is that some errors will cause the FATAL ERROR message box that won't go away. This is the symptom, not the cause of whatever the crash is.

[revolucas]

Okay, Beacon, I took a look in code of everything that reads from ini using r_s16().

static int goodwill_enemy   = pSettings->r_s16(GAME_RELATIONS_SECT, "goodwill_enemy");
static int goodwill_neutral = pSettings->r_s16(GAME_RELATIONS_SECT, "goodwill_neutal");
static int goodwill_friend  = pSettings->r_s16(GAME_RELATIONS_SECT, "goodwill_friend");
static int attitude_neutral = pSettings->r_s16(GAME_RELATIONS_SECT, "attitude_neutal_threshold");
static int attitude_friend = pSettings->r_s16(GAME_RELATIONS_SECT, "attitude_friend_threshold");
m_iPrefferedFireMode = READ_IF_EXISTS(pSettings, r_s16, section, "preffered_fire_mode", -1);

To be on the safe side and cover all our bases, check your configs (game_relations.ltx) to make sure the values for these variables range from −32,768 to 32,767. Everything also must have a value, they can't be empty or have values that cannot translate into a number - which can be due to typo or bad comment line, etc.

If you added any communities make sure the cross table is not missing anything. Make sure they are in the exact order defined in communities list directly above. In CoC we added 10 new communities and are not having issues like you or Swartz. I don't think engine would crash with r_s16 without a reason.

That is all that uses ini_file:r_s16, except some multiplayer stuff. So if you removed any multiplayer files, that could be possible cause.

I noticed with the new binaries that gamedata is processed differently, which could be due to the different compiler. We had an issue, for example, with the main logo being missing on the UI when using the VS2013 source. Turns out it was because we had a duplicate texture descr that was undetected by the vanilla binaries and our VS2008 binaries. OpenXray is more out spoken when there are errors.

This means if there is an issue with the new binaries, that they are not the problem per se, it could be a symptom of a problem that goes undetected by the old binaries. For now I'm unsure what could cause your issue. CoC has about a dozen testers and haven't come across anything similar. But If we do I will notify you or try my best to further assist you.

If you haven't already create a shortcut to xrEngine.exe using the -dbg -skiplogo command line with the 'Start In' path to your main game directory, with fsgame.ltx. This should give you extra logging that could possibly point out the actual cause to the error.

[BeaconDev]

H Alun,

Thanks for the in-depth response. I've checked through my game_relations.ltx and checked all the values for the variables you noted, and they all seem fine to me, along with a seemingly normal cross table. 'preffered_fire_mode' isn't present in any files in our gamedata, so it must be read from the vanilla file which hasn't been changed.

Here's my game_relations.ltx if you want to take a look, because I can't find anything amiss.

http://puu.sh/eMdRP/05713e80ec.ltx

Regarding the -dbg shortcut, it's not working. http://puu.sh/eMdUB/b3c808f9f8.png

I've also tried altering the Steam launch options and adding '-dbg', but the game .exe doesn't even launch, even though Steam says I'm playing the game for 5 seconds before realising it's not even open.

[avoitishin]

Which exe are you trying to start with -dbg?

[BeaconDev]

xrEngine.exe shortcut, moved to CoP Root.

[avoitishin]

Delete shortcut and create simple start.cmd file in COP root with something like

@echo off
@start bin\xrEngine.exe -dbg -skiplogo

[BeaconDev]

Thanks, that works when I use Highflex's bins so I guess when I get working bins from Swartz again it'll work with those too.
I'll do some testing and see if I can get more info when I crash with this error next time thanks to -dbg.

[avoitishin]

What is wrong with bins Swartz sent you?

One more suggestion I have for you is to stop using legacy IsStalker and company, and start utilizing new engine methods. For example:

if (obj and obj:is_stalker())   
-- do it   
end

[BeaconDev]

The crash on start I noted in the issue about 'video card doesn't meet game requirements'.

Thanks for the suggestion, that's not a bad option, but we're not quite ready to totally switch to using modified bins yet and using the new engine methods would mean we'd have to. If Alun can't think of anything else then maybe we'll have to.