Prerelease 3.0349 (Transport+, Cold storage perf+, auto-manufactories, riot tab)

[triggerman602]

I'm confused about the auto factory management. does it automatically turn factories off when resource flow goes negative?

[x4000]

Not factories -- manufactories.  The things that convert resources from one type to the other.

[triggerman602]

OH i got it

[quickstix]

Updates in 3.046:

-More performance improvements have been made

I"ve really noticed since the 3.0 release just how much smoother AI War has been on my ageing laptop, as well as the gameplay in general. Coupled with the combat improvements (such as player speed increase, non-melee ship range increase) AI War is just an absolute joy to play. It just feels right. Not everybody can afford fancy new hardware (including me), so it's a real joy to see work still being done on optimisations and performance improvements.

Thank you very much.

[x4000]

My pleasure, quickstix!  My goals with that are triplicate: support ever-lower hardware, support ever-larger battles smoothly, and continue to push the envelope of just how crazy a large/fast simulation I can demonstrate in a "slow" language like C#.

[TheDeadlyShoe]

IMO reactors have far more micro impact than manufacturies.

i just go to my home system and turn off/on the lot of them as necessary, which isn't often. I usually build ships that favor the resources I have surplus of, instead of trying to equalize.

I probably spend 3-4x as much time microing power IIIs than I do manufactories.

I mean... running 200k surplus, that's -120 of each resource, you have to have a huge number of manufacturies to have anywhere near that impact in terms of resource loss.

Although TBH I think the whole power model is a little weird, you can get MK IIIs off the bat (higher MK everything else takes research). And MK Is are kinda, sorta useless. But efficient. So you build em anyway.

-autotargetting now essentially ignores modules, though they will often be hit by a small percentage of shots in a heavy firefight due to the "spread it around" logic.  Hopefully we can figure out a good way of incorporating modules in the autotargetting routine, but for now this should prevent any really stupid target choices.

Could have turret hits hurt starship health too.

[Buttons840]

I believe either reactors should be automated or changed to give there management more strategic consideration.

Earlier you mentioned leaving an extra generator on to buffer potential losses, but this is silly, because you can turn on a new generation instantly (use the pause if needed).  Read again, "instantly."


I would rather have reactors changed than automated though.  But in there current state automation is the best option.

