2.10 Crashes - May be bow \ frontend acceleration related

[snatcher]

10 hours ago, stgatilov said:

Nobody should ever play in no-save mode!

If you want "ironman" experience, better play in no-load mode.

Let's agree to disagree. Software crash and thunders strike but this isn't the point because I already accepted failure as part of the deal. Games like The Dark Mod are at their peak when the stakes are high and psychologically, there's a big difference between no-save and no-load modes.

Anyone that likes this game should at least try once: pick a small mission and see how far you get without saving. The longer you venture into the mission the higher the stakes, the costlier the risks. Your comfort zone soon goes out of the window and you start thinking twice... will I pull this off?. Training and experience will certainly make a difference but you cannot do this on your own and you start valuing each and every skill, tool and trick at your disposal. You know you will fail, the question is when.

Now, does anything change if I save every now and then?

Edited October 29 by snatcher
Addition of quote because of new page

[AluminumHaste]

Oh I get your point for sure, but I don't have time for that anymore, if I spent day an hour playing iron man mode and does it failed, I just wouldn't play that mission again.

[snatcher]

22 hours ago, AluminumHaste said:

Just use the dev from now on, no point in troubleshooting something that might have been fixed already.

I just managed to make 2.12 dev16829-10455 crash.

[AluminumHaste]

What does your darkmod.log file say?

[snatcher]

Sorry it's a new install and I didn't change yet any of the log settings you recommended.

Darkmod.log:

Spoiler

[/game/DarkModGlobals.cpp ( 365):INI (INIT) GT:    0] LogFile created at 2023.10.29 21:17:36
[/game/DarkModGlobals.cpp ( 368):INI (INIT) GT:    0] Executable last cleaned and rebuilt on Sep 28 2023 21:01:29
[/game/DarkModGlobals.cpp ( 371):INI (INIT) GT:    0] The Dark Mod 2.12/64, code revision 10455 (1435:10455)
[/game/DarkModGlobals.cpp ( 417):FRC (FORCE) GT:    0] LogBegin: 0
[/game/DarkModGlobals.cpp ( 417):FRC (FORCE) GT:    0] LogEnd: 0
[/game/DarkModGlobals.cpp ( 417):FRC (FORCE) GT:    0] LogInfo: 0
[/game/DarkModGlobals.cpp ( 417):FRC (FORCE) GT:    0] LogDebug: 0
[/game/DarkModGlobals.cpp ( 417):FRC (FORCE) GT:    0] LogWarning: 0
[/game/DarkModGlobals.cpp ( 417):FRC (FORCE) GT:    0] LogError: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_FRAME: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_SYSTEM: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_MISC: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_FROBBING: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_AI: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_SOUND: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_FUNCTION: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_ENTITY: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_INVENTORY: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_LIGHT: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_WEAPON: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_MATH: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_MOVEMENT: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_STIM_RESPONSE: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_OBJECTIVES: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_DIFFICULTY: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_CONVERSATION: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_MAINMENU: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_LOCKPICK: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_AAS: 0
[/game/DarkModGlobals.cpp ( 427):FRC (FORCE) GT:    0] LogClass_STATE: 0

 

 

[AluminumHaste]

Well yeah, your darkmod.ini wasn't changed so the log file won't have captured anything.

 

Change the darkmod.ini:

 

LogError=0 to LogError=1

also maybe try

 

LogClass_STATE=0 to LogClass_STATE=1

LogClass_SYSTEM=0 to LogClass_SYSTEM=1

LogClass_ENTITY=0 to LogClass_ENTITY=1

 

 

Then when the game crashes TDM should log the errors.

Might give some info if you haven't done this already.

[snatcher]

14 minutes ago, AluminumHaste said:

Then when the game crashes TDM should log the errors.

 

Where, please? I can't find anything neither in the root nor in the fm folder.

 

[snatcher]

Shouldn't I set, in addition, something like what stgatilov suggested in the past?

• Set "logfile 2" so that all console text is recorded.
• Reproduce the crash.
• Find qconsole.log in the FM directory and post it here.

 

[AluminumHaste]

Sorry forgot about that

[stgatilov]

21 hours ago, snatcher said:

I just managed to make 2.12 dev16829-10455 crash.

Yes indeed, I would be surprised if it fixed by itself.

20 hours ago, AluminumHaste said:

What does your darkmod.log file say?

This log files is rather useless in most cases.
By the thing is: in case of bow crash, you won't see anything useful in console log either.

We already know that bow attachments (or something like that) are unexpectedly killed by tdm_suicide script, but I have no freaking idea why this script runs. The chain of events is long, looking at things at the moment of crash won't help.

[AluminumHaste]

Weird, I always use the bow attached aimer since it was introduced, and can't recall that crashing.

[AluminumHaste]

Could it be something as simple as the arrow being drawn in the bow animation, isn't the same object being shot, and the arrow being drawn is destroyed at the same time as the player releases the attack button?

[snatcher]

21 minutes ago, stgatilov said:

This log files is rather useless in most cases.
By the thing is: in case of bow crash, you won't see anything useful in console log either.

Seems true. I set logfile 2 in the console and I changed all =0 to =1 in darkmod.ini: fm/xxx/qconsole.log shows nothing relevant that I can detect.

11 minutes ago, AluminumHaste said:

Weird, I always use the bow attached aimer since it was introduced, and can't recall that crashing.

I can make it crash with and without the aimer.

[AluminumHaste]

