 |
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. |
|
|
com_smp 0 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. |
|
|
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. Thanks. |
- Anonymous
