Difference between revisions of "AI War:Current Post-5.000 Beta"

From Arcen Wiki
Jump to: navigation, search
(Prerelease 5.044)
m (minor typos fixed ("n" to "on", "th" to "the"))
Line 110: Line 110:
 
* Invincible modules now don't show some of the irrelevant data about them (health, armor, certain immunities, etc).
 
* Invincible modules now don't show some of the irrelevant data about them (health, armor, certain immunities, etc).
  
* Fixed bugs where several the seeding frequency of some things were based off the total number of "planets" in the game, including black holes and some other stuff that is solely tracked for the purpose of where-not-to-put-planets-or-links-in-mapgen and display on the galaxy map.  Some map types don't even have those cosmetic bits, making them somewhat different from those that did.
+
* Fixed bugs where several of the seeding frequencies of some things were based off the total number of "planets" in the game, including black holes and some other stuff that is solely tracked for the purpose of where-not-to-put-planets-or-links-in-mapgen and display on the galaxy map.  Some map types don't even have those cosmetic bits, making them somewhat different from those that did.
 
** This included special forces guard posts, astro train stations, and AI Eyes.
 
** This included special forces guard posts, astro train stations, and AI Eyes.
  
* Added "Reserved" slot type in the lobby; just makes it so that that player is in the game at the start even if there's no human to fill th spot.  Doesn't really do anything right now, though possibly it would allow creating singleplayer Multi-HW games that play like normal MP games, but the other player names would probably be "???".
+
* Added "Reserved" slot type in the lobby; just makes it so that that player is in the game at the start even if there's no human to fill the spot.  Doesn't really do anything right now, though possibly it would allow creating singleplayer Multi-HW games that play like normal MP games, but the other player names would probably be "???".
  
 
* Fixed a bug in the last version where right-clicking the units-to-place button in the line-place context menu would close the menu instead of reducing the amount of units-to-place.
 
* Fixed a bug in the last version where right-clicking the units-to-place button in the line-place context menu would close the menu instead of reducing the amount of units-to-place.
Line 470: Line 470:
 
*** Drones cannot traverse wormholes.
 
*** Drones cannot traverse wormholes.
 
*** Drones are super, super cheap in both metal/crystal and energy.
 
*** Drones are super, super cheap in both metal/crystal and energy.
*** Attack-power-wise n an individual basis they're about as strong as a normal fleet ship with 5x bonuses, making them fairly effective against the stuff with those hull types.
+
*** Attack-power-wise on an individual basis they're about as strong as a normal fleet ship with 5x bonuses, making them fairly effective against the stuff with those hull types.
 
** The motivation behind these:
 
** The motivation behind these:
 
*** High-difficulty play can make it feel very painful to spend knowledge unlocking something that doesn't give an offensive boost.  That's fine, but turrets in particular could get very little love due to their... very limited offensive use, shall we say.  So having turret research provide a modest amount of offensive boost (if you have CoN and thus the Neinzul Enclave Starship, anyhow) seemed like a fun way to do things.  And we've already done the cross-tech thing with having turret research unlock spire capital ship modules in LotS, so doing a bit more of it seemed fine.
 
*** High-difficulty play can make it feel very painful to spend knowledge unlocking something that doesn't give an offensive boost.  That's fine, but turrets in particular could get very little love due to their... very limited offensive use, shall we say.  So having turret research provide a modest amount of offensive boost (if you have CoN and thus the Neinzul Enclave Starship, anyhow) seemed like a fun way to do things.  And we've already done the cross-tech thing with having turret research unlock spire capital ship modules in LotS, so doing a bit more of it seemed fine.

Revision as of 01:28, 19 July 2012

Contents

Prerelease 5.044

