AI War Beta 4.052 Released!

[keith.lamothe]

In a recent game I only saw a hunter killer generated when there was something like 2500 ai threat on a single neutral border planet, just stalking me   And this was on low caps   I had already dealt with several such blobs (sometimes by chasing them into my defenses with my spire fleet which usually led to them plowing all the way to my homeworld before being stopped, sometimes by the good ol' emp-and-shred method), and the game was almost over at this point.  I don't recall ever actually seeing the hunter-killer (mkI, 2 of them, I think), but there was so much firepower flying around at that point I may have just missed it.

Anyway, there were lots and lots of huge battles in that game, the h/k stuff didn't interfere

As far as making them optional for higher-end rigs, I understand the desire (though I don't think it interferes as much with the big battles as it may sound), but the CPU performance problem isn't really the big one this is trying to solve, it's the "32-bit app can only use so much RAM" problem.  If you start getting into lots of 10k fleets flying around, it doesn't matter if you have a 4GHz quad-core with 32 GB of ram, the process may trespass into the 1.4-1.7GB (it varies strangely) territory and the AI will hit you with the "Too many heap sections" strategy   We did make some changes lately that hopefully are making the game hang onto less memory, but there's limits to what can be done there.

[Wingflier]

the AI will hit you with the "Too many heap sections" strategy

Hahahahaha, this is awesome!

[orzelek]

Is the 3GB option for process RAM supported by Unity per chance?
This would give more flexibility at least for x64 users with plenty of RAM. And also for others with 3GB option enabled for OS.

Note for planned turret changes:

Weren't it in plans to give them significant armor as it would suit immobile installations?

[keith.lamothe]

Is the 3GB option for process RAM supported by Unity per chance?
This would give more flexibility at least for x64 users with plenty of RAM. And also for others with 3GB option enabled for OS.

If we knew how, we'd try it, but it does not appear to be an option.  We couldn't do it under .NET either, as MS had intentionally chosen to not support the extended address space for C#/etc stuff (it was still physically possible but caused critical bugs if enabled, in our case).

If I was able to actually get a list of how many objects of each type (or even just total size by type) were allocated on the heap, it'd be a lot easier to just find where to optimize memory usage downward   And I was able to do that in .NET to a large degree.  But I'm not aware of tools that do that with the embedded mono runtime that Unity uses.  Any ideas are welcome

Note for planned turret changes:

Weren't it in plans to give them significant armor as it would suit immobile installations?

I had forgotten about that, actually, but yes that would be one way of beefing them up.  I think I'd like to try them with the current (working build) values for a bit before going higher.  They should be fairly effective now, with a cap of mkI turrets having very roughly 3x the dps of a mkI bonus ship type.  Also the attack-bonus and attack-power numbers have been leveled out a fair bit so that using the "matching" turret type gives you a roughly 2.4x advantage over using a non-matching type (which is plenty significant in a tactical sense) but there should be less in the way of turrets firing away madly with no perceptible effect on same-mark targets.  Though the armor of stuff like space tanks and armor ships could still result in that.

[x4000]

Is the 3GB option for process RAM supported by Unity per chance?
This would give more flexibility at least for x64 users with plenty of RAM. And also for others with 3GB option enabled for OS.

Supposedly, yes.  But, Unity is a kind of complex process with multiple different sections to it: unmanaged memory for the engine itself, the mono runtime as part of the same process, and for things like textures, etc; and then the managed memory that is for game objects, our code, etc.  It seems like there are limits on our managed part of the memory to keeping it to something like 1.2GB or something (which translates into maybe 1.6GB of unmanaged memory, usually, when the too many heap sections thing creeps in).

So it's kind of annoying with that, hopefully that will be improved on many fronts in the future.  The other big problem being that if there are currently (say) 850 MB of managed memory in use, and 450 of those would be freed by the next garbage collection run, and the game needs to allocate another 50 MB of managed memory, it will allocate those 50 MB of memory even if that would cause a too many heap sections error, despite the fact it could have easily avoided that.  Sui-freaking-cidal.  Grr.

At any rate, the H/Ks aren't an optional thing because their point is less about lower-end machines and more about avoiding running out of memory on higher-ship-count campaigns.  You can still easily get battles with absolutely thousands of ships in them, though, so it's not like it's cutting the ship counts down into the hundreds or anything.

I'm overall just trying to keep the battles to a few thousand per side, rather than ever having ten thousand per side; same as I'm trying to keep the overall ship counts for games to the 30,000 to 100,000 range, rather than letting them get up into the 300,000 ship range at times.  Same sort of reasons, in terms of memory usage restrictions.

[Suzera]

If you could make AP double/quadruple with lower ship caps so things stay more balanced with lower ship counts that could help too. Something that's balanced for high ship cap level AP is unbalanced in favor of high armor ships in low ship cap. Right now there's the choice of "play high ship cap with more memory issues but is the tested balance" or "play low ship cap with armor balance issues but less memory issues".

I haven't explicitly tested this yet so if it's just a graphical bug like the mk 3 science vessels not causing exponentially more reinforcements, then I guess it's just a display issue than a balance one.

[keith.lamothe]

Normal caps is actually the balance target, it's just that the raw numbers are for high so I tend to refer to those in patch notes.  I generally play on Low caps, fwiw.

Anyway, I had thought that AP was not scaled, but looking at the code it is, exactly the same as, say, health.  Are you seeing something different; i.e. a unit whose health scales but AP does not?

[Suzera]

Last I checked, the stat box doesn't reflect scaling AP. It might be a display issue like the reinforcement with multiple mk 3 science labs. Or you may have ninja fixed it since I last bothered to look rather than going by memory.

As I said, I haven't hard tested it to be sure, just going off what the box says.

[keith.lamothe]

The in-the-middle-of-the-game box or the lobby-map box?  The latter is notoriously not-quite-accurate with respects to scaling (and unit caps), I'm afraid

If a given display is displaying the properly scaled health, it should also display the properly displayed AP.

[Suzera]

In-the-middle-of-the-game. Which reminds me, do tractor beam counts and such scale with ship cap? I haven't looked for this one specifically, but I'm not sure if those do either according to the middle-of-the-game box.

Last I doublechecked was probably 3-4 versions ago.

If I were where I could check right now I'd do it but I can't.

[keith.lamothe]

Tractor beam counts don't scale; for scaled units (like tractor turrets) they really shouldn't, because on low you will have 1/4 as many tractor turrets as on high, but they'll also have 1/4 as many targets to tractor.

But for stuff like Riot tractors and the Martyr and whatnot it should probably scale to maintain balance.  But it wasn't really the goal to get _exactly_ the same balance between caps, just to smooth out any particularly egregious discrepancies or anything that was making a setting simply un-fun.

[Suzera]

Yeah, you're right about the ship counts scaling automatically scaling down the total tractor beam count proportionally. Wasn't thinking that through enough.

[Echo35]

As far as making them optional for higher-end rigs, I understand the desire (though I don't think it interferes as much with the big battles as it may sound), but the CPU performance problem isn't really the big one this is trying to solve, it's the "32-bit app can only use so much RAM" problem.  If you start getting into lots of 10k fleets flying around, it doesn't matter if you have a 4GHz quad-core with 32 GB of ram, the process may trespass into the 1.4-1.7GB (it varies strangely) territory and the AI will hit you with the "Too many heap sections" strategy   We did make some changes lately that hopefully are making the game hang onto less memory, but there's limits to what can be done there.

Funny you should mention that, because there was a game I used to play that ran into that same issue. For a good while after Empire: Total War came out, it was utterly unplayable on certain configurations that included a 64 bit processor/OS, a big video card, and more than 3 gigs of RAM. I don't remember the exact details but it involved the game trying to address more than the 3 GB of RAM that it could and crashing miserably. I did some research into it at the time but I don't remember much of it now, as this was a year or two ago. I know that in those cases the total address space is shared between discrete graphics and RAM, so if you were like me and had not only a lot of RAM, but also a large amount of discrete graphics memory, you'd run into the game not thinking it had enough RAM and failing to run. It was at the point it was literally unplayable for months until they patched it. One of the main reasons I stopped playing it and went back to Rome, which is still the best game in the Total War series!

[keith.lamothe]

Funny you should mention that, because there was a game I used to play that ran into that same issue. For a good while after Empire: Total War came out, it was utterly unplayable on certain configurations that included a 64 bit processor/OS, a big video card, and more than 3 gigs of RAM. I don't remember the exact details but it involved the game trying to address more than the 3 GB of RAM that it could and crashing miserably. I did some research into it at the time but I don't remember much of it now, as this was a year or two ago. I know that in those cases the total address space is shared between discrete graphics and RAM, so if you were like me and had not only a lot of RAM, but also a large amount of discrete graphics memory, you'd run into the game not thinking it had enough RAM and failing to run.

Interesting, yea, I know about the video-card-ram-needs-to-be-mapped-within-the-same-virtual-space problem where having more video ram can actually REDUCE the ceiling amount of memory your game can actually use for things like, you know, entity data   I suppose that could be at play right now.  Dunno how having more normal ram would make that problem worse, though.  Must've been a more specific bug in that game's way of detecting system resources.

It was at the point it was literally unplayable for months until they patched it. One of the main reasons I stopped playing it and went back to Rome, which is still the best game in the Total War series!

I'm partial to Medieval 2, though I only ever play the LotR mod, and the version for M2 is more sophisticated than the version for Rome

[Echo35]

I'm partial to Medieval 2, though I only ever play the LotR mod, and the version for M2 is more sophisticated than the version for Rome

Medieval 2 is definitely a close second. Good game there, but Rome ran a lot better on my old laptop, so I ended up playing it more because of that and now I'm stuck on it