Beta testing 2.11

[stgatilov]

On 1/9/2023 at 7:22 AM, Daft Mugi said:

Well, I have good news and bad news.
The good news is that I cannot reproduce the crash.
The bad news is that I cannot reproduce the crash.

It's odd. The crash used to happen frequently when I was learning combat skills on the Training Mission using 2.10. Today, I spent more than an hour trying 2.10 with and without a debugger and 2.11 beta 5 with a debugger. No crash yet. I also had a recent crash in the flooded section of "A Good Neighbor" during combat a few weeks ago.

I managed to reproduce it: 6225
Yes, it is very hard to reproduce.

[Daft Mugi]

19 hours ago, Dragofer said:

Stgatilov recently improved GUI console warnings, so a lot of mistakes in various GUIs have been exposed.

That's a welcomed improvement.

Are the core assets being worked on to clean up these warning messages before 2.11 release?

[nbohr1more]

On 1/10/2023 at 1:03 AM, nbohr1more said:

While trying to find a good map to bisect against ( smaller mission ), I ran into repeated crashes in "COS: Pearls 'n Swine".

Back trace:

pearlsandswine_bt.txt 4.55 kB · 2 downloads

https://bugs.thedarkmod.com/view.php?id=6227

Cannot reproduce on rev 9985... moving forward

Rev 10036 is good... moving forward

Rev 10071 is good

Rev 10071 with  matching 16599 dev assets = good ( no crash )  ( maybe try to run the latest SVN with 16599 assets plus the blackjack patch assets ? )

Rev 10071 with 10107 assets = crash

Rev 10072 = crash ( all testing was done with 10107 assets, if 10071 crashes the next step might be

to revert assets too... that said, if 10107 asset changes are responsible TDM still shouldn't crash )

Rev 10073 = crash ( may need to retest 10071 )

Rev 10078 = crash

Rev 10092 = crash

Rev 10093 = crash

Rev 10095 = crash

Rev 10107 = crash

Nothing in Rev 10093 should cause a crash like this.

New backtrace seems similar to the old one but uses different hash lookup ?

Thread 11 "thedarkmod.x64" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffaf6bf700 (LWP 3026)]
idDict::FindKey (this=0x80, key=key@entry=0x12e8bfb "pre_pickup_origin")
    at /home/user/tdm_src/new/piggie/darkmod_src/idlib/Dict.cpp:462
462        for ( int i = argHash.First( hash ); i != -1; i = argHash.Next( i ) ) {
(gdb) bt
#0  idDict::FindKey (this=0x80, key=key@entry=0x12e8bfb "pre_pickup_origin")
    at /home/user/tdm_src/new/piggie/darkmod_src/idlib/Dict.cpp:462
#1  0x000000000074f67a in idDict::GetString (out=<synthetic pointer>,
    defaultString=0x12995cc "0 0 0", key=0x12e8bfb "pre_pickup_origin",
    this=<optimized out>)

Going back to 10092 to see if I missed the crash somehow. Yep, same crash there. Rolling back to an earlier one...

Ran outta time. I will continue tomorrow ( unless someone else wants to build from source and bisect between 10071 and 10078 )

[Dragofer]

3 hours ago, Daft Mugi said:

That's a welcomed improvement.

Are the core assets being worked on to clean up these warning messages before 2.11 release?

No, I dont have time to fix them at the moment, and I think a lot of FMs that use custom briefing GUIs are affected by numerous new warnings, too.

[nbohr1more]

23 hours ago, nbohr1more said:

https://bugs.thedarkmod.com/view.php?id=6227

Cannot reproduce on rev 9985... moving forward

Rev 10036 is good... moving forward

Rev 10071 is good

Rev 10071 with  matching 16599 dev assets = good ( no crash )  ( maybe try to run the latest SVN with 16599 assets plus the blackjack patch assets ? )

Rev 10071 with 10107 assets = crash

Rev 10072 = crash ( all testing was done with 10107 assets, if 10071 crashes the next step might be

to revert assets too... that said, if 10107 asset changes are responsible TDM still shouldn't crash )

Rev 10073 = crash ( may need to retest 10071 )

Rev 10078 = crash

Rev 10092 = crash

Rev 10093 = crash

Rev 10095 = crash

Rev 10107 = crash

Nothing in Rev 10093 should cause a crash like this.

New backtrace seems similar to the old one but uses different hash lookup ?

Thread 11 "thedarkmod.x64" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffaf6bf700 (LWP 3026)]
idDict::FindKey (this=0x80, key=key@entry=0x12e8bfb "pre_pickup_origin")
    at /home/user/tdm_src/new/piggie/darkmod_src/idlib/Dict.cpp:462
462        for ( int i = argHash.First( hash ); i != -1; i = argHash.Next( i ) ) {
(gdb) bt
#0  idDict::FindKey (this=0x80, key=key@entry=0x12e8bfb "pre_pickup_origin")
    at /home/user/tdm_src/new/piggie/darkmod_src/idlib/Dict.cpp:462
#1  0x000000000074f67a in idDict::GetString (out=<synthetic pointer>,
    defaultString=0x12995cc "0 0 0", key=0x12e8bfb "pre_pickup_origin",
    this=<optimized out>)

