Prerelease 1.010H (Tug/Tractor Fixes, Bigger Build Queues)

[x4000]

The latest prerelease of AI War is now out:  http://www.arcengames.com/share/AIWar1010H.zip

That version is an upgrade from version 1.009, so you have to already have 1.009 (or greater) installed. Just unzip it into your game folder (usually C:\Program Files\Arcen Games\AI War\ unless you specified something else). Please make sure that your unzip process keeps the folder structure from the zip file, rather than just unpacking all of the files into the base target directory.

What's new since 1.010G:
(Cumulative release notes since 1.009 are attached at the bottom)

-------------------

-Space Tugs will now pick up ships with engine damage like they would ships with hull damage.

-It is now possible to put up to 16 ship types in a single constructor's build queue (the old limit was .

-It is now possible to manually give space tugs orders to go pick up a specific ship.

CHANGES FROM PRIOR PRERELEASES
--------------

-There were some bugs with the "reeling in" logic on tractor beams, which were sometimes causing the ships to be repeled instead (and which, in turn, could cause a game crash).  Fixed.

-Previously it was possible for space tugs to hold their charges outside the range of the repair station they were supposedly bringing them to.  Fixed.

[Pandemic]

Idea:

One of the things on the list of Upcoming DLC is a ship, with a cloaking bubble. Maybe make a ship like that, only with a shield? Basically, a mobile shield generator.

Dunno if this is already on the list and I overlooked it, but I think it would be interesting .


-Pandemic

[x4000]

Idea:

One of the things on the list of Upcoming DLC is a ship, with a cloaking bubble. Maybe make a ship like that, only with a shield? Basically, a mobile shield generator.

Dunno if this is already on the list and I overlooked it, but I think it would be interesting .

Actually, that's already in the game!  The Mark III force fields work this way.  Also, there's a smaller "recharging mobile force field" on the list from Admiral (but I can definitely understand that being overlooked!).

[Admiral]

Mobile shield ship: It's only smaller in shield strength, not in conceptual awesomeness.

[Pandemic]

Mark III Force Shields are mobile, and can go through wormholes? Really?


-Pandemic

[Admiral]

Mark III Force Shields are mobile, and can go through wormholes? Really?

Yes, apparently so. I have never tried to do either, though.

[darke]

The running out of memory when paused bug seems to be fixed. Left the game on overnight and it hasn't crashed and is sitting there using less then 500meg.

[x4000]

Mark III Force Shields are mobile, and can go through wormholes? Really?

Yes, apparently so. I have never tried to do either, though.

Yep, and yep.

[x4000]

Mobile shield ship: It's only smaller in shield strength, not in conceptual awesomeness.

Oh yeah, I really agree. I look forward to when that one comes around in the DLC.  With the DLC (just look at my huge list), I've just realized that I need to organize and schedule this stuff better, or I'm going to go insane.  I need to have a "speed limit" on myself so that I can feel like I'm accomplishing enough to add to the game in a given week, without spending every waking moment on free updates.  I'm supposed to be coding another puzzle game (yet to be officially announced -- it will be soon) for release in a few months, and then there is also so much work left to be done on Alden Ridge, as well as the first expansion for AI War. 

I'm still planning to keep going strong on all this DLC, but I've just been realizing that I can't keep going at this pace and actually accomplish anything else for the company's portfolio.  It seems like a lot of the requests are getting into the larger "nice to have" category that fits with the more rationed weekly DLC releases, rather than needing to be implemented en masse immediately.  Of course, there are still plenty of the immediate things at the moment, too, but proportionately it seems be getting less, thank goodness.

[x4000]

The running out of memory when paused bug seems to be fixed. Left the game on overnight and it hasn't crashed and is sitting there using less then 500meg.

Wonderful!  Sounds like it was a strange stack overflow type thing then.  I think that's what it meant by running out of memory in that case -- no more stack allocation space.  Now that it's putting the AI messages on the heap instead, the GC is taking care of that and everyone is happy.  Great!

[darke]

The running out of memory when paused bug seems to be fixed. Left the game on overnight and it hasn't crashed and is sitting there using less then 500meg.

Wonderful!  Sounds like it was a strange stack overflow type thing then.  I think that's what it meant by running out of memory in that case -- no more stack allocation space.  Now that it's putting the AI messages on the heap instead, the GC is taking care of that and everyone is happy.  Great!

