View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0026056 | AI War 2 | Gameplay Issue | Jan 5, 2022 3:17 pm | Jan 6, 2022 4:01 pm | |
| Reporter | Chris_McElligottPark | Assigned To | BadgerBadger | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | Beta 3.780 Nomadic Ark Empires And The Hull System | ||||
| Fixed in Version | Beta 3.781 Tachyon Healing Reversal | ||||
| Summary | 0026056: Scourge generating about 10k gamecommands per second in this save. | ||||
| Description | In this particular save, the scourge are misbehaving like crazy. If you use the new view in the escape menu that lets you see which faction is generating gamecommands, you'll see the scourge flood about 5k commands per realtime second, a couple of times per second, after loading up this save and simply unpausing it. You can see the top three command types it is, as well. Essentially, this just needs some sort of throttle, so that whatever is happening doesn't keep getting repeat orders over and over. This actually causes giant frame drops because of the volume of data, it's kind of interesting. A useful stress test case, anyhow! | ||||
| Tags | No tags attached. | ||||
|
|
good start 2.savemet (113 bytes)
CL 824530324 3982 2021 <color=#ff3fd9>Brutal </color> Jabberwock Difficulty 9 13 <color=#bea78f>MONTYBILL</color> |
|
|
I've throttled the major sources of scourge gamecommands significantly. However, this save is just so busy that when I play it, most of the factions have steadily increasing numbers of queued game commands. I saw even the sappers climb to thousands of queued game commands, and they have a handful of units. I think the easiest path forward would be to have a "Is the game overloaded" function that could be called from LRP or Sim, and allow for adaptive throttling when the game is really busy. |
|
|
Related to testing this save, and your suggestions: * Added in a new HostOnly_TimeWasLastGivenOrderFromLRP on squads, which can be set and used as a way to throttle how quickly new orders are given to the same unit. ** This has no generalized power, but it has been implemented in all of the fireteam and faction utility methods. *** If you pass 5f or similar to one of those methods, then it will only do that command if it has been at least 5 realtime seconds since the last time that unit (or all related units in a fireteam or other list) have has last been issued some order. *** If you pass 0f or -1f or somesuch, then it will do the command no matter what. ** There are various commands scattered around faction code that are called directly, and these won't be throttled at all unless someone (usually the faction author) feels like they need to be. ** If this winds up feeling too limiting, then we can always back it off on any faction that is being slow to react to things. Generally having a rule of "if you just told me something, don't tell me again for the next 5 seconds" does seem to cut down on faction command spam in the extreme test case game that we're looking at. * Our List<> class has been extended with an AddButRejectIfNull() method, which can be used to pass in things which may accidentally be null and should be rejected if so. ** This has then been applied to lots of places where the external data for factions is keeping track of things like territory. This should solve an exception that was able to happen in the elderlings code when it would find a null planet because and elderling who had died was still being processed by the LRP during that death. * The Dictionary<> class now handles null keys being passed in by ignoring them rather than throwing an exception. ** The idea is that this helps avoid exceptions when a background thread gets out of sync. * Fixed "CheckForShotAOEDetonation error at debugStage 8000" errors on sorting potential targets. * Found a further place where the simulation was able to double-run on multiple threads if it was running slowly enough because of an extremely bogged-down sim world. ** I thought I had gotten all of these yesterday, and indeed it was better, but one area slipped through and was the genesis of a ton of random-seeming bugs. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Jan 5, 2022 3:17 pm | Chris_McElligottPark | New Issue | |
| Jan 5, 2022 3:17 pm | Chris_McElligottPark | Status | new => assigned |
| Jan 5, 2022 3:17 pm | Chris_McElligottPark | Assigned To | => BadgerBadger |
| Jan 5, 2022 3:17 pm | Chris_McElligottPark | File Added: good start 2.save | |
| Jan 5, 2022 3:17 pm | Chris_McElligottPark | File Added: good start 2.savemet | |
| Jan 5, 2022 3:17 pm | Chris_McElligottPark | File Added: InsaneScourge.PNG | |
| Jan 6, 2022 12:46 am | BadgerBadger | Note Added: 0063659 | |
| Jan 6, 2022 4:01 pm | Chris_McElligottPark | Status | assigned => resolved |
| Jan 6, 2022 4:01 pm | Chris_McElligottPark | Resolution | open => fixed |
| Jan 6, 2022 4:01 pm | Chris_McElligottPark | Fixed in Version | => Beta 3.781 Tachyon Healing Reversal |
| Jan 6, 2022 4:01 pm | Chris_McElligottPark | Note Added: 0063664 |