Going back to 10092 to see if I missed the crash somehow. Yep, same crash there. Rolling back to an earlier one...

Ran outta time. I will continue tomorrow ( unless someone else wants to build from source and bisect between 10071 and 10078 )

WOO!!!

Updated to the latest SVN binary, using the 10071 assets.

At first it crashed on an AI Base Tactile error.

I copied the latest scripts and def folder from SVN and it started but the crash happened soon after.

I removed the def folder and it the crash could not be repeated. Time to step through def folder revisions!

Def rev 16602 = no crash

Def rev 16603 = crash ... I think got you!!

tdm_prop_items.def rev 16603 appears to be the culprit....

Yes, there seems to be some relation between the sitting animations and the AI who happens to have pickup twice in the name of the target bottle?

Spoiler

// entity 2540
{
"classname" "atdm:ai_thief01"
"name" "atdm_ai_townsfolk_commoner_2"
"comment" "Sits and plays idle sitting animations until hitting 'bottle_pickup', then plays drin-and-stare animations until hitting 'bottle_putdown', where the cycle continues."
"def_head" "atdm:ai_head_thief_hooded"
"def_vocal_set" "atdm:ai_vocal_set_mute"
"drink" "and"
"idle_animations_interval" "8"
"idle_animations_sitting" "bottle_pickup,idle_sit_2,idle_sit,idle_sit_tap01,idle_sit_cough01,idle_sit_armdrop01"
"is_civilian" "1"
"origin" "926.19 2753.79 -546"
"pickup_bottle_pickup" "drinking_bottle"
"rotation" "-0.403608 -0.914932 0 0.914932 -0.403608 0 0 0 1"
"shouldered_name" "Fen"
"shouldered_name_dead" "Fen's Corpse"
"sitting" "1"
"skin" "commoner/default_leathergreaves"
"team" "5"
}

 

[AluminumHaste]

Nice work!

[The Black Arrow]

Hey, I got one question for now; how can I test Volumetric Rays when I can't find any?

The three official missions don't seem to have any, can any of you suggest a map, or two, or hell every map known that uses Volumetric Maps?

Always liked those things, I want to give it a proper try, the more maps to try on the better.

[Daft Mugi]

27 minutes ago, The Black Arrow said:

The three official missions don't seem to have any, can any of you suggest a map, or two, or hell every map known that uses Volumetric Maps?

• Hazard Pay
• Iris
• Written in Stone
• Noble Affairs

You can bind a key to toggle volumetric lights off and on, if you'd like.

bind "]" "toggle r_volumetricEnable; reloadModels"

 

Edited January 13, 2023 by Daft Mugi

[datiswous]

Btw. you can make a DR filter to filter everything away except volumetric lights, so you could check a map on them. Maybe still too much work though.

 

12 hours ago, Daft Mugi said:

• Hazard Pay
• Iris
• Written in Stone
• Noble Affairs

Maybe more (technical) features should be listed here in a separate column:

https://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod

Edited January 13, 2023 by datiswous

[Araneidae]

The latest beta (2.11-5?) seems to be ignoring my autoexec.cfg file.  The first two lines are:

seta r_fboColorBits "32"
seta tdm_mainmenu_confirmquit "0"

and it's kind of pretty obvious when these are missing!

This was working on the previous beta, so something subtle has changed in this area.

I do notice the following message in the console output:

Couldn't exec autocommands.cfg - file does not exist.

Has the filename being looked for changed?

Edit: Certainly adding a soft link (`ln -s`) from autocommands.cfg to autoexec.cfg seems to fix the issue.

Edit: Oh, but now the log is full of

Unknown command '#'

