View Issue Details

IDProjectCategoryView StatusLast Update
0004613The Dark ModAIpublic04.09.2017 02:01
Reporternbohr1more Assigned Tograyman  
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.06Fixed in VersionTDM 2.06 
Summary0004613: Unexpected supernatural event in "The Golden Skull"
DescriptionSpoiler alert! This bug reveals a major plot point of Sotha's mission "The Golden Skull"

Somehow, the zombified fiance of the protagonist was triggered to awaken from her torture chamber and escape to massacre the inhabitants of the manor almost as soon as the mission started. I was terrified by this unexpected violation of the intended story progression so I'd almost count this as a feature.
Steps To Reproduce1) Start "The Golden Skull"
2) Step a few paces
3) Hear the protagonist wail about "What have I done"
4) Hear and see the Zombie girlfriend massacre the household
TagsNo tags attached.


related to 0002427 resolvedstgatilov Broken SIMD Support on Linux 
related to 0004610 resolvedstgatilov Severe slowdown and "No valid points found" spam from the hiding spot code (extremely intermittent) 




29.08.2017 02:32

developer (633,974 bytes)


29.08.2017 14:16

viewer   ~0009118

Last edited: 29.08.2017 14:19

I need a savegame _before_ the girlfriend wakes up.

Edit: Nevermind. Last night I couldn't reproduce it, but it happened first try this morning.



29.08.2017 15:22

viewer   ~0009119

The zombie is colliding with one of the upstairs females. ?????????

Both get upset, and start searching.

When the zombie leaves her room to search, the opening door triggers the voiceover and the zombie starts her way upstairs to slaughter everyone.


29.08.2017 19:02

viewer   ~0009120

The female AI named 'atdm_ai_townsfolk_female_1' is banging into everyone as she moves around, even those that are > 1000 units away from her.

Looks like something's gone wrong with her clipmodel.


29.08.2017 20:53

viewer   ~0009121

The problematic maid's clipmodel looks fine for a little while at mission start, then at random times, it becomes garbage. When that happens, the way the code is written, she is considered to be touching every other AI in the map. When she touches the zombie, they are enemies, so both get alerted.

No sense yet of where the corruption occurs or why.


30.08.2017 01:59

developer   ~0009123

I pinged Cabablistic in case this is a threading issue. May need to enforce atomic_thread_fence in trace model cache.


30.08.2017 02:13

viewer   ~0009124

Is there a cvar for reverting to non-thread behavior?

The garbage usually appears w/in a minute of starting the mission, so it should be evident that threading is the issue if several tests can be made where the garbage doesn't appear for 5min or more.


30.08.2017 02:27

developer   ~0009125

com_smp 0

is supposed to disable threading.


30.08.2017 03:47

developer   ~0009126

Unless com_smp doesn't work as advertised, I have reproduced the bug with threading disabled.


30.08.2017 11:26

viewer   ~0009127

At the moment the problem first occurs, I get these values:

cm->GetEntity()->GetPhysics()->GetAbsBounds() = [-1567,-9,8] -> [-1533,24,78]

cm->GetAbsBounds() = [-1.#IND00,-1.#IND00,-1.#IND00] -> [-1.#IND00,-1.#IND00,-1.#IND00]

"cm" is the clipmodel for atdm_ai_townsfolk_female_1, and the value snapshot occurs in idAF::EntitiesTouchingAF() (roughly line 366 in AF.cpp), where a search is going on to find entities colliding with an AI.

I would have thought that the clipmodel absolute bounds and the bounding box actual bounds would be identical or close.

The actual coordinates of the female are irrelevant. I've seen the problem first appear at various points as she follows her RIT path.


30.08.2017 13:03

viewer   ~0009128

Looking at the same values in 2.05, I see this:

cm->GetEntity()->GetPhysics()->GetAbsBounds() = [-1979,-369,7] -> [-1945,-335,77]

cm->GetAbsBounds() = [-1979,-369,7] -> [-1945,-335,77]

So I was correct in expecting these bounds to be the same.


30.08.2017 13:52

viewer   ~0009129

After reading 4521, I reverted TDM back to 14790/6866 and built the binaries.

The problem observed here still happens, so it appears to have nothing to do with st's changes in 6867-6869.

Will go back further.


30.08.2017 16:29

viewer   ~0009130

Last edited: 30.08.2017 16:35

The root cause of the problem lies in rev 6842, whose comment says:

"Removed most of the floating point hacks from the FPU days.
This takes effect only if SSE/SSE2 arithmetic is used (which is actually always used now)."

Will PM st to take a look.



03.09.2017 15:44

administrator   ~0009132

Coulod you please check if it can be reproduced after revision 7103?

To be honest, I did not manage to reproduce the issue myself =(
But I tried to fix one possible source of NaN-s.


03.09.2017 18:26

viewer   ~0009133

I built binaries with rev 7104 (the latest), and ran the mission for 10 minutes w/o seeing the problem. Since it always occurred when I was testing, I consider this fixed.

@NB: If you could confirm this, then we can close it out.


Issue History

Date Modified Username Field Change
29.08.2017 02:30 nbohr1more New Issue
29.08.2017 02:30 nbohr1more Status new => assigned
29.08.2017 02:30 nbohr1more Assigned To => grayman
29.08.2017 02:32 nbohr1more File Added:
29.08.2017 14:16 grayman Note Added: 0009118
29.08.2017 14:19 grayman Note Edited: 0009118
29.08.2017 15:22 grayman Note Added: 0009119
29.08.2017 19:02 grayman Note Added: 0009120
29.08.2017 20:53 grayman Note Added: 0009121
30.08.2017 01:55 nbohr1more Relationship added related to 0004610
30.08.2017 01:59 nbohr1more Note Added: 0009123
30.08.2017 02:13 grayman Note Added: 0009124
30.08.2017 02:27 nbohr1more Note Added: 0009125
30.08.2017 03:47 nbohr1more Note Added: 0009126
30.08.2017 11:26 grayman Note Added: 0009127
30.08.2017 13:01 nbohr1more Relationship added related to 0004521
30.08.2017 13:03 grayman Note Added: 0009128
30.08.2017 13:52 grayman Note Added: 0009129
30.08.2017 16:29 grayman Note Added: 0009130
30.08.2017 16:30 nbohr1more Relationship deleted related to 0004521
30.08.2017 16:35 grayman Note Edited: 0009130
30.08.2017 16:58 nbohr1more Relationship added related to 0002427
03.09.2017 15:44 stgatilov Note Added: 0009132
03.09.2017 18:26 grayman Note Added: 0009133
03.09.2017 18:26 grayman Status assigned => feedback
03.09.2017 18:26 grayman Resolution open => fixed
03.09.2017 18:26 grayman Fixed in Version => TDM 2.06
04.09.2017 02:01 nbohr1more Status feedback => resolved