|
|
|
|
|
Playing further, I have also seen this issue with anti-AI zombies and possibly others. |
|
|
Apparently lots can fail at once. See attached screenshot of what happened when I had just started a new game. From the timers, they had been inactive from before I even started this new save? |
|
|
0025504:0062676 I had the same issue happening on a new game on 3.509, with DLC3 factions affected also. |
|
|
Okay, 3.510 has these changes which hopefully will solve it: * Adjusted the thread manager class so that we now have threads initialized a lot earlier, and tied to their related sim contexts where needed, and then they are simply initialized in the future. ** The should prevent an exception that was reported by Badger and StarKelp and Zweihand that could occur in SetWorkDone(). I never could actually duplicate it, though. * Threads are now connected in a better way to their sim contexts, and we have extra debugging info on both ends in the event that either end thinks it is stuck. ** Additionally, we can now see idle threads (those created for games with more factions but then later a lower-faction-count game is loaded so the game has nothing to do with those threads), and we no longer complain about them. ** On top of that, all threads now kick off as promptly as they should on save load 0000002 in a game session (before it could sometimes have a 20 second delay for anti-AI zombies, as one example). ** And lastly, the issue where time in the lobby was causing threads to look idle upon exit is now fixed. I think that something was falling through the cracks. |
|
|
3.510 Still getting it, quite often, upon starting games. Unfortunately the list is even richer now. 2021-08-17 17_45_56-AIWar2.png (192,030 bytes) |
|
|
When this happens, can you right-click the time bar in the bottom of the screen? I forgot to mention that before. It has a bunch of information on the faction and the threads about what is happening, and I should be able to figure it out from that. I didn't expect it to keep happening, though. |
|
|
Next time it appears, I'll get that info. Now, after being in the game for quite some time, it didn't appear anymore, so it might be something that doesn't work only at start, because the bug doesn't appear later during the game. |
|
|
3.600 Here it is, but this time, after a few minutes of idling, the threads started running without requiring a reboot of the game. The background threads run fine since the start. |
|
|
Yeah, it seems that with 3.600 it still happens, but the game tends to start the inactive threds within 30-60s from the beginning of the match. |
|
|
Okay, so based on the picture that you posted in two posts up, it looks like the game thinks that it is less than 5 seconds into the game. This is incredibly strange! Because it should only be actually able to get to the part that you are seeing if it actually runs. So... that probably means that the entire thing is stale, which means that the background thread itself is not being run. Are there any errors being logged? |
|
|
Oh, another question: this isn't on a MP client, is it? |
|
|
* Put in a number of potential fixes for the inactive threads issue. Essentially, when they are being shut down because of exiting from the game, they are now sure to mark themselves as complete, etc. They were previously potentially (in theory) able to get stuck in an indeterminate state. ** Please note that multiplayer clients probably will have lots of inactive threads reported at the moment, but those threads are not meant to run on the MP client, so it's a false warning on those. ** If this is still something people see on MP hosts or in single player, any added info, exceptions, or steps to reproduce would be super welcome. We have yet to be able to duplicate it. |
|
|
I often pause at the start of the game, so maybe I don't give it enough time to reach the starting phase? This is not MP. |
|
|
This should be the last of this: * Internally, UnpausedTimeSinceLastRestartF has been replaced with NonSetupGameTimeSinceLastLoadOrStartF, which is more complicated but now accurately measures the sort of time we want it to. ** Essentially, we want to know about how much realtime has elapsed, network-related-delays-notwithstanding, since certain things happened. ** By using an internal accumulator that is actually per-frame, and then dealing with the accumulation during that part of the simulation that checks for network delays or proceeding with the sim, we get an accurate picture now. ** This fixes various bugs, like the "inactive threads" warning on game start after being in the lobby for a while, or the threads window (left click the timer in the bottom left) not showing actual activity as it should while the game is paused. Some of those threads do in fact run during pause. ** This in turn does make it accurate when threads are running or not running during pause, which means some extra controls in there to make it show the pause-skips process correctly and not alert when those are not running. |
- Anonymous