messages.  Are commands comments not supported now?  (Don't remember seeing this before...)

Edited January 14, 2023 by Araneidae

[Daft Mugi]

17 minutes ago, Araneidae said:

The latest beta (2.11-5?) seems to be ignoring my autoexec.cfg file.

Use "autocommands.cfg" instead of "autoexec.cfg".

Comments begin with "//" instead of "#".

Does that work for you?

[AluminumHaste]

@Araneidae Is there a reason you use 32bit instead of 64bit color precision?

[MirceaKitsune]

44 minutes ago, AluminumHaste said:

@Araneidae Is there a reason you use 32bit instead of 64bit color precision?

As a general note, 32bit increases FPS quite a bit over 64bit on some FM's for me. It's the only reason why I also use it. Only disadvantage is some ugly color banding in dark areas.

[AluminumHaste]

@MirceaKitsune

Do you have an example I could test for myself?

 

[Araneidae]

1 hour ago, AluminumHaste said:

@Araneidae Is there a reason you use 32bit instead of 64bit color precision?

Oh yes.  My graphics card (an elderly HD6950 if I remember correctly) produces messed up graphics when 64-bit colour precision is selected.  Unfortunately there seems to be a graphics driver bug, this was discussed at some length on this forum about a year ago.

[Araneidae]

1 hour ago, Daft Mugi said:

Use "autocommands.cfg" instead of "autoexec.cfg".

Comments begin with "//" instead of "#".

Sure (though haven't tried the // comments yet), but I was a bit surprised to see autoexec.cfg suddenly stop working halfway through the beta cycle -- what's changed?

[AluminumHaste]

@AraneidaeHave you tried 64 bit color with the most recent 2.11 beta?

I had issues with it also that were fixed on my AMD card.

EDIT: I just pulled out my old Alienware M17x R1 from 2008, has an Mobility HD5870, and while Iris runs at 8 fps, there's no graphics corruption that I can see from 32-64bit colour.

[Daft Mugi]

2 hours ago, Araneidae said:

Sure (though haven't tried the // comments yet), but I was a bit surprised to see autoexec.cfg suddenly stop working halfway through the beta cycle -- what's changed?

Looking at the source code and the core pk4 asset files, I don't see any changes that would make a difference.

Does this happen with a single FM? Does the FM pk4 file include an "autoexec.cfg" file?

From the source code, here's the load order of config files.

    exec default.cfg
    exec Darkmod.cfg
    exec DarkmodKeyboard.cfg
    exec DarkmodPadbinds.cfg
==> exec autoexec.cfg
    <load language>
    <exec command-line arguments>
    <init input>
    <init sound>
    <init OpenGL>
    <init ui>
    <load DLL>
    <init session>
==> exec autocommands.cfg

Details about the addition of "autocommands.cfg" are at https://bugs.thedarkmod.com/view.php?id=3199

I thought "autocommands.cfg" was the right way to do it, because that is what I've read on the forums. It seems that "autocommands.cfg" was originally designed for one use case: running "dmap".

However, maybe over time "autocommands.cfg" became the de facto config file for user commands and "autoexec.cfg" became the config file for FM authors to use. I don't know. Does anyone know for a fact whether or not this is the case?

Edited January 14, 2023 by Daft Mugi

[AluminumHaste]

autoexec.cfg and autocommands.cfg are loaded at different parts of TDM loading.

I don't know exactly when though.

EDIT:

Yeah, autocommands.cfg is the last thing that loads in the init order.

 

    // tels: #3199: now that the game DLL is loaded, we can execute another config, this
    // enables it to run f.i. dmap (dmap before DLL load produces no AAS):
    cmdSystem->BufferCommandText( CMD_EXEC_APPEND, "exec autocommands.cfg\n" );

 

autoexec.cfg is loaded way earlier.

 

 

    cmdSystem->BufferCommandText( CMD_EXEC_APPEND, "exec default.cfg\n" );

    // skip the config file if "safe" is on the command line
    if (!SafeMode())
    {
        // if any config file does not exist, ignore it and only use "default.cfg".
        // Darkmod.cfg and DarkmodKeybinds.cfg will be written upon exit
        if (fileSystem->FindFile(CONFIG_FILE) != FIND_NO) {
            cmdSystem->BufferCommandText(CMD_EXEC_APPEND, "exec " CONFIG_FILE "\n");        // Darkmod.cfg
            
        }
        if (fileSystem->FindFile(KEYBINDS_FILE) != FIND_NO) { // STiFU #4797
            cmdSystem->BufferCommandText(CMD_EXEC_APPEND, "exec " KEYBINDS_FILE "\n");        // DarkmodKeybinds.cfg
        }
        if (fileSystem->FindFile(PADBINDS_FILE) != FIND_NO) {
            cmdSystem->BufferCommandText(CMD_EXEC_APPEND, "exec " PADBINDS_FILE "\n");
        }
    }
    cmdSystem->BufferCommandText( CMD_EXEC_APPEND, "exec autoexec.cfg\n" );

[MirceaKitsune]

2 hours ago, AluminumHaste said:

@MirceaKitsune

Do you have an example I could test for myself?

 

I forgot which FM I saw it on. I know it improved by some 5 FPS or more. If I see it again I'll try taking comparison screenshots.

[Araneidae]

14 hours ago, AluminumHaste said:

@AraneidaeHave you tried 64 bit color with the most recent 2.11 beta?

Yes, that's how I knew my autoexec.cfg wasn't working anymore; setting 32 bit colour is the very first line in that file!

[AluminumHaste]

What does it look like? What's the bug?

[Araneidae]

44 minutes ago, AluminumHaste said:

What does it look like? What's the bug?

I had go hunting back quite a long way to find my initial report of the bug, but here it is (there's quite a bit of conversation following, mixed with a bunch of other 2.09 beta stuff):

followed here:

Actually, going back is pretty confusing, and I don't seem to be able find my original message about the screen being messed up.

This hasn't changed very much when I just inadvertently tried it, though this time it was the top half of the screen that was scrambled rather than the right hand side.

[AluminumHaste]

Yeah that's F'ed up.

That's still happening?

[Araneidae]

Just now, AluminumHaste said:

Yeah that's F'ed up.

That's still happening?

Alas, yes.