Heh. One of these days language designers will realise that re-implementing limitations of 16bit programming is *not* a good way to advance the art of language design. Honestly you'd think that the bytecode interpreter would realise that allocating an extra couple of meg when it runs out doesn't really hurt it so much, especially if it's only using under 500Meg on a machine with 8Gig physical memory in it... (Both Java and .NET seem to have this issue. MS managed to avoid copying so many flaws in Java when they made C#, why did they have to copy this brain damage as well?)

On another note, just started a game with parasites using a fairly defensive setup (since I'm surrounded by forcefields and Tech IV planets, again). With nearly 600 ships of various types (out of a possible 152+170+170+170+170+255+10, which is about 1100, so about half the potential maximum assault force), a few heavily defended wormholes (exo-wormhole, Tech IV planets, and the like), I only just ran out of energy of one of each of the Tech I + Tech II generators when placing the command center of my first conquered world (360 energy to spare, w00t! ). So it seems only in the truely "worst case" (you can only get off your world with max-ships), you have to make a decision.

[x4000]

The running out of memory when paused bug seems to be fixed. Left the game on overnight and it hasn't crashed and is sitting there using less then 500meg.

Wonderful!  Sounds like it was a strange stack overflow type thing then.  I think that's what it meant by running out of memory in that case -- no more stack allocation space.  Now that it's putting the AI messages on the heap instead, the GC is taking care of that and everyone is happy.  Great!

Heh. One of these days language designers will realise that re-implementing limitations of 16bit programming is *not* a good way to advance the art of language design. Honestly you'd think that the bytecode interpreter would realise that allocating an extra couple of meg when it runs out doesn't really hurt it so much, especially if it's only using under 500Meg on a machine with 8Gig physical memory in it... (Both Java and .NET seem to have this issue. MS managed to avoid copying so many flaws in Java when they made C#, why did they have to copy this brain damage as well?)

Overall it works pretty well, but I was using the stack for purposes of avoiding the GC and thus trying to keep memory maintenance low.  But evidently it didn't like the volume there.  I agree, though, that a such a severe limitation on that kind of thing is pretty strange.  Oh well, that's why I've rarely used structs in the past except for purposes of doing interop and the like (and for things that are meant to be value types, like my FInt fixed-in class).  Ah well.

On another note, just started a game with parasites using a fairly defensive setup (since I'm surrounded by forcefields and Tech IV planets, again). With nearly 600 ships of various types (out of a possible 152+170+170+170+170+255+10, which is about 1100, so about half the potential maximum assault force), a few heavily defended wormholes (exo-wormhole, Tech IV planets, and the like), I only just ran out of energy of one of each of the Tech I + Tech II generators when placing the command center of my first conquered world (360 energy to spare, w00t! ). So it seems only in the truely "worst case" (you can only get off your world with max-ships), you have to make a decision.

That's great to hear, actually.  You should start having to make more decisions once you take more planets -- since the command stations take so much energy.  So that will make you place your reactors on multiple planets, without crimping you too much at the start.

In that "Last Stand" scenario, I think we were also overlooking how much energy is freed up by losing all those other planets' command stations and defenses.  That should make fielding a "last stand" defensive force a lot better without the risk of being too hampered by energy to really do much.  Excellent!

[darke]

Heh. One of these days language designers will realise that re-implementing limitations of 16bit programming is *not* a good way to advance the art of language design. Honestly you'd think that the bytecode interpreter would realise that allocating an extra couple of meg when it runs out doesn't really hurt it so much, especially if it's only using under 500Meg on a machine with 8Gig physical memory in it... (Both Java and .NET seem to have this issue. MS managed to avoid copying so many flaws in Java when they made C#, why did they have to copy this brain damage as well?)

Overall it works pretty well, but I was using the stack for purposes of avoiding the GC and thus trying to keep memory maintenance low.  But evidently it didn't like the volume there.  I agree, though, that a such a severe limitation on that kind of thing is pretty strange.  Oh well, that's why I've rarely used structs in the past except for purposes of doing interop and the like (and for things that are meant to be value types, like my FInt fixed-in class).  Ah well.

They'll be a parameter you can use to alter it somewhere, I know java has it. It's usually something pretty low by default, and pretty much every tomcat server we're running has it set to something higher and more sane. Interestingly it looks like that the 32bit version of C# doesn't do some stack optimisations that the 64bit version does: http://wesnerm.blogs.com/net_undocumented/2009/04/il-features-missing-in-c.html

That's great to hear, actually.  You should start having to make more decisions once you take more planets -- since the command stations take so much energy.  So that will make you place your reactors on multiple planets, without crimping you too much at the start.

In that "Last Stand" scenario, I think we were also overlooking how much energy is freed up by losing all those other planets' command stations and defenses.  That should make fielding a "last stand" defensive force a lot better without the risk of being too hampered by energy to really do much.  Excellent!

Honestly I completely ignore the "last stand" scenario. Your general player will give up long and start a new game before you get there, and the Grognards (grumbling all the way ) will be able to handle whatever the game throws at them anyway.

[x4000]

Overall it works pretty well, but I was using the stack for purposes of avoiding the GC and thus trying to keep memory maintenance low.  But evidently it didn't like the volume there.  I agree, though, that a such a severe limitation on that kind of thing is pretty strange.  Oh well, that's why I've rarely used structs in the past except for purposes of doing interop and the like (and for things that are meant to be value types, like my FInt fixed-in class).  Ah well.

They'll be a parameter you can use to alter it somewhere, I know java has it. It's usually something pretty low by default, and pretty much every tomcat server we're running has it set to something higher and more sane. Interestingly it looks like that the 32bit version of C# doesn't do some stack optimisations that the 64bit version does: http://wesnerm.blogs.com/net_undocumented/2009/04/il-features-missing-in-c.html

Yeah, probably so.  I have to use the 32bit (rather than Any) runtime even on 64bit machines, though.  Otherwise the performance of integers goes down since "int" refers to int64 instead of int32, and also interop with 32bit libraries like the ogg vorbis dlls then fails mysteriously.  I used to have the game running on Any before I added music, but switching to just 32 solved the music problem and also improved performance pretty noticeably on 64bit machines.

I'm sure I could do some switches to make the stack behave differently, but the bigger question is why the stack was getting full in the first place when left like that.  I mean, that wasn't happening during gameplay, and the AI messages get cleared over time instead of just queuing (as evidenced by your normal-looking RAM usage after a night of pause when classes are used in place of structs), so there's something funky going on under the hood there.  I'd rather not get into that, I'm a lot more comfortable with how to optimize the GC and minimize collection interference, etc.

Honestly I completely ignore the "last stand" scenario. Your general player will give up long and start a new game before you get there, and the Grognards (grumbling all the way ) will be able to handle whatever the game throws at them anyway.

Yeah, that's true.  Of course, if I add some of the offensive changes that we're talking about on the other thread, that might all but eliminate stalemates in favor of many more pure wins and losses.  So that last stand scenario might start coming up more in those cases.

[darke]

Yeah, probably so.  I have to use the 32bit (rather than Any) runtime even on 64bit machines, though.  Otherwise the performance of integers goes down since "int" refers to int64 instead of int32, and also interop with 32bit libraries like the ogg vorbis dlls then fails mysteriously.  I used to have the game running on Any before I added music, but switching to just 32 solved the music problem and also improved performance pretty noticeably on 64bit machines.

I'm sure I could do some switches to make the stack behave differently, but the bigger question is why the stack was getting full in the first place when left like that.  I mean, that wasn't happening during gameplay, and the AI messages get cleared over time instead of just queuing (as evidenced by your normal-looking RAM usage after a night of pause when classes are used in place of structs), so there's something funky going on under the hood there.  I'd rather not get into that, I'm a lot more comfortable with how to optimize the GC and minimize collection interference, etc.

Ya. Especially when it actually sounds like a bug in the interpreter somewhere rather then actually in the code (since it's really not doing anything whilst paused.)

Honestly I completely ignore the "last stand" scenario. Your general player will give up long and start a new game before you get there, and the Grognards (grumbling all the way ) will be able to handle whatever the game throws at them anyway.

Yeah, that's true.  Of course, if I add some of the offensive changes that we're talking about on the other thread, that might all but eliminate stalemates in favor of many more pure wins and losses.  So that last stand scenario might start coming up more in those cases.

Maybe. I would still expect most people can tell when to cut their losses and start a new game, rather then trying to continue to fight out what is obviously going to be either a loosing game because your head's been cut off, or a loosing game because recovering from the assault is going to take enough time that it's given the AI enough edge that you'll never quite be able to push ahead fast enough.