Ok, make sure to set those all back to =0 or you can get some performance degradation. At least I used to with leaving those all on.

[snatcher]

2 hours ago, stgatilov said:

We already know that bow attachments (or something like that) are unexpectedly killed by tdm_suicide script, but I have no freaking idea why this script runs.

Indeed. I added some print outs to tdm_suicide.script and the very last thing I get in the log before the crash is:

 *** AFTER sys.wait( time_to_live ): idStaticEntity_atdm:attachment_aimer_7
 *** AFTER activateTargets(self): idStaticEntity_atdm:attachment_aimer_7

Code:

Spoiler

void tdm_suicide::init()
{

sys.println(" *** BEGIN: " + getName());

    float time_to_live = getFloatKey("remove_delay"); if (time_to_live < 0) { time_to_live = 360; }
    //sys.print ( "waiting " + time_to_live + " seconds until I kill myself.\n" );
    sys.wait( time_to_live );

sys.println(" *** AFTER sys.wait( time_to_live "  + getName());

    // activate our targets
    activateTargets(self);

sys.println(" *** AFTER  activateTargets(self): "  + getName());

    // TODO: optionally wait until this object is no longer in the same PVS as the player?

    // kill ourselves
    remove();
}

Edited October 30 by snatcher

[stgatilov]

I have an idea.

From time to time, these kind of guard create a penis during animation.
This penis creates a thread during spawn, but it starts it as DelayedStart(0 ms).
Instead of running the script immediately, it stores its entityNumber onto the callstack of the script thread.
Let's suppose that for some reason penis gets destroyed immediately, and bow attachment gets spawned at this exact moment: then the bow attachment reuses entityNumber of the penis.
At some moment suicide thread wakes up, reads entityNumber from stack, and kills the entity with this index --- but now it is bow attachment instead of penis.
That's a simple explanation why dangling pointers are dangerous!

However, if this really works like this, the whole scripting should be completely broken, since scripts in general often wait long time, and all the entities they reference might die during waiting. I can hardly believe this situation is always handled that bad.

I'd like to ask people who have used scripting a lot.
What happens if you have a local variable X of type "entity", then you do "sys.wait(1.0);", and then try to use X but it has died during waiting?

[stgatilov]

On 8/27/2023 at 1:46 PM, stgatilov said:

I built a custom TDM 2.11 executable with console logging when entity is attached and destroyed:

• https://drive.google.com/drive/folders/1gdXD9nugu4rgHwCIx-KX3ZefdteHizjI?usp=sharing

So you can do the following:

1. Unpack both files to TDM game directory.
2. Run thegame with new executable.
3. Set "logfile 2" so that all console text is recorded.
4. Reproduce the crash.
5. Find qconsole.log in the FM directory and post it here.

When this is over, make sure to revert cvar "logfile" back to its default value, and run tdm_installer to recover old executable if you didn't save it.

I created third version of debug executable (for TDM 2.11).

Could someone please reproduce the crash again and post new console log?

[snatcher]

Here: https://www.mediafire.com/file/kllcm82v92w751h/qconsole_202310311032.zip/file

[AluminumHaste]

Snatched sorry for the dumb question, but you're testing this on a fresh virgin TDM right? No mods installed?

[snatcher]

No dumb questions from you.

I get the game to crash with and without mods but I don't use mods for these tests.

I did manage to crash a fresh virgin 2.12 pretty easily. My TDM 2.11 isn't fresh but I make sure no modifications are present during the tests.

[AluminumHaste]

I've been trying to reproduce this also, but I can't, have you or anyone else recorded a video demonstrating it?

[snatcher]

Sorry, I don't do videos.

The crash is triggered at a very specific moment, always when starting fire. You miss that moment and the game won't crash, I understand.

Lieutenant 2: High Expectations is the best testbed. Spawn some broadheads and start doing any of the below in any order you want (but very fast):

• Raise broadheads and pretend to fire (press fire and quickly abort)
• Switch to Water arrows and pretend to fire
• Lower Bow
• Raise Blackjack
• Switch to Bow and pretend to fire
• ...

It eventually crashes here.

[nbohr1more]

2 hours ago, snatcher said:

Sorry, I don't do videos.

The crash is triggered at a very specific moment, always when starting fire. You miss that moment and the game won't crash, I understand.

Lieutenant 2: High Expectations is the best testbed. Spawn some broadheads and start doing any of the below in any order you want (but very fast):

• Raise broadheads and pretend to fire (press fire and quickly abort)
• Switch to Water arrows and pretend to fire
• Lower Bow
• Raise Blackjack
• Switch to Bow and pretend to fire
• ...

It eventually crashes here.

You deleted the mission and downloaded the latest one right? (original releases were bugged due to path structure in the pack file )

[snatcher]

2 hours ago, nbohr1more said:

You deleted the mission and downloaded the latest one right? (original releases were bugged due to path structure in the pack file )

I made High Expectations crash in my fresh virgin 2.12 so I don't think the version of the mission matters BUT it turned out I didn't have the latest version of the mission in TDM 2.11 because of the weird versioning thing going on with the built-in downloader.

So I deleted the mission and downloaded the version offered by the downloaded and managed to get a new crash: https://www.mediafire.com/file/9nuvomhqkucup0t/qconsole_202310311733.zip/file

[snatcher]

Here's one from Iris: https://www.mediafire.com/file/r1s9odtnti325wf/Iris_qconsole_202310311826.zip/file