Test after test after test, this appears to work. I'm able to fight battles with c. 400 Agents without running into lockups; the only one I've seen while getting my new code in place was due to having an insane number of troops spawn right next to each other (don't ask).
I guess I will just have to see what happens with end-users; it's a little spooky how this works, though.
What I'm *guessing* is going on is that the memory settings govern the amount of space that's available, per-spawn, for spawn events. Breaking that barrier is pretty easy (it's only 64MB after all, for dynamic normalmapped things), but the worst part is that this appears to be static data allocation; it literally eats into your memory budget for the battles. Moreover, the note about its size being related to performance is not a joke; it's a fairly major speedup to reduce the values.
The problem is, I'm fairly certain that the newly-spawned Agents are not made part of the main vertex buffers, because then they'd need to be rebuilt. Instead, they're in a secondary buffer, which is why those static allocations are made.
But if you exceed those limits, you cause either page faults or the vertex buffer attempts to rebuild itself... but if you don't have enough memory to do that, the game state gets all kinds of screwed up and the vertex buffer gets corrupted, and then you crash.
Static stuff doesn't need this memory, and apparently the troops that load when you spawn don't either; this makes it possible to work around the issue.
So I cut the allocations all the way back to 16384 to free up enough memory that it's always clean, even with Firefox, system eating its usual 500MB or so, Steam etc.- total Commit Charge without Warband loaded is 960MB, with roughly 1.5GB in available RAM. After Warband loads, with music loaded Commit Charge is around 2.6GB, but RAM use is only about 1.4GB, and battles have loads that vary enormously depending on how many Agents are present. I am tempted to see what happens if I turn Load Textures On Demand off; it appears that once this stuff is loaded, it can be paged, but I'll have to confirm that.
This means that I'm well into peak, but so long as I don't have an utterly insane data load in the battle, it appears to be OK, because I'm not hitting RAM limits. I suppose if I have enough Agents with different gear, it'll hit the wall again, but I'm playing it fairly safe; it looks like I have maybe 100MB to spare. There is also the issue of how much room is on your GPU, but IDK how Warband handles that and I'm not even sure how to get meaningful data back from my GPU about memory used, etc.; whatever method is being used, system RAM seems to be critical on this hardware though.
Best part about all of this is that it can be tied directly to both battle size in the Warband options / BattleSizer and to the mission code, so that end-users can scale it up if they have a monster PC and down if they're trying to run the game on a weak laptop or a barely-compliant PC, just like they always could. It should (in theory) allow even those users larger battles than they were used to.
Only major issues are game-design ones; when you don't have spawns, a lot of basic assumptions have to get re-visited, most important being how sieges work
Well, that, and I'll have to deal with the Aleph; previous method was a spawn switcheroo; that may or may not cause a crash now.
