Patch 3641 release checklist

[Sheeo]

Things to do before we can get 3641 released:

• [x] Verify that the lack of wreck GC doesn't cause issues

  Pick a GC implementation

  • [ ] @Crotalus
  • [ ] @ChrisKitching
  • [X] None?
• [X] Release testing version
• [x] Close these issues
• [x] Close these PR's
• [x] Update changelog

[aeoncleanse]

GC Memory Consumption: With - Maxes at 530-540MB Without - 2000 wrecks = 541, 3000 = 574, 4000 = 596, 5000 = 638, 10000 = 800 Default cleanup wreck count appears to be somewhere from 1200 - 1300 wrecks globally

On my machine (i7 4720Q, 980m), there's no simspeed drop once the smoke clears. Of more concern is a significant and noticable hiccup when zooming into an area with a very heavy wreck field, I assume as all those models are loaded to VRAM. Additionally, at the zoom point where wreck LODs first appear along with shadows, there's a significant FPS hit (In normal circumstances running the game maxed, 8*AA, with some shadow tweaks etc, I never go under my 75Hz refresh in any circumstances I've encountered. At that zoom level, I saw a dip down to the 40s. Not good!)

Once I get home tomorrow, I plan to run identical tests on two more machines, one a PhenomII Tricore and 7770, one an i5 4670 and 7870, to get data on how more common machines are affected.

There is also concern for modes such as Survival and Scout Wars.

[Sheeo]

I updated the issue. @Crotalus, @ChrisKitching could you butt heads together about the GC?

[ChrisKitching]

Well, if we do now want collection I have a constant time implementation with lowish overhead (two pointers per wreck, one counter, and at most a dequeue pop operation of extra work for each new wreck)

[Crotalus]

Is it sorted by mass then or something else? If we don't sort by mass and instead ID etc it's trivial to spam air scouts to remove all wrecks on map :)

[ChrisKitching]

The idea is to stratify them by mass value. You have a set of implicit dequeues, one for each mass category. You assign wreck-count limits to each stratum. When a new wreck is created, you tack it onto the dequeue and if appropriate delete the one at the other end.

That all said, I grow increasingly skeptical if this will actually fix the problems we were having. Wasn't the underlying bug that code was trying to operate on wrecks that had already been Destroy()'d (presumably by the background machinations of SetBoundedProp). If our collector is to operate in the same way, we're not really fixing anything.

[Sheeo]

So what are we ending up with here?

I'm still leaning towards leaving out the GC and handling the edgecases we'll hit individually (Survival games, coop).

[aeoncleanse]

I didnt post figures because it looked like we were settled on doing GC, but I saw a significant performance hit on my older Phenom II machine to the point of unplayability. It wont happen too often in some settings, but Setons games and other large 4v4 or bigger, especially in the lower ranks where reclaim is done less, its an unacceptable hit IMO. It's the framerates rather than the sim, but the memory increase will hit hard on anyone only running 2GB RAM as well