Perhaps remove the reactor pause feature all together?  If you build it, you pay to upkeep it (maintenance costs don't disappear if you shut down a reactor).  But players might build one to 99% and keep it as a backup.  I suppose there is nothing wrong with that though.

Perhaps a more reasonable option would be a time limit required to bring a reactor online.  If it took 60 seconds to unpause a reactor then leaving an extra on as a buffer would become a legitimate strategy rather than a mere convenience; currently I leave reactors on not because of strategy, but because I get tired of managing them.  Perhaps the reboot time would be proportional to the amount of energy the reactors produce?  Like 2 seconds for a mark 1 and 80 seconds for a mark 3.


Just some thoughts on the issue.

[x4000]

I'm not particularly bothered about the reactors as they stand -- yes, you can turn them on instantly, but during the heat of battle do you notice the need to?  Often the destruction of an unexpected reactor can give the AI the brief window it needs to do something really nasty, like kill you.  This, in turn, creates a lot of strategic decisions about where to build your reactors, how many to leave on, etc.  They aren't huge, but they are a part of the game.  And, the current setup of reactors (in general, not relating to automation or not) is something that encourages players to take more planets, which is important.  And neither Mark Is nor Mark IIIs are useless by any stretch, especially with certain playstyles that use lower numbers of planets.

At any rate, they aren't something that I'm inclined to do a major overhaul on.  For those who are newer to the game, you might not know, but these were already majorly overhauled back in August or so, with a lot of community feedback and ideas on there.  For now, I'm feeling pretty happy with them.

[HellishFiend]

Perhaps remove the reactor pause feature all together?  If you build it, you pay to upkeep it (maintenance costs don't disappear if you shut down a reactor).  But players might build one to 99% and keep it as a backup.  I suppose there is nothing wrong with that though.

Perhaps a more reasonable option would be a time limit required to bring a reactor online.  If it took 60 seconds to unpause a reactor then leaving an extra on as a buffer would become a legitimate strategy rather than a mere convenience; currently I leave reactors on not because of strategy, but because I get tired of managing them.  Perhaps the reboot time would be proportional to the amount of energy the reactors produce?  Like 2 seconds for a mark 1 and 80 seconds for a mark 3.


Just some thoughts on the issue.

Honestly I would hate both of those options. I feel it interrupts the flow of the game to have to go to the map and run a search for power generators to find out where you haven't built one yet, and thats exactly the sort of thing the first option would make us do.

As for the second thing, essentially punishing us for trying to do something that is, as X puts it, 'beneficial but unnecessary' seems totally off-base as a solution, considering what it is intended to treat is not even a "problem" that needs to be solved.

[x4000]

Updates in 3.047:

-Yet more performance improvements have been made for when ships are in FRD mode in particular, but also for combat in general.

-When loading from a savegame, the fg object numbers are now internally remapped to lower numbers to keep transmission requirements and savegame size as low as possible (so this can also help performance at least a little in very long games).

-Added Riot Control Starship MkII and MkIII and associated modules.  Added tractor module to the MkI list, and removed the tazer (which is now exclusive to the MkII).  A few changes to MkI balance.

[Kalzarius]

-in the last few prereleases the onboard forcefield module (can be mounted on Riot MkIs) was correctly functioning as a non-weak forcefield but as a result was reducing attack power of protected objects by 75% (like normal forcefields), changed to not apply this reduction in this particular case.

75%?  I thought it was 50%.  Is that reducing the attack power by 75% (100 attack power = 25 attack power under a forcefield) or to 75% (100 attack power = 75 attack power under a forcefield).  If the former, that seems a wee bit excessive.

[x4000]

-in the last few prereleases the onboard forcefield module (can be mounted on Riot MkIs) was correctly functioning as a non-weak forcefield but as a result was reducing attack power of protected objects by 75% (like normal forcefields), changed to not apply this reduction in this particular case.

75%?  I thought it was 50%.  Is that reducing the attack power by 75% (100 attack power = 25 attack power under a forcefield) or to 75% (100 attack power = 75 attack power under a forcefield).  If the former, that seems a wee bit excessive.

By -- the former.  That's what it's been ever since force fields stopped being damaged by stuff fired out from under themselves.  Think of it this way: if you're getting a huge health buff, basically making your ships invincible under that force field for as long as the force field holds, that 75% reduction doesn't seem so bad.  The force field can be repaired, etc.  But generally, the force fields are not intended as a force multiplier, but rather as something for protecting smaller or weaker ships that aren't combat-oriented.  The commonness of abuse for these before the changes were put in was just far too much, players could easily set themselves up in unassailable positions that the AI could never breach, etc, because of the insane cheapness of packing hundreds and hundreds of Mark III turrets under a single force field.  Hence the huge reduction, anyway, I definitely don't feel like it's too steep based on the history here.

[HellishFiend]

Can't roll with 47..  Keep crashing:

2/21/2010 2:40:08 AM (3.0.4.7)
-----------------------------------Application_ThreadException-----------------------------------System.NullReferenceException: Object reference not set to an instance of an object.
   at AIWar.GameForm.DrawDirect3D() in C:\vcprojs\AIWar\GameFormParts\GamePanel.cs:line 465
   at AIWar.GameForm.RunNextCycle(Boolean DoRendering, Boolean DoScrollingAndInput) in C:\vcprojs\AIWar\GameFormParts\GameLoop.cs:line 1729
   at AIWar.GameForm.gameLoop() in C:\vcprojs\AIWar\GameFormParts\GameLoop.cs:line 247
   at AIWar.GameForm.GameForm_Load(Object sender, EventArgs e) in C:\vcprojs\AIWar\GameFormParts\Startup.cs:line 276
   at System.Windows.Forms.Form.OnLoad(EventArgs e)
   at System.Windows.Forms.Form.OnCreateControl()
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl()
   at System.Windows.Forms.Control.WmShowWindow(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.Form.WmShowWindow(Message& m)
   at System.Windows.Forms.Form.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[RCIX]

Oh, and i've seen manufactories not working -- crystal flow will be negative, metal flow will be positive, and they don't turn on.

[x4000]

Oh, and i've seen manufactories not working -- crystal flow will be negative, metal flow will be positive, and they don't turn on.

They've been doing great for me, so if you have a save that can demonstrate this, I'd appreciate it.