 |
I get the exact same problem signature every time. It is upon death and I'm trying to click to swing/continue then CTD. |
 |
Please verify whether this happens in 2.07 beta: http://forums.thedarkmod.com/topic/19774-beta-testing-207/ |
 |
I can reproduce this bug on latest SVN. When the player dies, all AI searches are discontinued. There are pointers to AI maintained whose searches are supposed to be ended and that pointer points to inconclusive data. I assume the AI has already been destroyed (it is despawned right?) and we get a memory access violation when trying to make that AI leave the search. I'll see if I can convert those pointers to Weak pointers, to ensure we only access them if the AI has not yet been destroyed. Here is the callstack: TheDarkModx64.exe!idVec3::operator=(const idVec3 & a={...}) Line 422 TheDarkModx64.exe!CSearchManager::LeaveSearch(int searchID=15, idAI * ai=0x000002800aefccf4) Line 1532 TheDarkModx64.exe!CSearchManager::ProcessSearches() Line 2189 TheDarkModx64.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds=0x000000db83ffec18) Line 3464 TheDarkModx64.exe!idSessionLocal::RunGameTic() Line 2955 TheDarkModx64.exe!idSessionLocal::RunGameTics() Line 3024 TheDarkModx64.exe!idSessionLocal::FrontendThreadFunction() Line 3070 |
|
|
Ok, adding a Shared pointer / weak pointer construct is no option here, as that would penetrate the whole code base. What is also weird is that my breakpoint in // If the player is dead, all searchers should leave their searches. if (player->health <= 0) isn't always hit, which means that the search must've been canceled earlier already, or something like that. I am thinking about actively Leaving the search from the Destructor of idAi. |
|
|
Yes, the search is canceled earlier, when the AI enters combat state. I am still not 100% sure the AI is destroyed before LeaveSearch() was called. If that is the case, the fix is easy: Add the following to ~idAi() if (m_searchID >= 0) CSearchManager::Instance()->LeaveSearch(m_searchID, this); I will add logging to the destructor of idAi and LeaveSearch, to investigate the timing without the debugger attached. |
|
|
This issue occurs very rarely. For now, I give up finding proof that it is in fact trying to LeaveSearch() for an already destroyed AI, which I think is very likely. In case of the training mission, neither idAi::Killed() nor idAi::Knockout() are called. Both of these methods would properly call LeaveSearch(). Here, the AI is simply destroyed and the destructor does not have the LeaveSearch(), so adding the above two lines would generally be a good safety measure, regardless of whether this is the true cause of the issue or not. |
|
|
I still wonder why there is sometimes a search active although the AI who just beat me was in combat state. Could it be a timing issue? |
 |
Is the issue that when LeaveSearch() runs, its 'ai' argument is NULL? If so, why not just test for NULL and exit early if that's the case. |
|
|
No, ai is not NULL, but the data pointed to is trash, probably because the AI has been destroyed already. Hence, my proposal to actively LeaveSearch() in the destructor of idAi. |
|
|
Well, that should work. I suppose the only time AI are destructed are at the end of the mission when everything gets destructed, or in the Training Mission. I've never battled the TM guys, so was unaware that they were destructed rather than killed. |
|
|
After running an admittedly simple automation script for two hours, where I teleport into the fighting pit and wait until the AI kills me, I still couldn't reproduce this bug again. The AI killed me about 400 times. So, either this is not the right way to reproduce this issue or it is incredibly rare. I will commit my proposed fix and wait for further reports regarding this issue. |
|
|
@STiFU The night I reported the bug, I ran into it about 7-8 times. It seemed to be while I was holding keys/mouse button as well. |
|
|
2.07 beta 6 will include the latest fix. We will await further confirmation then. |
|
|
Fix deemed too risky for 2.07. Moving to 2.08. |
 |
I tried to revert the change locally, and failed to reproduce it after that. Maybe it depends on some settings... Unless 0004839 gets fixed, fighting with uncapped FPS is rather broken. |
|
|
Yes, this bug is incredibly rare. FYI, I have all graphical features enabled or the more advanced options chosen. |
- Anonymous
