View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004613||The Dark Mod||AI||public||29.08.2017 02:30||04.09.2017 02:01|
|Target Version||TDM 2.06||Fixed in Version||TDM 2.06|
|Summary||0004613: Unexpected supernatural event in "The Golden Skull"|
|Description||Spoiler 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 Reproduce||1) 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
|Tags||No tags attached.|
golden206.save (633,974 bytes)
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.
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.
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.
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.
|I pinged Cabablistic in case this is a threading issue. May need to enforce atomic_thread_fence in trace model cache.|
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.
is supposed to disable threading.
|Unless com_smp doesn't work as advertised, I have reproduced the bug with threading disabled.|
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.
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.
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.
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.
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.
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.
|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: golden206.save|
||Note Added: 0009118|
||Note Edited: 0009118||View Revisions|
||Note Added: 0009119|
||Note Added: 0009120|
||Note Added: 0009121|
|30.08.2017 01:55||nbohr1more||Relationship added||related to 0004610|
|30.08.2017 01:59||nbohr1more||Note Added: 0009123|
||Note Added: 0009124|
|30.08.2017 02:27||nbohr1more||Note Added: 0009125|
|30.08.2017 03:47||nbohr1more||Note Added: 0009126|
||Note Added: 0009127|
|30.08.2017 13:01||nbohr1more||Relationship added||related to 0004521|
||Note Added: 0009128|
||Note Added: 0009129|
||Note Added: 0009130|
|30.08.2017 16:30||nbohr1more||Relationship deleted||related to 0004521|
||Note Edited: 0009130||View Revisions|
|30.08.2017 16:58||nbohr1more||Relationship added||related to 0002427|
|03.09.2017 15:44||stgatilov||Note Added: 0009132|
||Note Added: 0009133|
||Status||assigned => feedback|
||Resolution||open => fixed|
||Fixed in Version||=> TDM 2.06|
|04.09.2017 02:01||nbohr1more||Status||feedback => resolved|