(Note: this prerelease is not publicly available yet, we're still working on it)

  • Fixed the close-zoom image for the AI Core Neinzul Spawner Guard Post having a height that wasn't a power of 2.
    • This would only impacted you if you were all the way zoomed in on one of these, and would have led to it looking stretched or (on older graphics card) looking gibberish-like.
    • But in the recent backporting we added some extra sanity checks that catch this when the player tries to look at it.
    • Thanks to Fleet for the report.

Prerelease 5.043 A Dubious Honor

(Released July 18th, 2012)

  • In honor of it winning the latest worst-unit poll, Zenith Reserves:
    • AIP cost on death from 5*mk => 1*mk.
    • Amount of ships granted increased roughly 33%.
    • Thanks to many players for telling us for months how the AIP cost made these not much of a choice in harder scenarios, and to the voters in general.
  • In honor of coming in second in the most recent worst-unit poll, the Decloaker:
    • In general, moving this from a mobile tachyon unit with outdated stats to a mobile tachyon unit with roughly mkI-starship stats.
      • Note the tachyon range of 20k was already huge, no buff seemed necessary there.
      • Also note that it isn't really a starship from the perspective of starship disassemblers, etc, it's just beefed up because it has a ship cap of 4.
    • No longer has the IsBlind flag.
    • Now has cloaking.
    • Base Damage-per-shot from 36k => 50k.
    • Seconds-per-salvo from 10 => 2.
    • Effective Attack Range from 18k => 8k (the only reason they had such a long range was that we hadn't revisited this one since the last major range changes).
    • Base Health from 40k => 2M (again, in the general range of mkI starships).
    • Base Energy Use from 100 => 1000.
    • Base Metal Cost from 5000 => 10000.
    • Base Crystal Cost from 7500 => 20000.
    • Now has most common-to-starship immunities.
    • Thanks to players who voted on the worst-unit poll and provided their feedback.
  • Captive Human Settlement, in honor of coming in third in the "worst unit" poll: AIP-on-death from 100 => 15.
    • As was understood in the discussion in the nomination/poll threads, these are supposed to be a "penalty" unit, but players had a very good point that 100 AIP was just gameshattering for something like that (rebel colonies have the same AIP-on-death, for instance).
    • Thanks to players who voted on the worst-unit poll and provided their feedback.
  • Spire Armor Rotter, in honor of coming in fourth in the latest "worst unit" poll:
    • The general idea is to make these pretty good combat ships in their own right, at least until armor matters more in the general case and armor rot thus means more.
    • Base Health from 14,500*mk => 23k*mk (this gives them a similar cap-health as fighters).
    • Multiplier vs UltraHeavy from 2 => 3.
    • Multiplier vs Heavy from 2 => 3.
    • Multiplier vs Polycrystal from 1 => 3.
    • Thanks to players who voted on the worst-unit poll and provided their feedback.
  • Microparasite, because it (like other experimentals we need to get back to) had really outdated stats:
    • In general, rebalancing these to be something like the MkV Parasite while maintaining their distinguishing characteristics (like having twice the cap and firing 4 times as fast).
    • Metal Cost from 1800 => 1400.
    • Crystal Cost from 240 => 3400.
    • Base Health from 7200 => 36k.
    • Base Armor Rating from 500 => 1500.
    • Base Damage-per-shot from 8000 => 2000.
      • Previously they had 6.4x the dps of a mkV parasite, even though they were considered mkIII! This is still 1.6x the dps of a mkV parasite.
    • Base Armor Piercing from 0 => 3000.
    • Effective Attack Range from 4600 => 6000.
    • Multiplier vs Polycrystal from 20 => 4.
    • Multiplier vs Artillery from 1 => 4.
  • Special Forces Guard Posts no longer count as reinforcement-warp-gates and are no longer autotargeted (by player or player-ally-minor-faction ships).
    • They still get reinforcements when their planet is reinforced, and those reinforcements use the special forces behavior, but they can no longer make a planet eligible for reinforcement all by themselves.
    • This removes the "cheese" that was possible by keeping them alive to trick the AI into reinforcing a planet with nothing but a special forces guard post on it (generally a waste).
    • With the cheese gone, there's no longer a need to make it hard to keep these alive, so the autotargeting could go away.
    • Which in turn removes the annoyance of getting +1 AIP from actions over which you did not have direct control (particularly with minor faction allies).
    • We may do something more clever with the special forces ships themselves in the future, we'll see. In the meantime these two changes seem to be a net improvement.
    • Thanks to Faulty Logic, Wanderer, rabican and others for inspiring this change.
  • Fixed a longstanding bug where Decloakers in waves (only possible by having 1 wave-sending AI and 1 support-corps AI) were not having their ship cap multiplier applied and thus were appearing in vastly larger numbers than they should have been. Wasn't a big deal before, but would have been devestating with their new stats.
    • Thanks to rabican for the preemptive report and wave-calc logs uncovering the decloaker plot to conquer the galaxy before it could be set in motion.
  • Adjusted the last version's addition of radar dampening to mkII+ basic, laser, mlrs, and HBC turrets:
    • MkII's from Attack Range - 1000 => Attack Range - 2500.
    • MkIII+'s from Attack Range - 1000 => Attack Range - 4000.
    • Thanks to Wanderer for showing how the previous values did not accomplish the stated goal of preventing wormhole-exit-alpha-strike by waves on those kinds of turrets.
  • Fixed some missing-loca errors in the previous version.
  • The Zenith Trader has finally yielded to the threat of sanctions and now only sells no-AIP-on-death versions of structures to the AI. The toys will still annoy you when the AI gets them (indeed, a new toy has been added to the AI-only list to maintain annoyance equilibrium) but the Trader will no longer be an indirect source of AIP.
    • Note that this will not affect stuff the AI has already bought off the trader.
    • Thanks to Wanderer and others for periodically reminding us that this was putting a cramp on their desire to include the trader, particularly in harder scenarios.

Prerelease 5.042 Pay No Attention To The Man Behind The Curtain

(Released July 17th, 2012)

  • The textbox improvements from AVWW have been backported to AI War.
    • Note that since we can't backport the entire AVWW GUI at this time (AI War has some controls that are simply not compatible with the AVWW-style GUI at the moment), there may still be some wonkiness with the textboxes in some cases. If you see any that are reproducible, please do let us know.
    • However, in the most-annoying-cases of things like the chat box losing focus, the hope is that these changes have fixed that issue. Knock on wood!
  • Backported the ability to do hue shifts via shader from AVWW.
  • Backported an enormous amount of the new render pipeline from AVWW; this doesn't involve much of the sorting that AVWW was doing, because AI War already had its own highly-evolved and engine-appropriate way of doing its graphical sorting.
    • However, this does decouple most of the graphics from the main CPU processing such that if your GPU is having trouble keeping up, it will impact the speed of gametime much less or not at all.
    • Additionally, as we saw with AVWW, we're now making more efficient use of GPU time in general by parallelizing some of that work, which leads to various gains (not really higher framerates here, but less likely of a drop in framerate and more flexibility about what target framerate you select, since that's something that can be manually set in this game).
  • Neinzul enclave drones are now immune to reclamation.
    • Thanks to Tssbackus for reporting oddities when the AI reclaimed drones.
  • Made the clamp/repeat status of images explicit rather than implicit inside the code, which lets us do a number of new visual effects when needed.
    • The immediate effect is that the various beams (repair, cloaking, etc) now have a slightly higher fidelity to themselves.
  • Non-square images are now supported by the game (more backporting from AVWW).
  • Sprite dictionaries are now supported by the game (again more backporting from AVWW).
  • All of the explosion effects in the game now use sprite dictionaries, which makes the initial game load quite a bit faster as it has to load 140ish fewer files (though the amount of data is roughly the same, it's still faster).
  • Backported the draw order sorting from AVWW after all. This should help with the performance of lots of shots, lines, forcefields, or similar being on the screen at the same time. Or far zoom icons for ships, for that matter. It won't help for the ships themselves when you are very zoomed in, but that's comparably rarer.
  • Fixed a bug in the new energy model where if you had zero home command stations (even in MP, where losing your home command isn't game-over) the energy collectors would produce 15k energy instead of 150k.
    • Thanks to Kalias for the report.
  • Invincible modules now don't show some of the irrelevant data about them (health, armor, certain immunities, etc).
  • Fixed bugs where several of the seeding frequencies of some things were based off the total number of "planets" in the game, including black holes and some other stuff that is solely tracked for the purpose of where-not-to-put-planets-or-links-in-mapgen and display on the galaxy map. Some map types don't even have those cosmetic bits, making them somewhat different from those that did.
    • This included special forces guard posts, astro train stations, and AI Eyes.
  • Added "Reserved" slot type in the lobby; just makes it so that that player is in the game at the start even if there's no human to fill the spot. Doesn't really do anything right now, though possibly it would allow creating singleplayer Multi-HW games that play like normal MP games, but the other player names would probably be "???".
  • Fixed a bug in the last version where right-clicking the units-to-place button in the line-place context menu would close the menu instead of reducing the amount of units-to-place.
    • Thanks to vadatajs and Eternaly_Lost for reporting.
  • Fixed some missing-loca bugs with the parts of the view-controls window pertaining to the line place context menu.
  • Shield Bearers (the normal ones; this was already true of the spirecraft ones) are now immune to insta-kill.
    • Thanks to Varone for the suggestion.
  • All non-shield modules are now immune to armor boosting (they're invincible, it'd be a waste).
    • Thanks to TechSY730 for the report.
  • AI Carriers:
    • Effective range from 6000 => 3000.
    • Base Health from 3M*mk => 2M*mk.
    • Thanks to Wanderer for inspiring these changes.
  • MkII+ Basic, Laser, MLRS, and Heavy Beam Cannon turrets now have radar dampening equal to their range minus 1000 to prevent them being inevitably alpha-striked by really substantial waves.
    • Thanks to Wanderer for inspiring these changes.

Prerelease 5.041

(Released July 11th, 2012)

  • Added "Line Place" context menu option for when you open the context menu (defaults to alt+right-click) while you have the build menu open and an item selected for direct placement.
    • From the line-place menu instructions:
      • Step 1: Click where you want one end of the line segment to be. This line segment doesn't actually set the final location of anything, Instead it tells the game the length and angle of the segment.
      • Step 2: Click where you want the other end of the line segment to be.
      • Step 3: Specify the maximum number of units you want to place below (left click the number to increase, right click to decrease, and the usual keys for multiplying by 5, 10, or 50), pick whether you want a packed line (good for mines), and then left-click where you want to place the units.
    • The main use case in mind for this was efficient use of mines, but can also be helpful for many defensive emplacements, or simply for aesthetic appeal. The interface could be cleaner but this is what we had time for right now.
    • Thanks to Wanderer for inspiring this addition.

Prerelease 5.040 Reenergized

(Released July 10th, 2012)

  • AI Guardians energy cost from 500*mk => 1250*mk; this is basically irrelevant (AI players don't have an energy model, really), but does help Impulse Reaction Emitters hurt them, giving the IRE another situation in which they are useful that isn't dependent on superweapons or something like that being enabled.
    • Thanks to Wingflier for the suggestion
  • Added some extra logging on the calculation of wave-time-intervals (when advanced logging is enabled).
  • Fixed a moderately longstanding bug where if while starting a new game you select a planet as a homeworld, then deselect it (in favor of some other homeworld(s) ) before actually starting the game, and that planet happens to have the superterminal on it, the superterminal would start the game in "active mode". Needless to say, that would be a short game.
    • Thanks to Mick for the report and save.
  • Forcefield-protection no longer prevents a cloaked unit from being revealed by tachyon beams.
    • Thanks to Wanderer for pointing out that this was happening, and wasn't much fun if the cloaked unit in question was a guard post.
  • Grenade Launcher grenade explosion radius from 200/300/400/500/600 => flat 500.
    • Thanks to Hearteater for pointing out that at 200 the MkI was frequently not hitting max targets even when fired into a relatively dense group.
  • Flak grenade (from guardians and turrets) radius from 300/350/400/450/500 => flat 500.

Energy System Rework

  • The motivation here:
    • The previous energy system was settled on after a series of different models were tried, and has been around for over 2 years, and has served pretty well.
    • But there were a number of problems pointed out by players over the years, the most bothersome being:
      • There's significant motive to maintain as close-to-zero positive net energy balance because energy costs metal+crystal per second and a positive net energy balance provides no real benefit.
        • A positive balance did protect against having your forcefields shut off in case of losing a reactor, but that could be easily protected against by a big pile of low-powered reactors that you can bring up as needed; or you can go low-power a hundred spider turrets, or whatever.
      • And maintaining that low-wasted-energy state involved _tons_ of micro. A couple of "automated energy hamster" hotkeys were added to greatly reduce that micro (by making the "low-power least efficient 'on' reactor" and "power-on most efficient 'off' reactor" operations a single keystroke instead of minutes of scrolling and clicking), but that was really just a bandaid.
    • Many people have requested automated energy management as a solution to all this, but whenever the game is simulating something that it then turns around and plays optimally without your involvement... that means something is wrong. In this genre, anyhow.
    • Thanks to Cyborg and other players for making this point, and being patient as we tried to find a better model.
  • The overall result is that the energy/econ game should actually be easier, unless you were relying on low-efficiency reactors or low-powering tons of stuff to make ends meet. In those cases it shouldn't be much harder.
    • But please let us know if the new model really messes you up in some way, or if you have other feedback. It's not like this model can't be changed, it just seemed a definite step in the right direction from where we were.
    • If you're curious about the comparison math, check out this post: http://www.arcengames.com/forums/index.php/topic,11031.msg110117.html#msg110117
    • Anyway, on to the specific changes:
  • Removed the Energy Reactors (all of them, MkI, MkII, MkIII).
  • Added the "Energy Collector", which is like the energy reactors were except:
    • Produces 150,000 energy.
      • For reference, in the previous model an EnergyI+EnergyII+EnergyIII produced 125,000.
    • No ongoing m+c cost.
      • For reference, in the previous model an EnergyI+EnergyII+EnergyIII cost 57m+57c per second to run.
    • Can only build one per planet per player.
    • Output scales up with that player's number of homeworlds (to scale up for the extra stuff multi-HW players can build, similar to how reactors used to do it but without spamming lots of them).
    • Cannot be low-powered (there'd be no point).
  • Added the "Matter Converter", which is like the energy reactors were except:
    • Produces 50,000 energy.
    • Costs 100m+100c per second to run.
    • No construction cap, and also no efficiency penalty for stacking.
      • Yes, this does mean that for now it's best to just pile these all up in a defensible place (much like manufactories); that will probably change in the future but probably not through an efficiency penalty.
    • Cannot be low-powered, since the main point of this rework is to avoid "player-time-tax" micro.
      • This can still result in mid-battle micro if you just lost a collector or whatever and need to build another converter, but that's real in-game costs at a critical moment rather than the only difference between optimal and sloppy play being how much wall-clock-time you personally want to spend "making change for a dollar" throughout the game.
    • In general, these are very inefficient compared to the old reactors, but more efficient than deeply-stacked low-efficiency reactors. The idea is that the collectors replace the output you used to get from normal-efficiency reactors, and the converters fill the role of the low-efficiency reactor piles.
  • Putting units in low-power mode now no longer reduces their energy use.
    • Again: removing the motive to micro stuff for energy purposes is one of the driving motivations here.
    • Renamed "Low Power mode" to "Stand Down mode", since it's no longer for the purpose of reducing energy.
    • The mechanic for reducing energy use in stand-down mode is still there, just unused. It may be used for golems or stuff like that later, we'll see.
  • Removed energy costs from Human Home Settlement and Cryogenic Pod structures, since you can't low-power the settlements anymore (and 8000e a pop isn't much fun in a tight early-game situation).
  • Removed the auto-build-energy-reactors controls, and added toggles at the galaxy-level and planet-level for autobuilding collectors, and sliders at the galaxy-level and planet-level for autobuilding converters.
  • Added new slider to galaxy-wide per-player-controls screen: Energy Buffer To Maintain
    • If this is set above zero, the game will try to maintain that amount of "buffer" energy above zero. A few examples:
      • Docks will not build ships that would take you below the buffer amount.
      • Ships will not be reclaimed if it would take you below the buffer amount.
      • Broken Golems will not be activated if it would take you below the buffer amount.
    • This can be restrictive, but it can also help if you're deliberately trying to keep all your defenses operational in the event of the AI destroying one or more of your energy producing units.
    • Note that this will not stop you from scrapping energy producing units (however low that may take your net energy), so be careful.
      • This is because going negative energy never stopped scrapping before, so that part wasn't changed.
    • Thanks to chemical_art for the suggestion.
  • When upgrading saves from 5.039 and earlier:
    • For all EnergyI, EnergyII, and EnergyIII units:
      • If that player already has an Energy Collector on that planet, the reactor is replaced by a Matter Converter.
      • Otherwise, the reactor is replaced by an Energy Collector.
    • After that, while the player has > 60,000 spare energy and any remaining Matter Converters:
      • Scrap a Matter Converter on the planet with the most remaining Matter Converters controlled by that player.
    • The result should be that:
      • If you had a positive energy balance before this version, you will have a positive energy balance when you load the save in 5.040+.
      • It won't give you a lot of Matter Converters you don't need.
      • You'll still want to look at your energy situation and make adjustments for the new model. Particularly if this version-upgrade logic somehow messes up in your case ;)
  • The automated energy hamsters have taken off without giving notice, but we suspect they're on vacation in Bermuda.
  • In case you were wondering, all the tooltips and relevant tutorial components have been updated for the new model, but please let us know if we missed something.
  • Thanks to many, many players over the years for weighing in with feedback on the energy model. Keep it up, we know this one isn't perfect either ;) Particularly:
    • Cyborg, for originally getting through to us that the old model was no more challenging than "making change for a dollar", and a lot more time-consuming.
    • Hearteater, for proposing multiple alternate models (including the one that inspired the one we ultimately went with above).
    • chemical_art, Diazo, Wingflier, Wanderer, TechSY730 for lots of participation in the discussions/debates/etc.
    • And many others I'm sure I'm forgetting; the forum search engine appears to have forgotten about the relevant threads to avoid further trauma.

Prerelease 5.039

(Released July 8th, 2012)

  • Remains Rebuilders no longer require supply, to make rebuilding a "satellite" planet at least possible.
    • If this makes some wild exploits possible please let us know, but since most of the stuff that can be rebuilt requires supply anyway...
    • Thanks to Wanderer for pointing out the tension between these requiring supply and the newly added rebuildable-ness of command stations.
  • Fixed a bug where neinzul drones (which cannot go through wormholes) could inherit a go-through-wormhole order from the enclave starship building them, and would actually go through the wormhole.
    • Now they'll generally _move_ to a point near the target wormhole, but they won't try to traverse the wormhole itself.
    • Thanks to TechSY730 for the report.
  • Fixed a longstanding omission preventing low-power ships under a forcefield protecting a passive guard post (and perhaps other guard posts) from coming out of low-power when the forcefield/post/guards were attacked.
    • Thanks to TechSY730 for the report and save.
  • Fixed the colony ship tooltip which was still saying it had to be near the target construction point, and also amended its hint about replacing existing command station to reflect recent changes.
    • Thanks to TechSY730 for the report.
  • Fixed a bug where beam and warbird starships were still in the "Starship mk III" buy-group for the AI; they're now in the mkV group where they're actually balanced to be now.
    • Thanks to zharmad and TechSY730 for the report.
  • Fixed a longstanding bug where the "prevent construction of new command station by a different player than the current controller of the planet" rule was preventing gifting of command stations.
    • Thanks to iob for the report.

Prerelease 5.038 If You Rebuild It They Will Come

(Released July 7th, 2012)

  • Fixed a longstanding bug where the AI fortresses in the tutorial were the mkIII _human_ versions, not the AI versions.
  • Human Fortresses now drop remains and can be rebuilt (and due to the 50% discount on a rebuild vs. a fresh build it's more than just a convenience).
    • Note that this does not impact AI fortresses at all.
    • Thanks to chemical_art and many other players for the suggestion.
  • Human Forcefield generators (including hardened ones) now drop remains and can be rebuilt.
    • Note that the normal under-construction-forcefield-generator restrictions still apply; namely that it cannot receive construction assistance if it is close to another forcefield that has recently taken damage (this was added a few months ago to prevent forcefield+engie stacks that were effectively immortal).
    • Still, the fact that the rebuild starts at 50% instead of 0% (and is automatic if there are remains rebuilders nearby, as opposed to requiring player intervention) is a buff.
    • Also note that this does not apply to the "player home forcefield generator" that starts next to each human home command station: those are supposed to be irreplaceable.
    • Thanks to chemical_art and other players for the suggestion.
  • Human command stations (other than the home command station) now drop remains and can be rebuilt.
    • Also removed the rule where colony ships and mobile builders on the planet (or in a transport on the planet) when a human command station dies also die.
    • That rule (and the lack of rebuildable command stations) was there to prevent exploits based around very rapidly rebuilding command stations. It could often tie up AI attack forces much longer than would normally be possible, etc.
    • However, one of the most unnecessarily-micro-intensive operations in the game was rebuilding lost planets because you have to build a colony ship, select it, give it a move order to the lost planet, switch to that planet, select the colony ship, select the command station type you want, and place it. Way more player interaction than should be necessary for "rebuild what was there". But we couldn't make it a lot easier without making those exploits possible again.
    • So, to replace the previous exploit-prevention, now when a non-home human command station dies then it "stalls" the construction of any human command station on that planet for 4 minutes (1 minute if the station that died was a military station); during that time a new station can be placed or the previous one's remains rez'd by a remains rebuilder, but the resulting under-construction station will not actually make any progress on construction until the stalling timer has expired.
      • Note that all ways of removing a human station will trigger this timer: being destroyed by enemy fire, being scrapped, and being replaced by another human command station. The latter is something of an inconvenience but the thought is that it is far less than the convenience gained by being able to automatically rebuild command stations. If this is wrong, let us know :)
    • Thanks to buttons840 and many other players for pointing out how much micro this could be.
  • Fixed a bug where remains-dropping-units destroyed by the forcefield-cascade-splash-damage from a siege plasma shot would not drop remains.
    • Thanks to TechSY730 for the report.
  • Fixed a bug in the last couple versions where the detect-loss-of-focus-windowed-mode (on windows) logic was causing the game to stop rendering a lot of stuff just because the window didn't have focus, though the window could actually still be visible.
    • Thanks to Wanderer for the report.
  • Fixed several bugs in the rule that changed possible wave time based on number of entry points, and added info on that computation to the wave logging logic.
    • Thanks to Wanderer for the report that led to this discovery.

Prerelease 5.037

(Released July 7th, 2012)

  • Fixed a bug in the last version where the new neinzul drones were not being selection-filtered the same way as most mobile military ships (it was because they can't go through wormholes, incidentally).
    • Thanks to TechSY730 for the report.
  • Now when a unit is actively making progress on a build queue it loses the ability to be cloaked until 2 seconds after the last build queue activity.
    • Notably, this prevents neinzul enclave starships from spamming a planet with drones (and whatever else) with impunity. Can still FRD built non-drones through a wormhole to a target planet, though, and that's fine.
    • Also this will break the cloak on modular ships that are building new modules, but since modules mostly can't die in combat anymore (except shield modules) and their internal build queue is disabled while they're in low-power mode, and if they're not in low-power mode and they're on an enemy planet they've probably lost cloak due to shooting at something... all told, shouldn't be a big change for them.
    • Thanks to RogueThunder and others for (reluctantly) notifying us of how exploitative this was.
  • Fixed a typo in wave size calculation logging.
    • Thanks to TechSY730 for the report.
  • Fixed a bug in the last version where the laser turret upgrades could show the stats on laser drones instead of... laser turrets. Similar for other turret techs that also unlock drones.
    • Thanks to Minotaar and Wanderer for the report.
  • Fixed a longstanding bug where a unit could both be reclaimed and regenerated, which would sometimes lead to an AI unit being reclaimed, zombified, and warped off somewhere deep in AI territory. Not great for threat management.
    • Fixed a related bug where a unit that had swallowed other units or was tractoring other units would take them with them when regenerated. Now those units simply cannot be regenerated unless they have no such "load".
    • Thanks to HTL2001 and TechSY730 for the reports.
  • Further improved the maw swallow-target logic to not get stuck on invalid targets (like if it's shooting at a starship, etc, it will now try to swallow valid targets on its target list).
    • Fixed a related bug where maws could try to swallow-target a starship (which it cannot swallow).
    • Thanks to Wanderer for reporting that they were still getting stuck.
  • Nuanced the new wave-time-calculation rule added in the last version such that it is not in effect at the very beginning, and gradually phases in so that it is fully in effect at the two-hour mark. So at the 30 minute mark it has about 25% impact, giving you a chance to expand the number of "entry points" before the AI starts throwing max time waves at you automatically.
    • Thanks to Wanderer for reporting a test game where this rule rather... decisively concluded the game early.
  • Carriers now display "x(Variable, see below)" next to their attack power to make clearer that their salvo size varies (by the number of contained ships).
    • Thanks to Wanderer for the suggestion.
  • Carrier hull type from Scout => Ultra-Heavy.
    • Thanks to Wanderer for inspiring this change.

Prerelease 5.036 The Wandering AI

(Released July 3rd, 2012)

  • Vampire claws are now immune to being camouflaged by the Camouflager AI Type because the combination of melee and cloaking didn't work very well there (could wind up with non-decloakable enemy vampire claws just sitting on your planet for a long time).
    • Thanks to Wingflier for the report and save.
  • Made Maws try to vacuum their shoot-at target if for some reason vacuuming their "assist" target failed.
    • Thanks to Wanderer and Eternaly_Lost for providing saves where Maws had lockjaw.
  • Amended the reinforcement logging to better reflect the impact of alert on the order that planets are checked for reinforcement.
    • Thanks to Wanderer for pointing out that what it was saying was not what was happening.
  • Fixed a bug where when the AI picked engineers or remains-rebuilders for reinforcements, it was "spending" too much on them.
    • Thanks to Wanderer for submitting the log that showed this.
  • Fixed a fairly longstanding bug where player ships would not autotarget an AI ship that was under a (non-module) forcefield and guarding something because that ship had not set its "angry" flag (to avoid leaving the protection of the forcefield). Now it considers the ship eligible for shooting if either it or its guard post has been angered recently.
    • Thanks to Wanderer for the report and save of player Spire Blades having this problem.
  • Core CPA Guard Posts now start a timer-for-CPA instead of instantly triggering a CPA.
    • Thanks to Wingflier for the suggestion.
  • Core CPA Guard Posts now trigger in response to >= 1 enemy human military ship being present, rather than > 1.
    • So that Artillery Golem won't get by on the ol' "But I'm just *one* ship!" excuse anymore.
  • Since the recent mine rebalance it's become apparent that the EMPs were made a bit too strong, and the Area mines hadn't been given enough to justify the 4k Knowledge cost.
    • EMP mines:
      • Health halved, which halves the number of times a single one will go off before needing to be rebuilt.
      • Knowledge cost from 1500 => 1000.
    • Area mines:
      • Knowledge cost from 4000 => 2000.
    • Thanks to Wanderer for inspiring these changes.
  • Spire Maw vacuum-recharge-seconds from 2 => 5/4/3/2/1.
    • Thanks to Wanderer for the suggestion.
  • Knowledge Hacker and Ship Design Hacker collision priority set to 890 (below only stationary objects, standard/hardened forcefield generators, command stations, command station cores, and rally posts).
    • Thanks to Wanderer for pointing out that trying to cover these with Riot starship forcefields could lead to a Riot displacing the hacker and resetting the timer.
  • Fixed a longstanding bug where an Ion Cannon killing a warhead would cause it to not properly detonate as if it had been killed by a Warhead Interceptor.
    • Thanks to Wingflier for the report and save.
  • Fixed a bug where the AI would not attack armored warheads (due to a "very low priority target" flag on those unit definitions).
    • Thanks to TechSY730 for the report and save.
  • The rest of the "official" lobby setup scripts have been updated to use the new grammar.
  • Fixed a bug with the do-not-auto-pause-on-lost-focus toggle where the lost-focus logic was still suppressing basically all game logic even though it wasn't entering a formally paused state.
    • Thanks to amethyst for the report.
  • Put in an experimental method of detecting that the game has lost focus in windowed mode (our recent solution for this only works in fullscreen mode). Once loss-of-focus is detected, the existing logic for that state will apply (not scrolling, resetting input afterward to clear stuck keys, autopausing unless the no-autopause toggle is on).
    • For now it only works on Windows (the new method is not even tried on Mac), sorry about that, but if this works out we can probably get something similar to work on Mac too.
  • Previously Core CPA Guard Post spawns were scaling with Floor(AIP/50) instead of actually AIP/50 due to the data type used to store the result; now that part does not get floored, allowing a more granular factoring-in of AIP.
  • Spirecraft Shieldbearers:
    • Can now be put in low power mode (shutting off their projected shield).
    • Now their projected shield no longer shrinks as the shieldbearer loses health.
      • Something more like shrinking-to-90% had been considered, but that would still have resulted in stacks of them getting whittled down all at once (while still taking up ship cap) rather than dying one at a time while leaving the remaining ones at high health (depending on how they were stacked).
    • Now have AI-only variants that can be chosen for exos.
      • To make them actually work with exos, this variant actually has normal guns. They're only moderately powerful (about 1/4 as much DPS as a same-mark siege tower), but they avoid the logical problems the gunless ones had in exos.
      • These still have the shrink-when-damaged behavior, to make them a bit easier to handle.
      • Adding shieldbearers may make exos significantly harder, but that may not be a bad thing. Let us know if you find it particularly fun or unfun; adjustments can be made.
    • Thanks to TechSY730 and others for inspiring these changes.

Rebalancing High (and-not-so-high) Difficulties

  • Since the many changes to high-difficulty wave calculations a few months ago the 9+ difficulty range has gotten a fair bit of play and generally looks easier than it has been. And just recently the game was beaten fair-and-square on 10/10. In response to that bug:
    • A Diff 9+ player will seed 1 less data center than normal (but no fewer than 1 if it would have seeded any).
    • On Diff 8+ the first step of the wave size formula has been changed from:
      • ( AIProgress * AIDifficulty ) / ( 13 - AIDifficulty )
      • to ( ( ( AIProgress * 0.8 ) ^ 1.1 ) * AIDifficulty ) / ( 13 - AIDifficulty )
      • This produces very similar sizes in the early game but adds a gradual exponential increase as AIP gets higher, having both the effect of making later planet captures not feel as much less significant (in terms of wave size) than early planet captures and increasing the overall "throw weight" of the AI's attacks on these higher difficulties.
    • On Diff 7+ the randomization of wave intervals (which feeds directly into step 5 of the wave size formula) has been changed to consider the number of planets that the AI can send waves against (and thus the probable defensive power of those worlds, i.e. chokepoints, and the viability or lack thereof of smaller waves):
      • If there are 6+ wave-targetable planets it uses the normal (pre-5.036) formula of adding a random number from (AIDifficulty*-60) to (AIDifficulty*120).
      • If there are 5 wave-targetable planets the random is from (AIDifficulty*-30) to (AIDifficulty*120).
      • If there are 4 the random is from 0 to (AIDifficulty*120).
      • If 3, from (AIDifficulty*30) to (AIDifficulty*120).
      • If 2, from (AIDifficulty*60) to (AIDifficulty*120).
      • If 1, from (AIDifficulty*90) to (AIDifficulty*150) (making it actually able to hit single-chokepoints harder than it used to).
      • The upshot is that it makes the AI a little "smarter" about figuring out that it may as well not bother sending small waves against concentrated defenses and should just save up for stronger attack forces. Accordingly, since the AI on <7 is intentionally a bit dumb it doesn't get this new rule at all.
    • Thanks to many players (including zoutzakje, Diazo, Wanderer, rabican, Orelius, chemical_art, and probably others I can't remember right now) for the past few months of 9+ playtesting and related suggestions. No good deed goes unpunished.
  • Previously, an AI of difficulty 9.3 or higher would automatically be one tech level higher than normal. This was generally fine but did cause a pretty massive difficulty cliff between 9.0 and 9.3, and we prefer to keep each step a relatively smooth progression from one step to the next. Now:
    • That automatic tech level increase has been removed.
    • AI's with difficulty > 9 get an additional reduction to their tech thresholds (on top of the normal difficulty*10 one) of ((difficulty-9)*200). So the threshold for reaching tech 2 is:
      • 9 = 210 (same as before).
      • 9.3 = 148.
      • 9.6 = 85.
      • 9.8 = 43.
      • 10 = 0 (so diff 10 starts at tech 2).
      • Of course, that makes the thresholds for tech 3 and tech 4 much higher since it's using the normal base of 800 and 1200 for those instead of 300 and 800 (which they used to use due to automatically being one tech level higher), thus actually making things a lot easier for those higher AIPs. See next change.
    • To add back some of the difficulty but in a more granular fashion than before, on diff 9+ (not just 9.3+) waves will have a portion of their fleet ships "promoted" to the next tech level according to how close AIP is to the next tech level.
      • So if you're playing on 9.6 and have 50 AIP, approximately 50/85= 58% of the mkIs fleet ships in a wave will be promoted to mkII.
      • Of course, they'll also run into the tech level multiplier which will reduce their actual numbers significantly, but roughly 58% of the wave's "strength" of that ship type was spent on the higher tech level.
    • Thanks to Wanderer for the suggestion.
  • Previously carriers were way less dangerous than the ships they contained, tending to make a wave + a stack of carriers feel a lot more like that many back-to-back waves. This is better than the pre-carrier condition of waves capping out at 2000 ships, but still tends to cause the actual difficulty of waves to increase much much slower with the size of the wave than is desirable. So:
    • Now gets +1 shots-per-salvo per 16 ships inside the carrier (that's on high caps; per 8 ships on normal, 4 on low, 2 on ultra low). So a carrier containing 1000 ships on a high caps game has 63 shots per salvo.
    • Base Attack Power from 1400*mk => 19200*mk (the base strength of 16 fighters on high caps, but without the fighter's bonuses).
    • Seconds-Per-Salvo from 2 => 4 (same as fighter, cuts down a bit on shot-spam).
    • Can no longer fire as though ignoring through forcefields, but it can still move through them.
    • Shot type from dark matter => energy bomb as the idea is not for these to be easily counterable via counter-dark-matter turrets.
    • Hull-bonus against Turret from 0.1 => 1.
    • Hull-bonus against Structural from 0.1 => 1.
    • Hull-bonuses against Scout and Command-Grade staying at 0.1.
    • In summary, a full carrier is now pretty dangerous, but the firepower is still significantly lower (by about 3x, probably) than its total contents. That's fine as they'll probably still feel more powerful than you want them to be.
    • Thanks to Wanderer for inspiring this change.
  • Previously it was possible for AI Homeworlds to get really brutal combinations like an AI Eye + 3 (or more) Core Raid Engine guard posts (which is pretty much the RNG saying "good game" on higher difficulties but you don't know until you scout it), or nothing really all that threatening at all. Randomization is core to AI War, but this particular bit of it could literally be the difference between a fairly easy endgame and a mathematically-impossible-to-win situation.
    • Now, for AI Homeworlds, it randomizes the three most brutal structures (Core Raid Engine, Core CPA, and AI Eye) separately from the rest of the structures:
      • On Diff 9+ it always gets two picks from this new set. So you could get an Eye + a Core Raid, or two CPAs, or two Eyes (which is actually kind of nice to you since they don't really stack), or whatever. But not 3 Core Raids. And not none of the above.
      • On Diff 8+ it randomly rolls (per homeworld) between one and two picks.
      • On Diff 7+ it always gets one pick.
      • Below Diff 7 it randomly rolls between zero and one picks.
    • As the set of core guard posts expands in the future (expansions, mainly), this "brutal" set can also be added to.
    • Thanks to Wanderer for inspiring this change.

New Drones For The Neinzul Enclave Starship

  • Didn't want to let the AI have _all_ the fun, so: Added 4 new drone ship types that only the Neinzul Enclave Starship can build:
    • Neinzul Laser Drone I-IV
      • MkI and II require Laser Turret II technology. MkIII and IV require Laser Turret III technology.
      • Has 5x bonuses against the hull types that Laser Turrets have a bonus against.
    • Neinzul Needler Drone I-IV
      • MkI and II require Basic Turret II technology. MkIII and IV require Basic Turret III technology.
      • Has 5x bonuses against the hull types that Basic Turrets have a bonus against.
    • Neinzul MLRS Drone I-IV
      • MkI and II require MLRS Turret II technology. MkIII and IV require MLRS Turret III technology.
      • Has 5x bonuses against the hull types that MLRS Turrets have a bonus against.
    • Neinzul Missile Drone I-IV
      • MkI and II require Missile Turret II technology. MkIII and IV require Missile Turret III technology.
      • Has 5x bonuses against the hull types that Missile Turrets have a bonus against.
    • A Neinzul Enclave Starship can build any of these up to its own mark level once you have the corresponding turret technology, just select an enclave and click the "DRONE" tab on the buy menu (similar to how the Starship Constructor has a "RIOT" tab for the Riot Control Starships).
    • Stat wise:
      • Each drone only lives 30 seconds; no repair, no attrition-stops-on-low-power, no regeneration chambers, nada. It's got 30 seconds to hurt something.
      • Drones do not have the lightning speed of the normal Youngling types (not wanting these to horn in on what makes the younglings special). One consequence is that the "mothership" has to be within a certain range of the stuff you want hurt.
      • Drones are pretty flimsy, but dying from enemy fire isn't much of an event for these.
      • Ship cap is about 25% of normal because these aren't supposed to be like a whole new ship unlock, they're just a bonus on top of what you already get for turret (and enclave starship) research.
      • Drones cannot traverse wormholes.
      • Drones are super, super cheap in both metal/crystal and energy.
      • Attack-power-wise on an individual basis they're about as strong as a normal fleet ship with 5x bonuses, making them fairly effective against the stuff with those hull types.
    • The motivation behind these:
      • High-difficulty play can make it feel very painful to spend knowledge unlocking something that doesn't give an offensive boost. That's fine, but turrets in particular could get very little love due to their... very limited offensive use, shall we say. So having turret research provide a modest amount of offensive boost (if you have CoN and thus the Neinzul Enclave Starship, anyhow) seemed like a fun way to do things. And we've already done the cross-tech thing with having turret research unlock spire capital ship modules in LotS, so doing a bit more of it seemed fine.
      • Despite the fairly massive buffs Neinzul Enclave Starships received not long ago there's still been a lot of feedback that they're underwhelming and that they don't have a lot of point. Well, now they can build lots of little sharp points that will really annoy the AI for you, and they're the only way to build them.
      • But this is also not so powerful that you have to do turret research or even use the enclaves at all, it's just making it nicer if you do.
    • Thanks to many players for feedback on a variety of issues that inspired this addition.

Better Scaling For Multi-Homeworld Games

  • Previously CPA size was multiplied by the number of (non-Helper-role) human players, fixed to be multiplied by the (starting) number of human homeworlds.
  • Previously if there were multiple human homeworlds (and thus human ship cap was much higher) each AI player would send that many extra waves (and various threats like normal CPAs and exo-attacks would be multiplied in size accordingly, though not always linearly).
    • This was generally fine but:
      • Particularly on high homeworld counts that could lead to a ton of waves all smaller than the carrier threshold that would nonetheless add up to larger than the max number of AI ships that the game generally allows on a planet (5000), causing those extra AI ships to just disappear.
      • Also, now that carriers will be more of a threat, it would be nice for them to see use in those circumstances.
      • Some important varieties of AI strength were not being increased at all, like: Reinforcements, Counterattack Guard Post spawns, Raid Engine spawns, Core Raid Engine spawns, Core CPA Guard Post spawns,
    • So now:
      • If there are one or two human homeworlds, the number of waves per AI player is calculated the same way as before: one and two, respectively. But if there's more than that it still doesn't go above two and instead increases the size of the individual waves proportionately.
        • So 3 HWs means twice as many waves as single-player (instead of three times as many) but they're 1.5x as large as they would have been. 4 HWs means twice as many waves that are 2x as large, and so on.
      • Reinforcements, Counterattack Guard Post spawns, Raid Engine spawns, Core Raid Engine spawns, and Core CPA Guard Post spawns now use the same scaling-with-HW-count as is used for normal CPAs: multiply by 1 + ((HW_count-1)*0.33).
        • This isn't 1:1 because the power increase from multiple homeworlds isn't (closer in MP, but the problems of coordination and efficiency are in play there).
    • Thanks to Wanderer, Eternaly_Lost, and others for feedback on multi-HW play (notably the lots-of-non-carrier-waves thing).
  • When Spirecraft are enabled and there's more than one human homeworld, the number of asteroids seeded will go up.
    • The main reason is that on Hard you're facing much harder exos on multi-HW, but weren't getting any additional benefit to match. Medium was not as much of a concern, but it could use it too.
    • The increase is 50% for each additional human homeworld, so 2 HHWs => 150% asteroids, 3 HHWs => 200%, 4 => 250%, etc. A straight-up 1:1 was also possible but seemed excessive. In general multi-HW isn't really a 1:1 increase, but let us know if this scaling feels like too much or too little.
    • Thanks to chemical_art for inspiring this change.

Prerelease 5.035 Teleport Battle Stations And The Return Of The Dyson Sphere

(Released May 24th, 2012)

  • Fixed bug where the new pop-cap mechanic for the dyson sphere was setting the population cap properly according to faction-intensity... and then setting it to 2. Yeaaaaah. Dyson's on vacation in 5.034, boys and girls!
    • Thanks to platinawolf for the report.
  • Fixed an omission in the previous version where the variable intensity of the Advanced Hybrids plot did not do anything (all values 1-10 did exactly the same thing as Advanced Hybrids being on before variable-intensity was implemented).
    • At intensity 1, hybrids get access to the more advanced modules and maturity classes normally granted by Advanced Hybrids.
    • At intensity 2, the super hybrid can execute the first stage of the Hybrid-Dyson plot.
      • Note that said plot no longer happens at all with Advanced Hybrids off; the super hybrid can still spawn but it'll just be a beefier hybrid in general.
    • At intensity 4, the second stage of the Hybrid-Dyson plot becomes possible.
    • At intensity 7, the third stage of the Hybrid-Dyson plot becomes possible.
    • Fixed a bug in the previous version in the computation of how much each maturity gain contributed to the hybrids' "central dirty tricks bank" where it was doubling it if Advanced Hybrids was _off_, not when it was on.
      • Also adjusted the computation so that instead of simply doubling it when Advanced Hybrids is on, it adds 25% of the original amount per point of the Advanced Hybrid plot's intensity (if the AI's have different intensities for it, picks the higher of the two). So on 4 it just doubles it, like before the variable-intensity thing.
    • More can and probably will be done with the different intensities, but it's a start.
  • Now if you use the mid-game Manage Players interface to switch a player from the Normal role to Helper and then save that, it properly tells you that you can't do that rather than trying (and generally causing a desync).
    • Thanks to Cyborg for the report.
  • The Lobby now has a "role" dropdown for each occupied human player slot. The only options are Normal and Helper, but that makes it possible to have someone join from the start as a Helper. A few notes:
    • At least one human player has to be in the "Normal" role for the game to be started. This does not have to be the first player (i.e. host).
    • Helpers cannot select homeworlds (and are not given any units or planets at the start of the game).
  • Fixed a bug in the handicap modifier computations that caused negative handicaps to be far harsher than they were supposed to be in some circumstances (like making CPA size zero when it was supposed to be, say, 24, because the multiplier was about 51x smaller than it was suppposed to be).
    • Thanks to Minotaar for the report and save.
  • CPAs now don't get queued up if the result based on difficulty, AIP, etc would be way too small (under 200 ships, for high caps, adjusted appropriately) (once a CPA is announced, however, it will happen).
  • Fixed a longstanding bug where AOE "canister" shots (flak, grenade, plasma-siege) were not properly hitting forcefields when targeting a ship protected by them, unless the targeted ship was also in range of the explosion from the point where the shot hit the forcefield.
    • Thanks to Dazio for the report and save.
  • Marauders and Resistance Fighters can now be targeted by ships that cannot target small units (Bomber Starship, etc).
    • Thanks to Wanderer for pointing out that the Marauder Frigate wasn't already like this.
  • Since the Riot Starship MkIII did pretty well in the last worst-ship poll:
    • Gave them tachyon coverage matching the MkIII scout starship.
    • Added a couple additional options for its highest-level hardpoint:
      • Grav Tazer
        • Similar to the Riot IIs tazer but also applies the "halt" effect (same as the grav ripper) to everything hit, making it take longer for even paralysis-immune ships to get away.
        • Note that these share the same planet-wide stagger category as Riot II tazers, to prevent these making permanent tazer lock possible again.
      • Grav Generator
        • Basically a ship-mounted grav turret, requires research of Grav Turret Is.
    • Thanks to many players for feedback indicating that they didn't really see a reason to upgrade from Riot IIs to Riot IIIs.
  • This doesn't really impact the player at all, but some may care: Implemented another, far saner grammar for the Lobby Setup Scripts.
    • Only BeginnerGame.xml, BeginnerGame2.xml, and RandomFactions1.xml have been updated to use it, but that covers all the unique syntax necessary to re-implement the others, too. Currently the game will still parse the old grammar, but that will go away when the rest of the "official" scripts have been converted.
  • Teleport Battlestations, in honor of doing pretty well in the last worst-unit poll:
    • Base Max Health from 14k*mk => 28k*mk (bringing it from 4.8M cap-hp, which is basically the minimum for a fleet ship, to 9.6M cap-hp where about 18 other types will be lower than it).
    • Base Attack Power from 400 => 700 (bringing it from 39.2k cap-base-dps and 94k cap-max-dps, where some ships have a base dps higher than that max-dps, to the midst of the respectable-attack types).
    • Thanks to many players for feedback on these.
  • Added new toggle to Interface tab of Settings window: Disable Pause On Lost Focus.
    • Normally the game will automatically pause if it detects that the game has lost focus (it can only detect this in fullscreen mode, not windowed mode).
    • Enabling this toggle will suppress that auto-pause behavior, which may be helpful for multiplayer games and some other situations.
    • Thanks to amethyst for the suggestion.

Prerelease 5.034 Is It Really A 'Minor' Faction If You Scale It That High?

(Released May 7th, 2012)

  • Fixed a bug in the previous version where Neinzul Rocketry Corps lightning warheads were causing AIP-on-death (despite saying they don't).
    • Thanks to dragon95046 for the report.
  • Amended the "if base max health >= 1,000,000, then immune to fusion cutters" rule to exclude fleet ship types whose mkI versions don't pass that >= 1,000,000 threshold (to prevent situations where fusion cutters were getting way less useful against higher-mark AI planets, etc). The fleet ship types that still have the immunity due to health:
    • Spire Stealth Battleship
    • Spire Blade Spawner
    • Spire Maw
    • Spire Tractor Platform
    • Thanks to chemical_art and other players for inspiring this change.
  • Ships killed by a zombie-reclamator no longer spread any excess reclamation damage they have to other ships. The spreading mechanic was intended to make non-zombie-reclamators more reliable; the zombie reclamators were already plenty powerful enough :)
    • Thanks to amethyst and Minotaar for reporting.
  • Fixed a bug where the Dyson Sphere itself was alerting its planet and neighboring planets on the AI thread, but not on the main thread. It now does not alert on either (but the actual enemy-to-all gatlings and player-ally gatlings count for alert purposes, of course).
    • Thanks to zoutzakje and others for reporting.
  • There's now a galaxy-wide population cap on each of the three types (enemy-to-all, player-ally, and ai-ally) of Dyson Gatling, equal to the current effective AIP.
    • So if AIP is 80, there could be 80 enemy-to-all gatlings, 80 AI-ally gatlings, and 79 player-ally gatlings and if the Dyson was currently player-ally it would still spawn another player-ally gatling before ceasing to spawn until either the player-ally gatling count went down or the AIP went up.
    • Thanks to Wanderer (and others, more recently) for pointing out how dominating the Dyson Sphere could be.

New Variety for Existing Minor Factions

  • Human Resistance Fighters:
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" increment frequency, 1 is way less frequent than that, and 10 is way more frequent than that (it's not linear).
    • Don't use a high value unless you want to see these happening a LOT.
  • Marauders:
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" increment frequency, 1 is way less frequent than that, and 10 is way more frequent than that (it's not linear).
    • Don't use a high value unless you want to see these happening a LOT.
  • Human Colony Rebellions
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" frequency, 1 is way less frequent than that, and 10 is way more frequent than that (it's not linear).
    • Don't use a high value unless you want to see these happening a LOT.
  • Dyson Sphere:
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" spawn-check frequency (one check per 20 seconds), 1 is 1/4th of 4 (one check per 80 seconds), 8 is 2x what 4 is (one check per 10 seconds), and 10 is insane (one check per 6 seconds).
    • The galaxy-wide population caps on each of the three gatling types are modified by this 0-10 value. 4 is cap = AIP; 1 is cap = AIP / 4, 8 is cap = AIP * 2, etc (it's linear).
    • So if you want a game-dominating dyson sphere, you can still get it :)
  • Zenith Miners
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" frequency, 1 is way less frequent than that, and 10 is way more frequent than that (it's not linear).
    • Don't use a high value unless you want to see these happening a LOT.
  • Broken Golems (Hard)
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" strength, 1 is way less than that, and 10 is way more than that (it's not linear).
    • Note: the only thing impacted by the intensity value for Broken Golems (Hard) is the strength of the exogalactic strikeforces sent by the AI as a response to this faction being on. The benefit you derive from it (number or strength of golems, etc) is not affected.
    • Don't use a high value unless you want to see VERY strong exogalactic strikeforces (their frequency does not change).
  • Neinzul Preservation Wardens:
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" increment frequency, 1 is way less frequent than that, and 10 is way more frequent than that (it's not linear).
    • Don't use a high value unless you want to see these happening a LOT.
  • Neinzul Roaming Enclaves:
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" increment frequency, 1 is way less frequent than that, and 10 is way more frequent than that (it's not linear).
    • Don't use a high value unless you want to see these happening a LOT.
  • Neinzul Rocketry Corps:
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" number seeded at the beginning of the game, 1 is way fewer than that, and 10 is way more than that (it's not linear).
    • Don't use a high value unless you want to see a LOT of these (Would you like to play a game of... ?).
  • Fallen Spire
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" strength, 1 is way less than that, and 10 is way more than that (it's not linear).
    • Note: the only thing impacted by the intensity value for Fallen Spire is the strength of the exogalactic strikeforces sent by the AI as a response to this faction being on. The benefit you derive from it is not affected.
    • Don't use a high value unless you want to see VERY strong exogalactic strikeforces (their frequency does not change).
  • Spirecraft (Hard)
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" strength, 1 is way less than that, and 10 is way more than that (it's not linear).
    • Note: the only thing impacted by the intensity value for Spirecraft (Hard) is the strength of the exogalactic strikeforces sent by the AI as a response to this faction being on. The benefit you derive from it (number of asteroids or strength of spirecraft, etc) is not affected.
    • Don't use a high value unless you want to see VERY strong exogalactic strikeforces (their frequency does not change).
  • Note that the Trader, Devourer, Easy and Moderate Golems (which don't fit into this idea of "faction intensity", they're really just different things than Hard Golems), Spire Civilian Leaders, and Easy and Moderate Spirecraft are all still just on/off. This isn't because we don't have any ideas on how they might be made so, just none that were very simple to implement at this stage.

New Variety For Existing AI Plots

  • Hybrid Hives
    • Now instead of being an on/off toggle in the lobby, it can be set to a value from 0 to 10. 0 is disabled, 4 is the previous "normal" number of hive spawners seeded at the beginning of the game, 1 is way fewer than that, and 10 is way more than that (it's not linear).
    • Don't use a high value unless you want to see a LOT of these.

Lobby Setup Scripts

  • Preface: over the years we've had requests accumulate on a number of different fronts that couldn't easily be handled the way things were, like:
    • Numerous new players asking "What's a good setup for my first game?"
    • Variable-strength minor factions and AI plots (which could be handled just by the above changes, but read on)
    • Randomized minor factions and AI plots, particularly combined with variable-strength.
    • Randomized and hidden minor factions and AI plots (so you don't know what's there until you run into it in the game, with potentially hilarious results).
    • Some kind of overall "difficulty ranking" for a particular game setup.
  • So, from a small scripting language that was written for (and actually not ultimately used for) AVWW, a Lobby Setup Scripting system has been cobbled together. The actual scripting language is likely to completely change in the next version (it's really verbose, cumbersome, etc, but it does work), but the short story is it's now possible to define external scripts which populate the settings in the lobby.
    • Please note, those of you with scenario-building aspirations, that this really only sets stuff in the lobby. It cannot directly influence mapgen (placement of planets, units, etc) in any way.
    • To use a script, start a new game, and in the lobby on the Map tab pick an option from the Setup Script dropdown. It will then immediately execute the script and apply the changes to the lobby.
    • The following scripts are available in this version:
      • Beginner Game
        • A fairly simple, fairly easy scenario that may be a good next step for new players who have just completed the intermediate tutorial.
      • Beginner Game 2
        • A bit harder than the scenario generated by the Beginner Game script. May be a good next step for new players who have just completed the intermediate tutorial and are feeling confident.
      • Random Factions 1
        • This script sets up some randomized minor factions and AI plots from the base game (no expansions required).
          • Note (this goes for the rest of these scripts, too): it's not purely random, it starts with a certain number of "points" and randomly picks factions/plots to allocate them to. Friendly factions (in this case, human resistance fighters) actually increase the point total when chosen, rather than decreasing it. The point is that while there's simply no way to get any kind of overall "difficulty score" of a particular scenario, it is possible (with significant effort) to make a script which produces scenarios within a particular range of difficulty. Which, hopefully, scratches the real itch behind the "difficulty score" request.
      • Random Factions 2
        • This script sets up some randomized minor factions and AI plots from the base game and The Zenith Remnant expansion.
      • Random Factions 3
        • This script sets up some randomized minor factions and AI plots from the base game and the The Zenith Remnant and Children Of Neinzul expansions.
      • Random Factions 4
        • This script sets up some randomized minor factions and AI plots from the base game and the The Zenith Remnant, Children Of Neinzul, and Light Of The Spire expansions.
      • Unknown Factions 1
        • This script sets up some randomized minor factions and AI plots from the base game (no expansions required), and then hides them so that you cannot see what has been selected either in the lobby or in the game. If you then pick another script (or none) the hidden status will be reset.
      • Unknown Factions 2
        • This script sets up some randomized minor factions and AI plots from the base game and The Zenith Remnant expansion. It then hides them so that you cannot see what has been selected either in the lobby or in the game. If you then pick another script (or none) the hidden status will be reset.
      • Unknown Factions 3
        • This script sets up some randomized minor factions and AI plots from the base game and The Zenith Remnant and Children Of Neinzul expansions. It then hides them so that you cannot see what has been selected either in the lobby or in the game. If you then pick another script (or none) the hidden status will be reset.
      • Unknown Factions 4
        • This script sets up some randomized minor factions and AI plots from the base game and The Zenith Remnant, Children Of Neinzul, and Light Of The Spire expansions. It then hides them so that you cannot see what has been selected either in the lobby or in the game. If you then pick another script (or none) the hidden status will be reset.
  • Thanks to HitmanN, Chris Fifty-Two, KDR_11k, Vinraith, Sunshine (and probably others) for suggesting randomized minor factions and AI plots.
  • Thanks to zebramatt and others for advocating for scenario difficulty-scores, even though we can't quite do that.
  • Thanks to topper and others for requesting some kind of "suggested settings" or "presets" for the lobby, particularly for new players.

Major Improvements Relating To Loss Of Window Focus In Fullscreen Mode

  • Some recent breakthroughs with the unity engine from A Valley Without Wind have now been backported to AI War. Specifically:
    • The game now knows if it has focus or not if you're running in fullscreen mode (not windowed, sorry).
    • If the game does not have focus, it now stops doing any edge scrolling (so you don't return to find yourself out in the middle of nowhere.
    • If the game does not have focus, it issues a pause command just one time -- that way, in solo or multiplayer, accidental clicks onto a secondary monitor out of fullscreen now pause the game without spamming pauses at other players.
    • IF the game does not have focus OR if the Steam Overlay is brought up, it now does a better job of resetting all the input. This should finally resolve that stupid "stuck keys" thing with alt-tabbing and shift-tabbing.

Prerelease 5.033 And Other Times There Are A Few Too Many Ponies

(Released April 17th, 2012)

  • Metal/Crystal Harvester Upgrades:
    • MkII production from 31 => 30.
    • MkIII production from 73 => 55.
    • Results/Rationale:
      • Assuming 12 resource spots on the homeworld and 4 resource spots per captured planet (the latter is a well-attested average, to the author's surprise).
      • MkII upgrades are better than EconII if you have 1, 2, 3, or greater than 12 planets, but are worse from 4 to 11.
      • MkIII upgrades are better than EconIII (plus EconII since it's unlocked on the way) if you have 1-4 or greater than 13 planets, but are worse from 5 to 12.
      • Harvesters still have the advantage of not occupying the command station "slot" but also still have the disadvantage of being at the mercy of mapgen: sometimes you don't have the luxury of picking a planet with 4+ resource spots instead of a planet with 1-2.
      • All in all, the question of "do I upgrade harvesters or econ stations?" should now be more situational and map-based.
    • Thanks to many players for feedback on the recent harvester buffs, including strident efficiency graphs and amusing anecdotes of overrunning the galaxy with unending waves of constant production.
  • Fixed a null exception that happened when gifting a spirecraft mining enclosure to another player.
    • Thanks to topper for the report and save.
  • Neinzul Enclave Starships, in honor of winning the fifth "Worst Unit" poll.
    • Base Armor Rating from 1000 flat => 1000*mk.
    • Base Health from 500K*mk => 3M*mk.
      • This gives an individual one 80% the health of an individual corresponding fleet-boosting starship; not using cap comparisons here since these are not military ships (i.e. ships with an attack), but for reference those fleet-boosting starships have 2x as much cap.
    • Now have radar dampening of 8000/7500/7000/6500.
      • Between this, the armor, and the health it should be a lot more reasonable to keep these alive unless you get overwhelmed, in which case these should die (cloaking was experimented with, but was way too exploitable; that much cheese requires cloaker starships).
    • Knowledge Costs from 0/3000/5000/10000 => 0/2000/2000/14000.
      • This is because the first two upgrades are purely for in-the-field construction (which is worth something) and the last is a game-changing ability to have mkIV production capacity without an advanced factory.
    • The rate at which they construct ships used to be the same as a space dock, and is now 4*mk as fast as a space dock (so 16x for a mkIV).
      • This is because previously using these efficiently basically required engineer support (specifically, engineer mkIII support). Engies still help, but it's not as critical.
    • Thanks to many players for providing feedback on these in recent months, and for voting in the poll.
  • Armored Warheads, in honor of placing second in the fifth "Worst Unit" poll:
    • Base Attack Power from 300k/1.5M/2.4M => 1M*mk.
    • Explosion Size from 1500/1250/750 => 1500*mk.
    • Now do 10k*mk armor damage, enough to strip all the armor off most units that aren't some kind of boss fight.
    • In general you still aren't going to want to use these a lot, it's still a "rot your teeth" sort of unit where heavy use is rarely a good sign for how well your game is going. But these should be more useful than they were, for sure.
    • Thanks to many players for providing feedback on these in recent months, and for voting in the poll.
  • Lightning Warheads:
    • Base Attack Power from 300k/1.5M/2.4M => 800k*mk.
      • Just keeping up with the armored warhead changes; only a significant change to the mkI, really. So the armored ones pack about 25% more punch, for whatever that's worth.
    • Explosion size changed to match the new armored warheads: 1500/1250/750 => 1500*mk.
  • Metal/Crystal manufactory input and output scale multiplied by 10 (so consumes 200 of a resource to produce 140, instead of 20 for 14), in honor of placing 3rd in the fifth "Worst Unit" poll.
    • Thanks to many players for suggesting an increase in scale for these, and for voting in the poll.

Prerelease 5.032 Then The Pendulum Swung Back

(Released March 30th, 2012)

  • Fixed an omission in the previous release; nanoswarm attack power was supposed to be doubled and their reclamation double-efficiency flag removed. The latter happened, but not the former. Now both are in.
    • Thanks to Dazio for the report.
  • Fixed a really, really longstanding bug where the AI got 1 bonus reinforcement at diff 8, 1 bonus reinforcement at diff 9, and 2 bonus reinforcements at diff 10, but no bonus reinforcements at any of the non-integer difficulties between those. Now it's 2 for 10 and 1 for >= 8
  • Fixed a longstanding bug (since ship cap scales were added, roughly) where the ship-cap-scale multiplier was being applied twice to reinforcement calculations (so high got the normal amount, normal got half as much as it should have, low got 1/4 as much as it should have, etc).
    • The effect isn't as severe as it probably sounds, because most of the calculations ended in "if less than 1, set to 1" and other bugs (see below) were letting the AI get a lot more mileage than was mathematically sanitary out of that 1.
  • Corrected some longstanding issues where reinforcements were frequently getting stuff like Spire Blade Spawners in roughly the same proportion as Fighters; the ship cap multipliers were being used, but if a particular individual group of spawns in a reinforcement (there could be over 10 in a single reinforcement-of-planet event, and multiple such events can happen on a single planet per overall reinforcement) only had 1 ship to pick it could freely pick either a fighter or a spire blade spawner (or whatever it had unlocked) and the fact that it had just gotten something like 30x as strong as what "1" normally means was simply ignored. If it had 20 ships to pick and picked a blade spawner that would be the end of the pick, though, so it wasn't totally ignorant of that dynamic.
    • Now it does a bit of arithmetic "carrying" so that if one individual spawn really picks something low-cap like that (and it still can do that, otherwise stuff like blade spawners just won't happen in most reinforcements) then it remembers that for further spawns in that reinforcement event, which can make certain reinforcements a little lopsided but in general is at least a balanceable situation now.
    • Thanks to TechSY730 and many other players reporting odd and/or brutal populations of these kinds of units from reinforcements over the past year and some months.
  • Now that the AI is no longer able to get a ton of low-cap ships where it should only be getting a few of them, the AI-specifc per-guard-post caps on those low-cap types have been removed (and some per-planet ones, but the ones on stuff like engineers): those had just been bandaids to prevent massive swarming by those ship types because we didn't know what was going on there or how to fix it.
    • This is particularly important because the bandaid was pretty brutal about making sure it was enforced, so the AI would wind up sending a reinforcement and part/most of it would be ditched without spawning because it would violate the caps, etc.
  • Just under "Enable Advanced Logging" on the Advanced tab of the Settings window, added a "Enable Reinforcement Logging" toggle.
    • Similar to Enable Advanced Logging, this enables logging of AI reinforcements to the ReinforcementsLog_MainThread.txt and ReinforcementsLog_AIThread.txt files in your RuntimeData directory.
    • This is off by default because:
      • This is really only for when you want to see if there is some problem with the reinforcement logic (short of logging, it is very hard for anyone to tell) and want to show evidence to the developers
      • Reading one of these logs in midgame will give "spoilers" about what the AI has, etc. It's not considered a cheat, however, because all the actually-important info it gives you would be available if you had turned off fog-of-war in the lobby before the game.
      • Lots of disk I/O during the game causes instability on some systems.
    • All that said, if you're curious about the numbers, and especially if you think something is wrong (there certainly was plenty wrong for a while now, though it worked ok in most scenarios), have a look and let us know :)
  • Fixed a bug in multiplayer where hacking an ARS and having the first player pick an unlock on that planet would cause the other human players to be given a random unlock about a game-second later.
    • Thanks to Niccus for the report and save.
  • Added new button to Galaxy Layout context menu: "Reset My Layout To Official"
    • Prompts you to confirm the action, and if you confirm it sets the positions of all planets in your alternate layout to the official positions.
    • Thanks to Nodor (and others, previously) for pointing out the need for this in case the planet positions get messed up (as can sometimes happen on load and/or changing resolutions).
  • Made the "signal markers" in Fallen Spire invincible in the same sense as the Dyson Sphere (well, without a certain caveat which applies to the Dyson).
    • Thanks to Tharrick for reporting that it was actually possible for one of these to get destroyed if the AI did a tachyon burst during hacking to drop the marker's perma-cloak. "Pay no attention to the man behind the curtain" apparently wasn't sinking in.
  • Changed the targeting logic for AOE units (that don't already use the alternate logic for engine damage, paralysis, reclamation, or insta-kill) to prefer non-AOE-immune targets. This is necessary because of the recent change to let flaks and some other aoe units be able to damage an aoe-immune ship they fire directly at, but since an aoe-immune ship is likely to be in a pile of other aoe-immune ships most of the dps is wasted when there are non-aoe-immune targets available.
    • Note that if the flaks are already locked on to something aoe-immune (like a missile frigate) and something non-aoe-immune (like a fighter) comes into range, the flaks will probably take a few seconds to retarget since the game only does the target logic every so often.
    • Thanks to Wanderer for reporting the highly-sub-optimal behavior.
  • Mobile Repair Stations, in belated honor of doing well in the last "worst unit" poll
    • Maximum simultaneous repairs from 100 => 20.
    • Repair rate reduced.
    • Time it must remain stationary before starting repairs from 60 seconds => 5.
    • Now has cloaking.
      • This doesn't break when repairing, but beware AI tachyons.
    • Thanks to many players for feedback on how this unit just didn't seem worth the trouble; hopefully now it will be worth 4000 K but also not be so "insta-heal entire fleet" overpowered as it was before the last rework (but if you have all 9 in range of a fleet not much will stay damaged unless it is under ongoing fire). If there are still problems please let us know :)
  • Fixed a bug where if the AI had a pile of over 2000 zombie threat ships (and over 4000 total threat) it was possible for it to try to redeploy those zombies to carriers, and the carrier would be created with the appropriate contents, but the zombies would not actually be scrapped. Causing the AI to redeploy them again, creating still more carriers, and failing to scrap the zombies again. It was just carriers all the way down, leading rapidly to tens and hundreds of thousands of threat. Fixed so that the scrapping works, and thus the duplicate redeployments no longer happen.
    • Thanks to mlhibou for providing a report and save of this apocalyptic situation, and to Niccus for a similar report.
  • Fixed a regrettably longstanding bug where it was possible for modules (notably hybrid modules) to become "stranded" without a parent ship and to basically act as somewhat buggy (and, recently, the non-forcefield ones are now invinicible) turrets.
    • Thanks to Draco18s, SpaceBrotha, and Caseycc for providing reports and saves.
  • The Tech buttons on the ARS tab of a science ship on an ARS planet are now sorted so that the leftmost one is the one that would be unlocked by capturing without hacking.
    • This is more info than it really should give, but getting the info is a simple savescum operation so we may as well shortcircuit that.
  • Added new galaxy display mode "Detected Immobile Minor Factions".
    • This shows "DS" next to the planet with the Dyson Sphere, "RC" for a Neinzul Rocketry Corps Silo, and "HC" for a Rebelling Human Colony.
  • Mostly as a visual improvement (via more variety of shot speed) and somewhat to make some weapons a little more effective:
    • Laser shot speed tripled (wait, why does a laser shot have a speed?)
    • Minor electric shot speed doubled.
    • Shell shot speed increased to 1.5x what it was.
    • Ion shot speed doubled.
    • Combat style now applies to all shot speeds, not only artificially-increased ones.
    • Note: shots will always move at least 40 faster than their target.
    • Feedback is very welcome on whether these changes make combat more interesting, or are a detriment; just an experiment, really.
  • Missile shots (from the missile frigate, MLRS fleet ship, MLRS turret, Missile Turret, Anti-Armor Ship, etc) now can acquire a new target from their firing ship's target list if their current target is destroyed or otherwise no longer available (note that all shots insta-hit a ship trying to leave the planet, but missiles now won't "overkill" them in that case).
    • Bear in mind that the parent ship's target list does not necessarily include all viable targets, and is often limited to 50 nearby targets, but this still significantly decreases DPS wastage for missiles (which generally move fairly slowly).
  • Fixed a bug where a superterminal could be "paused" by scrapping your command station, saving, and reloading.
    • Thanks to Niccus for the report and save.

Prerelease 5.031 Harvest Of The Unloved

(Released March 21st, 2012)

  • The hacking-response wild-roll for "short range warp jump" can now generate a much wider range of spawn points.
    • Thanks to Toranth for reporting that it was always picking points in two relatively small areas.
  • Now when a unit dies while under the influence of a parasite infestation ("reclamation damage"), those parasites will behave far more efficiently:
    • If there are enough of them on the ship to take it over (that is, reclamation damage is >= half the ship's max health) then enough will remain to perform the takeover.
    • Any remaining parasites (which means all of them, if there aren't enough to take the dying ship over) will spread to nearby (within 2000 range units) valid targets that have not been fully infested.
    • The end result is that while the exact same amount of reclamation damage is being done, the efficiency of it actually doing something in condensed fighting is way more satisfactory, particularly towards the end as all the partially-reclaimed ships die off and the parasites all pile up on the survivors.
      • In fact, it's possible that reclamators are now back to being OP, but not nearly as much as in the days when a single leech-starship salvo could "tag" 40 ships for guarunteed reclamation. Your feedback on the new balance will be appreciated.
    • Thanks to many players over the past year or so for reminding us that reclamators are more fun when it's easier to get some kind of reliable reclamation-rate out of them (even if said rate is not OP).
  • Youngling Nanoswarm:
    • Base attack power from 400*mk => 800*mk. Still not much at all, but it allows:
    • Inherent "damage does 2x as much reclamation damage" rule removed. So it does the same amount of RD as before, just without the fiddly rule (which is now completely gone, the nanoswarm was the only thing using it).
  • Mines:
    • Base Health is now 16 times the damage done, to allow 16 detonations before "wearing out" instead of the 2/3 that were probably common before. There are 16 mines in the graphic: the logic is unassailable, no?
    • Standard Mines:
      • Base Metal+Crystal cost from 360+1200 => 20+40, which puts them at about 2x the cap m+c cost of zenith autobombs (which are in many ways simply mobile mines).
        • Note that the build time for all 3 mine types is still 90 seconds.
    • Area Mines:
      • Base Metal+Crystal cost from 1080+3600 => 40+80.
      • Now hit a maximum of 10 targets with their aoe.
      • Base Damage per hit from 7500 => 52500 (half as much damage as a normal single-target mine).
    • EMP Mines:
      • Base Metal+Crystal cost from 720+2400 => 60+120.
      • Fixed an error in the tooltip: it said the paralysis was 60 seconds long, but it's really only 10 seconds.
    • Thanks to TechSY730 and several other players for recent feedback on mines, leading to these changes.
  • Harvester Exo-Shields, in honor of winning the 4th "Worst Unit" poll (and the first one for which it was eligible) :
    • Now has cloaking.
    • Now cloaks the protected harvester.
    • No longer halves production of protected harvester.
    • Energy Use from 1000 => 5000. At maximum non-ZPG energy efficiency (running everything off mkIIs) that's a bit under 4 (m+c)/s to run, or 1/5th of a mkI harvester.
    • The result is that:
      • They have a much lower operational cost which no longer scales up with higher harvester marks or with your energy efficiency.
      • More importantly, they allow a new tactical choice: do you want attacking enemies to potentially be distracted some/all of the harvesters in the system, or do you want to make sure they stay focused on the command station or some other objective? Some defensive setups get much higher efficiency when the enemy stays focused in a particular radial or linear area, and this can help with that. On the other hand, sometimes the AI's tendency to split up after harvesters is a big help.
    • Thanks to many players for their feedback on why this unit was very rarely an interesting choice.
  • Metal/Crystal Harvester II/III, in honor of getting 2nd place (by one vote) in the first "Worst Unit" poll in which they were eligible:
    • A bit of background:
      • Unlocking Econ Station II costs 4000 knowledge and gives a total of 576 m+c above the "standard" command station (econ I) if you build all 6, and that bonus is still relevant if you unlock Econ III. That's about 0.144 (m+c)/s per knowledge point.
      • Unlocking Econ Station III costs 5000 knowledge and gives a total of 1536 m+c above the "standard" command station. Benefit/K Ratio is about 0.3072.
      • Previously, unlocking mark II of either metal or crystal harvester cost 3250 knowledge and, assuming a mid-game situation of 13 total planets (i.e. all 6 of econ II and econ III could be placed) with an average of 2 spots of that resource per planet (ymmv, but it's probably not far off) gave a total of 208 resources above mkI harvesters. Benefit/K Ratio was about 0.064.
      • Previously, unlocking mark III of either harvester cost 4000 knowledge (but really 7250 since you don't get the benefits of mkII and mkIII at the same time like you do with econ stations) and, across 26 ressource spots, gave a total of 416 resources above mkI harvesters. Benefit/K Ratio (assuming 7250 "real" K cost) was about 0.0574.
    • So, to do something about this pretty vast disparity:
      • Harvester II:
        • Knowledge cost from 3250 => 2000.
        • Production from 28 => 31 (so +8 => +11).
      • Harvester III:
        • Knowledge cost from 4000 => 2500 (so 4500 total).
        • Production from 36 => 73 (so +16 => +53).
          • Yes, that's a lot, but that's what parity with econ III looks like. And nerfing econ III would have been an outrage considering how much waiting-for-resources happens on challenging games _with_ econ IIIs.
    • In short, harvester upgrades should now be competitive with econ station upgrades. Getting mkIII in both harvesters also now costs the same amount of knowledge as getting mkIII econ stations, but has a somewhat lower "barrier to entry" in that the individual knowledge costs are smaller.
      • Further balance feedback is, of course, welcome. This change will have a fairly dramatic impact in favor of harvesters on multi-HW games, for one, but it's primarily important that choices be interesting in single-HW games and adjustments can be made for the less common scenarios (as long as multi-HW doesn't become excruciating, of course). Of more concern is the impact on multiplayer games if all players gift all their harvesters to one player who upgrades to mkIII harvesters (and gives resources back) and other such tomfoolery, but that can also be adjusted for as the need arises.
    • Thanks to Cyborg and many other players for pointing out the fact that harvester upgrades were basically just universally inferior (with some small exception) to econ station upgrades.
  • Warp Jammer Command Stations, in honor of tying for third in the first "Worst Unit" poll it was eligible for:
    • Now prevent their planets from putting adjacent AI planets on alert.
      • Those adjacent planets can still be put on alert any other way (for example, but another bordering human world without a jammer or by a significant human presence on the planet or a different adjacent planet).
      • But this still allows a new strategic choice in shaping the AI's response to your presence.
      • Notably, this could be used on a planet adjacent to a particularly hard-to-crack AI planet to allow you to get supply on the target planet and thus deploy turrets and such without putting the target planet on permanent alert (which is normally a distinct no-no for core worlds and homeworlds). But beware, if the jammer is destroyed, its effects go away. Also, jammers are far from free.
    • Also fixed a longstanding bug where these counted (for display purposes only, apparently) as an AI reinforcement warp gate.
    • Thanks to chemical_art for broaching the subject of how to make these more interesting, and to many other players for confirming the idea that the jammer needed something more.

Prerelease 5.030 Refined Hacking

(Released March 14th, 2012)

  • Fixed a bug in the wave-mouseover-to-show-ship-info feature in the last version that would display a blank info window and throw some (thankfully harmless) errors if the ship-type-info window had last been used to display an unlocked ship type with a "(x out of y in service)" addendum (like from mouseovering the buy queue items on a space dock).
    • Many thanks to zoutzakje, Cyborg, and Ranakastrasz for the reports and saves to track this one down, it was pretty elusive.
  • The "AI is responding to your hacking on (planet name)" messages now specify whether it's knowledge-hacking or ship-design hacking, to avoid confusion. If both are actually happening on one planet, it will display both messages.
    • Thanks to Cyborg for inspiring this change.
  • Previously if a planet had multiple AI Advanced Research Stations on it then doing a ship-design-hack on the planet and then capturing the planet would only let you unlock 1 bonus type (capturing it without sd-hacking led to the normal multiple types being unlocked) out of the normal set of 3. Fixed it to let you unlock n bonus types out of a set of n*3, where n is the number of AI Advanced Research Stations on the planet. In general multi-hacking like this is more advantageous, but it's very much an edge case due to the small planet counts necessary to get more than 1 ARS on a planet.
    • This change applies retroactively to uncaptured ARS's from old saves, but could not be applied to already-captured ARS's, sorry about the inconvenience.
    • Thanks to Nic for the report.
  • Now the tech menu's ARS tab (which is used to view and select what bonus type you want to unlock after hacking and capturing an ARS) displays even if no hacking has been done, so you can make a decision about whether you want to hack or not without savescumming (not that anyone would do that).
    • The tab still won't show if there were never AI-controlled ARS's on the planet, since then the planet has no bonus types to show.
    • Thanks to Wanderer for inspiring this change.
  • Superterminal-hacking response:
    • Surges no longer automatically set the recharge time for the next pulse to 1 second (15 seconds is the normal time), as chain-surges were entertaining to the developer but not so much to the players.
      • Thanks to Wanderer for inspiring this change.
    • Fixed a bug where multiple surges could happen on the same spawn; two surges on the same spawn on diff 7 would multiply spawn strength by 12.25. Ow. This wasn't intended, but a flag wasn't being set right. Now surge-rolls after the first on a spawn are treated like a "multiply by 1.5" roll, similar to how the short-range-warp-jump roll is treated as a x1.5 roll if it's already happened for that spawn.
    • When spawn strength is over the cap (500), the way it "trades" strength for higher-mark-level-spawns and shorter-recharge-to-next-pulse has been significantly changed:
      • Instead of trading for tech until <= 200 and then trading for recharge until <= 500, it randomly picks one to trade for if over 500; if it's still over 500 it randomly picks again, etc. Max tech level is 5, of course, and minimum recharge is 1 second.
      • When trading for tech, it now multiplies strength by current_mark/next_mark instead of deducting a flat 150, to better represent the linearly-increasing power that typically happens with higher marks.
        • Thanks to Hearteater for inspiring this change.
      • When trading for lower recharge time, it now multiplies strength by new_time/old_time instead of deducting a flat 33, to better represent the increasing impact of multiple cooldown reductions.
  • Changed the Ship-Design-Hacker's description to be a bit clearer.
    • Thanks to Hearteater and Wanderer for suggestions on how to reword it.
  • Previously hacking response wild-rolls that increased spawn strength did so by multiplying the current strength value by some x%. The exponential growth this caused with higher numbers of rolls was intentional but turned out to get wildly out of control, doing things like spawning 4000 raid starships (heh) or arithmetic overflow, etc. So it's been changed to be an additive boost instead, adding x% of the pre-rolls strength to the current strength value.
    • To compensate, the now-additive bonuses are a bit higher in magnitude than they used to be.
    • The one exception to this is the superterminal's "surge" roll, which is still mutiplicative, but can only happen once per spawn. Still, it can put on some real hurt if it happens after a bunch of additive boosts (but nothing that will challenge the domain of the datatype storing the strength value).
    • (posthumous) Thanks to Toranth for warning us of the 4000+ raid starship spawn.
  • Fixed a bug where the "spawn raid starships" wild-roll was giving the AI the kind of raid starship reserved for human use. Now gives the AI-variant. Already-created ones will probably remain as they are, but it shouldn't be a big deal.
    • Thanks to Toranth for the report.
  • Previously hacking responses continued after the hacking was "done" (all knowledge gathered by a knowledge hacker, or the planet successfully sd-hacked by a ship-design hacker). This was intentional, to motivate getting the hacker out of there or in a transport or whatever, but it's a reasonable request to have the responses stop without player intervention, so that's what will happen now.
    • Thanks to TechSY730 for the suggestion.
  • The "spawn raid starships" wild-roll no longer creates "zombie" raid starships that blindly agress upon whatever humans are in vision, but rather non-zombies that are coordinated like an exo and go charging after some juicy human target.
    • Thanks to Wanderer for the suggestion; please direct your rotten fruit in his direction (assuming it doesn't have a bonus vs. Ultra-Light hulls, you'll need those).
  • The grav well display circles now use much more subtle colors and rotate 1/8th as fast as they used to.
    • Thanks to clone, doctorfrog, Wanderer and others for suggestions on how to make these less Yeargh!-inducing.
  • Previously there was no way to know how ticked off the AI was at previous hacking attempts and thus what to expect in future ones. This was somewhat by design, as this isn't another AIP or whatever, but if the player is to make strategic decisions about hacking some kind of feedback (other than angry-ships-to-the-face) is important. So now once there's been any hacking antagonism actually generated (note: ship-design hacking doesn't actually increase that value until the hack is complete, since you haven't gained anything until then) an alert will display with a general descriptor ("Very Low", "Low", "Moderate", etc) of where things are.
    • The numeric ranges represented are pretty broad and somewhat guesses, so let us know if the AI hacking response just roflstomped the galaxy at "Low", etc.
    • Thanks to Hearteater and others for inspiring this change.
  • Previously the bonus-type selection buttons on the ARS tab of the tech menu for ship-design-hacked planets would still show the "KNWL" indicator over the top of buttons for which you didn't have enough knowledge to do the unlock if you were unlocking mkII of that type normally. Except you aren't spending knowledge by clicking them, so it shouldn't show the KNWL thing, and now it no longer does.
    • Thanks to HTL2001 for the report.
  • Now picking a bonus type from the ARS tab of the tech menu after a ship-design-hack is a per-player decision in multiplayer (and in singleplayer, but the difference isn't noticeable unless other players join).
    • If you think you might have players joining later, don't forget which planets had the ARS unlocks :)
    • Note that normal (no hacking) capture of an ARS still gives the same bonus type to all players, which gives ship-design hacking an additional advantage in multiplayer (though remember there's still only 3 types to pick from per ARS, so it's not all that much of an advantage).
    • Thanks to Cyborg for inspiring this change.
  • Dyson Antagonizer/Converter alert messages now contain the planet name if you've scouted the planet since that unit came into existence, not just when you've actively got a scout on the planet.
    • Thanks to Shrugging Khan for the suggestion.
  • Fixed a bug where helper players were getting the overflow from other players resources income-past-cap.
    • The resources were basically being lost since helpers cannot gift resources, which is intentional as otherwise this overflow case would represent an in-game bonus from having slots devoted to "helper", which would invalidate the assumption that the game can be balanced as if they weren't there and thus the AI's strength doesn't have to go up due to the presence of helpers, etc.
    • Along with this: apparently in the past overflow was going to ALL human player slots, even those that had never had any players in them, causing the resources to be split more ways than necessary in MP games with fewer than 8 human players. Fixed now.
    • Thanks to Mercatio for the report.
  • Reference tab of stats window:
    • The label on the "Display Comparisons For Ship" dropdown has been changed to "Target Ship".
    • The labels on the columns have been changed from "Them > Me" to "Opponent Attacking" (note: the header of the first column on the table is "Opponent") and from "Me > Them" to "Target Attacking". Also, "Result?" has been changed to "Opponent Wins?" and the Win/Loss text switched.
    • The Opponent-Attacking columns have been swapped with the Target-Attacking columns so that the Opponent-Attacking ones are first.
    • The overall idea behind the above changes is that the reference comparison is most often used to see "what do I have that can efficiently kill a bunch of the target type?", and not often used to see "what can the target type kill efficiently?".
    • Thanks to Ragnorak for reminding us about this.
  • The mouse wheel will no longer do affect zooming of the main game window while the stats window is visible (previously it was a real pain when trying to mousewheel-scroll through the various tables and dropdowns, etc).
    • Thanks to many players for repeatedly reminding us about this.
  • Fortresses (mkI, II, and III; human and AI) now have a radar dampening range of 30000. Since most ships have ranges lower than that it doesn't affect them, but this prevents sniping them (notably with zenith-bombards and sentinel frigates) from way out of range.
    • Thanks to chemical_art for the suggestion.
  • Fixed a bug in the reference export where flak guardians were showing as firing only one shot per salvo.
    • Thanks to Dazio for the report.
  • Spirecraft-Medium and Broken-Golems-Medium no longer have a score penalty.
    • Thanks to many players over the months pointing out that medium's counterbalance is at least as effective as hard's.
  • Fixed a bug where the hacking data (how much you'd done, and thus how annoyed the AI was) was not getting reset between games (the logic was there, but the wrong function was getting called).
    • Thanks to Toranth for the report leading to the discovery of this.
  • Added a sanity check preventing QueueAnotherSpawnAfterThisOne wild-rolls from causing an theoretically infinite loop on spawns with a very high number of rolls. This probably wasn't happening, but it was probably happening enough to bog things down if you hacked all 5 Advanced Research Stations or whatever.
    • Thanks to Toranth for reporting a hang during hacking, which was probably due to this (and the multiplicative spawn strength stuff).
  • Knowledge-Hacking / Ship-Design-Hacking responses now honor the last "mutate" roll instead of the first, and can now roll to switch back to a normal-ship spawn. Previously as roll count got high basically all the spawns would be mutated (raid or zombie guardian, currently) and this wasn't as fun as genuine variety.
    • Thanks to _K_ for inspiring this change.

Prerelease 5.029

(Released March 5th, 2012)

  • Fixed a critical data-loss bug in 5.028 where mkII/mkIII unlocks of bonus ship types would be lost upon loading the game (i.e. don't save in 5.028!)
    • Many thanks to Physical Original for the report and save.

Prerelease 5.028 Hacker Revolution

(Released March 5th, 2012)

  • Added new toggle to CTRLS window: Brave Scout Starships.
    • If this toggle is checked, your Scout Starships will suppress their normal self-preservation instincts. Specifically:
      • They will not evade (run to a far-off spot) upon exiting a wormhole under any circumstances.
      • They will not avoid being included in a selection with military ships.
    • This will tend to reduce the effectiveness of their automatic behavior for the purpose of scouting, but may make them much more useful for providing tachyon and counter-sniper coverage for a fleet.
    • Note: this applies to the scout starships of the player who's brave-scout-starships toggle is checked, regardless of who is trying to control them in a multiplayer game with Allow Team Control on. Allied Scout Starships will still be wimps unless their owners check this toggle too.
    • Thanks to many players for requesting a way of making their scout starships not imitate Sir Robin.
  • Scout Starship:
    • Base Health from 120k/480k/960k/1.2M => 300k*mk.
    • Base Armor Rating from 1500 flat => 1500*mk.
    • Tachyon Range from 750/950/1150/1550 => 2000*mk.
    • Ship Cap from 5/4/3/2 => 5/5/5/2.
    • Energy Use from 2000/4000/6000/6000 => 2000/2000/2000/5000.
    • Base Move Speed from 224/464/704/704 => 240/480/720/720.
    • Now can cloak-boost up to 20*mk allied cloaked ships (range: 4k/5k/6k), except the MkIV which isn't being given cloak-boosting due to potential issues with a tachyon-immune ship having a lot of cloak-boosting.
    • The MkIV Scout Starship:
      • Now provides counter-missile coverage.
      • Will now not use the evade-after-exiting-wormhole logic at all, since it is permacloaked (the non-starship MkIV Scout has the same attribute already).
    • Thanks to many players for feedback leading to these changes.
  • Fixed a longstanding bug (ever since starships were allowed to be loaded into a transport) where putting a ship with modules into a transport, saving the game, and loading the game would cause the modules to be removed from the game because the game thought they were no longer accessible (the "has a parent ship" link wasn't being checked).
    • Thanks to ArcDM for the report and Solarity for a more recent report and save.
  • Fixed some longstanding (since introduction of group move trying to handle immune-to-speed-boosting units) bugs with group move:
    • Previously, for example, a speed-boostable 140-speed unit group-moving with a non-speed-boostable 152-speed unit would result in the boostable ship going 152, and the non-boostable ship going 140 (_below_ its normal speed!). This was because the non-boostable one was taking the minimum speed of it's boostable friends, and then setting its speed limit as if those friends were not actually boostable.
      • This bug has been captured, stuffed, and placed in the museum. It couldn't get away fast enough.
    • Thanks to HellishFiend and Spikey00 (among others) for reporting.
  • Fixed a few longstanding bugs where ships were able to fire on targets significantly out of their range because in a few places the range checking was early-out'ing with max(dx,dy). This would have been fine if the target's current-forcefield-radius (and possibly other factors, none confirmed) were applied before the range check instead of after, but that wasn't the case and so the early-out threshold was wrong. Well, it's right now.
    • Thanks to Draco18s for the (initial) report and save.
  • Knowledge Raiding:
    • Now scales more granularly with difficulty (for example,previously 9.3, 9.6, and 9.8 all had the same intensity of response as 9; no longer). This somewhat increases the difficulty of k-raids on non-integer difficulties.
    • Now considers the ship cap of ships being spawned when deciding how many to spawn, so a laser gatling doesn't "cost" as much as a fighter, but a Maw "costs" quite a lot more. This makes the difficulty of k-raids not nearly as variable based on what bonus ship types the AI has, or the unit-cap-scale being used.
    • Now only the AI controlling the planet spawns response ships, but spawns twice as many, rather than both AIs spawning ships separately. This makes the composition different if the AIs have different bonus types.
    • Now the spawns happen every 10 seconds instead of (11 - Difficulty) seconds, and the strength is multiplied by 2.5 to roughly normalize it to what diff 7 was doing. The base strength of the spawn is still linearly proportional to difficulty, but this second difficulty-based factor which made it heavily higher-than-linear is no longer there. That really steep ramp-up at the end was good before, but would be excessive with the other changes below.
    • Now, the more knowledge you raid for, the more intense the response. Up to 1 planet's worth of knowledge there is no change, after a full 2 planet's worth of knowledge the response is 1.5x as intense (having increased linearly during the raids after the first planet's worth), at 3 planet's two times as intense, at 4 2.5x, and so on.
      • In multiplayer games this ramping-up is adjusted, e.g. if 3 players have raided 9000 total knowledge (3000 each), the ramp-up is the same as in a single-player game where that player has raided 3000 knowledge. Multi-homeworld players only count as 1 for this purpose.
      • Now each spawn makes a number of "wild rolls" which apply various effects to what happens.
        • These range from "nothing" to "make it spawn around the planet edge" to "multiply it by 1.5" to "make it all raid starships" to "make it spawn on a neighboring planet", etc.
        • At first there is only 1 roll per spawn, but this goes up by 1 for every 1500 knowledge raided.
    • If you have Advanced Logging enabled, each spawn will generate an entry in the "CounterSaboteurSpawns.txt" log file; it may not make sense to players but is very helpful to us if you submit it with your feedback.
    • For the detailed discussion see http://www.arcengames.com/forums/index.php/topic,9906.0.html , but in brief the rationale is:
      • K-raiding's main purpose is to let players dig themselves out of a hole by gaining power without increasing AIP.
      • K-raiding also needs to not be a way of circumventing normal AIP-gain on a wide scale. To some extent it's good; avoiding 200 AIP via it is a bit much.
        • If a player gets in a hole multiple times in a row, it's ok if the k-raiding gets harder and eventually either they die to it (sparing them a longer game) or they have to bite more AIP (making progress, probably towards sparing them a longer game).
      • If possible, K-raiding also needs to not be boring. Partly that means making it so that "playing optimally" doesn't involve 10+ k-raids in a game, and partly that means making the actual AI response to the raids more interesting.
      • In general, the balance of all this is tentative. It looks right in our testing, but it may be too easy or (perhaps more likely) too hard. Please give us feedback and we will continue to refine towards better balance and more fun :)
    • Thanks to Hearteater, Wanderer , techsy730, chemical_art, and others for feedback on how k-raiding was (still) exploitable and boring, and on proposals to improve it.
  • Science Lab III:
    • Has been renamed to "Knowledge Hacker"
    • Is now mobile, cloaked, and significantly more durable.
    • Now has a 15-second setup-after-moving time (similar to the MRS's 60-second setup time before it can repair) during which it cannot gather knowledge.
    • Since you can now build them off-planet where they're not triggering spawns, these changes significantly reduce the amount of player-hassle and wall-clock-time spent on a single knowledge raid; the raids themselves (beyond the first raid) are far more dangerous so it should balance out difficulty-wise, but be less annoying.
  • Superterminal Hacking:
    • Now the superterminal never seeds on an AI homeworld or core world (can still seed next to a core world which is mean, but not nearly so mean as having to permanently alert a homeworld, or capture one, in order to use the superterminal).
    • Also, the superterminal's response is now based only on the reduction achieved through the superterminal, not total AIP-reduction, so it's no longer very important to do the ST before getting reduction from other sources.
    • Now the antagonism generated by knowledge raiding feeds into the strength of superterminal spawns, and the number of times a superterminal has "ticked" feeds into that same antagonism (thematically, they're both "hacking" and the AI dinnae like it).
      • Reducing AIP via superterminal hacking is significantly more "efficient" than knowledge raiding in terms of what you gain in return for making future hacking efforts more dangerous. The disadvantage is that this requires the superterminal, and doesn't stop if you lose control of the system (unless you destroy the superterminal).
    • Now also uses a "wild roll" system like what k-raiding uses, but it's somewhat more tame in terms of what kinds of crazy it can throw in there. Right now all it can do is surges (10% of the time, the same effect that was added in the previous version), and the "short range warp jump" (15% of the time, spawns the units away from the superterminal itself) wild-effect that the k-raid spawns can get.
    • If you have Advanced Logging enabled, each spawn will generate an entry in the "CounterSaboteurSpawns.txt" log file; it may not make sense to players but is very helpful to us if you submit it with your feedback.
    • The rationale for this is trying to make both k-raiding and superterminal-hacking more interesting and more of a strategic choice (since now using one makes the other more dangerous), but also to make it harder to use the superterminal for arbitrarily-high AIP reductions (we've seen cases where players could kill 400 AIP with it without even being in much danger).
      • As with k-raiding: In general, the balance of all this is tentative. It looks right in our testing, but it may be too easy or (perhaps more likely) too hard. Please give us feedback and we will continue to refine towards better balance and more fun :)
    • Thanks to Wanderer and others for various feedback over the past year showing how much people could run away with the game using the superterminal, generally stopping due to boredom rather than threat. Now you'll die of something else before you die of boredom :)
  • Advanced Research Station Hacking:
    • Added the "Ship-Design Hacker" (for lack of a better name, let us know if you think of one): a 4th ship to the "science lab" line, very similar to the "Knowledge Hacker". It gathers no knowledge, but has another ability.
    • If you keep a Ship-Design Hacker on an AI-controlled planet with an AI-controlled ARS for 10 minutes (it must remain stationary during this time; it's one of those kinds of countdowns), it will "hack" the Advanced Research Station and reprogram it such that when you capture the planet:
      • Instead of being immediately granted a new bonus ship type, you will be able (from the tech menu of the ARS, or of a Ship-Design Hacker) to select one of three bonus ship types.
      • Note the hacker does not have to survive after the hack has been completed, and the ARS does not have to survive after the planet is captured, but you will need a science lab, ARS, or SDH (anything with a tech menu that normally lets you unlock II/III versions of fleet ships, basically).
    • However, the AI will react to Ship-Design Hackers the same way they react to Knowledge Hackers. Also, the number of previous ship-design-hacks you've pulled off will increase AI response to future hacking (of all 3 kinds). Each subsequent ship-design-hack makes things a lot worse than the previous one did, such that 1 isn't a big deal, 2 is a big deal, 3 is a huge deal, 4 is probably death if you hack seriously again, and 5 is really going to mess you up if you so much as look like you're hacking the rest of the game.
    • In summary: if you don't "use" your opportunity to hack for k-raiding, or for the super-terminal, you can use it here to get more flexibility in your fleet composition. You can also do all three activities, but remember that they each make the others more dangerous.
  • Amended Bomber Starship description to note that it is unable to hit small targets.
    • Thanks to rabican for reminding us that it wasn't admitting to this particular limitation.
  • Fixed a bug where aoe shots would do fail to hit a forcefield they detonated against unless the actual forcefield-generating unit was in range of the explosion. Now the collision check is done against the forcefield's current radius rather than its center point.
    • Specifically, this deals with plasma siege starships firing upon but being unable to damage an AI forcefield (when it was high enough health, at least).
    • Thanks to TechSY730 and rabican for reporting and providing saves.
  • Dyson Antagonizer (hybrid plot) :
    • Now tries to be built somewhat closer to the AI's border.
    • Health from 80M => 40M.
    • The more dangerous values may be restored for Advanced Hybrids or some other option in the future, but the previous string of buffs to this plot was proving too much for normal.
    • Thanks to various players for feedback on this.
  • The "Detected AI Progress Reducers" galaxy map display used to just show "DC " followed by the total number of reducers on the planet (for planets with any). Now it shows "DC", "CP", "ST", or "CL" (Data Center, Co-processor, SuperTerminal, Civlian Leader) and if there are multiple on a planet it shows them with spaces inbetween (so potentially something like "ST DC DC").
    • Thanks to Spikey00 for pointing out that the previous display left something to be desired.
  • Impulse Reaction Emitter, in recognition of winning the 3rd "worst ship" award:
    • Effective Range from 4200 => 6000.
    • Base Move Speed from 20 => 30. This makes it slightly faster than a fighter.
    • Base Metal+Crystal cost from 300+300 => 250+250. That's mkI; other marks use normal progression.
    • Minimum multiplier from 5 => 8.
      • The base-cap-dps was already high at 73k and is now in the top 10 among fleet ships (including self-destructing ships and ships with no bonuses) at 117k, but this helps counterbalance the fact that it doesn't get more than the minimum multiplier against most fleet-ship targets.
    • Multiplier from (target energy use)/1024 => (target energy use)/256. So it starts getting a higher-than-minimum bonus against ships using 2049+ energy, up to the max multiplier of 30 against targets using 7680+ energy (note that the IRE is not any better damage-wise against max-multiplier targets, since it was already very powerful there).
    • Thanks to the poll voters for bestowing this dubious honor, and for more specific feedback on what the unit actually was lacking.
  • Space Plane, in recognition of doing really well in the 3rd "worst ship" poll:
    • Vs-Hull multipliers from 2.4 => 3.2.
      • For reference, that's against Light (Fighter), Polycrystal (Bomber), Heavy (... a lot of things), and UltraHeavy.
      • Eyebots have 3.2, and a somewhat lower base-dps, but can shoot through forcefields.
    • Seconds-per-salvo from 3 => 9.
    • Base Attack Power from 600*mk => 1800*mk.
      • So that's the same dps as before (aside from the multiplier increase), but higher alpha capacity for hit-and-run using their radar dampening, etc.
    • Base Energy Use from 100 => 50, because with the 1.75x ship cap the default energy use (100) was kind of excessive.
    • Base Metal+Crystal cost from 90+90 => 75+75 (that's mkI). More in keeping with the dies-due-to-light-breeze-when-it-can-catch-them nature of the ship.
    • And the AI is really happy about this part: the Space Plane is now immune to AoE damage. That's bargained down from immune-to-gravity, so be happy.
    • Thanks to the poll voters for their feedback on this unit.
  • Vampire Claw, also in recognition of runner-up-for-worst-ship:
    • Base Health from 5000*mk => 10000*mk.
      • Previously they only had 4M cap-health, which was below even stuff like eyebots. Kind of rough for a melee ship even with self-regen. Now at 8M they're still really low compared to most fleet ships.
    • Now have cloaking. Be afraid. Bring tachyons. And garlic.
      • Note that this means that games with cloaking ships disabled won't have claws. But any game already started that has them will continue having them, regardless of that setting.
    • Base Energy Use from 200 => 160.
    • Base Attack Power from 650 => 850.
    • Added Artillery to the hull types this has a bonus against (om nom missile frigate tasty).
    • Now has a 0.3x multiplier against the command-grade hull type.
    • Thanks to the poll voters for their feedback on this unit.
  • Youngling Tiger:
    • Base Metal+Crystal from 40+40 => 25+25, same as commandos and weasels.
  • Youngling Vulture:
    • Base Metal+Crystal from 40+40 => 25+25, same as commandos and weasels (and tigers, now).
  • Spire Gravity Drain:
    • Base Metal+Crystal from 0+3000 => 500+1000. These were tied for most expensive fleet ship, and 2x (or more) as expensive as all but 6 other fleet ship types. Wasn't really anything to justify that.
    • These need more rebalancing attention, but ran out of time for that in this release.
  • Spire Gravity Ripper:
    • Base Metal+Crystal from 1800+1200 => 1000+500. Was similar to the grav drain's situation.
    • These need more rebalancing attention, but ran out of time for that in this release.
  • Spire Armor Rotter:
    • Base Metal+Crystal from 800+1900 => 450+900. Was 3rd most expensive.
    • These need more rebalancing attention, but ran out of time for that in this release.
  • Space Tank:
    • Base Metal+Crystal from 1100+0 => 600+100. Was 5th most expensive, and more expensive than bombers, now slightly less expensive than bombers.
    • Base Attack Power from 2600*mk => 2300*mk.
    • Vs-Hull-Type multipliers from 3.2 => 6.
      • Bombers have 6. Space Tanks now have a roughly 30% higher base-dps, since the general idea is for bonus ship types to be 30-50% more useful than triangle types.
    • Effective range from 4800+200*mk => 6300+200*mk. Since they're so slow.
  • Grenade Launcher:
    • Base Energy Use from 400 => 150. It had twice the cap-energy-use of the next highest fleet ship type.
  • Sentinel Frigate:
    • Base Attack Power from 14000*mk => 31000*mk. It had a cap-dps (base=max for this one) of 44k, which was really laughable. 100k is bit on the low end for a type with no bonus of any kind, but it is an infinite-range ship.
  • Made end-of-Fallen-Spire spawns yet more enthusiastic, due to the opposition they sometimes face on 10/10. That AI sure is stubborn...
  • On planet view, the game now draws two circles representing the key zones of the planet's "gravity well". These will generally only be seen when zoomed very far out. The inner circle (60000 range from planet center) represents the bounds of the area within which stationary structures may be built and transports may unload. The outer circle (80000 range from planet center) represents the boundary beyond which ship engines are unable to maintain a useful velocity.
    • The underlying rules have been there for over a year, but seeing the ranges involved the minimap.
    • To go with this, added new toggle: Disable Planet Area Display, which disables this new drawing behavior. If there's a bunch of complaints this toggle may be changed to default to "on", but we'll see :)
    • Thanks to clone for reminding us how little clue the game gave (particularly to new players) about the existence and importance of these two ranges.
  • Now for wave alerts that list the actual ship type being sent at you: moving your mouse cursor over a wave alert will bring up that ship's data, similar to mousing-over a ship of that type.
    • Thanks to clone for the suggestion.
  • Science Labs I/II/III, the Survey Ship, and the new Ship Design Hacker are now all immune to the maw's swallow effect. This has nothing to do with a recent test going unexpectedly and terribly awry, of course.

Prerelease 5.027 SuperTerminal Overload

(Released February 23rd, 2012)

  • Fixed a bug where the stages of the hybrid-dyson plot that were supposed to only happen when Advanced Hybrids were on were happening when only Normal Hybrids were on.
    • Note: the antagonizer is part of what should happen with normal hybrids, but we're working towards more flexibility there too.
    • Thanks to orzelek for the report.
  • AI Super-Terminals:
    • Previously these became active after you finished building a command station on the planet, and went dormant again as soon as your command station was destroyed. Now they never go dormant after becoming active: now, the only way to shut down an active superterminal is to destroy it.
      • Thanks to Atomjack for pointing out that it was too easy to keep turning the terminal on and off previously.
    • Now each super-terminal "pulse" has a 10% chance to be a "surge":
      • It puts a message in the chat log letting you know there was a surge.
      • It intensifies the pulse by (highest AI difficulty / 2) (so diff 7 means that pulse will be 3.5 as strong in terms of enemy ships generated).
      • It sets the time until the next pulse to 1 second instead of the usual 15. "Chain surges" are therefore possible, albeit fairly unlikely.
    • Previously when the super terminal reached a certain size of mkV pulse it simply didn't get any more dangerous; now it will start shortening the time between pulses as the strength goes past that point.
    • In all, super terminals were being a little too tame. It's great that proper playing of an ST can make the difference between winning and losing, but they seemed to need more danger and unpredictability to balance out their fairly powerful advantages. It's more like "riding the bull" now, and if it gets out of control it can kill you.
  • Mapgen will no longer put the dyson sphere adjacent to an AI core world, because having a core world on alert the whole game was nearly an automatic loss on some more intense scenarios. It's better if you die because of something you actually had influence over.
    • Thanks to Wanderer for reporting a game where the dyson sphere was bordering 3 core worlds. Ouch.
  • Riot Tazer:
    • Paralysis Time from 1 => 3 (internally 2 => 4, but the first second generally gets eaten due to processing order).
    • Reload Time from 2 => 8.
    • Per-planet stagger from 2 seconds => 6 seconds.
    • This helps prevent some transient (and difficult to reproduce) stunlocks due to processing order, while maintaining the ability to keep things locked down 50% of the time.
    • Thanks to Wanderer for reporting the transient stunlocks.
  • Anti-Starship Arachnid V:
    • Has become Spider Bot V, which it has been internally since the beginning but had a bunch of special changes to make it an anti-starship unit.
      • Long ago this was a really important unit for the AI because it would spawn them in response to human usage of starships, but that hasn't been the case for rather a while.
      • In the meantime, they generally only see service if a human player captures a fabricator that produces them, and while the AI does use some starships generally these units are very, very low on usefulness to a human player because they literally can't hit anything that isn't a starship. So now they're just Spider V.
    • Thanks to Wanderer for reporting that he shot his monitor after finding 2 Anti-Starship V fabricators. At least, that's what's on the police report.
  • Spider Bots:
    • Engine Damage per shot from 15 => 60.
      • This brings mark I cap-engine-damage-per-second to about 30% of a cap of Spider Turrets; a cap of mkII (which has fewer ships) to 50-55%, and so on.
    • Base Health from 3600*mk => 7200*mk. They were right at the flimsiest end of fleet ship cap-health (5M), now just in the lower 3rd (10M).
  • Beam Starship:
    • Rebalancing as a MkV starship, since the fleet ship fabricators produce MkV stuff.
    • Base Move Speed from 14 => 22.
    • Base Health from 4.5M => 22.5M. Now on par with the Core Starship for cap-health.
    • Max targets hit per shot from infinite => 9. Same as Zenith Beam Frigate.
    • Seconds-per-salvo from 5 => 2. Not the same as Zenith Beam Frigate.
    • Base Attack Power from 28k => 44k. If it hits 9 targets every 2 seconds, that puts cap-dps at about 3/4 that of the Core Starship's bonus cap-dps.
    • All vs-hull-type multipliers removed; the "bonus" for ships like this is typically obtained by hitting more than one ship; max bonus is against large clumps where you can always hit the max.
    • Energy and m+c costs looked ok; energy a bit high, m+c rather low for mkV but since you have to get a fabricator to build these we can let it slide unless it becomes a problem.
    • Thanks to zharmad for the reminder that these have needed a rebalance since before 4.0.
  • Warbird Starship:
    • Rebalancing as a MkV starship, since the fleet ship fabricators produce MkV stuff.
    • Made eligible for spawning in exos again; were originally removed from that because if they were lead ships they made the whole group go terrifast. Well, Raid Starships are even faster and are still eligible, so these are going back in. Generally these won't be picked to lead all but relatively early exos with lighter overall firepower.
    • Base Health from 3M => 17M. Now about 70% of Core Starship for cap-health (or: a bit over 10M*mk, where 7.5M*mk is about as low as any combat starship should go in the current approach).
    • From no vs-hull-type multipliers => 4 vs polycrystal, heavy, ultra-heavy, and structural.
    • Seconds-per-salvo from 5 => 2.
    • Shots-per-salvo from 40 => 16.
    • Base Attack Power from 2k => 8k. This brings non-bonus/bonus cap-dps to a bit under 200k/800k, very similar to the core starship in that regard.
    • Energy and m+c costs looked ok; energy a bit low, m+c rather low for mkV but since you have to get a fabricator to build these we can let it slide unless it becomes a problem.
    • Thanks to Spikey00 for the reminder that these needed a rebalancing.
  • Paralyzers (specifically, zenith paralyzers, but also nanoswarms to some extent) are now much more aggressive about spreading out their fire across available targets to make better use of the paralysis effect.
    • It still will focus more than is optimal in cases where a group of more than 100 paralyzers (of the same mark, controlled by the same player, relatively near one another) has more than 100 non-paralyzed targets in range (they'll generally all focus on 100 of the targets in the first volley, and spread out afterward) due to our desire to not have target lists longer than 100 for RAM-consumption reasons. But it's a lot better than it used to be.
    • Thanks to soMe_RandoM and (more recently) zharmad for bringing to our attention how sub-optimal the targeting used to be.
  • Reference tab balance export:
    • Removed a lot of no-longer-relevant columns.
    • Added columns for base shot strength, targets hit per shot, shots per salvo, seconds per salvo, minimum and maximum special multipliers (for vulture/IRE/polarizer), short name, wave name, etc.
    • Improved computation of non-bonus and bonus dps to be right in more cases (still off for autobombs/minirams/nanoswarms, etc).
    • Thanks to Dazio for suggestions on what would be helpful for working on the new wiki pages for each ship (and thanks to him and others for that work, of course!)
  • Fixed a bug where the minimum special multiplier wasn't working for Zenith Polarizers against targets that literally had zero armor, so their dps was 1/4 the intended value in those cases. Fixed a related bug for Impulse Reaction Emitters, but that probably wasn't affecting any significant cases.
    • Thanks to TechSY730 for the report.
  • Acid Sprayers:
    • Base Attack from 450 => 600. This puts the non-bonus cap-dps pretty exactly at the fighter's.
    • Base Movement Speed from 40 => 50. Now same as the ether-jet; this is a very short range ship and needs to be able to close the distance.
    • Vs Hull Type Multipliers from 6 => 8. The fighter's vs-polycrystal bonus is 5, for reference.
    • Base Metal/Crystal cost from 0/300 => 40/180. So 10% more expensive to build to cap than a fighter (though it's still twice as much energy).
    • Thanks to the many players weighing in the poll naming the Acid Sprayer as the second winner of the "worst ship" award. In honor of these changes, the award has been optimistically confiscated.

Prerelease 5.026 Pay Attention, Exos!

(Released February 15th, 2012)

  • Fixed a bug in the previous version where broken-golems-hard and spirecraft-hard exos could sometimes pick any human-controlled unit as their main target.
    • Thanks to dotjd for the report and save.
  • Vorticular Cutlass:
    • Base Health from 7000*mk => 10500*mk. This puts them at the top of the target fleet ship range with 30M*mk cap-health (Armor Ships and Shield Bearers were the only other ones up there before this).
    • Base Speed from 16 => 54. So from slower than a fighter to slightly faster than an etherjet.
    • Base Metal/Crystal cost from 200/50 => 30/30. Now the same price as infiltrators, a bit lower than tele-raiders, etc.
    • Base Energy use from 100 => 20.
    • Thanks to many players for ongoing feedback about these being, possibly, the least useful fleet ship in the game since its last major changes.
  • Fixed bug where autobombs/nanoswarms/etc could now target and fly into an aoe-immune ship but couldn't actually do anything to it. They'll now do damage and their other effects as normal, though if it's just a big pile of aoe-immune targets you'll probably want to hold them off for efficiency reasons: they'll only hit the direct target, unless there's something aoe-able in range.
    • Thanks to techsy730 for the report.
  • Youngling Nanoswarm:
    • Paralysis time from 1*mk seconds to 3*mk seconds. Partly because really short paralysis times work a bit oddly, partly because these needed to be more useful.
    • Engine damage from 2*mk => 10*mk.
  • The "The Tank" AI-type wave multiplier from 0.5 => 1, as the intent behind it is that it be actually stronger on offense than usual, rather than weaker. The average should be fine, but possibly another increase can come later.

Prerelease 5.025 Balance Beam

(Released February 13th, 2012)

  • Everything that fires Siege Plasma (Plasma Siege Starship, Plasma Siege Cannon modules), Flak grenades, grenades, or self-explodes (autobomb, nanoswarm) can now fire directly upon aoe-immune targets, but the resulting aoe will still not hit any aoe-immune targets (just the directly hit target).
    • Notably, this restores the Plasma Siege Starship's ability to target Raid Starships, which was unintentionally lost in the previous version.
    • Thanks to techsy730 for pointing out the error, and several players for the suggested mechanic change.
  • Added new toggle to CTRLS window: "Make Multi-Planet FRD Patrol" (defaults to on).
    • If this toggle is checked, your FRD units will pursue and engage enemy units on the same planet even if currently under orders to proceed to a different planet.
    • Otherwise, your FRD units will prioritize a "move to different planet order" and will not break off to pursue enemy units.
    • Note: This used to be the default behavior but was changed during the last year. Several requests to return to the previous behavior have led to this change, but the suppress-patrol behavior is available by unchecking this toggle, for those who want it (or to use it for a certain period of time). More granular control could be added, but we didn't want to overbuild this.
    • Thanks to many players for reminding us that they really like it when FRD means "Patrol".
  • When computing the number of reactors of a specific mark controlled by a specific player on a specific planet for the purposes of reactor-inefficiency, that number is now divided by that player's number of homeworlds (if that player has more than 1). This allows them to get basically the same energy output per m+c cost as an equivalent number of separate players with the same total number of homeworlds.
    • On the same note, the "auto build energy reactor" toggles on the CTRLS window (both galaxy-wide and per-planet) have been converted to sliders allowing you to specifying that more than one should be auto-built. If both the galaxy-wide one and a per-planet one are greater than zero, that planet will auto-build the higher of the two numbers (but not the sum, unlike with engineers).
    • The energy difference between multi-HW and multi-players has been known for a long time and not considered a priority. However, recent scientific analysis has concluded that multi-HW AARs have significant potential entertainment value, hence the change.
    • Thanks to many, many players asking for this over the years.
  • Added new unit cap scale option: Ultra Low
    • Most large-cap ships have roughly a quarter of the standard cap (Fighter MkI = 24), and are roughly four times as expensive, four times as strong, etc.
    • This puts the lowest possible load on the your CPU when you have the biggest-possible battles. Also helpful if you're playing a game with 8 human homeworlds (in multiplayer or otherwise).
    • Thanks to Wanderer for submitting a save that showed a Low-caps battle making a modern CPU cry.
  • Flak Turrets:
    • Effective range from 4000/5000/6000 => 4500/5500/6500 to make them a little easier to place around a wormhole.
    • Now when under a firepower-reducing forcefield they retain 75% of their attack power instead of the customary 25%.
    • Hopefully they'll now be closer to the general usefulness of other turrets in that they don't have to die immediately (if protected).
    • Thanks to chemical_art, techsy730, Wanderer and other players for weighing in on the flak's recent usefulness and making suggestions.
  • Lightning Turrets:
    • Now when under a firepower-reducing forcefield they retain 75% of their attack power instead of the customary 25%.
  • Heavy Beam Cannons (just the human standalone ones, not any of the spire variants, though the spire variants were impacted by the m+c and knowledge cost changes) :
    • All marks:
      • All vs-hull-type bonuses removed, these are just straight damage now, which is more thematically appropriate. Also, it's nice to have at least one turret type that doesn't have that kind of bonus.
      • For reference, these aren't really "aoe", they're "blast-through"; a beam loses strength as it does damage.
    • MkI
      • For reference, MkI unit cap is 12 for these, and each fires 3 beams every 7 seconds.
      • Base Health from 250k => 850k. This brings cap-health a bit higher than missile turrets, which are the squishy end of turret types.
      • Base Energy Use from 750 => 1650. This brings cap-energy to just slightly above MLRS and several other turret types.
      • Base Metal/Crystal Cost from 8000/14000 => 6500/11000. This brings cap-mc to slightly below most turret types.
      • Base Attack Power from 50000 => 140000. This brings cap-dps to be second highest turret non-bonus-dps (lightning being highest) but well below the any turret's bonus-dps.
      • Knowledge cost from 2000 => 500. The other mkI turrets are free.
    • MkII
      • For reference, MkII unit cap is 8 for these, and each fires 6 beams every 6 seconds.
      • Base Health from 1.25M => 2.55M. Basically: mkI health * (2 for being mkII) * (1.5 for smaller unit cap)
      • Base Energy Use from 1300 => 2500. (roughly mkI * 1.5 for cap)
      • Base Metal/Crystal Cost from 16000/28000 => 13000/22000. (mkI * 2, customary for mkII)
      • Base Attack Power from 50000 => 180000. Basically: mkI damage * (0.429 for rate-of-fire-difference) * (2 for mkII) * (1.5 for unit cap)
      • Knowledge cost from 3000 => 2500. Most other mkII turrets are 2000-3000.
    • MkIII
      • For reference, MkIII unit cap is 4 for these, and each fires 12 beams every 5 seconds.
      • Base Health from 2.25M => 7.65M. Basically: mkI health * (3 for mark) * (3 for unit cap)
      • Base Energy Use from 2000 => 5000. (roughly mkI * 3 for cap)
      • Base Metal/Crystal Cost from 32000/56000 => 26000/44000. (mkI * 4, customary for mkIII)
      • Base Attack Power from 50000 => 225000. Basically: mkI damage * (0.179 for rof diff) * (3 for mark) * (3 for cap)
      • Knowledge cost from 3500 => 3000. That's pretty normal for a mkIII turret.
    • MkIV
      • For reference, MkIV unit cap is _1_ for these, and it fires 40 beams every 4 seconds.
      • Base Health from 3.25M => 40M. Basically: mkI health * (4 for mark) * (12 for unit cap)
      • Base Energy Use from 2000 => 20000. (roughly mkI * 12 for cap)
      • Base Metal/Crystal Cost from 64000/112000 => 52000/88000. (mkI * 8, customary for mkIV)
      • Base Attack Power from 50000 => 290000. Basically: mkI damage * (0.043 for rof diff) * (4 for mark) * (12 for cap)
      • Knowledge cost staying at 3000. Thought about 3500, but it really is just one unit.
    • These haven't seen a real rebalance in... a long time, and had fallen behind pretty drastically through the various changes since the 3.x days. Hopefully this will make them statistically competitive with other turret types (that have much larger caps). Feedback on how it all actually works out in practice is very welcome.
    • Thanks to Hearteater and others for feedback that inspired these changes.
  • All modules (except those that generate forcefields) are now invincible and thus untargetable, etc.
    • This really helps prevent a lot of fiddliness when losing modules on a Riot (or whatever), especially when you've got a build queue competing with the ship's auto-replacement logic, etc.
  • Fixed a longstanding bug where modules would not always decloak their parent ship when firing.
    • Thanks to several players for reporting that the previous fix for this wasn't working.
  • Now when a modular ship is in low-power-mode, all its modules act as if in low-power-mode.
    • Note that if a module was already in low power mode and the parent is made low-power and then taken out of low-power, that module will stay in low-power. The other modules that were not in low-power before will come out of it when the parent does.
  • Riot Starships:
    • Ship Cap from 4/3/2 => 4 flat. Most of the special starship types have non-decreasing caps already.
    • Base Health from 900k*mk => 1.8M*mk. This brings their just-the-hull health up to just below the squishy end of the current target zone for starships (7.5M*mk cap-hp, though Raids and Leeches are currently way below that for other reasons).
    • Shield mkI/mkII Base Health from 500k*mk => 1.8M*mk. This brings their hull+shield health up to the middle of the target zone.
    • Base Speed from 20/17/14 => flat 20.
    • Base Energy Cost from 3000/4000/5000 => flat 3000.
    • Base mkI Metal+Crystal Cost from 20k+60k => 30k+50k (mkII is 2x, mkIII is 4x).
    • Knowledge Cost from free/3500/4500 => free/4000/5000. DPS starships run 0/5k/7k, more specialized ones like the raid run 0/4k/4k, etc.
    • Base Attack Power from 3600/5200/6800 => 4000*mk. This brings their non-bonus-dps up to the very low end of the current target zone for starship (20k*mk cap-dps). So it's really low (even with module damage), but it's a utility type.
    • Base Engine Damage from 40/55/70 => 40*mk.
    • Multiplier vs Medium from 2 => 4. Its other 4 bonuses were already 4.
    • All Modules:
      • No longer have an energy cost. 12k cap-e for the hulls is enough.
    • Machine Gun Modules:
      • Engine Damage Percent Floor from 50%/30% => 40%/20%.
    • Laser Modules:
      • Engine Damage from 17*mk => 30*mk. The machine guns are still 3x as efficient for total EDPS but have shorter range and cannot bring engines as low as these.
      • Multiplier vs CloseCombat from 5 => 4.
      • Multiplier vs Neutron from 3 => 4.
    • Shotgun Modules:
      • Base Attack Power from 40 => 400.
      • Engine Damage from 28 => 36. Makes these 2x as efficient as MGs for total EDPS.
      • Shots per salvo from 25/49 => 25*mk.
      • Multiplier vs Swarmer from 6 => 4.
      • Multiplier vs CloseCombat from 5 => 4.
      • Multiplier vs Refractive from 5 => 4.
    • Tazer Module:
      • Multiplier vs Medium from 3 => 4.
      • Multiplier vs Artillery from 3 => 4.
      • Now has a planet-wide stagger time of 2 seconds, to prevent permanently stunlocking 4000+ ships in a multi-hw setting with 4 Riot IIs. They can still be used to effectively halve the attack power (due to prolonging reload time) of non-paralysis immune enemies. Also tends to interrupt them while they try to get away.
      • Thanks to Wanderer for being the one to confirm the long-held suspicion that these were horribly exploitable.
    • Tractor Modules:
      • Tractor Range from 1700*mk => flat 4400. Same as mkIII tractor turrets.
      • Tractor Count from 10/40 => 72*mk. Same as mkII/mkIII tractor turrets (but mobile and not needing supply).
        • Note that this doesn't scale with unit cap scale and really should, but that's a bit out of scope for this time frame and these would be the numbers on high caps so you're not losing anything.
    • For reference, total cap-EDPS with all MG/SG builds firing within main-gun range is now 3080/4720/7080, compared to the spider turret's 7833 (from infinite range, insta-fire, and able to take engines down to 1%, but immobile and way more expensive).
    • This was another long-overdue rebalancing, hence the magnitude of changes.
  • Orbital Mass Drivers:
    • Now when under a firepower-reducing forcefield they retain 75% of their attack power instead of the customary 25%.
    • Thanks to techsy730 for the suggestion.
  • Leech Starship:
    • Base Energy Use from 10k/14k/18k => flat 5k. So cap-e is same now as Raids (the next highest for combat starships)
    • All vs-hull-type bonuses removed, to allow for a bit more of an overall damage buff and thus more general reclamation utility.
    • Base Health from 1.6M*mk => 3.2M*mk. Was well below the target range for starship cap-health, is now just on the low-end (bottom is 7.5M*mk).
    • Shots per salvo from 1 => 3. That brings it up to the target range for starship-with-no-bonuses cap-dps (about 66k*mk), and should help it reclaim more.
    • Hull type from UltraLight => Heavy because UltraLight tends to be a major pain to kill when in the hands of the AI (see: raid starships) and the health just doubled.
    • Thanks to many players for feedback that this was an underwhelming unit.
  • Light Starship/Flagship/Zenith Starship/Spire Starship/Core Starship
    • Ship Cap from 5/3/2/2/2 => 4 flat.
    • Base Speed from 15/18/18/24/22 => 22 flat.
    • Base Armor Rating from 1000/2500/2500/2500/2500 => 1000*mk.
    • Base Energy Use from 2k/10k/20k/20k/20k => 4k flat.
    • Base Attack Range from 1500/4800/3000/10000/500 => 3000+(200*mk).
    • Base Health from 2M/6M/14,625k/12,675k/25,350k => 3.75M*mk. This brings them to 15M*mk cap-health, and the target range for starships is 7.5M-40M*mk (though there aren't any "Armor Starships" or whatever that would actually use the top of that range, etc).
    • Shots-per-salvo from 5/9/14/4/5 => 5 flat.
    • Seconds-per-salvo from 4/4/2/2/5 => 4 flat.
    • Multiplier vs CloseCombat from 12/12/1/1/1 => 4.
    • Multiplier vs Medium from 8/8/1/6/1 => 4.
    • Multiplier vs Light from 6/6/1/1/1 => 1/1/4/1/4.
    • Multiplier vs Polycrystal from 1/1/0.01/4/1 => 4/1/1/4/4.
    • Multiplier vs Artillery from 1 => 1/4/1/1/4.
    • Multiplier vs UltraLight from 1/1/1/4/1 => 1.
    • Multiplier vs Swarmer from 1/1/1/1/0.1 => 1.
      • Part of this is to make each of the mkI-IV varieties good against one triangle ship type, and the mkV good against them all (not that you can get the mkV normally, but the AI can!).
    • Base Attack Power from 3600/12k/30k/60k/60k => 8k*mk. This brings them to 40k*mk non-bonus and 160k*mk bonus cap-dps, which is about right for a 4x-bonus starship.
    • Munitions boost range from 3k/6k/5k/8k = 2k+(1k*mk).
    • Most of the mark-specific quirks (flagships do a little engine damage, zeniths and up have warp detection, spires are immune to gravity, different ammo types, etc) are still there.
    • There've been a lot of balance problems with this line for a while, and we've held off from comprehensive changes partly since they're really two separate lines (fleet starship and alien starship) and we'll probably split them up at some point. We'll probably still split them up later since that would be cool, but for now it's easier to balance them as a cohesive line according to the guidelines used for the other combat starships.
  • Golems-Hard and Spirecraft-Hard exos are now a bit more wily about what their primary objectives. FS exos may follow suit later.

Prerelease 5.024 Carrier Rules Of Engagement

(Released February 6th, 2012)

  • Fixed an... interesting omission in the previous version: Plasma Siege Starship base range was supposed to have gone from 16k to 4k, but did not. On further thought, the change was made to 6500/7000/7500 instead (same as mkI/II/III missile frigate).
    • Thanks to TechSY730 and Wanderer for the report.
  • Spider turrets:
    • Base Metal Cost from 6000 => 1200.
    • Base Crystal Cost 15000 => 2400.
    • These weren't actually changed in last patch because they weren't inheriting the sniper turret costs. This is actually a good thing as spider turrets are substantially more useful than sniper turrets. They now cost 2x as much m+c as the sniper turret (3600 vs 1800).
    • Thanks to c4sc4 for pointing out that the costs hadn't changed.
  • Fixed a bug in the previous version where Ally counts on the galaxy map display were higher than they should have been (specifically, it was taking the total number of friendly ships and adding the number of "my ships" instead of subtracting it).
    • Thanks to dorenthas for the report.
  • Fixed a display bug where a constructor that had to stop building would sometimes still show in some places as continuing to spend resources. They were not actually continuing to spend resources while unable to build, but it looked like it.
    • Thanks to Cyborg for the report.
  • Fixed a bug where a constructor that had to stop a build in mid-construction due to the ship cap for that type becoming full (another constructor "won the race", so to speak) would usually fail to refund the resources it had already spent on the ship being built.
    • Thanks to Cyborg for the report that led to this being found.
  • Stats Window -> Resource Flows Tab, detail (i.e. non-summary) mode:
    • The unit type name for each entry is now a button.
      • Left clicks center your view on the unit (and switch to its planet, if different from your current view).
      • Right clicks try to toggle whether the unit is in low power mode (note that a unit in low power mode will typically not be shown in detail mode because it only shows stuff with a non-zero metal or crystal impact).
      • Fixed a bug where the "Reason" column always said "Normal Operation", even if it was supposed to say Assisting, Repairing, Self-Building, Build Queue, or Low Power Operation.
  • After a few months of etiquette classes, player-ally zombie ships have learned to die silently. (Note: minor faction player-ally ships already knew this)
    • Thanks to Red Spot for the suggestion.
  • AI Carriers:
    • Are no longer invincible if there's >= 2000 AI ships already on the planet.
      • Previously this was necessary to avoid too many AI ships on a planet at once for decent cpu/ram performance.
    • Now, when a carrier deploys (it deploys when destroyed):
      • If there are fewer than 1400 AI ships already on the planet, and another carrier has not deployed in the last few seconds, it deploys normally as before.
      • Otherwise, it "combines" its contained units into a fairly small assortment of ships and deploys those. The population of this group uses similar logic as exo waves, but is not itself an exo wave (there's no leader, no beeline-human-homeworld logic, etc), it behaves as normal threat.
        • The more AI ships there are on the planet, the more "condensed" it tries to make this deployment, so in those cases you'll see more enemy starships, etc but far smaller quantity.
    • Also, if there are less than 500 AI ships already on the planet, and it is a non-AI planet and there's at least one enemy military (non-mine) unit, and another carrier has not deployed in the last few seconds, it automatically deploys.
    • Rationale: Previously it was possible to have carriers slip through otherwise impenetrable defenses because there were simply too many AI ships (which may have been somewhere else on the planet) to quickly kill. This was desirable from a design standpoint because we don't want a single layer of impenetrable defenses to be the end-all defensive strategy in the game. However, it has proved consistently frustrating (in a non-fun way) for some players so it seemed a good time to try something different. Now the presence of a ton of other AI ships doesn't make the carriers invincible, it just makes them very dangerous to destroy. Hopefully in an interesting way :)
    • Note: none of this impacts Barracks; they're still invincible in such cases, but we haven't heard many reports of players being frustrated by barracks invincibility.
    • Thanks to Cyborg and others for inspiring this change.
  • Added new toggle to controls (CTRLS) window: Auto-target Carriers.
    • If this toggle is checked, your units will consider AI Carriers normally when picking targets automatically. Otherwise, they will not automatically fire upon an AI Carrier (it may still fire upon a carrier that it has already put on its target list, but that will last no longer than the current engagement).
    • Regardless of this toggle, you may still directly order your ships to fire upon an AI Carrier.
    • This toggle is useful because killing a Carrier can be dangerous (due to what comes out), but sometimes it's more important to make sure your defenses don't ignore them.
    • This defaults to off. If you want your units to auto-target carriers, you will need to turn it on.
    • Note: implementing this involved a fundamental change to the logic that controls "can this unit be targeted at all?" and "can this unit be automatically targeted?". Specifically, that was always previously decided solely based on the potential target's type, and now it has to consider the player that owns the unit trying to do the targeting. While these changes were tested and very carefully checked it's certainly possible that a bug slipped through and will cause all manner of strange and wonderful consequences. Mantis and enjoy.
  • Plasma Siege Starship
    • Shot now has a traditional (lightning-type) aoe that does 6.25% of normal damage to up to 14 extra nearby targets.
      • In order for this normal aoe to work, the restriction from firing upon fleet ships has been removed. Previously it was there primarily to keep the autotargeting from "wasting" shots on small stuff, but this has become less important. It still prefers targeting starships, etc.
    • Still has the "siege" effect when hitting a forcefield, but that's been changed from 1% of the damage done to up to 200 ships to 6.25% to up to 25. That's less total, adjusting somewhat for the addition of the traditional aoe and the greater ease of getting the whole bonus.
    • For reference, the Siege's dps (per unit, not per cap) against a single target is about 71% that of the Bomber Starship (previous version notes said 1/3rd, that was actually inaccurate). If the traditional aoe hits the full 14 targets, that brings it up to about 133% that of the Bomber Starship. If the shot also hit a forcefield that's protecting other units, that extra "siege" damage is just gravy on top (potentially up to a total of 245% or so).
      • If this proves to be too much, adjustments can be made, but typically we get more useful feedback for a new/changed unit that's stronger than it should be than if it were weaker.
    • Thanks to many players for the feedback leading to these changes.
  • Fixed a bug in the previous version where the siege splash damage from the Plasma Siege Starship could hit targets normally untargetable or direct-target-only.
    • Thanks to Wanderer for the report and to the brave (if unwitting) Advanced Research Station that died discovering this bug.
  • Spirecraft Shield Bearers:
    • Ship cap doubled.
    • Amounts produced:
      • Reptite: from 0 => 1 mkI (so can now be built from Reptite)
      • Pysite: from 1 => 2 mkI
      • Xampite: from 1 => 2 mkII
      • Ebonite: from 1 => 2 mkIII
      • Adamantite: from 1 => 2 mkIV
      • Titanite: from 1 => 2 mkV
    • Hopefully this will bring their costs more into line with their actual utility (as non-repairable shields).
    • Thanks to techsy730 and others for inspiring these changes.
  • Fixed a bug where ships with no attack power would still display hull attack multipliers if they were internally defined (such as with ships that used to have an attack, like Spirecraft Shield Bearers).
    • Thanks to techsy730 for the report.
  • Lightning Turrets
    • Attack changed to function like electric shuttles: Hits up to 200 targets, and if hits are left over can hit each target up to 5 times (meaning that groups as small as 40 take the full power of the attack).
  • Lighting Turrets/Electric Shuttles: The per-planet-per-player-per-type-per-mark delay has been reduced to a very minimal duration, generally allowing a full cap of lightning turrets to unload its full power before the first one finishes reloading.
    • This still prevents a total alpha strike, but that also helps avoid a situation where the entire lightning turret cluster unloads on a couple of leading fighters before the rest of the wave shows up.
    • It also looked really cool in testing.
  • Player-Ally Dyson Gatlings are no longer unable to shoot mkV units.
    • In previous iterations this rule was necessary because player-ally dysons were clearing off AI homeworlds and/or core worlds. Since player-ally dysons rarely wind up on AI planets anymore the rule no longer seems necessary, and "why are my dysons not shooting X?" questions have been happening on a regular basis for quite some time.
    • Thanks to many players over time reminding us (sometimes unintentionally) how much they wanted their ally gatlings to shoot mkV things.
  • Hybrids:
    • If either player has Advanced Hybrids enabled, hybrid maturity-xp contributions to the central dirty-tricks "bank" are now doubled compared to Normal Hybrids.
    • The first couple stages of the only such dirty-trick progression currently implemented now happen a bit faster, but the first and second nasty bits have been made less nasty.
    • Thanks for Wanderer for the testing and feedback leading to these changes.

Prerelease 5.023 Plasma Siege Starships

(Released January 30th, 2012)

  • Fixed a bug in the previous version where all tractor beams (instead of just the black widow golem tractor beams) were doing the paralysis effect.
    • Thanks to Fleet for the report.
  • Zombie and minor faction ships no longer count as part of the "My" counts on the galaxy map. Those that used to count as part of that total now count as part of the "Allied" total.
    • Thanks to BobTheJanitor for the suggestion.
  • Fixed a bug in recent versions where the context menus never had scroll-bars and thus the galaxy-map-display select couldn't be used to select some of the further-down items.
    • Thanks to Minotaar for the report.
  • Removed the "press slash while mousing over an option for more info" text from the bottom of the context menu since there wasn't actually such info to be had on a lot of items in various modes of the context menu.
    • Thanks to Minotaar for the report.
  • Artillery Golem:
    • Base Armor Rating from 0 => 4000.
    • Base Recharge Time from 30 => 8.
    • Basically: when you see an Artillery Golem you can get on your side, we want you to be happy. When you see an Artillery Golem on the enemy side, we want you to be sad. Previously it wasn't doing a whole lot of either.
    • Thanks to Orelius and others for feedback on golems.
  • Fixed a bug in the previous version where the Black Widow paralyzing tractors would only apply a maximum of 2 seconds of paralysis, with quick gaps in the middle every 2 seconds. Now it correctly applies 2 seconds of paralysis damage per 1 second of tractoring.
  • Regenerator Golem:
    • Repair cost reduced by 90% to make regeneration not "cost" quite so much more than simply producing the ships from scratch, in metal+crystal terms.
  • Cursed Golem:
    • Self-attrition reduced by 50% (now would go from 100% to 0% in 60 minutes instead of 40).
  • Fixed a bug in the new munitions boost listing where it was displaying +70% as -31% or suchlike. Also fixed a rounding bug (+19% instead of the actual +20%, etc) in both that listing and the maximum-personal-boost listing.
    • Thanks to Hearteater for the report.
  • Fixed a bug where units with no attack were showing the new maximum-personal-boost listing.
    • Thanks to Nice Save for the report.
  • Turret base energy costs:
    • Basic Turret from 150 => 100.
    • MLRS Turret from 150 => 100.
    • Flak Turret from 300 => 200.
    • Missile Turret from 150 => 100.
    • Counter-Dark-Matter Turret from 4000 => 1000.
    • Counter-Missile-Turret from 4000 => 1000.
    • Counter-Sniper-Turret from 4000 => 1000.
    • Sniper & Spider Turrets from 250 => 150.
    • Grav Turret from 500/8000/10000 => 400*mk.
    • Tractor Turret left alone (150/240/300).
    • Laser Turret (150) and Heavy Beam Cannon (750/1300/2000/20000) left alone. They're energy weapons.
    • Lightning Turret from 500/1000/2000 => 400 flat. Energy weapon, yes, but that was a bit high.
    • These really aren't that big a deal, but it does help rein in some numbers that were set long ago, and bring the energy-per-dps ratio of the main attack turrets under the stuff that shoots and has engines.
    • Thanks to Cyborg, Hearteater, and others for feedback leading to this.
  • Fixed a longstanding bug where the number of spire shipyards and spire hab centers supported by a spire shard reactor was being multiplied by the number of human home command stations. The number of spire capital ships of each type supported by a spire shipyard (or refugee outpost, for the frigates) is still multiplied by that number, as is intentional.
    • Thanks to Wanderer for the report.
  • Fixed a bug where a ship with an inherent kiting range (raptor, zenith bombard, etc) would not correct for the radar dampening range of its target.
    • Thanks to Sunshine and others for reporting this.
  • Fixed a bug in the auto-build-energy-reactors controls where they were trying to check for remains of other energy reactors but were not checking the right list for those.
    • Thanks to Spikey00 for the report.
  • The Shards recovered in the Fallen-Spire events are no longer cloakable. Previously they could be cloaked via a cloaking starship; this was not deliberate on our part and made those recoveries way easier than they really should be.
    • Thanks to Spikey00 for reminding us about this.
  • Zenith Beam Frigate Base Range from 7500+100*mk => 6500+100*mk.
    • They're supposed to be long-ranged, but some marks were outranging their main triangle counter (missile frigate, which has 6500+500*mk base range), which isn't appropriate given the beam frigate's very high damage when it hits several targets per shot.
    • Thanks to Hearteater for the feedback inspiring this change.
  • Some further adjustment to high-difficulty wave size calculation, this time not changing diff 10 much at all but making the 9.3-9.8 stretch build up more gradually rather than 10 being more than 2x as hard as 9.8.
    • Previously in step 8 any difficulty greater than 7 received a 2.5 multiplier (7 got 2.25, and lower the lower you went).
    • Now:
      • 7.3 through 9 still get 2.5.
      • 9.3 gets 2.75 (10% harder than before).
      • 9.6 gets 3.00 (20% harder than before).
      • 9.8 gets 3.80 (52% harder than before).
      • 10 gets 4.5 (would be 80% harder than before, but see next change).
    • Previously each wave on diff 10 would actually cause 2 separate waves. This was from an old rule where 8 through 10 got double waves, but that was changed to just 8 due to the challenge-cliff it caused between 7.6 and 8. Now this rule has been entirely removed, since 10's waves are now so much larger than before.
    • We're very much open to more feedback on this; basically diffs 9.3 through 10 aren't really where we expect people to play (indeed, we may need to make them harder if someone actually beats 10 in a fair fight again), but we want it to be fun for those who do.
    • Thanks to Hearteater and others for the feedback inspiring this change.
  • Previously Sniper and Spider turrets cost 8 to 10 times as much metal+crystal to build a cap of compared to all other turret types, so:
    • Base Metal Cost from 1500 => 300.
    • Base Crystal Cost from 7500 => 1500.
    • They're still the most expensive turrets, that's intentional, but they're no longer quite so punishing (before you could have built a fleet of starships for the cost of a cap of sniper turrets).
    • Thanks to Wanderer and others for reminding us of how skewed this was.
  • Antimatter Starship:
    • Yes, this one is getting _another_ revamp. Some background:
      • First, they were called dreadnoughts. They did tons of engine damage. Too much. Nerfed.
      • Then, they were called useless. For a long time.
      • Then, we made them hit like a train from long range, but unable to fire upon anything remotely small. They were called Siege Starships (alias: "awesome").
      • But this broke a lot balance because you could just camp around your siege starships from across the planet and bomb everything to bits.
      • So they were given antimatter bombs that can't hit forcefields, fortresses, or... well, much of anything. In fairness they do great against starships and guardians, but that's proven too small a niche to really please their users. They were renamed "Antimatter Starship", which has since become a dire insult in 75% of the inhabited galaxy.
      • But the solution was unclear: we could shorten their range, but Bomber Starships (which were made normally available shortly after these were changed to Siege Starships) already fill the short-range big-stuff-killing niche.
      • And now, the next episode...
    • Base range from 16000 => 4000.
    • Shot type changed back from Antimatter Bomb => Energy Bomb (same basic type as bombers use, so no one is specifically immune to it like some are to antimatter bombs). Still cannot fire on small ships, like before.
    • If it hits a forcefield, it will also damage up to 200 units protected by that forcefield (or forcefields physically near that forcefield) with 1% (to each target) of the damage done to the forcefield.
      • Note: even stuff the starship itself cannot aim at (small units and cloaked units, etc) can be hit by the splash damage.
      • The 200-count doesn't change between low, normal, and high unit caps because that would change the dps of the unit pretty significantly. If it proves to be a problem we can try a few things.
    • Has been renamed to the Plasma Siege Starship.
    • The end result:
      • Still longer-ranged than the bomber starship, but much shorter than before, so not worrying that it will break balance in that way.
      • Still only about 1/3 of the bomber starship's single-target dps, but can up to triple the total damage output in a "siege" situation against a forcefielded group of targets. Still not the better choice in terms of raw damage, but the utility of being able to get at the protected targets should counterbalance that and create its own niche.
    • Thanks to many players for continuing to remind us that they want this starship to be cool.
  • Plasma Siege Cannon Modules (the ones for Fallen Spire modular stuff) now also have the forcefield-splash-damage attribute. Thematically, the Siege starship is (using) a plasma-siege-cannon now.

Prerelease Minor Tweaks And Fixes

(Released January 27th, 2011)

  • Fixed a bug in the previous prerelease that broke all the tutorials.
    • Thanks to Lorini for the report.
  • Black Widow Golem:
    • Number of tractors from 100 => 200.
      • Tractors on non-scaling ships do need to be made to scale with unit caps, but we don't have time to implement that just yet. Bear in mind that when that scaling comes, the current number of tractors will be the _highest_ value: corresponding to "high" caps, because that's what the caps were before scaling was added (when the tractor numbers were established to begin with), so it won't make them any better. For now, enjoy :)
    • This golem's tractors now do 2 seconds of paralysis damage per second to each held ship. Ships immune to paralysis are not affected.
    • Base Health from 80M => 200M.
    • Basically just trying to make this golem a lot more useful and a lot less likely to die when not baby-sat.
    • Thanks to Orelius and others for some recent feedback on this golem.
  • The earliest time that an AI player can even check for sending a wave has been changed to avoid both AIs sending their first waves on the exact same second on higher difficulties (which artificially increases the difficulty of the first wave, giving a false impression of how hard the second will be). Specifically, it's still (( 14 - Difficulty ) * 100) seconds for the first AI player, and 1.5 times that for the second AI player.
    • Thanks to Wanderer for feedback that inspired this change.

Prerelease 5.021 Hybrid Helper Pie

(Released January 24th, 2012)

  • Added some lightweight extra debug info to GameButton.RenderSelf to help us find the bug that's causing really intermittent null exceptions in there somewhere (we can't reproduce it ourselves, and user reports don't have code line numbers, but this new info should help).
  • Added a note to the context menu about how to get info on what a menu item does.
  • Sentinel Frigates and Zenith Electric Bombers are now considered large enough targets for ships like the Antimatter Starship.
    • Thanks to techsy730 for the suggestion.
  • Now, when a Hybrid is at maximum maturity, additional "experience points" go towards a fund for ruining the player's day. Their first funding goal seems to involve the Dyson Sphere.
    • To clarify: this doesn't mean that they're building or spawning dyson spheres or whatever. Something more sinister.
  • All Hunter-Killers have been shifted up one "tier" in terms of the "cost" the AI has to pay to include them in an exogalactic strikeforce. This should help avoid them happening unintentedly-early in MP games, etc.
    • Thanks to several players for sharing their, um, "experiences" with early/mid-game HKs.
  • Decoy Drone energy cost from 18000 => 1000, to let the unit's use not be obscured by the power cost.
    • Thanks to Wanderer for reminding us of how high it was.
  • Wave size calculation: the minimum base wave size is now 34, regardless of difficulty.
    • The minimum base size of a wave used to be (AI Player Difficulty * 10 * AI Player Handicap). Assuming no positive or negative handicap this generally meant that the first few points of AIP would not increase wave size and the initial wave size was prevented from being embarrassingly tiny.
      • This has served us well but caused the first wave on very high difficulties to be disproportionately difficult such that it's a punishing puzzle to survive the first 7 minutes and after that holding on is significantly easier (though still very tough) because then the player has had more time to actually build initial defenses and so on. It's better for the first wave to not be way more difficult than the second wave on non-trivial difficulties, so the minimum is now just 34. This actually makes difficulties 1-3 harder, but those are so incredibly easy to start with that it's not likely to make much difference.
    • Now AIP increases will actually have an impact on wave size much earlier on difficulties 4+.
    • AI handicap is still factored in (so with 300% it will have a minimum size of 102).
    • The wave size calculation article has been updated to reflect this change, and is a good reference if you want more info.
  • The alternate-victory condition on the Fallen Spire condition has been made a bit more vigorous about winning, since the recently added AI Hunter Killers were refusing to go quietly.
    • Thanks to a number of players for observing that the alternate victory was not always resolving in a timely fashion.
  • Neinzul Preservation Warden spawn counts now scale up with AI Difficulty (the higher of the two is used, this is 1 at diff 7, 1.5 at 8, 2 at 9, 3 at 10) and AI Handicap (again, the higher of the two, negative handicaps don't apply to this), similar to other non-AIP-based threats. Previously it only scaled with the number of human players/homeworlds, and of course the number of human-controlled resource extractors.
  • Added new "Switch To UI" buttons to the Stats window (Scores tab) that allows you to switch your UI to display what another player is seeing.
    • This only works if the target player has the "Allow Team Control Of Ships" control enabled.
    • This is different from the already existing team-control in that:
      • Your resource bar will show the resources for target player, rather than your own.
      • Your planetary summary and so forth will display ships as if the target players ships were "yours"; any ships of your own will show like "ally" ships.
      • The control group keybinds will respond according to the control groups set for the target player, not your own.
      • The CTRLS screen will show (and allow manipulation of) the target player's control options. Yes, that's a lot of power, and some additional "permissions" may prove necessary. But in general: please cooperate :) If it's a problem, just don't use allow-team-control.
        • To clarify: this is options like focus-fire, auto-frd, etc. None of this has anything to do with what keys/buttons are mapped to what commands, that's all local to each machine and doesn't change regardless of whose interface you're looking at.
      • In general, the game's UI should work just like the target player's UI.
    • All that said, this would be somewhat limited in usefulness, were it not for the next feature in these notes.
    • This is in need of a lot of testing to make sure it works right, so don't be surprised by bugs, just report them :)
  • Added new human player role: "Helper" (probably not the best description, but it's more than "Observer", which is the usual term for a non-playing "player").
    • Currently the only way for a player to get into this role is:
      • Host opens "Manage Players" menu.
      • Host sets a previously unused player slot to:
        • Name = profile name of the player who wants to join as an observer/helper
        • Change "Disabled" to "Active"
        • Change "Role: None" to "Role: Helper"
      • Host clicks "Save"
      • The player who wants to join as an observer/helper connects and joins the game.
    • A player in the "Helper" role has no (and cannot be given) units, metal, crystal, energy, or knowledge. More generally, they have nothing in the game.
    • However (and the resource bar tells them this, in lieu of an m/c/e/k display) they can use the new "Switch To UI" buttons on the Stats screen to "switch" to another player who has the "Allow Team Control Of Ships" control enabled, and then can play normally as if they were connected as that player.
    • Also, they can simply observe the game as they have the same vision as the other human players.
    • These "Helper" players do not provoke extra waves or other increased threats normally associated with a multiplayer game.
    • Some possible uses of this feature:
      • If you want to play a game with other people but want to play against a single-player level of challenge with a single-player level of resources, albeit with more hands helping to control (and micromanage, if desired).
      • If you want to let someone simply watch a game without impacting the balance at all.
      • If you want to help someone learn some part of the game; they can play and you can jump in or out as needed.
    • Like the switch-to-ui feature, this is in need of a lot of testing to make sure it works right, so don't be surprised by bugs, just report them :)
  • Neinzul Youngling Tigers:
    • Time-to-live from 2 minutes => 4 minutes, which is the same as other youngling types.
    • Metal and Crystal cost from 50/50 => 40/40.
    • Base Armor Rating from 300*mk => 600*mk.
    • Base Health from 11k*mk => 13k*mk.
    • Thanks to chemical_art for suggesting/inspiring these changes.
  • Neinzul Youngling Vulture:
    • Metal and Crystal cost from 50/50 => 40/40.
  • Spire Teleporting Leech:
    • Base Energy Cost from 400 => 200.
    • Base Metal Cost from 2200 => 1200.
    • Base Crystal Cost from 800 => 500.
  • Science Lab MkII:
    • Base Health from 120k => 500k.
    • Base Armor Rating from 1500 => 5000.
    • Now has cloaking.
    • Long story short: they're still more expensive than MkIs, but now they actually are significantly easier to keep alive in dicey situations than MkIs.
    • Thanks to Hearteater and others for inspiring this change.
  • AI Superfortress:
    • Base health from 750 million => 450 million. This brings it from 5*human-version to 3*human-version, putting it in line with the other fortresses.
    • Health regen halved.
    • Thanks to several players for pointing out that superforts had not been changed in line with the other fort types.
  • AI Fortress I/II/III: health regen halved.
  • Fixed a longstanding bug where the galaxy-nav code of AI-ally Dyson Gatlings was getting distracted from its main purpose.
  • Ships that generate attack (munitions) boosts now show the magnitude of the boost in the tooltip, not just the range.
    • Thanks to SpaceBrotha for the question that reminded us that this info wasn't directly displayed anywhere.
  • Ships that are not immune to attack boosting but have a attack-boost-ceiling below the default (which is 4, i.e. 5x or 500% of normal damage) now display their maximum receivable boost in their tooltip.
  • Higher mark Hybrid Drone Spawners now spawn drones more quickly in addition to being capable of spawning higher mark drones (a mkIV drone spawner still only spawns mkI drones for a hybrid at the first maturity level, and so on).
  • Hybrids: second-stage and third-stage maturity now takes less time (about half what it used to, still longer than first-stage), as previously most hybrids died either before or during the first stage.
  • Attack Hybrids now use a variant of the behavior the standard AI free (threat) ships use to avoid charging a human planet with insufficient firepower. Combined with other hybrid changes in this release this may result in hybrids being a lot harder (and/or a lot more annoying) than they used to be. Which may be for the best, but feedback is welcome :)
  • Hybrids will no longer try to take Spire Mini-Rams as drones, as generally melee drones don't work that great.

Prerelease 5.020

(Released November 3rd, 2011)

  • Fallen-Spire city-provoked exogalactic strikeforces "buildup" rate (this only impacts the time between attacks, not their size or composition) redistributed a bit:
    • Spire City Hubs now generate 1/4 the "aggro" they used to.
    • Spire Shard Reactors, Habitation Centers, and Shipyards now, instead of generating zero "aggro", generate 1/8th what the Spire City Hub used to generate.
    • So a city with all 6 building slots taken up causes exactly the same amount of buildup as before.
    • But the advantage is that if your cities get really beat up in an AI attack and you lose city structures you have more time to rebuild before the next exo. Not exactly smart of the AI, but the alternative is often a game that is fundamentally lost but just a matter of time.
    • Thanks to chemical_art for inspiring this change.
  • Youngling Nanoswarm:
    • Fixed bug in targeting logic that was making it focus on single targets when the intent was that they would aggressively spread themselves out across all available targets. The new behavior still doesn't reach quite the desired behavior (they still tend to only spread out over a subset of the available targets) but it's still a significant improvement. Hopefully more can be done later.
      • Note that this overrides the Non-Sniper-Focus-Fire control; there's very little reason one would ever want these the auto focus-fire since they do so very little damage. Of course if you really want a bunch of nanoswarms to all attack the same target you can give them a normal attack order.
    • Explosion range from 200/225/250/275/300 => flat 1000.
      • They still only hit a max of 3/5/7/9/11 targets when they explode, so this makes it more likely that they'll actually get multiple hits.
  • AI Fortress health from 6x human fortress equivalents => 3x human fortress equivalents.
    • Previously it was easy to take out an AI Fortress with just bombers (and other polycrystal stuff, since fortresses can barely scratch the paint on polycrystal) but it could take a really long time. We want the fortresses to be challenging but not in the "how long do I have to wait before it dies" sense. Hopefully we can find some other more interesting (and not very time consuming) way of making them more challenging.
    • Thanks to many players for weighing in on this subject.

Prerelease 5.019

(Released October 5th, 2011)

  • Fixed a divide by zero bug in the previous version.
    • Thanks to Fleet for the report.

Prerelease 5.018

(Released September 30th, 2011)

  • Spirecraft Ion normal shot damage from 700 => 14000, and armor piercing from 0 => Max.
    • Previously their damage was just token, but this brings them up to roughly the DPS of the Spirecraft Siege Tower (which, for reference, also has max armor piercing), but can't target anything that's immune to insta-kill (which is basically anything bigger than a fleet ship). The result is that a cap (8) of MkI Spirecraft Ions is capable of doing well against a single cap of even MkV fleet ships unless those fleet ships have a bonus against them (bombers, chameleons, raiders, IRE's, etc), and so on. In general, a lot of these together can put some serious hurt on fleet ships (particularly low health ones) even when they can't insta-kill.
    • Related note: since their seconds-per-salvo is higher on the lower cap scales, and since their shot damage now actually matters, and since just about everything they can target scales with the caps, their damage will now be scale upward on the lower caps.
    • Updated the tooltip, which is reproduced here since it probably helps understand what we're doing here:
      • Like Zenith Ion weapons (which AI Ion Cannons use), Spire Ion weapons insta-kill most ships with a mark level equal to or lower than its mark value, and cannot fire at all on ships immune to Ion weapons (i.e. immune to insta-kill). Unlike Zenith Ion technology, these ships are mobile, much shorter-ranged, and actually do decent damage to higher mark ships.
  • Humorously, Ion Cannons, Core Warhead Interceptors, and Orbital Mass Drivers were previously not immune to insta-kill. They now are.
  • Added to the Dyson Gatling tooltip to reflect the lack of ability to shoot at Mark V targets.
  • If an AI player has a positive handicap that is now factored into that game's TotalSpecialDifficultyModifier which is in turn used for determining the total "population cap" of Hybrids in a game with them on, and also factors in to the budget multiplier for exo waves. Negative handicaps on AI players have no effect, and the higher of the two AI handicaps is used if they're not equal.
  • Added a new ability to the Spirecraft Attritioner in hopes of making it more generally useful. From the new tooltip:
    • One unique side effect of Spire attrition technology is that when an enemy ship is destroyed by any cause all its allies (that aren't immune to attrition) take a certain percent of that ship's maximum health as feedback damage. This feedback damage is cumulative with multiple Spirecraft Attritioners and higher mark attritioners cause a higher percentage, but this feedback damage is divided evenly across all affected targets and thus does not greatly damage any one target.
    • Basically, this functions as a small boost to overall fleet dps (averaged out over time), and thus makes the attritioner useful in short engagements where previously its contribution would have been minimal.
    • Current percentages are 0.5%/1.0%/1.5%/2.5%/5.0% for the 5 marks of attritioner. Also, this effect does trigger on enemies killed by attrition/feedback (otherwise it motivates micro to make sure a triggering-source kills big targets). In our tests this has not seemed overpowered though it is likely that further balancing will be needed. Bear in mind that mkV attritioners require the extremely rare Titanite, and mkIVs require the not-much-more-common Adamantite.
    • Thanks to Hearteater and many other players for weighing in with feedback that led to this change.

Prerelease 5.017

(Released September 12th, 2011)

  • AI Hunter/Killers are now eligible to be chosen for exogalactic battlegroups. The MkI is considered one notch above the Armored Golem cost-wise, and proceeding up from there. For anyone who remembers the slaughter those things could perform before, their number of shots-per-salvo has been halved but their health has been doubled.
    • chemical_art will probably regret making the suggestion that inspired this.
  • Fixed an (apparently) rare array-index-out-of-bounds error in the buy-menu "tooltip" window.
    • Thanks to Cyborg for the report.
  • Added a second confirm step when scrapping Spirecraft mining enclosures (since scrapping them does not give you back the asteroid from which they came) and the player home forcefield generator (since it cannot be rebuilt).
    • Thanks to Cyborg for inspiring this.
  • Strong forcefields (the same ones that had the blocking effect in 5.015) now have their blocking effect back.
    • The "cannot use a wormhole covered by a hostile forcefield" rule is still in to prevent the bug with teleporting stuff "sneaking" through.
    • The collision detection between blocking forcefields and hostile ships has been refined to include a more precise check for ships that appear to be colliding to the coarse check we've used for a while. This is because the coarse check was making it a lot more likely that AI ships would get "stuck" on a single human forcefield that just happened to be in their way. Now they should slide around a lot more readily.
      • Note that you can still set up blocking walls of multiple forcefields and catch AI ships in a pocket, etc. We aren't thrilled by this as it's basically exploiting the simplistic AI movement logic (it has no pathfinding, just straight line to target, because anything else is cpu-prohibitive for this game) but there are actually more efficient ways to slow down most serious AI assualts (grav turrets under ffs, logistics stations, etc) so this particular "exploit" isn't really breaking the challenge. Maybe one day we'll make it so when the AI detects a blocking wall it retaliates by initiating some gargantuan pathfinding routine and thus churns your processor and framerate to a halt. For now, knock yourselves out :P
    • Thanks to everyone who chimed in with feedback on this!
  • Hardened Forcefields:
    • Now shrink with damage like normal forcefields, since the rigidity was making them much more likely to actually die rather than diminish to a point where the AI left it alone, and since they would make the "blocking walls" tactic even more effective than it used to be.
    • Armor from 1 million to 500k, to expand the set of armor-nemesis things that can actually get through it. If this feels too low, let us know!
  • For the ships listed below, armor piercing increased from "really high" (6 figures) to 999,999. They're really supposed to just flat out get through any armor, excepting maybe some of the ships so large we don't mention them in release notes because it would be a spoiler.
    • Zenith Polarizer
    • Spire Armor Rotter
    • Youngling Vulture
    • Youngling Nanoswarm
    • Raid Starship
    • Lightning/Armored/EMP/Tachyon-warheads
    • Botnet Golem
    • Devourer Golem
    • Sentinel Frigate
    • Spire Blade
    • Spire Gravity Drain
    • Spirecraft Siege Tower
    • Sniper
    • Electric Shuttle
    • Lightning Turret
    • Sniper Turret
    • Spider Turret
    • And a variety of lesser known but related types.
  • Fixed a null exception that could happen rarely when a unit was looking for the next wormhole to move to while moving from planet to planet.
    • Thanks to TechSY730 for the report.

Prerelease 5.016

(Released September 6th, 2011)

  • Preservation Wardens previously did not scale at all when there were multiple human homeworlds and/or multiple human players. Now each time the game spawns a warden it instead spawns 1 warden per player/human-homeworld (specifically, the number of human players or the number of human homeworlds, whichever is greater).
  • Human Forcefield Generators:
    • Ship-cap from 9/5/5 => 10/6/6
    • HP from 14M/30M/56M => 20M*mk.
    • Metal cost from 4k/6k/12k => 4k*mk.
    • Crystal cost from 19k/35k/70k => 20k*mk.
    • Energy use from 3k/6k/10k => 3k*mk.
    • Build time (seconds) from 240/300/480 => 120 + (120*mk) (240/360/480).
  • Added new unlockable support unit type: Hardened Forcefield Generator MkI-III. Basically the same as normal human generators except:
    • 1/4th the HP.
    • 1,000,000 Armor Rating instead of zero (this effectively reduces all incoming damage to 1/5th its normal power, unless the attacker has extremely high armor piercing or very high damage-per-shot).
    • They do not shrink as they take damage, making it easier to know how long a given target will be protected, etc. On the other hand this may make it harder to tell "at a glance" how long the generator has left to hold, so we might need to do something else here.
    • The first mark is not available by default, but costs 1000 knowledge (mkII and III are 2000 and 4000 knowledge each like the normal line).
    • Thanks to Lancefighter for the suggestion (some time ago) that led to this.
  • Due to very widespread feedback that ion weaponry is very underpowered, all Ion Cannon and Spirecraft Ion Blasters now fire 4 shots per salvo instead of 1. Other changes are likely to follow, we'll see how it feels to players.
  • Put in a fairly radical change to the base forcefields, but bear with us on this -- if it's not workable we'll take it out. And really, in most senses this should be equivalent to the way that things were before, but more CPU-efficient as well as fixing one bug and one exploit. With that out of the way:
    • Change 1: Made it so that strong force fields no longer block enemy ships from passing through them -- on either side. So if you have a forcefield in the way of the AI, or they have a forcefield in your way, your ships can pass right through them with no problem. As with weaker forcefields, the thematic explanation is that you're going around the forcefield in the Z axis, which makes sense. This change has no bearing on the protection of ships under the forcefield; ships are just as well protected now as ever.
      • The exploit in question was a problem with players being able to block enemy ships due to those ships sometimes "sticking" against the force fields. The reason ships would stick is because of the coarseness of the distance check we were using, which was coarse so not to take up so much CPU. Now enemy ships can just fly past your forcefields unimpeded if they're heading to targets beyond them, which -- with one exception, see below -- is what we've always intended in the first place.
      • This is also where we derive our CPU gains from, as normally each ship had to check its relative position to all enemy strong forcefields on a planet every time its position changed even a little. This isn't killer, but in light of the bug and exploit relating to strong forcefields
    • Change 2: Made it so that when a strong forcefield is covering a wormhole, no non-forcefield-immune enemy ships can go through that wormhole from the side the forcefield is on.
      • Players have been using forcefields to do this very thing for a long time, and we think that's great. However, this was taking advantage of ships not being able to move in to actually physically reach the wormhole, and that was thus not working very well for teleporting ships, which would teleport right to the center of the forcefield, then get caught in the wormhole before the forcefield could push them back out. This is the bug we referenced above, and it was very much not in players' favor (unlike the exploit), and this set of changes now fixes it.
    • NET EFFECTS:
      • 1. Players can't use forcefields to interrupt enemy travel on the planet they are on, nor can the AI.
        • Some players would set up forcefield clusters to trap enemies inside when they come through wormholes, but that was already error-prone because enemies would tend to pop out to the other side if the forcefields weren't positioned precisely right. These players should instead put a single forcefield (or all their forcefields, if they really prefer) on the enemy side of their wormhole and that will now provide much better protection than their older method ever did.
      • 2. The AI can't slip teleporting ships past your forcefields over wormholes unless those teleporting units are also forcefield immune, which should be a huge boon to players in games with teleporting enemies.
    • Thanks to mindloss for most directly inspiring these changes, although we've been mulling it for a while based on cumulative feedback.

Prerelease 5.015

(Released August 29th, 2011)

  • Previously, the recently added ActivateHighestEfficiencyLowPowerEnergyReactor and PutLowestEfficiencyActiveEnergyReactorIntoLowPower keybinds were considering reactors that were still under construction. Hamster re-education has taken place (bug fixed).
    • Thanks to Ranakastrasz for the report.
  • Due to widespread feedback that the martyr is very OP, we've drastically increased the asteroid "cost" of building them:
    • Previously Reptite could be used to build 2 MkI Martyrs. Now it cannot build martyrs at all.
    • Previously Pysite could be used to build 4 MkI Martyrs or 2 MkII Martyrs. Now it can only build 1 MkII (can't build MkIs).
    • Previously Xampite could be used to build 4 MkII Martyrs or 2 MkIII Martyrs. Now it can only build 1 MkIII (can't build MkIIs).
    • Previously Ebonite could be used to build 4 MkIII Martyrs or 2 MkIV Martyrs. Now it can only build 1 MkIV (can't build MkIIIs).
    • Previously Adamantite could be used to build 4 MkIV Martyrs or 2 MkV Martyrs. Now it can only build 1 MkV (can't build MkIVs).
    • Note that the units themselves are just as incredibly powerful as before (we really want them to be highly useful), but hopefully this change puts their real cost more in line with their utility and also puts a saner limit on the total number the players can have in a game. More changes may follow if necessary.
    • For reference, previously the total number of martyrs that could be produced from all asteroids in an average 80-planet galaxy was about 2200 on average (so someone holding 15% of the galaxy might reasonably field 220 over the course of the game, if they didn't use many other spirecraft). Now that total-possible number average about 480 (so that same martyr-happy player would probably only have about 48 to use, unless they take more planets).
    • Thanks to the many players who've weighed in on this subject.
  • Zenith Viral Shredders:
    • Simplified the scaling of replication costs (how much damage a shredder has to do to replicate) and made it better at preventing game-breaking swarms of shredders. Now instead of it using a linear multiplier based on the owner's number of shredders on that specific planet, it quadruples the replication cost for every full cap of that mark of shredder owned by that player anywhere in the galaxy (but if they own less than or equal to a full cap, there is no extra cost).
      • So if the mkI cap is 98 (normal cap scale) and you have between 99 and 195 (inclusive) mkI shredders they will have to do 4x as much damage to replicate as normal. If you have between 196 and 293 (inclusive) mkI shredders they will have to do 16x as much damage to replicate as normal. And so on (maximum multiplier is 1024 to avoid arithmetic overflow; at that point a mkIV on low caps would need to do over 376 million damage to replicate).
    • Base Energy Use from 100 => 50 (note: all mkI types use half normal energy).
    • Replication-created shredders now copy the FRD, Attack Move, and any unit commands (movement waypoints and whatnot) of their "parent". Note that they already copy the control groups and "am I currently selected" status of their parent.
    • The end result of all this should be that if you play your shredders well you'll be able to maintain maybe 2 or 3 caps worth of them (a pretty significant advantage over other bonus ship types) but it's going to be difficult to get into the really absurd numbers. On the other hand, maintaining that swarm won't cost as much energy as it used to and it should require less micro due to the commmand copying.
    • Thanks to the players who've told us about their massive abuse of absurdly large shredder swarms.
  • For a very long time it's been possible to ward off almost any amount of damage through sufficient micro of a pile of forcefield generators and engineers (to repair the ff's as they collapse within the protection of other generators, or go on low power mode, or are being newly built). While ff's are supposed to be extremely helpful in protecting stuff, it wasn't intended that they be able to do so indefinitely while under constant attack. So:
    • When a forcefield is damaged by enemy fire, all allied forcefields whose fields are in contact (or very close to it) with the damaged ff will take 1 point of damage from the energy conducted along the surface of the field. The damage itself is inconsequential since the ff's have millions of hp, but it will trigger the "cannot be repaired less than 6 seconds after being damaged" logic. This also applies to forcefields currently under construction or in low-power mode. So it won't be possible to repair some forcefields in a ff-pile while others in the same group are under fire.
    • Forcefield generators now cannot be assisted during construction if they have been damaged recently.
    • When a new forcefield is placed for construction, if it is in near any allied forcefields (low power or not) that is currently unrepairable due to recent damage, the newly placed forcefield inherits the longest assist-delay present among those neighbors. So it won't be possible to speed-build new generators under other fields that are currently under fire.
    • This also applies to all the "shield bearer" and module type shields.
    • If this leaves some situations unreasonably hard other changes can be made to compensate, we just wanted to close this "micro to dodge anything" loophole.
    • Thanks to mindloss for most recently bringing this up.
  • Put in a small code change that might lead to more efficiency during really large battles with a lot of things being drawn as well as a lot of sound effects being played. It might also make no difference, but it's a good precaution either way; our tests so far have not really been clear as to whether there is any benefit.

Prerelease 5.014

(Released August 4th, 2011)

  • Starship costs tweaked around a bit:
    • Bomber starship metal cost reduced from 120k to 80k.
    • Fleet starship metal cost reduced from 60k to 40.
    • Siege starship crystal cost reduced from 120k to 80k.
    • Riot Control starships crystal cost reduced from 80k to 60k, and metal cost reduced from 30k to 20k.
    • Enclave starship costs reduced from 30k metal and crystal to 20k each instead.
    • Thanks to Lancefighter for suggesting.
  • Zentih SpaceTime Manipulator energy costs reduced to 20k from 60k.
    • Thanks to Lancefighter for suggesting.
  • Removed all mention of the AIP costs on the Zenith SpaceTime manipulator text.
    • Thanks to Zair for reporting.
  • Siege Starships renamed to Antimatter Starships for the sake of clarity, and given the following new description text:
    • This starship is the best capital killer in your basic fleet: excellent against starships, guard posts, guardians, most turrets, and other large ships like golems or spirecraft. It is so specialized that it can't even fire upon most small mobile targets. That said, many targets (forcefields, most fortresses and command stations, etc) are specifically protected against its antimatter bombs.
    • All in-game references to them (tutorials, etc) have been adjusted.
    • Thanks to the several dozen players who weighed in on our poll for how to rename these!

Prerelease 5.013

(Released August 1st, 2011)

  • Gravity Drills under player control can now be scrapped by that player.
    • Thanks to Wingsofdomain for suggesting.
  • Stealth Battleships previously had a bonus of 1.4x against artillery hulls. Now they don't, making them not so overpowered against things like siege starships.
  • Speaking of siege starships, they have now gotten doubled health -- making them no longer "glass cannons," which they haven't been in a while anyhow. And making them substantially more useful in general.
  • All marks of Spire Stealth Battleship now have an AIPerPlanetShipCap of 8 (only applies to not-freed ships). This is an experiment brought about by continuing feedback that the per-guard-post caps are insufficient forkeeping the populations down to a level that doesn't make the game way harder when the AI happens to roll SSBs as a bonus type. This won't impact their numbers in waves and other offensive uses, but one thing at a time.
  • Riot Control Starships mark I are now unlocked from the start of every game. This should help with uncertainty that players would feel about whether or not they would be useful in a given scenario. Now players can try them out and see; and if they are useful and they want more, then the mark II and mark III versions are effectively 1500 knowledge cheaper now, since they no longer have the mark I prerequisite.
  • Mark II scout starships now cost 250 knowledge to unlock instead of 1500. Mark III are now 2000 instead of 3500, and mark IV are now 3500 instead of 4500. This brings the mark II down into the realm of "candy tech," and makes the III and IV variants not so cost-prohibitive that nobody uses them.
  • Mark I gravity turrets are now 750 knowledge to unlock instead of 2000, making them a lot more feasible for players to experiment with as well.
  • Zenith SpaceTime Manipulators no longer have an AI Progress of 1 on their death; that made them very difficult to use. They now cost 2x more energy to use, however (from 30k to 60k). The AI also no longer cares about them at all in terms of extra priority on killing them. And lastly, they now cost 1750 knowledge to unlock instead of 1000.
  • Mark II scouts now cost 500 knowledge to unlock instead of 1000. Mark III scouts now cost 2250 instead of 2000, making the entire scout line only slightly cheaper.
  • Completely rebalanced armored warheads, as they have been the unused warhead for too long:
    • They now cost 50k energy to run instead of 2.5k.
    • They now cost 10x more metal and crystal to create.
    • They now cost 2/4/6 AIP rather than 10/15/20.
    • They now have the same (much lower) attack stats of their lightning warhead counterparts.
  • The attack range of mark III lightning and armored warheads has been increased by 250 -- making them not so much smaller than the mark II versions of the same.
  • Some starfield changes:
    • Slightly improved the draw efficiency of the starfields by reusing a single mersenne twister rather than initializing a new one every frame.
    • Changed it so that there is only now one layer of starfield, rather than three. This makes for a more cohesive style with most of the starfields, as well as making the sky not QUITE so incredibly dense with stars. This also removes the parallax effect from the stars themselves, which made the foreground stars really look more like dust than stars.
      • This also is a small boost to performance, and a slight reduction in VRAM usage per frame. On most computers it won't make a substantial difference, though.
    • Added in a parallax effect to the nebulae, making it so that they now have a slight motion and will wrap around the screen view if players scroll enough.
    • Thanks to annikk.exe for inspiring these changes.
  • Added a bit more command-queue-related debug info in for hitting F3 and hovering over ships.
  • Fixed a bug that would cause ships to sometimes ignore their wormhole orders to instead stay and fight when they have a target. This was most noticeable with astro trains since they are never supposed to stop to fight, but it actually was affecting all AI ships since sometime prior to 5.0 most likely. Possibly as far back as 4.0. This had serious implications to the AI's ability to effectively retreat; the AI should be a lot more swift-footed now, while still getting in pot-shots when it decides to leave.
    • Additionally, a potential desync was discovered where players that were using the F3 debug menu and hovering over ships might cause a desync in multiplayer. Fixed that.
      • Fixing this also reduced the per-ship memory footprint by about 8 bytes, which we're always pleased to do.
    • Thanks to Hearteater for reporting.
  • Made Cloaker Starships mark I knowledge-free now, instead of costing 1k knowledge. This helps to compensate players a bit for the generally-increased difficulty of the Zenith expansion.
  • Same with the Neinzul Rnclave Starships mark I. They were 2k knowledge, but now they are knowledge-free.
  • Mercenary Neinzul Enclave Starships, which would now be pretty well pointless, have also been revamped. Now they are the equivalent of the mark II Neinzul Enclave Starship, rather than the mark I starship. This is very powerful, but they are also now limited to only a single ship in their shipcap, rather than 6 ships.

Prerelease 5.012

(Released July 21st, 2011)

  • Added new "Activate Highest Efficiency Low Power Energy Reactor" KeyBind, InGame context, no default binding.
    • Searches through all your energy reactors that are low power, finds the one with the highest efficiency (accounting for penalties from multiple of the same mark on the planet), and takes it out of low power.
  • Added new "Put Lowest Efficiency Active Energy Reactor Into Low Power" KeyBind, InGame context, no default binding.
    • Searches through all your energy reactors that are not in low power, finds the one with the lowest efficiency (accounting for penalties from multiple of the same mark on the planet), and puts it into low power.
  • Fixed bug where the command-station foldouts each player got on each ally's planet were not executing galaxy-wide or per-planet controls (like Auto-FRD, auto-build engineers, auto-build energy reactors).
    • Thanks to many players for pointing this one out.
  • Added new galaxy-wide control toggle: "Prevent Auto Build On Ally Planets".
    • If this toggle is checked, it prevents your galaxy-wide auto-building controls (for stuff like engineers, rebuilders, and energy reactors) from taking effect on ally planets.
    • Your per-planet auto-building controls ignore this toggle.
  • Added new galaxy-wide control toggle: "Allow Ally Rebuilders To Rebuild My Remains".
    • If this toggle is checked, ally rebuilders will automatically consider the remains of any of your units to be valid rebuilding targets. Note that starting the rebuilding process costs no resources, the rebuilt unit is yours, and the rest of the rebuilding process is paid for like normal construction.
    • Also, please note that if an ally is using the "Engineers Do Not Assist Allies" toggle, their rebuilders will not automatically consider your remains regardless of your controls.
    • Thanks to lanstro for inspiring this change.
  • Fixed bug where Core Starships were not immune to translocation.
    • Thanks to Toll for the report.
  • Fixed some old tooltips referring to the expansions tab of the settings screen to correctly refer to the "License / Expansions" window (which is accessible from the main menu).
    • Thanks to FroBodine for the report.
  • Fixed a bug that has been causing astro-trains to not be able to attack for the last six months or so.
    • Thanks to Prezombie, Hearteater, and ArcDM for reporting.
  • Ships that have "temporary invincibility" (such as Core Shield Generators that are on planets you don't control, or AI Core Guard Posts and AI Core Command Stations when there are Core Shield Generators still active, or AI carriers when there are more than 2k AI ships active on their planet) now show up with a new angry red/yellow ship-style force field that is visually marking them as invulnerable. The actual mechanics haven't changed, but now there is a more clear visual indicator of the pre-existing logic.
    • Thanks to Elok for suggesting.

Prerelease 5.011

(Released June 21st, 2011)

  • Fixed rare null exception that could happen when changing control groups.
    • Thanks to leb0fh for the report and save.
  • Spire Civilian Leaders are now no longer giftable, to avoid a bug whereby gifting them back and forth would repeat the AIP decrease.
    • Thanks to dnatabar for the report.
  • Added a new "Galaxy-Wide Select Own Science Lab" key-bind that works in both planet-view and galaxy-view (like go-to-flare does) and defaults to Ctrl+T.
    • If you are viewing a planet and you own science labs on that planet, this drops any current selection you may have and selects one of those science labs (note that it does not center the viewport, there's another key for centering on the selection if you want that).
    • Otherwise, if you own science labs on another planet in the galaxy, this drops any current selection you may have, switches your view to one of those planets, and selects one of those science labs on that planet, and centers the viewport on that lab.
    • Otherwise (if you own no science labs), this does nothing.
    • Note that this only works with your science labs, it completely ignores science labs of allied players. Also, it does not attempt to rotate through eligible selections the way other selection functions do.
    • The reason for all the caveats of what this doesn't do is that its SOLE purpose is to let you access the tech-research menu from anywhere in the galaxy without having to know specifically where to find a science lab.
    • Thanks to TheDeadlyShoe for the suggestion that inspired this.
  • Fixed a bug where a self-destructing aoe weapon with a limited number of secondary targets (autobomb, nanoswarm, etc) would fail to do any damage to anything in some cases where only the main target was hit.
    • Thanks to Nalgas for the report and save.
  • Added "Galaxy Layout" item to top-level context menu (when showing the galaxy map). Clicking it shows these options:
    • "Official Layout" - Switches your galaxy view to the official layout, meaning the map as actually generated.
    • "My Layout" - Switches your galaxy view to your alternate layout. If you have not made any changes, this will look like the official layout.
      • While looking at your alternate layout you can move a planet around by holding shift, left clicking the planet, and dragging it aroud while holding the left mouse button.
    • "Player 1 Layout" - Switches your galaxy view to this player's alternate layout.
      • And 7 others just like it for players 2 through 8.
  • Fixed bug where copying in your global controls from disk could lead to building engineer IIs and IIIs without the required tech.
    • Thanks to Ranakastrasz (and others) for reporting this.
  • Added new global control toggle "Prevent Warhead FRD".
    • If this toggle is checked, it prevents your warheads from entering Free-Roaming-Defender mode even when something like the 'Auto-FRD Military' toggle or a slip of the finger when giving a move order would set them to FRD.
    • If you can imagine a nuclear warhead attached to a roomba, you can imagine cases where you would use this toggle. And cases where you would not.
    • Please note that this will not take any warheads already in FRD out of it.
    • Thanks to Ranakastrasz for inspiring this addition.
  • Fixed a bug where Defender games were always being recorded in the high-score list as lost.
    • Thanks to Night for the report and save.
  • Fixed a bug where lightning and armored warheads were following the unit-cap-scale.
    • One of the side effects of this is that some Neinzul Rocketry Corps silos (only the lower-mark ones, and only on low or normal caps) were "scaling down" to a maximum internal capacity of zero, effectively making them Neinzul Rocketry Bricks. No longer.
    • Thanks to ArcDM for the report and save that led to this being discovered.
  • The "Hostile Warheads on (planet name)" alerts are now shown for all planets you have scouting on, not just human-controlled planets.

Prerelease 5.010

(Released April 14th, 2011)

  • Spire Blade Spawners:
    • Now have an attack again (not having an attack was causing all kinds of bugs and unintended behaviors), with a base power of 1000 per shot, 8 shots per salvo, 2 seconds per salvo, and effective range of 6000 (for reference, that's the same as the spire stealth battleship except it's 25% the base power and 1000 lower range).
      • Notably, this should make the BaseAIPerGuardPostShipCap flag work correctly again for them (it's set to 1 for them).
      • But since they were unable to guard stuff in the past due to zero attack, to correct old saves the AI ones just being completely stripped out when loading something from 5.009 or earlier. Human ones are not affected.
    • Have the new DoesNotMoveToPursueUnlessOrderGivenByPlayer flag, which prevents human ones from chasing an auto-targetted target (in FRD or not). Hopefully this will deal with the complaint that lead to the original removal of their guns.
    • Thanks to Sunshine! and techsy730 for reports and saves of the bypassing-caps problem.

Prerelease 5.009

(Released March 28th, 2011)

  • The health of the non-core AI Spire Shield Spheres has been reduced by half (for all five mark levels of the non-core versions).
    • Thanks to Vinraith for suggesting.
  • Fixed another rare desync that would occur when the "ship to kill" logic was loaded from savegames that were saved during a big battle. Not many people save DURING a big battle, so this one didn't come up much.
    • Thanks once again to Fleet and Tssbackus for reporting, and for their patience. They have all the bad luck!
  • Added in a new "aggregate hash" that sums up a few key integer stats from non-cold-storage ships (location xy, destination xy, is destination settled, "ship to kill" object number), to provide a sort of early warning system against desyncs.
    • This makes the game much likely to actually desync quicker when there is a desync going on under the hood, which will make them easier to find, and hopefully also easier to reproduce when a player does run into a desync.
    • This adds a bit to the CPU load, but since it's all addition, it's nothing particularly notable, which is one of the plusses of this.
    • We are, of course, hoping not to have to use this any time soon. But in the event that Fleet and Tssbackus get unlucky again, this should help eliminate any ambiguities that might otherwise come up.

Prerelease 5.008

(Released March 25th, 2011)

  • Zenith SpaceTime Manipulators can no longer be swallowed or regenerated.
    • Thanks to FunnyMan for suggesting.
  • Human-allied zombies and minor factions were not being properly limited in their pool of planets to fix, thanks to a typo in their logic. It should now be fixed.
    • Thanks to techsy730, Vinraith, and zoutzakje for reporting.
  • Zenith Electric Bombers:
    • No longer use scaled caps (due to the 0.1 ship cap multiplier, that can make the additional /2 or /4 from normal and low caps cause a more significant truncation than is desirable).
    • Event attack cost (used for exogalactic strikeforce computations) tiers increased from "Medium Corvette" through "Heavy Frigate" to "Light Frigate" through "Medium Destroyer", since the previous placement was putting mkIII zelecs at the same place as a mkV bomber. It's not a goal to balance the event attack costs terribly precisely, but that was a bit excessive.
    • Thanks to Garthor for bringing the odd cost issue to light.
  • Sentinel Frigates:
    • Event attack cost (used for exogalactic strikeforce computations) tiers increased from "Heavy Corvette" through "Light Destroyer" to "Light Frigate" through "Medium Destroyer".

Prerelease 5.007

(Released March 24th, 2011)

  • AI ships that are spawned in response to saboteurs, such as the human mark III science lab, are now zombie bots.
    • Thanks to Irxallis for suggesting.
  • Fixed a bug with zombie or minor faction electric shuttles, where the shuttles would just sit there. This also should improve the behavior for any ships that explode (including warheads, etc) when controlled by a minor faction, when zombified, when in FRD or attack-move in general, and possibly when in the hands of the AI in some circumstances.
    • Thanks to Burnstreet and BobTheJanitor for reporting.
  • Previously, zombiefied ships were being bound by player ship caps, but they should not have been. Fixed.
    • Thanks to Dalden and Ozymandiaz for reporting.
  • Previously, allied minor faction and zombie ships would just patrol around player planets endlessly, which was helpful for defense, but problematic for two reasons: first, that it could cause massive amounts of slowdown after many hours of them stacking up, and second, that it could cause massive buildups of AI stalkers, who never dare to attack the planets with so many defenders, which leads to something akin to stalemate situations.
    • Thus the allied minor faction and zombie logic has been adjusted as follows:
      • Neutral planets are now considered the same as allied planets, and the ships will patrol to them like any others.
      • If there are more than about 100 of AI threat ships on an adjacent planet, the ships will also patrol to that planet to clean them off.
      • If the human-allied team has more than a token military force (more than about 10 ships) on a planet, then these ships will patrol to there, to help aid in that attack.
        • This allows for small raids to still happen with raid starships or whatever without assistance from these minor factions, but it enlists their help for larger-scale engagements.
    • Thanks to many players for weighing in on this, including Burnstreet, Draco18s, TechSY730, vinco, BluePhoenix, and ArcDM for reporting various things related to this, with various suggestions.
  • Dyson Gatlings are now immune to paralysis attacks.
    • Thanks to Sunshine for suggesting.
  • Slightly improved the targeting handling when a ship is targeting a teleporting ship that is out of range.
  • Spirecraft Penetrator balance:
    • Mark I moved from pysite to xampite. Mark II moved to ebonite, and now produce two per asteroid. All the other marks not moved around.
    • Penetrator health reduced 8x.
    • Penetrator perma-cloaking replaced with normal cloaking.
    • Thanks to Irxallis for suggesting.
  • Fixed a problem with too-low throttles on minor faction / zombie ships preventing them from even attacking at all in some cases.
    • Thanks to zoutzakje for reporting.
  • The devourer golem is now completely invincible -- it was never meant to be killable in the first place, but recent changes to the game made that so that it was possible post-5.0. Like the dyson sphere, the devourer is more intersting when it is indestructible.
    • Thanks to ArcDM for inspiring this, although I'm not sure if that's what he really was hoping for.
  • Minor factions now shoot low-power ships without prejudice, which means that devourer golems actually will devourer more again.
    • Thanks to ArcDM for reporting.
  • Zenith SpaceTime Manipulators, like forcefields, now have the ability to move very slowly but not to go through wormholes, to allow for better repositioning of them.
    • Thanks to vinco for suggesting.
  • Gifting a ship now copies across its current attack recharge, cloaking recharge, and similar, preventing a few exploits related to that and penetrators in particular.
    • Thanks to Irxallis for reporting.
  • Fixed the bug with two buttons for mark V fighters showing up in the mark V fighter fabricator.
    • Thanks to leb0fh, Orelius, akbr1984, and snelg for reporting.
  • Previously, when command stations were replaced, colony ships and mobile builders were still dying even though they shouldn't have been. Fixed.
    • Thanks to Red Spot and TechSY730 for reporting.
  • Improved the clarity of the colony ship description.
    • Thanks to TechSY730 for suggesting.
  • Previously, when a player was controlling an ally's ships and tried to put that ship into a control group, it would add it to the ally's control group instead of the local player's control group. Having cross-player control groups is not possible without really expanding the control group data structure, which doesn't seem like a good idea to do at the present time, so for the time being allied ships simply won't go into control groups if a player tries to put them in there, at least cutting out the worst of the confusion.
    • Thanks to FunnyMan for reporting.
  • The Zenith Trader previously had incorrect line breaks. Fixed.
    • Thanks to doctorfrog for reporting.
  • Previously, if there were fewer than 30 enemy-to-the-AI ships and none of them were both uncloaked and had attack strength of 0, then the planet was incorrectly being put into cold storage. Now it's only in cold storage if there are fewer than 30 enemy-to-the-AI ships and all of them have full cloaking, which was the intended logic from the start.
    • This should fix some issues with the devourer golem not really doing its thing, and in general some minor faction issues in general.
    • Thanks to Fleet and TechSY730 for reporting related bugs.
  • Previously, adding and removing ships to control groups was way slower than it should have been. In terms of bulk add/removes, it was way, WAY slower than it should have been. This was a past optimization that was not fully optimized -- it had one critical flaw, mainly. This is now fixed, and it has a couple of major effects:
    • Obviously, when editing control groups in bulk, it's hugely improving the speed of that (it could cause "Waiting For Players" messages, before).
    • Unexpectedly, it also makes savegames load in less than half the time they used to. As it turns out, there was a lot of "take this ship out of the control group it already wasn't in" going on in there, and that was just eating performance.
    • Thanks to FunnyMan for reporting.
  • AI Progress reduction messages now show up as light green instead of light red, to avoid being misleading.
    • Thanks to sgt_deacon for suggesting.
  • The radar dampening range of marauders and resistance fighters has been changed to be about 1000 greater than their attack range in all cases, soo that they always have to come into range of their targets in order to fire on their targets. This makes it so that turrets and other fixed-position defenses are not completely powerless against them.
    • Thanks to Draco Cretel for suggesting.
  • Spire Civilian Leader Outposts are now included in the galaxy map filter for Detected AI Progress Reducers.
    • Thanks to Orelius and c4sc4 for suggesting.
  • Spire Civilian Leader Outposts previously did not have their minor faction stance properly set, so they could not be attacked. Now they are properly noted as AI Allies until captured by the human team. They are still direct-only to attack, though, so unless you accidentally mis-click on them your ships won't attack them.
    • Thanks to chemical_art for reporting.
  • Armored Warhead health reduced from over 2 billion to 40 million. This is still a huge amount of health, but they are no longer infinitely survivable. This also fixes a bug where the interface was having an overflow exception and rendering their health as 1.
    • Thanks to rustayne for reporting.
  • When planet-wide EMP or tachyon detonations occur, as from a warhead or an EMP guardian, a chat message is now sent to the human players telling them who detonated what, and where. This message is also clickable. The goal here is preventing EMP guardians from punching QUITE so impenetrable a hole in player defenses without notice.
    • Thanks to KDR_11k for suggesting.
  • Warhead Interceptors have been nonfunctional since slightly before 5.0 of the game (I disabled them, but never did get around to re-enabling them. They should work once again, but I haven't had a test case to work on it to be sure. If anyone has a save with them not working after this version, please let us know.
    • Thanks to Orelius for reminding us of this.
  • The efficiency of gravitational slowing (gravity drains, gravity turrets) has been greatly improved, such that big battles that previously would grind to a halt because of them can now be played at 3x their prior framerate in one test case in particular.
    • One major improvement was to exclude checking of gravitational slowing for ships that can't move or aren't moving at the moment (since they don't need to be slowed!), and the other was to skip redundant gravitational slowing checks for gravitational sources that are the same and which are too close together. This last is very similar to how the speed improvements on the range data display (from way back pre-2.0 days) works.
    • Thanks to rustayne for reporting.

Prerelease 5.006

(Released March 23rd, 2011)

  • Astro Trains are now immune to translocation and gravity effects, since both of those cause more problems for players than they would ever solve.
    • Thanks to Sunshine for suggesting.
  • Adjusted controls window to be more likely to fit within 1024-wide resolutions; previously it was functional but didn't quite fit.
    • Thanks to Balthier for the repot.
  • Double-clicking a profile name in the profile list now selects it, rather than opening it for editing.
  • When a desync is encountered, the clients are now notified of that instead of them thinking it's just a regular waiting for players.
  • FINALLY fixed a long-standing and excruciatingly rare desync that nevertheless was reliably hit by two of our players, Fleet and Tssbackus. Huge thanks to them for their persistence in helping us figure this out. For all the details, here's the mantis issue: http://www.arcengames.com/mantisbt/view.php?id=3077
  • The planetary summary now makes substantially better use of its available vertical space, thus saving horizontal space in many cases.
    • Thanks to gamewarlord777 for suggesting.
  • Guard posts, fortresses, superfortresses, force fields, and exo-shields are all now immune to regeneration from regenerator golems/trains.
    • Thanks to FunnyMan for reporting.
  • AI Motherships are now considered large ships for purposes of bomber starships and siege starships being able to hit them.
    • Thanks to TechSY730 for reporting.
  • When an engineer is repairing a ship, and it was not set to repair that ship explicitly by the player, and it's not in free-roaming defender mode or attack-move mode, it will no longer try to chase the ship it is repairing. Instead it will just find a better target and keep its position. This allows for players to exercise more tight control over their engineers now that engineers have a huge repair range and no longer teleport.
    • Thanks to Sunshine for suggesting.
  • In recent versions, the self attrition time has been reporting a negative time. Fixed.
    • Thanks to Garthor for reporting.
  • When a ship is translocated away from its current location, all incoming projectiles now are also immediately translocated to its new destination, and thus will hit it instead of fizzling. This makes the military command stations a lot less unwieldy.
    • Thanks to KDR_11k for suggesting.
  • Raid starship rebalance, thanks to many players for various suggestions:
    • Raid Starship health has been increased from 1.6 million health * mark level to 2 million health * mark level.
    • The AI now has separate versions of the Raid Starships, which have only 1/2 the health of the human counterparts.

Prerelease 5.005

(Released March 17th, 2011)

  • Savegames from 5.004 were accidentally all uncompressed, though flagged as compressed, which caused them to not be able to be read back in. Two fixes:
    • First, fixed the actual cause of this, so new savegames in 5.005 will be saved properly.
    • Second, updated the load savegame process so that it can read even the "corrupt" saves from 5.004 without issue.
    • Thanks to SpaceJelly for reporting!
  • Spire Blade Spawner:
    • Ship cap from 0.05 of normal to 0.03 of normal (in practice, from 9 to 5 for mkI). Note that this impacts AI usage as well as human.
    • BaseAIPerGuardPostShipCap from 2 => 1.
  • Spire Gravity Drain:
    • Grav range from 3000*mk => 8000 (flat).
  • Spire Gravity Ripper:
    • Attack power from 1000*mk => 2000*mk.
    • Seconds-per-salvo from 1 => 2.
    • So basically the gravity ripping effect is being nerfed to 50% of what it was, and the normal attack is better against armor. We'll see where to go from there.
  • Spire Miniram:
    • Ship cap multiplier from 0.25 => 0.20.
  • Spire Stealth Battleship:
    • Effective Attack range from 6500 + (500*mk) => 7000 flat (thus, they can no longer engage while still protected by their 8000 radar dampening range).
  • Spire Tractor Platform:
    • Hull Type from Turret => Heavy.
  • Previously, turtle AI types had over 13 times as many AI Eyes as "normal". Moderately defensive ones (Shield Ninny, Grav Driller, and Peacemaker) had only 2 times as many as normal. Turtles now have about 2.6 times as many as normal.
  • Light Starship:
    • Base Health from 1.5m => 2m.
    • Armor Rating from 500 => 1000.
    • Given Radar Dampening of 8000 (to make it harder to deny a fleet its fleet starship munitions boost by ganking the fleet starships from long range). For reference, its munitions boost range is 3000.
  • Flagship:
    • Base Health From 4,875k => 6m.
    • Given Radar Dampening of 8000. For reference, its munitions boost range is 6000.
  • Neinzul Youngling Commando:
    • Base Health from 6600*mk => 8000*mk.
    • Base Attack Power from 1000*mk => 1200*mk.
  • Impulse Reaction Emitter:
    • Now has a minimum multiplier of 5 (roughly what it would get vs a ship with 5,000 energy cost). This might be excessive, we'll see, but the ship was having significant "used as a paperweight" issues against anything at all small.
  • Zenith Mirrors:
    • When a shot is reflected, the returned shot's power is now increased 4x. Thought to be a perpetual motion machine until the first power bill arrived. More seriously, this is an attempt to correct for the fact that things now tend to have a higher ratio of hp to damage (particularly against their own hull type) than when the mirrors were first added.

Prerelease 5.004

(Released March 16th, 2011)

  • Added "Toggle Use-Group-Move-By-Default" In-Game key-bind (no default key, but you can set one on the In-Game tab of the input bindings window):
    • Toggles the value of the Use-Group-Move-By-Default global control (normally changed through the controls screen, but can be set this way for convenience).
    • Note that if you have the controls window open while using this key-bind, the controls window will not automatically update to reflect the change as that would destroy any changes made since the window was opened.
    • To make it easier to know which way it was toggled (without having to open the controls window, which would defeat the purpose), using this toggle displays a local message on the screen noting the change.
  • HUGE Memory breakthrough.
    • Bad news first: the bad news is that this touched 63 different code files, and has resulted in approximately 4500 disparate lines of code being changed in a spiderweb pattern all throughout the application. So... expect some bugs. So far we haven't seen any, but with an organization change this drastic some are inevitable. Why, oh why, would we do this?
    • Well, that brings us to the good news: the baseline heap memory usage for the application has been literally HALVED, and in large savegames it's also... well, about halved in most cases. For those players that had been experiencing the dreaded "Too Many Heap Sections" error (thanks to Unity 3D's less than stellar garbage collector bounding capping out at about 900MB), this is tremendous news.
    • As a small ancillary bonus, this also makes both the program itself and individual savegames load a bit faster. The older your CPU, the more you will notice this effect (on older CPUs, it could shave off multiple seconds, actually).
    • As another not-so-small bonus, this restructuring cuts down on some confusing cases with the spirecraft and how some of the by-unit-scale stuff works. Long-term, this should mean a lot fewer bugs related to the unit cap scales, which is also welcome news. Some subtle bugs related to the armor rating have already been fixed as just part of making this transition, though we don't think anyone reported these specific ones.
  • The regen ability now shows how long, in time, it will take to completely heal the ship from 0 hitpoints to full hitpoints, rather than showing the per-second gain. Thus some mental math is removed, and the display of this can be consistent between different unit cap scales.
  • Ever since the porting to unity, annoyingly, we've had a bug of our own making that caused the first profile to always be the one used, rather than whatever you last used. Fixed.
  • Player profiles are also now once again sorted by name, which they used to be but haven't been since the switch.
  • A new "Don't Compress Savegames" toggle has been added to the Advanced tab.
    • The only time you should turn this on is if your save process is being inordinately slow, or if you are getting "Too Many Heap Sections" crashes. Otherwise, you'll want this on, as uncompressed savegames are pretty huge. But enabling this will save on RAM use during savegame compression and decompression -- the larger the save, the more the savings in RAM with the compression disabled.

Prerelease 5.003

(Released March 8th, 2011)

  • Updated the Unit Cap Scale "High" option's lobby tooltip to note the chance of the game simply running out of memory in the late game and that autosaving and reloading every couple hours can be necessary to get through it.
  • Fixed a typo in the first Fallen Spire journal entry.
    • Thanks to Neck for the report.
  • Fixed a bug where the "I Have A Bad Feeling About This" achievement was not being awarded.
    • Thanks to Tirulii for the report and save.
  • The AI's (announced) exogalactic strikeforces provoked by the Fallen Spire stuff now also contribute points to a sort of "homeworld defense fund". If that has any points and an AI homeworld comes under major assault, a defense force is immediately spawned on that homeworld. This can prove... unpleasant.
  • Minor faction Fallen Spire ships (NOT the human-controllable ones) buffed quite a bit.
  • Previously the controls window was not fitting vertically on 1024x600 (which isn't officially supported but we try to make it playable). Fixed to fit better.
    • Thanks to Talaraine for the report.
  • Courtesy of the current #1 on the mantis vote tallies: Added "Copy To Disk" and "Copy From Disk" buttons to bottom of the controls screen.
    • Copy To File creates a copy of your global controls (excluding per-planet stuff, but including ship designs) as "copiedGlobalControlSet.dat" in your RuntimeData directory.
    • Copy From File prompts you to confirm first, and if you confirm it overwrites all your global control (excluding per-planet stuff, but including ship designs) from what's in "copiedGlobalControlSet.dat" in your RuntimeData directory. If you don't actually have such a file it doesn't do anything when you confirm.
    • Thanks to Fleet for the suggestion that inspired this feature.
  • Courtesy of the new #2 item on the mantis vote tallies list: Added "Mobile Tractors With Full Load Rally" toggle to the global tab of the controls screen.
    • If this toggle is checked, when one of your mobile units with tractor beams (notably Etherjets, Spire Tractor Platforms, Spirecraft Martyrs, and Black Widow Golems) has a "full load" (all tractors active), it will look for a rally post to rally to. If that rally post happens to be a redirector, that will work as it normally does, etc.
    • When the rally trigger kicks in, all other orders (including FRD and attack-move, etc) will be canceled on the tractoring unit. But if you give the ship an order after the rally behavior is triggered, it won't retry the rally unless it it loses one of its tractor targets and then fills up again.
    • Note that this does not apply to Riot Control Starships with tractor modules, because the modules themselves are not mobile units.
    • Thanks to PineappleSam for the suggestion inspiring this control.
  • Another from the vote tallies: Artillery Golems are now immune to radar dampening.
    • Thanks to Fleet for the suggestion.
  • Courtesy of the new #2 item on the mantis vote-tallies: Added "Auto-Scout-Picket" command to the context menu (there's also an key bind, unbound by default):
    • Tell all cloaking scout units in the selection to try to station themselves on a planet where you do not currently have scout intel. Basically it:
      • 1) Makes a list of all scouts with cloaking in your selection.
      • 2) Makes a list of all planets you do not have current (less than 5 seconds ago) scout intel.
      • 3) Sorts that list of planets by distance (ascending) to the planet with your selection.
      • 4) Tells the first scout in the first list to go to the first planet in the second list, and so on. If it runs out of planets it loops back to the beginning of the planet list and thus it will double up, etc. When it runs out of scouts it stops.
    • Please remember that this order (and auto-explore) are only intended to automate simple scouting situations and thus save you time giving otherwise trivial orders. If your scouts all die before accomplishing anything that means that it's not a simple scouting situation and you'll need to take manual control to get good results.
    • Thanks to Malibu Stacey for the suggestion that inspired this command.
  • AI War engine upgraded to Unity 3.3, from previously being Unity 3.1.

Prerelease 5.002

(Released February 22nd, 2011)

  • Fixed bug in last version where maws had no ship cap.
    • Thanks to Orelius for the report.
  • Removed the (somewhat jokingly named) "HasWarpEngineMufflers" UnitData flag, and replaced it with per-unit logic that looks at ActionStatus (Normal, MinorFaction, or Zombie) and tells it to not play wormhole-transition sounds for MinorFaction or Zombie ships that are allied with the player.
  • Fixed bug on the stats window resource-flows tab where most construction/repair/etc outflows were reported as positive instead of negative.
  • Fixed bug that was greatly delaying the onset of gravity slowdown on units entering grav range in some cases.
    • Thanks to chemical_art for the report and save.
  • Courtesy of being really high on the vote tallies: previously double-clicking a single unit would select all (your) units of that exact type on the screen. Now triple-clicking will do the same thing except it will include all units of the same general type (ShipType). Meaning that triple-clicking a fighter of any mark will select all your fighters of any mark on the screen.
    • Caveat: the general categorization being used is sometimes more general than mark; notably remains rebuilders have the same ShipType as engineers. Requests to make triple-clicking an engineer not also select remains rebuilders are likely to be ignored ;)
    • Also, we have to do this triple-click detection manually, so basically it's looking for a third click within 3 tenths of a second after the double-click selection. If this timing is problematic, let us know.
    • Thanks to Toll for the suggestion.
  • In response to the number-one-on-the-vote-tallies mantis issue:
    • Added new PlanetView KeyBind: "Show Strong/Weak Info":
      • Defaults to Alt+W.
      • When this is active and the mouse cursor is over a ship, each planetary summary sidebar entry will display Win/Lose/Draw (and a % indicating intensity of win or loss, if it's not a draw) as a rough indicator of how effective a cap of the ship type under the cursor would be against a cap of the entry's ship type. Since planetary summary entries frequently include multiple distinct types of ships, this is perhaps most useful in conjunction with the "Guide" mode of the planetary summary that shows all ships of a given mark level (the default key for switching to guide mode is F1). However, even in normal mode this can be useful to at least get a rough feel for which of your ships on the planet are the best you have on hand against a specific target.
      • Caveat: this is not using a full simulation or anything like that, it uses the same simplified formula as the reference tab uses. So stuff with modules won't really get accurate results (because it's only counting the base hull), etc.
      • Suggestions on text color, default keys, etc, are quite welcome; we're not totally happy with the effect right now but don't have a lot of time to fiddle with alternatives.
    • Added new PlanetView KeyBind: "Strong/Weak => One Vs One":
      • Defaults to Alt+E (so the full combination would be to hold Alt+W+E).
      • When both this and the "Show Strong/Weak Info" keybind are active, the strong/weak info shown will use a one-ship vs. one-ship comparison instead of the normal cap vs. cap comparison.
  • Snipers (the ship, not the turrets) :
    • Bonus vs UltraLight from 6 => 1.
    • Bonus vs Light from 1 => 6.
  • On to #2 on the vote tallies list: The mouseover tooltip for the AI Progress display on the resource bar now displays each of the tech level thresholds for each AI Player.
    • Thanks to wyvern83 for the suggestion.
  • Fixed a moderately longstanding bug where having the first AI player at tech level 1 and the second AI player at tech level 2 would actually draw as the text "II/II" instead of "I/II" on the resource bar.
  • The "selection description" window in the bottom right of the hud that shows the count of each type in the selection now shows two percents: the first is the average percent-of-max-health of the living ships of that type (this used to be there before the Unity port, and it's back now!), the second is the lowest percent-of-max-health of the living ships of that type.
    • Thanks to Vinraith for reminding us about the missing average-health info.
  • The selection description window will now try to display up to 30 entries without resorting to a scrollbar, instead of only 5.
  • Replaced the old "if CanUseNeinzulRegenerator then multiply by 2" wave-size rule with a more general UsefulnessInAIWaveMultiplier UnitData field.
    • Everything with CanUseNeinzulRegenerator (which is just the 5 youngling types), gets a 2 for this.
    • As an experiment, Bombers get 0.8 and Fighters and Missile Frigates get 1.2. Bomber waves will probably still be more dangerous (as is intended) but it might make the difference in "interestingness" less. Not planning to touch the bonus ship types because if the AI has a particularly bomber-like bonus ship type that should just be a characteristic of the kind of difficulty you'll be facing in that game, etc.
  • Exogalactic strikeforces provoked by the Broken-Golems-Hard or Spirecraft-Hard minor factions (but not Fallen Spire ones) now have a chance (50% for Broken-Golems, 20% for Spirecraft) of using an alternate composition distribution that heavily favors a large lead ship and a single battlegroup.
  • Broken-Golems-Hard and Spirecraft-Hard exogalactic strikeforce initial-strength, per-minute-increment-amount, and maximum-strength all increased roughly 10%.
    • Thanks to Shrugging Khan for pointing out that these are a bit on the easy side right now. In other words, blame him if these slaughter you now.
  • The Armored, Black-Widow, Artillery, and Regenerator Golems used in exogalactic strikeforces are now different than the "standard" AI golems (like those used by the Golemite AI Type). The main difference is that they lack the 1/10th-health-of-a-normal-golem rule (but the Armored variants still have a 1/2 health modifier, since they're so buff).
    • Thanks to Shrugging Khan for continuing to provoke the golems.
  • Black Widow golem health and Attack Power boosted a bit (15%-ish).
  • Regenerator Golem health doubled, in response to various concerns that they're less useful than other golems.
  • The "shot travels at least 40 speed faster than its target's current speed" logic has been extended to include "shot travels at least 40 speed faster than its target's tractor-er's current speed", since in the "tow" case the target's current speed is almost always zero.
    • Thanks to kjara for the report.

Prerelease 5.001

(Released February 16th, 2011)

  • Made it possible to bind Mouse2, Mouse3, Mouse4, Mouse5, or Mouse6 to the primary key of a KeyBinding. For reference, Mouse2 is the middle mouse button. Mouse0 is left-click, Mouse1 is right-click, and both are excluded from this due to being used in many other ways by the main input code. Mouse3-6 don't exist on most mice, but are available for those who have them.
    • One example use of this is to bind OpenDefaultContextMenu to Mouse2 (middle mouse). We're not sure if this would cause major conflicts with middle-mouse-scrolling or mouse-wheel-zooming (due to accidental click-downs during wheeling); if you try it please let us know how it goes. Seemed ok in our testing.
  • Fixed a bug where the special-move context menu's catch-right-clicks option was basically failing to do anything. Now when it is toggled on it properly re-interprets right clicks outside the menu as "set destination to clicked point and then execute".
  • Updated tooltips for:
    • Armored Golem.
    • Artillery Golem.
    • Black Widow Golem.
    • Cursed Golem.
    • Regenerator Golem.
    • Hive Golem.
    • Botnet Golem.
    • Military Command Stations.
    • Captive Human Settlements.
    • Fallen Spire lobby tooltip (reference to wiki removed due to complaints).
    • Thanks to Burnstreet, c4sc4, techsy730, and Sunshine! for contributing suggestions about these.
  • Fixed a bug where hybrids were... basically completely broken. Sigh. The "don't let hybrids rebuild modules if they've recently been damaged" code was inverted in such a way that they could never build modules. And because they could never get modules, they were never satisfied that they were ready to go attack or defend or whatever.
    • For reference, this bug went unreported for roughly 20 versions. The Hybrids are plotting revenge.
    • Thanks to Draco18s and Draco Cretel for reporting. The Hybrids might spare them.
  • Reclamators (excluding zombie-reclamators) :
    • Replaced the "cannot do reclamation damage to ships more than one mk level higher" rule: the reclamation effect of the actual damage done is multiplied as follows:
      • If the reclamator is 4 mks higher than the target (mkV shooting mkI), multiply by 64.
      • If the reclamator is 3 mks higher than the target, 48.
      • If the reclamator is 2 mks higher than the target, 32.
      • If the reclamator is 1 mk higher than the target, 16.
      • If the reclamator is the same mk as the target, 8.
      • If the reclamator is 1 mk lower than the target, 4.
      • If the reclamator is 2 mks lower than the target, 2.
      • If the reclamator is 3 mks lower than the target, 1.
      • There is no 4-mk-lower case because mkV are not reclaimable.
    • Leech Starship base attack power from 120k*mk => 30k*mk.
    • Parasite base attack power from 4000*mk => 1000*mk.
    • Nanoswarms inherent 16x-reclamation property down to 2x, but no reduction in actual damage.
    • Spire Teleporting Leech base attack power also not reduced, because the general feeling is that these are pretty underpowered already. Might nerf these later if this proves to be too much.
  • Parasites:
    • Effective range from 3700 => 6000.
    • Armor piercing from 0 => 750*mk.
    • Base Health from 7200*mk => 14400*mk.
  • Fixed a relatively longstanding bug where AIPerPlanetShipCap and AIPerGuardPostShipCap were generally not being enforced when loading a game (either just-starting or loading later).
  • Some triangle rebalancing:
    • The rationale here is that bombers have been having their way with forcefields a bit too much, and having fighters be so much more "general-dps" than the other two has made them much less a natural predator of the Bomber. Also, the Missile Frigate is still being reported as the least desirable by a significant margin.
    • Fighters (including the tachyon and bulletproof variants) :
      • Bonus vs Polycrystal from 2.4 => 5.
    • Bombers:
      • Bonus vs UltraHeavy from 10 => 6.
      • Bonus vs Structural from 10 => 6.
      • Bonus vs Heavy from 10 => 6.
      • Bonus vs Artillery from 10 => 6.
      • Base Attack Power from 1900*mk => 2400*mk.
    • Missile Frigates:
      • Bonus vs Light from 10 => 6.
      • Bonus vs UltraLight from 10 => 6.
      • Bonus vs Swarmer from 10 => 6.
      • Bonus vs Neutron from 10 => 6.
      • Bonus vs Composite from 10 => 6.
      • Bonus vs Refractive from 10 => 6.
      • Base Attack Power from 1600*mk => 2400*mk.
      • Base Crystal Cost from 700 => 500.
  • Fixed a bug with the electric shuttle "chain lightning" mechanic where it could hit a single forcefield way more times than intended. Used to be as many as 200 per shot, but now down to 5 (anything can be hit 5 times per shot).
    • Thanks to Draco18s for reporting.
  • Fixed bug where electric shuttles were able to chain-hit the same target 10 times in one blast (thus getting maximum efficiency against groups 20 or larger) instead of 5 (thus needing to hit at least 40 to get full damage).
  • Fixed a bug where Spire Blades, Spire Minirams, and Spire Rams would not actually automatically die (but just self-damage by some amount) when attacking.
  • Tractor Beam Turrets:
    • Base Health from 210k/840k/1680k => 560k*mk.
    • Base Armor Rating from 1200 (flat) => 450*mk.
  • Beam Guardians:
    • Bonus Vs Turret from 8 => 1.
    • Bonus Vs UltraLight from 8 => 1.
    • Bonus Vs Artillery from 2 => 1.
    • Base Attack Power from 4000*mk => 4500*mk.
    • Base Armor Rating from 600*mk => 300*mk.
  • Laser Guardians:
    • Base Armor Rating from 1000*mk => 300*mk.
    • Base Health from 1.4*(standard guardian health) to 1.1*(standard).
    • Shots Per Salvo from 3 => 15.
    • Seconds Per Salvo from 4 => 2.
    • Base Attack Power from 17k*mk => 1700*mk.
    • Base Armor Piercing from 500*mk => 300*mk.
    • Base Attack Range from 7000 => 5000.
  • Raider Guardians:
    • Now Have Radar Dampening Range of 8000.
  • Lightning Guardians:
    • Base Armor Rating from 800*mk => 600*mk.
    • Now use the same "can hit up to 200 targets max, but can do max damage to as few as 40 by hiting each target up to 5 times" logic as Electric Shuttles.
    • Base Attack Power from 1600*mk => 2400*mk (for reference, Electric shuttles on low caps have 1600*mk, albeit somewhat slower reloading).
  • Tractor Guardians:
    • Base Armor Rating from 1200 (flat) => 450*mk.
  • Spider Guardians:
    • Base Armor Rating from 1000 (flat) => 150*mk.
  • Sniper Guardians:
    • Base Armor Rating from 1000 (flat) => 150*mk.
  • Tachyon Guardians:
    • Base Armor Rating from 400 (flat) => 150*mk.
  • Gravity Guardians:
    • Max Target Base Speed from 10/8/6/4/2 => 11/10/9/8/7.
    • Grav Beam Base Range from 8k/10k/12k/14k/16k => 7k/8k/9k/10k/11k.
    • Base Armor Rating from 100*mk => 300*mk.
  • Zombie Guardians:
    • Shots Per Salvo from 2/3/4/5/6 => flat 2.
    • Base Armor Rating from 5000*mk => 300*mk.
    • Base Attack Range from 9000 => 7000.
  • EMP Guardians:
    • Base Armor Rating from 1200 (flat) => 300*mk.
  • Carrier Guardians:
    • Base Armor Rating from 1200 (flat) => 300*mk.
  • Note: the guardian rebalancing is far from done, this was just to tone down some more obvious issues.
  • Handicap now has the following effects, all of which is new unless otherwise noted:
    • AI
      • Previously it affected the speed at which the AI reinforced. It no longer does.
      • Increases the number of ships in each wave and reinforcement, and decreases when negative.
      • Roaming Enclaves and Preservation Wardens are spawned sooner or later into the game.
      • Scrap waves are scaled accordingly.
      • Specifically "forced waves" are scaled accordingly.
      • Cross planet atacks are scaled accordingly.
      • Saboteur and deep strike reactions are scaled accordingly.
      • For now, event attacks are NOT affected by this.
      • Initial seeding of AI planets are intentionally not affected by this -- same as human players get no starting benefit from handicaps.
    • Player
      • Increases the amount of resources gathered from producers (using a new formula), and decreases when negative (also using the new formula).
    • Thanks to TechSY730 for suggesting we revisit this.
  • The tech level of the AI is now only inflated by 1 artificially when playing on greater than difficulty 9, rather than greater than difficulty 8.
    • Thanks to TechSY730 for suggesting.