AI War 2:The Grand New AI

Known Issues

• Any bugs or requests should go to mantis: https://bugtracker.arcengames.com/view_all_bug_page.php

• Multiplayer is disabled until post-1.0 while we focus on tightening up the single-player loop (more info here).

What's this phase all about?

After lots of feedback, we're ready to take it to the next level! Major new functionality and improvements across the board are incoming to make games more interesting than ever, and we're also going to start building toward multiplayer.

Version 1.311

(Not yet released -- we're still working on it!)

BETA 1.310 A Smarter Warden

(Released January 24th, 2020)

• The Warden Fleet now uses Fireteams.
  • Needs testing before pushing to the main steam branch.

• Increase the threshold for "Ships in combat" voice lines. Don't play the "Your home command station is under attack" voice line unless the AI actually has enough ships to be scary.
  • I don't want to know if one cloaked AI fleetship is shooting at the shield on my home command station anymore

Version 1.309 Instigator Cheekiness

(Released January 23rd, 2020)

• The counterattack notifier hovertext now tells you how many guard posts you have to kill to disable the counterattack

• Fix a bug where the Devourer wasn't shooting the zenith trader
  • Thanks to Ovalcircle for reporting

• When the game tries to create notifications up at the top part of the screen for the human player, if it runs into an error it now is much more informative about what the error was, although it's still not exact in every case.
  • Thanks to DefeatedByTheCat for the report that triggered us to add this.

• Fixed a variety of places where if the AI did not have a "most annoying faction" at a location, it would error instead of simply waiting because it was not annoyed.
  • In "send a wave if alerted after X seconds" (raid engine).
  • In the human notification checks for raid engines.
  • And that's it, from a thorough code review. Everything else actually already checks properly for the most annoying faction index being -1, or the resulting faction object being null, as relevant.
    • Though it is worth noting that if there is mysterious threat showing up because of minor faction aggro against the AI, it's possibly because the AI got a -1 from this at some point.
  • Thanks to DefeatedByTheCat for the report that led us to finding this. This isn't actually a new bug at all, just a rare one apparently.

• Lone Wolf Flagships can no longer have ship lines swapped to them. This is a very longstanding bug.
  • Thanks to a bunch of people for reporting, including Chthon, Iocaine and deo

• Fixed the "Called AI Sentinels_execCont_607 pathfinder from two different contexts! First was executionContext, new one is specialFactionContext_22_AI" error, and probably all related errors.
  • The correct pathfinder to use for a faction is now centrally calculated from a method called GetPathfindersOfRelevanceFromContext, and there are now many more pathfinder instances possible to have on a faction instance to avoid the potential case where factions need to pathfind out of cases we were expecting.
    • If pathfinding is done by Faction.FindPath in a generalized sense from certain types of threads (anything other than the main, execution context, or background faction planning threads), then honestly it will probably wind up with an exception and the programmer in question needs to instantiate their own custom pathfinder instance for whatever it is they have in mind.
  • As it stands, it's now lazy-instantiating all these new possible pathfinding contexts per thread type per faction, since a lot of factions do next to no pathfinding and all of them only use some of the thread cases.
    • This helps to avoid memory over-usage (even though that would still be minor in the grand scheme), and makes instantiating faction external data slightly faster than it was in the past and would have become in the future.
  • Thanks to zeusalmighty for reporting.

• Also put in a count of pathfinders created in total, and discovered that we were creating and discarding a pathfinder or two every second or so. This was a minor performance drain and is now fixed.
  • You will notice that the number of pathfinders goes up over time early in a new game because of the lazy-creation of them as factions need them, and that's normal (even some getting added hours after starting is normal, if a faction enters a new mode for the first time). Exiting one game and creating another will also cause more to get created. But there shouldn't be a runaway growth of them indefinitely.

• Fixed a cross-threading bug that could cause GetWormholeToOtherPlanetOrNull to have a nullref inside it.
  • Thanks to Binary Blitz for reporting.

• CPAs no longer allow you to C-click them, and the slight information that was actually useful inside a c-click of one is now just in the direct tooltip, which no longer asks you to c-click them. This is all just a lot more clean and clear.
  • Thanks to Badger for suggesting.

• Change Instigator Base spawning rules to hopefully make them a bit less frustrating
  • Previously once you hit 300 AIP the Instigator base could spawn anywhere
  • Now between 300 and 600 AIP the instigator base must spawn between 4 and 7 hops from one of your planet, and it's only unlimited after 600 AIP

Version 1.308 Mega Performance

(Released January 22nd, 2020)

• Most Notifications now work as follows. Clicking on them in the Galaxy view will center you on the planet. Clicking on them in the Planet view will take you to that planet.

• Combat fleets now include their Strength in the tooltip in the Intel menu
  • Thanks to Admiral for suggesting

• Even on the brief tooltips, the game now shows how many ships and what their strength is for AI reinforcement points. The medium tooltips show the types of ships in there and a bit more info. This is pretty important information at every tooltip level.

• Add a setting for preventing instigator bases from spawning.
  • While canonically the AI gets instigator bases, some people find them frustrating or stressful to play against.
  • Requested by Admiral

• Ghost, Ensnarer and Sniper AI Turrets now say their type, so the Ensnarer Battlestation having them doesn't seem so odd (as it now specifically says "Ensnarer Pike Great-Turret" for instance).
  • Mentioned by Ryulong and Venger.

Astro Train Buffs

• Astro trains can now spawn multiple trains at once, based on the intensity of the faction.
• Only for intensity >= 5. Chance for multi-spawn starts at 10% for intensity 5 up to 60% at intensity 10.
  • Lets see if this is enough to make them more exciting. From a discussion on Discord with Hyde, zeus and others

Bugfixes

• Fireteams drop out of 'bonus speed mode' once they are actually attacking the target. A fireteam only gets bonus move speed to make sure all the fireteams attacking arrive in a coordinated fashion
  • Thanks to Astillious for pointing this out

• Fireteam-based Nanocausts now are constrained from attacking the player too early.
• Killing a nanocaust hive now means nanocaust ships won't get any new orders (except 'fight on this planet')
  • Thanks to Astillious for the bug reports
• Fixed a bug in the last couple of builds where it would always talk about your "best fleet" in the end of the game (win or lose) as "useless cowards" (which is just what it says when it can't find a fleet).
  • Thanks to Ovalcircle for reporting.

• Fix a bug where factories weren't printing things they were rebuilding
  • Thanks to Mongoose on Steam for reporting.

• Macrophages and Enraged Macrophages won't be counted as Threat anymore
  • Thanks to WolfWhiteFire for reminding me about this

• Fix a bug where the Nanocaust invasion could trigger a bunch of threat against the player
  • Thanks to vodkasheep on steam for reporting

• Fix a bug where Norris Effect ships were being blocked from going through wormholes by shields
  • Thanks to Flypaste for reporting

• Put in even more of a fix to the fire teams having an INNER exception of thread abort that was being reported erroneously because it could happen during a sort operation.
  • This should solve some of the marauder debug code 1200 errors we were seeing that were not really a bug.

• Units such as Hydra Heads and Mini Cluster Bombs will no longer show in the Double Shipline Cap option screen.
  • Thanks to Admiral, Daniexpert and NRSirLimbo for reporting.

• Fixed an exception that could happen in rare cases on loading a savegame with a wave incoming, where it might say "Exception in ShipIconImageBase.RenderContents at stage 170"

• Fixed Royal Tethuida and Shredder Guardians not having Drones.
  • Reported by Ryulong.

• Hacks against the Dark Spire now correctly consume hacking points. Whoops
  • Thanks to NRSirLimbo for reporting

• Unexplored planets will no longer show their mark level or the number of reinforcement points they had. Previously you could deduce way too much information about planets (including the location of AI Overlords)
  • Thanks to Fluffiest for reporting

• Finally fixed a bunch of spurious errors that could happen when you exited out of the game and it was in the middle of shutting down background threads. They made it seem like things were happening such as clashes between pathfinding calls to the same pathfinder, and other things of that nature, but it was just the threads dying and not being as quiet about it as they should have been.

• Fixed a couple of nullref exceptions that could happen during DoForEntities and a few related methods if the collection was changing during a cross-thread update clash.
  • Thanks to Ryulong for reporting.

• Fixed a variety of quasi-invisible bugs where the wrong movement or decollision points could be given to the wrong entity if ships died in between when the command was issued and when they got it.
  • This could cause rare random things like a ship of your own suddenly moving without you telling it to, etc. It was likely pretty rare, although it got more common after we stopped pooling ships.
  • Thanks to NRSirLimbo and Badger for helping us accidentally find this.

• Probably fixed a bug that could happen inside entity order creation for decollision. Whether we really fixed it or not will require more testing, as it was pretty rare in the first case. This was quasi-related to the above fix.
  • Thanks to NRSirLimbo and Badger for reporting.

• Put in a lot of extra debugging stage code to help us know what is happening in the faction metal outflows code, so that when we get something like "ERROR In BuildingDronesInternally" we will know where the problem is. As it stands the code looks okay, but someone hit the error, so we'll need them to hit it again in the new code version before we can figure out what it is.
  • Thanks to NRSirLimbo for being our resident nullref exception sponge.

• Put in a likely fix for a rare exception that could happen in GenerateMercenaryObjectives.
  • Thanks to NRSirLimbo for reporting.

Performance Hunting And Open-Sourcing

• Reduce the number of FindPath calls made by Fireteams

• Fix a bug where empty fireteams in some states were never being disbanded

• The way that the game tracks commands that are actually queued versus those that are just requested but not actually sent is now much better, giving us insight into what the heck is going on and where we might be able to squeeze out some more performance in giant games in particular.

• A large amount of code relating to simulation that happens at the planet level has been moved into the open-source dlls.

• A whole bunch more of the world-step sim logic has been moved into the open-source (moddable) part of the code.

• Fixed a minor performance drain where our "combine into stacks" code was pulling thousands more gamecommands from the pool in large savegames, then not using most of them because of whatever invalidities.

• Put in a variety of fixes to the AI background thread where it could pull a "send wormhole" command prematurely and then realize that it had nothing to send, thus causing it to trigger some locks pointlessly and waste some background CPU cycles.

• Put in some defensive code in dark spire, devourer, dyson sphere, instigators, and outguard that could cause it to issue blank wormhole move commands and calculate paths for no ships in potential rare circumstances.

• Improved some of our utility methods to early-out a lot sooner when they don't have targets to chase, etc.

• Improved the divide ships among planets code to definitely never send empty wormhole commands anymore.

• Improved the auto pursuit mode for engineers to not request extra commands and then put them back, again improving performance slightly.

• If null commands or null types on commands are sent, it now shows those in red in the escape menu.

• For commands that have a different number of requests and actual queuings in the escape menu, it now shows those in red for easy identification.

• When the game gets a request to shut down or quit to the main menu or other things of that sort, it is now absolutely brutal with the background threads, killing them all and exiting immediately. It was before trying to be polite and wait for them to tidy up and finish, but that was at the best case slow (now with fire teams in particular), and in the worst case would never exit (in the case of a stalled background thread).

• Fixed an issue where if one of the background long term planning fields got stuck or was slow, it could cause others to be very slow to send their commands.
  • In general also made it so that long term faction threads now send their commands as they finish their individual work, which is far superior in terms of smooth performance when there are many factions.

• If the game runs into a background thread that is taking more than 10 seconds (which means it is then blocking all other background threads, too), it now shows a message on the right hand side of the screen saying slow background threads and showing what the slow thread is.
  • In this way we can actually tell if something stalls out and then starts blocking the rest of the game, versus before it was pretty invisible.

• Fixed some excessive requests for SetWaiting and SetBehavior_FromFaction_ThreatTimeToFight that were then never being queued for actual use.

• Fixed some excessive requests to TransferEntitiesToFaction and ScrapUnits that would then not be queued.

• Split the singular "SetWormholePath" into 17 distinct variants so we can see what is going on in terms of high volumes of those being sent in some savegames and thus causing a big slowdown.
  • The general idea is for us to be able to recognize hotspots at a glance, but all of these function the same so it doesn't matter which one a mod's code uses.
  • An interesting side effect of this is that it potentially cuts down on cross-threading contention since the pool has to be locked to take items out and put them back in.
    • The pool being locked and unlocked is one reason not requesting more commands than we need is a really good idea, too.
  • There is actually a measurable performance boost from these things alone.

• Same thing with splitting CreateSpeedGroup into 4 variants.

• FlushReinforcementPoints can now only be called on a planet once every 5 seconds at most.
  • This keeps certain factions from flooding the command queue with hundreds of such requests over the course of a second or two of game time.

• Refinements to the pathfinding performance, round 1 (existing algorithm changes):
  • Starting performance:
    • 3.30017 ms per call on average for marauders, over 25k calls in 84 seconds of processing for the marauders faction long term planning thread (stopped thread after this).
  • After making GetNeighborOfNodeByIndex much more direct and not involving a loop:
    • To start, 2.883 ms per call on average for marauders, over 16k calls in 48 seconds of processing for the marauders faction long term planning thread.
    • But then 3.212 ms per call on average for marauders, over 30k calls in 98 seconds of processing for the marauders faction long term planning thread (stopped thread after this)
    • It's worth noting that there's fuzz in all this data, from disk write speeds and application being in the foreground or background more, different routes being considered, etc. So it's only so precise.
  • Removed DoForNodesInFlood since it was never used anyway.
  • Then changed the pathfinding object itself to not instantiate a ton of stuff on the heap with every call, instead reusing objects and lists and dictionaries except for the final result dictionary.
    • As part of this, made it so that the FindPathInner method now also checks to see if it has simultaneous calls on the same object, to make it complain if it's used in a non-threadsafe manner. A single thread would only call these serially, after all.
    • After this, 2.642 ms per call on average for marauders, over 16k calls in 44 seconds of processing for the marauders faction long term planning thread (stopped thread after this)
  • It's observed that we're doing quite a few calls to these pathfinders on the main thread as well, but nothing at the sort of scale that the long term planning threads do. But some of the substantial performance degradation to the sim is probably this on the main thread also.
  • With the logging turned off, the long-running thread for marauders in the super-slow s6 save is now something that takes still north of 136 seconds, so this sort of low-hanging fruit is making very little difference in aggregate and could even simply be the result of instrumentation error (so to speak). The revisions definitely are performance improvements, but are apparently such a tiny portion of the load as to not be noteworthy.

• Before we get into more extreme changes, the ArcenPathfinder class and its internals have been moved to the external public source code.
  • This makes things far quicker for us to change and then test the results with.

• Added a new abstract Pathfindable class in the Arcen Core area, which is now required for use in the pathfinding code, and which Planet inherits from.
  • This lets us make a number of things more efficient, and not just in pathfinding.
  • PlanetIndex on the planet object is now just Index on Pathfindable.
  • LinkedPlanetIndices is now just LinkedIndices on Pathfindable.
  • Added a new LinkedPathfindables on Pathfindable which gets recalculated as needed and which can be manually recalculated via FillLinkedPathfindablesIfNeeded().
    • This actually should speed up calculations for a lot of things with adjacent planet checks, even outside of pathfinding.
  • The pathfinding code is now able to directly call a few things on Pathfindable, rather than having to indirectly get things via method calls.
    • This is another incremental improvement, but paves the way for a number of things, and in general makes the load on the call stack lower. Given how many paths are being calculated by fire teams, every little bit matters, even before we get into the larger changes.

• Made some tweaks to fireteam code to reduce the number of FindPath calls.
  • This alone shifts the performance of the s6 savegame case to be able to finish the marauders long-running thread in 98 seconds now instead of it running somewhere north of 150 or 200 seconds.

• The ArcenSimContext now has a non-sim incrementing loop counter in it that tells us when we need to refresh the pathfinding data and other things.
  • This is "non sim" in the sense that it doesn't matter what the loop counter number is, it just matters that it knows when the number is different. This is safe to use for multiplayer and on short and long term planning threads, main thread, etc.
  • To check if this is the same execution that it was the last time you were in a thread, you can now check a stored integer against NonsimLoopIndex on the context. If the numbers don't match, sim or not sim, then you should recalculate whatever you're intending to cache on a per-iteration-of-this-thread-whatever-that-is basis.

• The pathfinding code now requires that an ArcenSimContext so that we can use that new stuff for lazy-load precalculations.
  • This lets us be sure that we're not wasting any CPU on precalculations that will never be used, but at the same time since these are per-thread we don't recalculate the same things over and over again. At least that's what will be the case.

• The pathfinding code now also keeps track of what the first ArcenSimContext was to call into it, and if another context is ever used to call into it, it will complain.
  • Thus if we wind up with short term planning code calling long term planning code, we'll know, etc. So far the tests show no instances of this happening, but prior to now that would have been a silent problem if it was happening.

• More tweaks to fireteam code to even further reduce the number of FindPath calls.
  • This shifts the performance of the s6 savegame case to be able to finish the marauders long-running thread in 77 seconds.

• The background threads are now set to run not in background mode, and with a priority that is above normal. This shouldn't affect the front-end framerate except on extremely limited old-school single-core machines, which don't meet the minimum requirements anyhow.
  • This makes better use of your entire processor, and the more cores you have the better the improvement is. This may also be somewhat OS-dependent, as different OSes have different threading models and are better and worse at different things.
  • On Windows 10, simply switching from using the unity editor as our test environment to using a standalone build gets us from 40% sim speed to 50-70% sim speed in the s6 savegame, and it drops the background marauder thread from 80 seconds to 55 seconds to execute. On Linux, Badger reports 20 seconds or so for the same background thread, though.
  • After these changes to upping the priority, we get a much more solid 70-100% sim speed (those all are running on "background" threads as well, after all), and the background marauder thread drops from 55 seconds to 50.
  • We still have a ways to go with the pathfinding efficiency itself, and potentially with culling yet more cases where it's actually calling the pathing threads in a nested fashion, but some of this was based on our internal testing environment (who knew that unity's editor doesn't at all obey thread priorities?), and some of it is improved by giving the background threads in the actual standalone game more freedom to use your available processor space. If your CPU is half idle and the game is running at all slowly, that's just silly.

• Made a variety of changes to improve pathfinding performance further.
  • We're precalculating node passability, which gets rid of the most frequent method call that we were seeing inside the pathfinding code. However, this only drops us from 55 seconds to 51 seconds (a 7.3% increase) for marauder path computations. We need to take it further! (Even though Badger has solved the problem another way that isn't checked in yet, we still want pathfinding to fly.)

• Made further pathfinding changes to remove all uses of dictionaries and almost all use of lists, and definitely all uses of Contains.
  • This has basically linearized the node states into a series of arrays of fixed length 500, and if there are ever more than 500 planets in a galaxy the pathfinding will break unless it is recompiled to support higher numbers of planets. The overall game would burn performance at 500 planets and it would be unpleasant to play, anyway, so this does not seem like a problem to have.
  • With the changes to linearize things in this way, performance went down from 51 seconds on the marauder thread to... 7 seconds. So from the recent 55 seconds this is a full 87% improvement to pathfinding speed.

• Badger figured out a way to also time-slice the fire team logic so that they only scan a certain number of planets (per faction) per check of fire teams.
  • This makes some of the fire teams a bit "slower to react" (this is VERY relative) in the super short term in saves with literally hundreds of fire teams on one faction and 200 planets, but it keeps everything running far faster.
  • A single fire team might need to evaluate hundreds of planets in order to find out what it needs to do after completing a major objective or just coming into an existence, and this was the case where the game could spike and have really long-running threads (north of 200 seconds prior to this release, now down to 7 seconds as of Chris's prior changes just above).
  • While Chris was doing his changes, Badger got in this throttling and managed to make the simulation run at full speed and take an average of 5 seconds instead of 55 even before the pathfinding was 87% more efficient. That was with 1000 planets being scanned at a time, max.
  • There is a new galaxy setting which lets you adjust the number of planets to scan, and its new default is now 2500 since between these changes, other fire team improvements, and the pathfinding improvements, what was once taking 200+ seconds now takes a second or two.
  • So the fire teams "reacting slower" as noted above means they might delay for a few seconds, maybe 10 at most, in the really huge savegames. But it's not something that will stall the game or performance anymore, and the prior amount of time we had to wait in prior builds for ANYTHING to happen was 200+ seconds. So... it's just plain faster.
  • Also, the name of the galaxy option to control this is "Max targets Fireteams can scan in one iteration" in the performance section.

Exo tweaks

• Fix a bug where exos were losing their exo target between save/reload
• If a unit had been in an exo but the target died, the ship drops out of the exo and joins the threat
• Units in an exo stuck by a black hole machine should prioritize killing the black hole machine
• This should make exos even more adept at chasing units across planets. Especially big, shard-shaped ones.
  • Thanks to Ovalcircle for the bug report

Cross Planet Attack (CPA) tweaks

• AI homeworlds can no longer contribute to cross planet attacks (CPAs).

• When pulling ships for a CPA, the AI now starts with the planets that are at or below its current mark level (whatever that is), minimum 2.
  • It then goes to planets 1 mark level above, then two, then random among everything else.
  • This makes it most likely, particularly in the early game, that most things will be relatively low-level.

• To clarify, since many have been confused, while CPAs do have a budget, they do NOT create new ships.
  • As with the first AI War, they instead turn guards into threat. Aka, they set guards "free" to come attack you.
  • The budget of the CPA determines how many ships they can set free, but doesn't let them purchase anything new.
  • Specifically it only pulls from ships that are IN guard posts at the moment.

• Previously, the mark level of ships in a CPA was downgraded (or upgraded) to whatever the mark level of the AI was in general at the time.
  • This was wildly unfair to the AI in a lot of cases, making high-mark ships into low-mark ones.
  • Now the AI gets whatever their actual mark of ships are freed, but it tries to free appropriate-or-lower mark ships first before launching harder stuff.
  • When it launches things that are lower-mark or higher-mark than its baseline, it pays less or more from its budget based on the strength differential. So the end strength should be the same in general.

• When ships come out of guard posts for CPAs, previously it would grind some games to a halt because of them coming out unstacked and potentially huge in number.
  • Now it tries to stack them up to 99 ships at a time per stack, as it can.

• Also previously, when the CPA launched you had no idea what you were in for. Now it tells you how many ships, what total strength, and how many of each mark level of ship were freed.
  • The idea is definitely to keep you from being surprised by higher-mark ships showing up, or in general by what is happening. Where the ships are and what specifically their composition is remains a mystery, though.
  • This also should immediately dispel any confusion about these being new ships versus freed guards, based on the wording of the notification.

• The in-game Tip now explains these new mechanics

Balance Tweaks

• Some buffs to the Macrophage, who are feeling pretty uninspiring. More buffs to come if they are still underperforming

• Nanocausts and Marauders that were created before fireteams were an option now default to using fireteams
  • This includes Nanocausts and Marauders from quickstarts

• Altered most of the Fleet Designs again, to fix some problems accidentally introduced previously, regarding Mono-Tech Fleets and the general chances of each Tech line being on paper fine, but in practice notably off.
  • Also added 15 new Designs, and removed 2 that were notable culprits.

• Dark Spire Wraith and Phantoms can now be affected by the Strikecraft Coordinator, as well as have their lines doubled.
  • Mentioned by Ryulong.

• Space Planes, Mirages and Apparitions have their damage resistance range reduced, to account for the recent 0.8x range modifier that does not affect this.
  • Also mentioned by Ryulong.

• Added some more Guardian types to the Instigator Base spawns.
  • Requested by ArnaudB and Fluffiest.

Strikecraft

• Vanguard speed 400 -> 600, shots per salvo 1 -> 8, damage 360 -> 90, reload time 6s -> 8s.

• Vanguard Hydra speed 600 -> 800, shots per salvo 1 -> 8, damage 180 -> 60, reload time 6s -> 8s.

• Pulsar Tank speed 400 -> 500, main weapon range 4,200 -> 5,600, main weapon has the same damage bonus as the secondary.

• Ablative Gatling speed 600 -> 800.

• Ablative Troll speed 400 -> 600.

• Pike Corvette and Porcupine speed 500 -> 600.

• Grenade Launcher Corvette speed 400 -> 600.

• Molotov speed 800 -> 1,000.

• MLRS Corvette speed 400 -> 600.

• Raptor damage bonus 4x -> 6x.

• Ranger speed 800 -> 1,000, damage 225 -> 450, reload time 4s -> 8s, range infinite -> 10,100, now has a cloaking device.

Zenith Trader

• Scrubbed Abberation and Abomination now do full Zombification rather than a form of Nanocaustation that would create normal zombies.
  • Led to a problem with the changes to Zombification to restrict what could be affected. Those did not affect Nanocaustation, so these units could still give the player zombie versions of Dire Guardians, for instance.

• Now sells a Trader specific version of the Orbital Mass Driver, as to not interfere with the galaxy wide caps if you hack any.

• All Zenith Trader goodies have a galaxy wide cap of 2.
  • Before you could armour up every planet you owned to a large amount with no other investment. Now you have to choose where these goodies go.

• Zenith Forcefield is now Markless, but has improved stats over what it used to be.
  • Just clarity. It couldn't be upgraded anyhow.

• All other Trader goodies are Markless.
  • Also for clarity, since most weren't affected anyhow, and the one that could (Tamed Macrophage) could have huge power spikes from planetary upgrades.
  • This might change in future.

Version 1.304 So You Like Combat Engineers?

(Released January 14th, 2020)

• The right hand chat/log window in the lobby is now hidden, since it isn't used for now.
  • Thanks to Sounds for suggesting.

• Added a new setting to the performance section of personal settings: Enable Performance Logging
  • Turning this on may hurt performance a bit, but not hugely so in most cases. It lets you then see a lot of information about how the game is spending its CPU time by right-clicking the timer in the bottom left of the main game view. Off by default, as it has no other purpose than that.
  • Prior to this build it was always on. It wasn't a performance drain at all that we can tell, but it's worth being careful, and it was a source of some cross-threading issues which would give slight performance issues. But we can't detect even a 1% difference in general performance with this on, presently.

Bugfixes

• Friendly nanocaust should now honor the 'dont kill command station' setting
  • Thanks to Ovalcircle for reminding me about this

• Fix a typo that was causing the outguard to go through withdrawl
  • Thanks to Ryulong for reporting.

• Some text editors put a shadow copy with .xml~ at the end, and that can be a problem for people who have files open to make tweaks (modding or development) while testing the game. It also can cause errors in the game if we accidentally push one out like that. The game now explicitly ignores such files.

• Put even MORE paranoid-style cross-threading protections in on FramePartTimings, since themouthofsauron reports still seeing a few of those in the very latest 1.303 builds. Our fixes in that build probably cut down on those, but clearly didn't eliminate them.

• Fixed a visual-only bug where factories seemed to be helping build for fleets when the factory was disabled or still self-building or similar. Especially if other factories were actually making progress on the same things the factory was ostensibly helping, it was confusing.
  • Thanks to Daniexpert for reporting.

• Fixed a harmless but annoying exception that could happen as you exit the game or quit to the main menu in the last few versions.

• Put in some fixes for a cascade of errors that could happen from a fleet member's type being inexplicably set to null.

• Fixed a variety of places where the game simply being in the process of exiting could cause the game to log an error that was actually harmless and not something to log.
  • Thanks to NRSirLimbo for reporting.

• Improved performance on the main menu by ensuring that background threads were not able to run (they would be pointless there in general).

• The way that the performance logging is handled is now a bit more idiot-proof in terms of us being less likely to cause problems with mismatched calls to it.

• Fixed a kind of face-palmy issue on the main menu that was causing it to lag horribly while everything else was fine. This only happened on Steam, not GOG, and was us basically checking too frequently to see if we needed to update Steam achievements online with things that were achieved locally but not yet logged to Steam.
  • Once we got GOG achievements in, this would have hit there as well, so it's good to get that out of the way for both platforms.
  • This shifts the framerate on the main menu from a very choppy 20fps to a super fluid 200+ fps.
  • This also seems to make the entire game load faster, too.

• Added a bunch of internal compiler toggles which let us isolate different parts of the code to see where our performance bottlenecks are on the really high planet count late-game high-ship-count peformance problem games.

• Fixed a rare cross-threading exception in PlaySFX_ShotHitting, and another one in GameEntity_Shot.ClearVisualObjIfExists.
  • Thanks to Ryulong for reporting.

• Fixed an issue in the prior build where combat engineers and combat sentry frigates could not be built.
  • This was due to a rule change in how self-building units work, and these happened to inherit some improper self-building xml.
  • Now they properly are able to have their self-building xml overrideen to 0, which makes them work again while still keeping the nice new rules in general.
  • Presumably these were the only two ships affected (units that normally are planetary but can be used in battlestations with copy_from variants), but if there are more the fix is a quick xml adjustment.
  • Thanks to Ryulong, Afferian, Daniexpert, ArnaudB, Vortex, ckellsworth, zerschleisser, Riken Avadur, Maggo 0815, daimyo_willem, XTRMNTR2K, and Distuth for reporting.

Balance Tweaks

• The Nanocaust can now use fireteams; like marauders, enable "Tactician" mode

• Tactician is now the default for marauders and nanocaust

• Some minor buffs to how quickly marauders can consolidate their planets

• Sabotage hack duration 30 -> 15, Cost 20 -> 15.

• Slight increase of Super Terminal response intervals.

Version 1.303 AI Hunter Fireteams For All

(Released January 13th, 2020)

• Build categories on the sidebar now sort their items by the name that they show in the sidebar, not by the actual full name of the entity. Sometimes this is different, and it makes it hard to find things when it is.

• What factories are up to is now shown even on the brief tooltips, not just medium and up.
  • Thanks to several players for suggesting this.

• Several improvements to what factories show when they have no work to do on various fleets.

• Put in some fixes to an exception that could happen in the mercenary code, and also made it more informative if it happens again.
  • Thanks to Daniexpert for reporting.

• The "GAAAH! We have a command we need to execute during frame" error has finally been retired. Instead it now just executes the command late, which will be a desync in multiplayer that it can fix on its own. Better slightly late than never, in that case. In cases for single player it literally won't affect anything.
  • Thanks to NRSirLimbo for the most recent report.

AI Improvements And Related Fixes

• Some bugfixing/IQ enhancement for the AI. AI threat against players had a deplorable habit of not realizing it was supposed to be against the player, and getting distracted by any other minor faction in the game. This was A. making the AI threat not press home attacks and B. making the threat not join the threat fleet appropriately.
  • From a discussion on discord with a number of people about why the hunter fleet seemed to be absent. This should be a big improvement.

• Fix a bug with assassin mode (aka fireteam) hunter fleets where they were using stale/invalid data to decide when to attack. This usually meant they would fling themselves onto your defenses with reckless abandon

• Fixed up a wide variety of places where RemoveEntity() was not being called properly when removing entities from a speed group.
  • This should lead to more correct behavior in group-move for players, and probably it will help with exos and fireteams and whatnot that are also using speed groups.

• NPC/AI group move now works like it used to (more or less) prior to the player-specific group move enhancements. This keeps things like exos moving at expected speeds, for example.
  • Several bugs were fixed in this whole area as well while we were at it, including some things getting left in groups they should not have, and overriding speeds being forgotten when a compound command was given to units that were already in group move, etc.
  • Essentially the single group move command now works one way for players and one way for everyone else.

• The Assassin hunter fleet type has been removed, as that was just for fire teams. Now all of the non-defensive hunter types use fire teams.
  • This is a pretty scary update to the hunter, making it so you no longer have to opt in to using their new exciting behaviors!

• Fireteams in allied factions can now coordinate their assaults. AI-allied fireteams can also coordinate with AI threat forces

Version 1.302 Frigate Empowerment

(Released January 12th, 2020)

• Added a new amount_added_to_range_per_ship_of_this_type_on_planet for ships, which allows for ships of a certain type to get a bonus of that integer (for instance something like 50 or 500 or whatever we want) for each ship of that same type on the planet beyond the first.
  • This currently gives the benefit to all systems of the ship, whether they are weapons or not.
  • This allows for the "Networked Targeters" type of mechanic that RocketAssistedPuffin thought up.
  • Thanks to Puffin for suggesting!

• In the lobby, it now says "Intensity" for factions, like it does in game, rather than saying Strength. Strength means something else in-game, so keeping this separate and consistent is helpful for clarity.
  • Thanks to Ovalcircle for suggesting.

• For external invulnerability to be granted, now the granters have to either have the tag "InvulnerabilityGranter" on them, or be of type guard post.
  • This lets things that would become invulnerable do far less checking, thus being far more efficient about it.

Balance Improvements

• Infinite-ranged ships now have some new logic that should set them to always attacking ONLY the types of ships that they prefer to shoot (based on your selection) if those sorts of targets are available in their current system.
  • Thanks to DEMOCRACY? DEMOCRACY! for reporting.

• Ships that are crippled no longer provide vision to the planets they are on. People were able to use crippled flagships as scouts.
  • Thanks to Fluffiest for reporting.

• Frigates now automatically have 1/3 as much priority as targets for enemies to shoot. They should feel more beefy now.

• The deprioritization based on overkill or frigates now only happens if the potential target is "not my special target," meaning not set to specifically be what the player ship shoots at, or the strongest tractor beam grappling the ship.

• The frigate deprioritization now only affects player frigates. Won't help outguard or other factions or AIs or zombies.

Bugfixes

• If a forcefield is sitting on top of a wormhole, it will block enemies from going into the wormhole even if the simulation speed is very high or coarse background processing is on.
  • Thanks to a variety of people for reporting, including Waladil, MatterofLight, and KDR_11k.

• Fixed a bug where the targeting was deprioritizing anything that would be overkilled, and not factoring in stacks when doing so. This led to large things being prioritized more in general by ships.

• Fixed an exception that could happen when disbanding fireteams if they did not belong to the scourge faction, thus leading to ships no longer moving.
  • Thanks to Histidine for reporting.

• Put in some fixes for an exception that could happen inside GetFleetCap, particularly for mods.
  • Thanks to Flypaste for reporting.

• Fixed a longstanding bug that could happen in LowerOrRaiseGameSpeedStyle if you tried to raise that kind of alternative game speed increase too many times.
  • Please do note that increasing the game speed in this particular way will absolutely hammer even a top-end CPU and probably lead to worse game performance despite not affecting gameplay accuracy. It's kind of meant for computers that don't exist yet, which is why we haven't had anyone run into this before now.
  • Thanks to Daniexpert for reporting.

• Fixed a probably-rare exception that could happen during tooltip generation for factories, most likely related to cross-thread updates.
  • Thanks to Daniexpert for reporting.

• Fixed a RenderShip error that could happen in some rare cases as ships were dying.
  • Thanks to NoMoreBlender for reporting.

• Fixed a variety of possible exceptions that could happen during loops through certain entity lists if the list changed during the loop. This is somewhat a side effect of more parallelism, but was already a thing that could happen prior to the most recent updates just because of what we already had in parallel. The game already was guarding against the most common cases where this could happen, but not another few subsets. It now guards against them all.
  • Thanks to Daniexpert for reporting.

• Fixed a rare exception that could happen inside GetWormholeToOtherPlanet in entity orders.
  • Thanks to Daniexpert for reporting.

• Fixed an exception in the claiming code for neutral entities that could happen and then spam the log endlessly.
  • Thanks to Daniexpert for reporting.

• Fixed a really rare and strange error that could sometimes happen in FramePartTimings. This happened to Chris periodically for the last year, but it had never been seen "in the wild"" until Daniexpert ran into it. We thought it was just related to the dev environment somehow, but it seems to be a cross-threading thing that can rarely happen on startup if things go just wrongly. The game itself will run terribly and spam the world if this happens, so making it gracefully recover is a good thing.
  • Thanks to Daniexpert for reporting.

• Fixed some typos in the AIP history where it had double "from" and where it would try to say what planet you captured a planet, but always say "null" instead since we don't actually track the linked planets to things.
  • Thanks to Histidine for reporting.

Version 1.3 The Grand New AI

( Released January 10th, 2020 )

• The multipliers in the interface in the bottom left are once again literal (1.5x, 2x, etc, up to 5x).
  • Thanks to folks in Discord for suggesting.

• Some updates to the Octopus map generator from Tadrinth

• Added some more tips, including explanations of Wave, CPA, etc.

• Some ships are never eligible for repairs because they self-attrition, and now the tooltip says that so that it doesn't seem like a bug when they are not repaired.

• The "investigating starfields" line on the startup sequence is now randomized with a variety of silly things, because we boot the game so often and get bored of the same text. Enjoy!

Bugfixes

• Fixed Forcefields being non-functional in the prior build.
  • Thanks to Histidine, ArnaudB and tadrinth for reporting.

• Fix a visual bug where allied forces were sometimes reported as having negative strength
  • Thanks to Histidine, NRSirLimbo and Daniexpert for reporting.

• Fixed a bug in the recent internal versions where it was showing lots of the text as brown in the C-click menus because of an un-closed color tag.
  • Thanks to Astilious for reporting.

• Fixed a bug where the achievements that you had previously completed locally were not properly able to be loaded, and thus would be awarded to you again every time you restarted the game.

• The "FleetMembership was null on unit" error no longer shows, and instead the game mostly-silently just fixes this in the background.
  • However, it also increments CountOfNullFleetMembershipsFixed, which is now shown in the escape menu as "Null Mem Fixes" so we can see if that's skyrocketing for some reason.
  • This prevents a bunch of the marauders from being lost and problematic in certain savegames that may have had prior trauma or who knows exactly what the reason was.
  • Thanks to eppiox for reporting. This goes back to prior to the current beta versions.

• Put in a fix for an exception in DoEntityFramePlanningLogic_TargetPrioritizing, such that in particular even if there is an exception it won't cause all targeting to fail forever after that. It will give us a better error message as well as not fouling up the whole system.
  • Thanks to NRSirLimbo for reporting. This goes back to prior to the current beta versions.

• Suppressing the error "BUG: tried to go past the end of workinShipPool," which was harmless.

• Fixed a bug that could happen in some of the patrol code since more than one faction now uses that. It was particularly likely on multithreaded background factions, but could crop up even in normal play.

• Warden Fleet Bases are no longer considered reinforcement points, as this caused some weirdness with them, and could result in it being MIA over time as units were stuck inside.
  • Thanks to ArnaudB for reporting something about reinforcements, which led into this discovery which was possibly a large root cause.

• Previously it was possible for map generation algorithms to generate links/wormholes to themselves, which would throw off all manner of logic. Rather than leaving that to individual map authors to fix themselves, the game now checks for those and automatically repairs them, including in existing savegames.
  • From testing through the various map types, it looks like this was only happening with linked rings map type and its subtypes, but you never know what might have arisen in the future.
  • We're not really sure what negative effects this was having beyond strange visuals, but it probably affected AI decisions in terms of how strong a planet and its "neighbors" were by double-counting the planet itself, and it may have also impacted pathfinding between planets in a negative way.
  • Thanks to CaptainTaz, Acuzik, and Rivet for reporting.

• Fixed a bug in general in the code where it could give the wrong mark for a fleet membership if it passed in the wrong ship/structure type line. This probably caused some strangeness in the AI transforming units, it's hard to say.
  • This also led to an exploit where you could have a higher-mark command station of one type (military, whatever), then switch to a different command station type and keep the higher mark.
  • All of that is now fixed, although it won't retroactively fix any existing savegames.
  • Thanks to RockyBst for reporting.

• Improve the 'capture flagships' objective hovertext with more colour, to improve readability

No More Ship Pooling

• The "BUG: Could not find a wormhole between" two planets wormhole movement command is no longer silent, but now pops up as an error in your face.
  • Additionally, all wormhole commands now should have a reason code for the command (so we can fix cases like this), and this shows the reson code.
    • The sole purpose of the reason code is to help us find the places where wormhole paths are calculated incorrectly.
    • But we can't actually REQUIRE the reason code, because older savegames will pop up with errors if we did so.

• Found some major bugs in AI_GO_RAID and AI_FLEE_THRT.
  • It now logs different errors if trying to send ships from disparate planets along a path from a starting planet that doesn't match.

• BUT, really, the true bug behind all of this is that we are holding references to GameEntity_Squad objects in various background threads, and those are not reliable in their identity.
  • Because of pooling, it's possible for an entity to be an AI ship for a while, then die and get reborn as a player ship. The errors we were seeing were with player ships being ordered around as if they were threatfleet.
  • The natural way of solving this that we had developed for the game was to use SquadWrapper, which adds a layer that prevents such mixups from happening.
  • The amount of code rework to make SquadWrapper happen all throughout the code is incredibly huge, however, and would be problematic for a wide variety of reasons. Even if we managed to change those thousands of lines of code required, that code would then run more slowly.
  • So the only solution, in the end, is... to stop pooling the GameEntity_Squad objects. All other types of objects can continue to be pooled as they are now, because nothing needs to hold onto such long-term references as with these.
  • This will cause a lot more weight on the memory garbage collector (GC) during heavy fighting or other circumstances when many ships are being created or killed. In the past, this was unacceptable.
    • However, this is now mitigated by the fact that unity has more recently implemented a time-sliced garbage collector, and so the hits to it are far less severe.
    • And even beyond that, we've implemented stacks of untis, and kill units "off the top," which means that the number of times we have to kill or create GameEntity_Squad units is a whole lot less.
  • There is a tradeoff here for sure, but in the end this also means we can then stop using SquadWrapper in other places, which in turn will improve some efficiency (mildly) in other areas of the code.
  • This does also mean that if background factions don't ever check for dead entities and prune them, they will wind up causing these entities to never be garbage collected and thus lead to an eventual memory leak. Previously it was that they would have incorrect game function, so this is preferable.

• No longer using squad wrappers for the factories calculations on the fleets. This has a very tiny benefit to performance, almost nothing.

More Performance!

• VASTLY improved the performance of probably most savegames, but certainly certain ones, by making the following changes.
  • (The performance bump in the "performance concern" save from Democracy is from about 10% on Chris's machine to full speed.)
  • The following kinds of metal flows never even get checked anymore except for player ships: SelfConstruction, FactoryConstructionForPlayerMobileFleets, ClaimingNeutrals, RebuildingRemains.
    • If any other non-player factions ever need to do these, we can deal with that, but frankly these are all player-centric things. However, tons of NPC and AI faction ships had one or more of these, and would check thorugh them in an expensive way every frame.
  • The following kinds of metal flows never even get checked anymore except for non-AI ships (so this means players and other factions do these): RepairingHullsOfFriendlies, RepairingShieldsOfFriendlies, RepairingEnginesOfFriendlies, AssistConstruction.
    • This means that engineers in the hands of the AI are absolutely pointless in every way. And the medic gunboats in the hands of the AI lose their medic capabilities. The AI could field ridiculous numbers of meidc gunboats, which are computationally very expensive, and it also made the battlefield more chaotic.
    • Given the AI doesn't actually pay metal to repair things, just not letting the AI make repairs in the (already super rare) cases where it would try to do so is a big performance gain. But things like outguard and other factions may need to help themselves or player ships, so them still checking it is good.
  • And then any faction can still do: BuildingDronesInternally. So no change there.

• Then we took this even further, changing the efficiency of metal flow checks from millions of calculations and loops per second to mere thousands.
  • In other words, as Badger phrased it, O(n^2) == > O(n) ==> happy.
  • Essentially something that executed in exponential load as there were more units and more things to repair the units has become something that executes in close to linear time.
  • There are a variety of further shortcuts that we put in place that skip processing entirely for planets/factions where there's nothing possible to find, but before it wasted some CPU time checking anyway. We use slightly more RAM to be able to figure all that out, but it's maybe a MB or two.

PFP Goes Mainstream

• In the performance section of your personal settings, we had a setting called "Advanced: Run Massively Parallel Faction Processing"
  • That has been removed, and replaced with a new option called "Disable Parallel Faction Processing".
  • The default is essentially now that the parallel processing is on, whereas at first it was off by default.
  • The purpose of keeping this option at all is for people with very few cores on their machines.
  • Description of the new setting:
    • Only matters in single-player, or the host in multiplayer. Parallel Faction Processing (PFP) lets the factions in the game be substantially smarter and faster in how they react to things, and is most notable at higher simulation speeds (5x, etc).
    • On a lot of gaming-style computers, not only does the PFP function make factions and the AI smarter, but it actually can improve performance. We highly recommend you play with this on if your performance in the game is looking suitable.
    • If you are on a computer with very few cores, then we provide the option here to disable PFP so that the processing is time-sliced. This makes the AI and factions notably slower to react, and the higher the simulation speed you choose, the worse it will get.
    • If you play at 5x sim speed and have PFP off, we don't consider that a valid way to beat difficulty 10 AIs -- they're half-braindead, so it's not really a fair fight. With PFP on, or at 1x sim speed, you'll see the true fury of the maximum difficulties.
  • Huge thanks to Badger and some others for diagnosing this problem.

Balance Tweaks

• AI Overlord AIP on death 120 -> 37.

• AI Overlord Phase Two AIP on death 20 -> 37, durability increased 25%, Parasite Bolt damage doubled, Fusion Bomb damage increased 50%.

• Both AI Overlord Phases grant 5,000 Science and 30 Hacking on defeat.

• All Dire Guard Posts increase AIP by 8 on death.

• Increased the Instigator time interval between each effect triggering.

• Troop Accelerator effect 2x -> 1.5x.

• Reduced AIs initial strikecraft a bit.

• Dire Forcefield Guardian forcefield radius increased 66%.

• The ai_planet_defense_multiplier values were a bit on the high side, previously.
  • Notes: We made mk3 the baseline for balance just because it's in the lower-middle range and something that is very common. It's the start of the real power curve, while mark 1 is incredibly underpowered and mark 2 is just somewhat underpowered. From mk3 up it's meant to be more of a gradient, but with 7s being somewhat overpowered. So really 3-6 are a good gradient is the goal.
  • In-game the stuff that is within 1-2 hops of a player homeworld is weakened no matter what mark it is, already, incidentally. And AI homeworlds get a major buff even above mark 7, too.
  • Before the marks went 0.6 on budget for mark 1, 0.8 mk2, 1 mk3, then a crazy 1.2 for mk4 (given the higher strength of those units at those planets that could be a jump from 20 to 120 strength), then 1.6 mk5, 2 mk5, 2.5 mk7
  • So let's try this instead: keep all of that the same, but make mk4 0.95 (so smaller budget but WAY more powerful stuff), 1.05 mk5, 1.15 mk6, and then 1.8 mk7. These are the fortresses.

• Neutering of AI planets is now more effective.
  • The resulting percentage of "number of reinforcement points divided by max seen here" now squares itself. So 0.8 becomes 0.64, it's an exponential falloff.
  • But don't let it go below 0.05, or 5%, as the multiplier.
  • Additionally, if there are no reinforcement points left at all, don't let the AI have any reinforcement budget at all.
  • And if there is only ONE reinforcement point left (assuming this is the command station, but you never know), then it automatically drops to 0.05, 5%.
  • People would fully neuter a planet and then still see the budget just be far too high.

• If there is more than twice the "enemy" strength on an AI planet ("enemy" here meaning you-the-player, your friends, or mutual enemies of you and the AI), then the AI now loses all its reinforcement budgets at that planet. But only after the first 5 seconds of the game, so this doesn't impact mapgen with things like nanocaust seeding or whatever else.
  • Thanks to a number of people for suggesting.

• Improved some of the mapgen logic to have different logic on how it's able to seed things when quarters get tight. There are now several different modes for expansion of the seedable area, which for instance on maze map types and other low-granularity types should make it so that you still get a global command agumenter within 2 hops, even if it's not within 1.
  • Thanks to Puffin for suggesting.

• Order of mapgen seeding was fleets, then tv, then ars, then gca, then fce.
  • This has been improved to fleets, gca, ars, tv, then fce.
  • Thanks to Puffin for suggesting.

Planet Mark Level Assignment Rework

• The code that determines the mark levels of planets has been significantly overhauled. The practical upshot of this is that the planetary mark levels are now more reasonably distributed. Here's how it works now.
  • For each Player homeworld, the game assigns low mark (marks 1-3) planets nearby. Note that if the highest ai difficulty is <= 5 has some extra low-mark planets
  • For each AI homeworld, the game assigns high mark (marks 5-7) planets nearby
  • For the remaining planets, they are randomly allocated based on percentages. The base values for those are as follows (with minor adjustments for particularly low or high ai difficulties)
    • Mark 2: 5%
    • Mark 3: 25%
    • Mark 4: 35%
    • Mark 5: 30%
    • Mark 6: 5%

BETA Version 1.104 The Speed We Need

(Released January 7th, 2020)

Hi there! To play this on Steam, please right-click the game, hit properties, and go to the betas tab. Then go to the current_beta option and it will download this. We could really use feedback from a variety of folks as we build in the remaining stuff that we have planned for the 1.3 build that we plan to officially call all this once we're sure it's stable. Please take a moment in particular to try the new parallel processing and see if you can run it and how much smarter all the factions are at high speeds if you play at those speeds.

• Updated the test chamber so that you can better assign things like allied factions and so on.

• Game Speed Types of Faster Ships, and all those above, now only have a 1.4x ship movement speed multiplier, instead of going up to 8x at the highest setting.

Performance

• Precalculated a lot more pieces of data that get checked very frequently, giving general minor speed boosts for things that get checked millions of times per second cumulatively.
  • It's the sort of thing that is really a minor improvement per check, but the volume of checks makes a big deal in a variety of circumstances.
  • Some of this stuff was as minor as avoiding an extra method call on the stack, virtual or otherwise, and others were as major as avoiding internal loops over systems once per frame per unit.
  • More such improvements could be made, but all the ones that were likely to be any notable performance hit have been fixed at this point.

• The game now only goes up to the equivalent of what the old 5x was, but labels that as a new 9x as the top end.
  • We were finding that above these higher speeds, accuracy of battles was highly off. You'd essentially be playing against a lobotomized AI on anything above 5x, and above even 3x it really wasn't quite the same in terms of battle results.
  • The new scaling actually shows how it improves overall simulation performance (relative to realtime), so if you had a 50% speed of frames and you move up the sim speed it could accurately show you as having actually 250% clock speed if you max out the multiplier. You can typically get just under 500% of clock speed if your CPU is keeping up and you go up to the new 9x.
  • There are still things that don't work as accurately when you overdrive things to this degree, but it's not absolutely on easy mode in quite the same way anymore.
    • As an example, it would typically take the Warden Fleet was taking 90-120 seconds to notice that you'd attacked a planet at the old 10x speed. So you could go capture a planet adjacent to a major warden fleet force before they would even think about joining the battle.

• On tier 3 planets, guardians that patrol don't bother patrolling. It eats up CPU time (and later bandwidth) for no purpose at all, since it's invisible and doesn't impact your units either.

• Renamed a bunch of methods to be a lot more clear what is sim and what is not. Turns out lots of stuff in the factions code that we thought might not be okay actually is, and it is now marked as such.
  • Other bits of the code we marked as "definitely breaks in multiplayer" or "not sure if breaks in multiplayer" to come back to. Multiplayer can recover from it, but it would be highly wasteful of network traffic.

• Noticed a huge number of commands being sent for SetBehavior, so split that out some so that we can use the escape menu to try and figure out why that's the case.
  • Split all of the "set behavior" commands out into different variants so that in the escape menu we can see what is causing a bunch of them if there are a bunch being sent.
  • Then used that to fix a general performance regression in the betas that was sending a ton of SetBehavior_FromFaction_ITractoredShips for ships that were not relevant for that. This was the biggest part of the performance regression seen by Democracy, but it was also in all campaigns.

• Fixed a number of leaks of gamecommands out of their pools. This isn't strictly a memory leak, but it acts vaguely similarly and doesn't help with garbage collection at any rate.
  • Essentially if "you" (the programmer or modder) queue a gamecommand, it will automatically go back in the pool after you use it. However, if you decide not to queue it even after pulling it out of the pool (it turns out there are no relevant entities, etc), then you have to call ReturnToPool() on it. In a few cases these were just being set to null instead, which doesn't help much.
  • In some other cases here, we didn't really reduce the turnover of the gamecommands, but we did make improvements to places where it might send a largely-pointless gamecommand saying "send all these ships through this wormhole path" and the list of ships turned out to be empty, etc. This sort of thing helps with performance even in single player far more than one might expect.
  • There wasn't anything truly egregious, but it was enough to be a drain. There are probably more such things, of lower incidence. Watching the escape menu numbers while unpaused gives clues as to where problems might be.

• The way that metal flows are calculated are now literally an order of magnitude more efficient in terms of how many things they allocate and why. They now lazy-allocate things when they really have to, and otherwise just skip creating flow objects if there's nothing to do.
  • This was another major component of Democracy's slowdown, and this is extremely longstanding in the game in general (as old as the game itself), but it's not something that fully fixes the particular performance hole we were chasing. At least not fully.

Balance Tweaks

• V-Wing range 4,200 -> 3,200.

• Fusion Bomber range 4,000 -> 4,200.

• Parasite range 3,200 -> 6,000.

• Sentinel Gunboat tachyon range 1,700 -> 3,200.

• Ranger tachyon range 3,200 -> 5,000.
  • Thanks to tadrinth for some notes on the above units.

• Consolidated all the Auto Bomb variants into a lower cap style of ship, with health and damage increased to compensate.
  • They should be more or less very similar, just with less performance strain from units constantly dying then being rebuilt.
  • Cluster Bombs only spawn 3 Mini Bombs now instead of 5, but their damage is increased to compensate, beyond what was already done above.

• Consolidated the Railpod into the same style.

• Vanguard Hydras now spawn 3 heads on death instead of 5, stats bumped to compensate.

• Stingray Hydras now spawn 2 heads on death instead of 3.

• Automated Construction Bots now spawn only 3 Mini versions, stats bumped up to compensate.

• Slight reduction to most Frigate metal and energy costs.
  • Going slow with this, as increasing energy cost later if it's overdone can cause brownouts in existing saves.

BETA Version 1.103 Tooltip Sweet Brevity

(Released January 6th, 2020)

Hi there! To play this on Steam, please right-click the game, hit properties, and go to the betas tab. Then go to the current_beta option and it will download this. We could really use feedback from a variety of folks as we build in the remaining stuff that we have planned for the 1.3 build that we plan to officially call all this once we're sure it's stable. Please take a moment in particular to try the new parallel processing and see if you can run it and how much smarter all the factions are at high speeds if you play at those speeds.

• Wave tooltips now correctly show 'adaptive' or 'random' where appropriate, instead of always telling you the real AI type
  • Thanks to zeusalmighty for reporting

• The 'remove unlock variance' option now applies to fleets you can capture
  • Thanks to CyberKun for reporting

• The hack options for ARS grant ship line now correctly report how many ships would be granted, as does C-Clicking on the ARS
  • Thanks to Daniexpert for reporting

• Maps now default to having 7 FCEs instead of 11 (there were just too many before)

Tooltips Three Modes of Verbosity

• TLDR of the below: There are now three levels of detail on the planet and ship tooltips: brief, medium, and full.
  • The default is now brief, which is new for both planets and ships, and is WAY smaller. Just the real basics, easier to understand.
    • It's probably worth keeping this as the default even if you like more detail, just because these specific bits are the really core facts about a given ship. We may pare a few bits down even more. BUT if you prefer the old style of tooltips...
  • Medium is what the old "brief" used to be, and it has very slightly less detail than before. In the main it's better while not being much less detailed than before. A lot of the contrast of this with the other view is something that highlights the second tier of details better than ever, which is kind of cool.
    • If you want this to be your new default, just turn on a setting and it will be. You can't shift "down" to brief if you do that, though.
  • Full is what it always has been, tons of information. You now have to hold ctrl and alt to see it, while ctrl OR alt will give you the medium view.
    • You can also see full as your default, as you always could, if you prefer. However you can no longer go "down" to medium or the new brief from the full view if it's your default.

• Old hotkey being removed: Toggle Ship And Planet Tooltip Detail Mode
  • Description: By default, the amount of information about ships and planets is abbreviated. Hold this key to see the full thing.
  • In the tooltips section of the settings menu, you can switch it so that the default is showing the full text, in which case holding this causes the abbreviation.

• New hotkeys added: Increase Ship And Planet Tooltip Detail (Key 1) and (Key 2)
  • Description of both: By default, the amount of information about ships and planets is heavily abbreviated. Hold this key alone to see the medium detail view. Hold this AND the other 'increase detail' key to see the max detail.
  • In the tooltips section of the settings menu, you can adjust the default up to show medium or high detail. In those cases, there's no way to see the abbreviated versions.

• Old game setting: Show Ship And Planet Detail Mode By Default
  • Renamed to Show Ship And Planet Complete Detail By Default
  • New description: Normally ships and planets show a very condensed amount of information about themselves in their tooltips. However, you can hold a key (shown at the bottom of those tooltips) to make them show a little more info or a whole lot more info. If you prefer to see the complete info by default, then you can enable this option.

• New game setting: Show Ship And Planet Medium Detail By Default
  • Normally ships and planets show a very condensed amount of information about themselves in their tooltips. However, you can hold a key (shown at the bottom of those tooltips) to make them show a little more info or a whole lot more info. If you prefer to see the medium level of info by default, then you can enable this option.

Balance Tweaks

• Spider reload time 4s -> 3s, shots per salvo 1 -> 3, engine stun per shot 12 -> 6, damage 96 -> 45.
  • Tarantula is same.

• Terrier reload time 4s -> 3s, shots per salvo 1 -> 3, engine stun per shot 16 -> 8, damage 51 -> 30, speed 1,000 -> 1,200.

• Paralyser reload time 9s -> 4s, damage 135 -> 68, shots per salvo 1 -> 2, paralysis per shot 4 -> 2.

• Railpods use the same self damage mechanism as Minefields, now self destruct in 2 shots regardless of other factors. Reload time 4s -> 2s.

BETA Version 1.102 Fireteam Refinements

(Released January 3rd, 2020)

Hi there! To play this on Steam, please right-click the game, hit properties, and go to the betas tab. Then go to the current_beta option and it will download this. We could really use feedback from a variety of folks as we build in the remaining stuff that we have planned for the 1.3 build that we plan to officially call all this once we're sure it's stable. Please take a moment in particular to try the new parallel processing and see if you can run it and how much smarter all the factions are at high speeds if you play at those speeds.

• Add a "Select all non-flagship military on planet" selection option
  • Suggested by Iocaine

• Some minor improvements to fireteam based factions

BETA Version 1.101 Ship Cap Reversions

(Released January 2nd, 2020)

Hi there! To play this on Steam, please right-click the game, hit properties, and go to the betas tab. Then go to the current_beta option and it will download this. We could really use feedback from a variety of folks as we build in the remaining stuff that we have planned for the 1.3 build that we plan to officially call all this once we're sure it's stable. Please take a moment in particular to try the new parallel processing and see if you can run it and how much smarter all the factions are at high speeds if you play at those speeds.

• Fifteen new achievements have been added, to account for the new adaptive AI types. That brings us up to 154 achievements in total!
• Added "Remove Unlock Variance in Capturables" option. This option removes the random ranges ships and turrets can be found with, fixing it at a constant average. Suggested by Flypaste, Fluffiest, CyberKun and many others on Discord. Thanks donblas.

Fireteam and Minor Faction changes

• Consolidate the Hunter Fleet and Marauder fireteam logic. This should make it quite easy to add fireteam logic to new minor factions, and allow for improved intelligence of fireteams going forward

• Fix a bug where marauder fireteams weren't always detecting that they had won a battle

• Allied Marauders are back to killing command stations by default, but with a setting to disable it. This is a no-longer-basically-cheating version of "minor factions don't cause AIP increases". Allied Marauders always kill warp gates though. If this works then I'm going to deprecate "minor factions don't cause AIP increase" since that's too cheaty for my tastes

Balance

• In the prior release there was a thing with "growth versus stagnant" multipliers. Those are gone now, reverted to how they were before.

• Also in the prior release, there were a lot of things that didn't get cap increases anymore, but now they work like strikecraft (and thus like they always did, although with some extra clarity because the cap scaling is still iterative as noted last release).
  • Frigates are unaffected by all this, as their scaling was essentially just evened out and they were still "growth style" units.

• uses_growth_multipliers_even_if_stagnant has been removed, as the mechanic it was working with is now gone.

• AI Great Turret health 3x instead of 5x. Tesla isn't mostly in hull anymore.

• Tesla Turret bit more expensive for the AI too.

• Put in some changes to how strikecraft reinforcements are placed, which makes them evenly fill all the available guard posts as much as they can. Previously the logic was really strange and also really slow, so now mapgen is a bit faster yet again (other changes in the prior build also made it faster).
  • So there should no longer be empty guard posts at the start of the game where you run into them and that's strange.

• Also put in a change that allows more than 800 ships of a category (strikecraft, turrets, etc) to be reinforced at a planet at a time if need be, since that is a thing that can happen with strikecraft. It now allows for up to 8000.

• Magnifiers and Troop Accelerators are now set to appear on the galaxy map on planets they are at, like most other "devious devices" the AI has.

Bugfixes And Similar

• Added the ability to mod out or deprecate ship lines in starting fleets or otherwise by setting their max cap to 0, which then takes them out completely.
  • Thanks to Flypaste for requesting this ability.

• Fixed a bug where display_name was being incorrectly blanked out on partial records when reading xml.
  • Thanks to Flypaste for reporting.

• The Adaptive AI types now actually show their names as being easier, harder, moderate, brutal, full, etc, rather than just all showing "adaptive" in the interface. Now you can see what you're getting into!

• Fixed a mysterious bug where sometimes guard posts would not be able to seed during a reconquest seeding. This may have been exclusively related to the adaptive AI type, it's hard to be sure. But at any rate, when it runs into a lack of data on what kinds of guard posts to use, it now chooses what to use properly so that it has something.
  • Thanks to Ovalcircle for reporting.

• Fix a bug where the actual Random AI type was being shown, instead of just "random"
  • Thanks to Kesseleth for the bug report

• Fixed a longstanding bug where draw_in_galaxy_view being true was not enough to make structures or ships properly show up in the galaxy map view.
  • This makes it so that things like black hole machines and so on are visible on the galaxy map for the first time. And ion cannons and mass drivers, etc.

• If a quick start includes a faction that is not present in the installation of a player later trying to load the quickstart (mods, expansions, etc), it now blanks out the offending faction and continues as normal with all the other factions. Anyone who DOES have that faction will see it work as expected, while anyone else will just see it missing but all else well, which is really the best of both worlds.
  • This was affecting a lot of our quick starts in the prior beta build.
  • Thanks to Daniexpert for reporting.

BETA Version 1.1 So Much Stuff We Can't Even, But More Is Still Coming

(Released January 1st, 2020)

Hi there! To play this on Steam, please right-click the game, hit properties, and go to the betas tab. Then go to the current_beta option and it will download this. We could really use feedback from a variety of folks as we build in the remaining stuff that we have planned for the 1.3 build that we plan to officially call all this once we're sure it's stable. Please take a moment in particular to try the new parallel processing and see if you can run it and how much smarter all the factions are at high speeds if you play at those speeds.

• Add the "Extreme" category of Quickstarts, with 2 default, 1 nearly default, and 2 bonus scenarios.
  • Thanks to CyberKun for suggesting the category.

• Ion Cannons and Orbital Mass Drivers will now be automatically targeted by units again, but are set to a low priority.
  • They still seem to like shooting these first however, if they happen to be in the way.
  • This lets factions destroy these again rather than being shot to bits, ignoring them.
  • Feedback is appreciated - this is a fairly opinion heavy thing.
    • Thanks to Ovalcircle for reporting.

• Updated the "Various Weapons" fleet name styling with DEMOCRACY_DEMOCRACY's latest changes.

• Fix a bug where the Random Any ai type could pick 'random easier'

• The Tech History menu (viewable by clicking the Science icon in the resource bar at the top of the screen) now shows the total science you've spent.

• The "Show Entity Strength When Hovering" tooltip has been removed, as we are now going to do this by default. It was strange not showing it.
  • Ships now say if they are showing their own strength or the strength of themselves as a stack when you hover over them.

• Targeting behavior of ships that are freely moving around (pursuit mode, whether of the player or other factions) are now vastly smarter in how they deal with non-combatants in general (things without guns but that need to die).
  • They'll still shoot at them just as frequently as ever IN PASSING, if there's nothing else to shoot at or that thing is the most important priority to shoot at based on the various metrics. But they no longer will specifically pursue those sorts of things with an excess weight just because they happen to be close.
  • If there are non-combatants with a high priority, then ships should still beeline for those just as well as ever, it's worth noting. And if they're not in pursuit mode, then nothing is different at all.
  • The net effect of this is that ships will generally approach and destroy dangerous things like great-turrets before they start messing about with an unarmed guard post or a gravity generator or whatever else. Survivability goes way up.

• Nanocaust construction centers and Marauder Outposts now warp in over time (a short time interval, like 30 seconds to a minute) rather than warping in instantly. This gives their enemies a bigger window to counter attack in.

• The Tech Menu now tells you a very approximate strength increase for both defenses and ships after upgrading.

• Added the ability to hack Global Command Augmenters to re-roll provided turrets. (Thanks donblas)

Optional Advanced: Massively Parallel Faction Processing

• New setting in the personal settings: "Advanced: Run Massively Parallel Faction Processing"
  • Only matters on the host in multiplayer. This lets the factions in the game be substantially smarter and faster in how they react to things, and is most notable at higher simulation speeds (10x, etc).
  • But all this may come at a cost that your CPU can't handle; we're still testing that and would love feedback on the difference you see in simulation speed (the percent under the game speed multiplier) if you turn this on and off.
  • You will have a much fiercer foe at 10x speed with this on, versus an almost braindead one without it. At regular speed it won't matter much between one or the other.
  • We're hoping to build toward this being the default for everyone, but for now we don't want to inflict slower framerates on everyone just so that 10x speed runs smarter. One step at a time.
  • Right now this is off by default, and needs a lot of testing, but amazingly with the current design it did not slow down at all in a relatively-small-number-of-factions game on Chris's i7-6700 HQ. Much more data is needed.

• You may experience some strange and awful bugs by enabling this, at least at first, as the factions have never been parallel in quite this way before. This may tank performance or cause lots of strange errors, and in most cases we can find and fix them if you send us the errors or the savegame with the bad performance. In most cases it would be two threads from different factions trying to use the same list or other collection. To report: https://bugtracker.arcengames.com/
  • Thank you!

Fireteams

• Fireteams are a concept developed by Badger to allow non-player factions to flexibly coordinate a variety of simultaneous actions. It's the smartest strategic AI mechanism in either AIWC or AIW2 (in theory at least). Fireteams were developed to power the Scourge, a feature for the first DLC, but we can use the same basic logic for other minor factions to give those factions a nice intelligence boost. We are backporting R&D done for an expansion-only feature to the base game because the base game isn't hard enough yet. Mwahahaha.
• Allied ships using fireteams (just marauder raiders for now) will show you what that fireteam is planning on doing in the verbose hovertext, to make coordinating between you and your allies more possible.
  • The simplest description for how Fireteams work is like this. All units for a given minor faction are assigned to small fireteams of 1-4 strength, so there will be lots of fireteams. Each fireteam determines its own objectives independently. If multiple fireteams have the same objective then they will coordinate their attacks.
  • This is currently available for the Hunter Fleet (via the 'Assassin' type in the Game Lobby) or the Marauders (via choosing "Intelligence: Tactician" in the game lobby).
    • The Fireteam implementation for Marauders and Hunter Fleets is brand new, so I expect some teething pains and would love feedback (with save games)

All-New "Adaptive" AI Type

• Add in a new Adaptive AI type, which alternates between available types every so often. They work similarly to Random, in that there is "Adaptive Easier", "Adaptive Brutal", "Adaptive Any", and so on.
  • Change interval is in XML, and is once per hour. It won't change any existing units, but reinforcements/wave composition and so on will change.
  • There are currently no Achievements for these AI types
  • Thanks to Flypaste for the suggestion

Balance Tweaks

• Orbital Mass Driver reload time 9s -> 6s.

• Hack Ion Cannon and Mass Driver now takes 2 seconds, rather than 15.

• Ion Cannons and Orbital Mass Drivers that the player either hacked or bought now die to remains.

• Replaced Military Command Stations engine stun with paralysis.
  • Engine Stun on this thing could be fairly exploitable, allowing it to hold off incredible amounts of enemy strength.
  • However, that was only possible if the enemy could be slowed at all. If they couldn't, it tended to fall relatively easily.
  • Swapping it to paralysis should let it not be as strong in the old ideal case, but also improves it in the worst possible case.

• Dire Nucleophilic Guardian damage 4,000 -> 8,000, shots per salvo 6 -> 3.

• Reduced range of Tesla weapons very slightly (10% ish?) and bumped up the splash size by 15% ish.
  • What this means is they effectively act more or less the same, except will not waste their initial shots on the first singular ship to come into range, and will tend to hit more beyond.
  • This was split between both the range and splash size to avoid making the visual effect too much larger. Shouldn't have much impact on gameplay, however.

• Dire Tesla Guard Post now has the fortified effect on it.

• Hydra heads and the like cost no energy.
  • This was the cause of mysterious brownouts.
  • Thanks to DEMOCRACY? DEMOCRACY! for reporting.

• Reworked the way that wave compositions are filled to be more efficient and ensure that absolutely as much of the budget is spent of a wave as possible.
  • Thanks to Puffin for discovering that this was not happening.

• In the normal non-stealth-planet themes, the stealth guard posts are now 1/50th as likely to appear as before. There were vastly too many of these showing up in the galaxy prior to now.

• Dire Tesla Guardian damage 2,500 -> 5,000, now has the same durability as the other Dires.

• Reduced range slightly of MLRS, Concussion and Nucleophilic Guard Posts.
  • The main contributors to the "small world problem".

• Increased the cost of normal Guardians by 50%.
  • This is in preparation of the next update, in which these'll be getting buffs. It's done in two stages to avoid current saves suddenly getting much harder.
  • With this, old games will be similar, and new ones will have the correct Guardian count for when the buffs hit. So for a time, Guardians'll be a bit easier.
  • This is part of making Guardians scarier individually, as right now they can feel a bit flimsy and kind of just too close to Strikecraft overall.

• Okay, so this is a kind of funny story... cough.
  • Essentially, various ships and turrets and whatever have modifiers to kill other specific types of ships or structures with certain characteristics, right?
  • So something is really good at killing structures in general, or high-energy-usage stuff, or items with thin hulls or whatever else. Easy enough.
  • The problem was, we had these ships getting BETTER at killing those same things at higher marks, while also getting a general damage buff.
  • Puffin's example, as he was the one to realize this:
    • MK1 Pike Corvette does 45 damage, 3x to high armour, 2x to high hull remaining, for...270 damage.
    • MK6 is 189 damage, 5.5x to high armour, 3.5x to high hull remaining, for...3,638.
  • As he put it, "I feel like I know where the "late game is easier than early" problem is."
  • We may need to rebalance some of these units to generally have higher specialized damage or higher damage in general, BUT, we've now removed the increase in damage multipliers from the following categories of stuff:
    • Strikecraft (yours and enemy of course), Turrets (ditto), Frigates (mostly yours), Guardians (mostly enemy), and Guard Posts (mostly enemy).
  • We've LEFT this monstrosity of multiplication on a few specific things:
    • The Rorqual Hegira Ark (yours), AI Fortresses (enemies), and any battlestations (yours) with weapons.
    • This may be something we want to give to a few other special units of the AI or you, we'll see, but it would be specifically for Very Special Units.

• Metabolizing Gangsaw armour 60 -> 90, reduced count found in ARS and Fleets.

• Consumer Starting Fleet now uses normal Gangsaws instead of the Vicious variant.

• All normal Turrets (i.e not Plasma or Beam) have armour of 80mm.

• Doorkicker Starting Fleet now uses Vanguard Hydras instead of the normal one. Also has 25 instead of 20.

• Nucleophilic Guardian speed 600 -> 1,000.

• The "singular freaky surprises" of AIs now will only appear on planets between marks 2 and up, rather than every planet owned by the AI. No surprises TOO early in the game, then, with golemite and similar.
  • Thanks to Puffin for suggesting.

• GCAs now have a higher chance of having an extra "OtherDefense" item at the end.
  • Thanks to donblas for a suggestion in this area.

• Reduced the cost a bit of Weaken Turret and Weaken Guard Post hacks.

Ship Cap Calculation Refinements

• The way that the caps for ships are calculated is now vastly different, and a bit more expensive on the CPU (but worth it).
  • Essentially before it was using a floating point number to get a result, and then rounding up. So very often this would lead to things not actually increasing in a manner that you'd expect, or frigate counts not increasing at all for several marks before finally increasing.
  • Now it applies each multiplier sequentially to the original number, and then rounds up each time in between, so you always get the expected result.
  • This means that, for example, the mark 3 frigates of things with cap 1 now have a cap 3 instead of 2. The end result is usually pretty much the same at mark 6 and 7, or close, but the intervening marks are now more accurate and we shouldn't have people with lots of confusion on their caps not increasing like they would expect.

• There are now three different ship cap growth styles, rather than one:
  • Stikecraft (works about the same as it always has, although will give you slightly more now, working as expected because of iterative math).
    • This was already pretty much working fine.
  • Frigates (much lower growth rate than before, but ends up in a similar place numbers-wise, however gives you what you'd expect rather than something surprising now).
    • Numerically this was balanced fine, but people couldn't understand why it jumped around strangely because of rounding with fractions.
  • Everything else (does... not gain cap by leveling up).
    • Wait, wut? Hold on a moment, though: one of the most annoying things ever is having to go back and put out more mines or turrets later on on all your planets because you just increased your caps. That still will happen from GCAs, but it's at least less common because general techs won't cause this to happen.
    • Besides which, performance can be a real pain with turrets if there are just excessive numbers of those. How about we increase the strength without that? Same result, but game runs better and also less micro for you. For more about that, see below.

• On the mark levels, rather than just having a multiplier for hull/shield points and attack, it now has a "growth" one and a "stagnant" one.
  • "Growth" are the same numbers as before, and apply to frigates and strikecraft. Aka nothing changes as these have both a power/hull increase AND a ship cap increase as they go up.
  • "Stagnant" are used for ships that used to get a mark level bonus to ship cap, but no longer do. So to keep them equal in power while smaller in number, it includes their hull or attack power multiplier multiplied by what their old ship cap multiplier would have been.
    • The end power on these is absolutely identical to what it used to be, but it's for turrets and similar where they are now not something you need to go in and place extra every time you upgrade a tech that improves turrets. See the above notes.
    • This obviously does also apply to things like tractor beam arrays and minefields and so forth, and given that AIs don't use the human-style caps for those that does mean that those are just plain stronger now on AI planets when they are (rarely) used.
      • If we want to change that, we can make AI versions with the uses_growth_multipliers_even_if_stagnant flag from below, but that doesn't seem super important for anything but turrets.

• Added a new uses_growth_multipliers_even_if_stagnant flag which, when set to true, causes something that would normally grow attack bonuses and hull bonuses per mark level as if unit cap was stagnant (thus larger bonuses) and change it to grow as if it had an increasing cap (thus smaller bonuses).
  • This is used for the Great-Turrets so that they don't get crazy stronger at higher mark levels, since the AI doesn't use normal human-style caps anyway.

• Any fleet leaders (golems, arks, battlestations, citadels, etc) now act as though uses_growth_multipliers_even_if_stagnant is true. Thus they'll scale as they always have. Same with guardians, guard posts, command stations, king units, and drones. Also LargeShips and SmallShips that are used by third party facions.

• All of the AI structures now explicitly have uses_growth_multipliers_even_if_stagnant on them to avoid them getting accidental crazy buffs of any sorts. This mainly benefits AI Fortresses and the like, which could have been very scary otherwise.

• Fleet Capacity Extenders now only work for strikecraft, as their increasing a frigate could be absolutely crazy in terms of the impact to both your power (in a good way) and your economy (in a bad way).

• Stationary planet-bound forcefields, tractor beam sources, gravity sources, and tachyon sources now upgrade in the same way that frigates do (aka they behave more or less like they always have, but with slightly more clarity -- they get more unit cap as they go, and the lower "growth" style stats increases instead of the higher "stagnant" ones).
  • People do love having more forcefields, that's for sure, and the ability to field more tractors and so forth are similarly not something we want to condense down like we would turrets.

• Minefields now have their own special_entity_type and also a rollup for easy iteration over them. Some clever AI routines may need that sometime in the future.
  • Additionally, minefields now continue to get a larger ship cap at the strikecraft-style rate of addition, and regular growth stats. Got to have enough for coverage, of course!

AI Great-Turrets

• All of the AI turrets were already different from the player turrets in that they generally have half the range of the player counterparts. Now we're taking it even further.
  • Mainly because turrets can't stack, and thus will grind the game to a halt if the AI builds full caps of them at the sort of strength and costs that we had them at previously, we've condensed them to being essentially like stacks-in-one right from the start.
  • All of the AI turrets are called Great-Turrets instead of just turrets, and they have 5x the cost and firepower and health that the player versions do (while still having half the range).
  • This makes them truly terrifying even in small numbers, but it's something that is actually slightly in your favor compared to what it was when they were separate since they had more shots and thus were less likely to overkill your ships (just your framerate).
  • This shouldn't really affect existing games too much, because the AIs barely used turrets before -- mostly -- at least compared to what they do now.

• For any games older than 1.026, it will now remove 4/5ths of the turrets from AI planets, since AI turrets are now a lot stronger and more condensed being great-turrets.

Attack Ranges And The Small World Problem

• Added a new galaxy option to the balance section: "All Ship Attack Ranges"
  • Lets you adjust the effective range of all of the ships in the galaxy -- yours and enemies. Does not affect 'infinite' sniper ranges, naturally. Also does impact tractor beams. The default is 0.8x in order to avoid the 'small world' problem where all the enemies are fighting you at once on a planet.
  • This does make it so that you need to be slightly more strategic with placements of your own turrets, of course. Your turrets naturally have 2x the range of their AI great-turret counterparts, though.
  • If you want to crank this as low as 0.1x (bad idea) you can, or you can crank it all the way up to 1.3x (also probably not the best thing).
  • Chris notes: This is a softer nerf than we originally thought of, just to play it safe for now. But if people are interested in trying smaller values, you now can.

Spire Frigates

• Lance weapon of all variants (plus Laser Pulse weapon) 12,000 -> 10,100.

• Triple Lance variant damage 4,000 -> 1,800, now hits 15 targets instead of 10.

• Other variants Lance damage 6,000 -> 2,650, now hits 15 targets instead of 10.

• Laser Pulse damage 4,500 -> 3,500.

AI Reinforcement Budget Caps And So Much More

• The five "balance_initial_ai_defenses" xml entries in our central constants have been completely removed, and equivalents are now on the actual AI types instead.
  • This lets us completely balance the AI defenses around AI types if we ever want to tune that.
  • These are also per-reinforcement-point now, rather than per-planet, and they are also directly in AI cost units rather than "caps" which have to be converted to those units by a mysterious multiplier.

• The entire way that we calculate what the defensive budget cap at a planet is has been rewritten from scratch. It was giving absurdly high numbers previously, such as 443 strength for the AI home planet's cap at the START of a game. That was just way too much for the start to be sitting at, cap-wise.
  • Now things are balanced completely around the number of reinforcement points, like the original game was, so if you go in and neuter a planet it will absolutely cripple their ability to reinforce. More power to you, the player! Yay!
  • The overall caps are also far lower than they ever were in the past, this is worth stressing before you read the next two bits.
  • But there remains a very tiny (laughably small, really) percentage bonus that the AI gets as the AIP rises. Eh.
  • There's also a NEW fairly small percentage bonus based on time spent in the campaign. The way it works out is a 48% increase in budget after TEN HOURS of playing at difficulty TEN. After 10 hours at difficulty 7, it's a much more modest 12% increase. This gives you some time pressure, but it's really nothing major and is still less than the AI could theoretically start out with prior to now. And with your new ability to absolutely cripple the AI by neutering guard posts at no AIP cost... we may need to make some of these multipliers higher, who knows. But probably now, we mainly have other plans.

• Special Forces Ninja hideouts no longer count as reinforcement points. That was old AIWC-style thinking. Now it's just guard posts and the command station itself.

• We've been experimentally tuning the numbers a bunch on these, too.

• planet_dire_guardian_count has been changed to planet_dire_guardian_percentage.
  • This lets us be a little more flexible with the marks of planets getting percentages of dire guardians rather than explicit numbers,
  • The AI homeworlds are always full-dire, still.

• The way that guardians are spawned on initial planet creation, and/or on reconquest, is now completely different and respects the budgets and budget caps.
  • Previously it was adding guardians kinda-sorta twice, and thus often making the really high-mark planets absurdly overpowered in general but in particular on AI types like Royal.
  • Not only was this logic doing the above, but it also was interpreting the budget caps entirely incorrectly, thus more or less ignoring them.

• Added a new setting to the Debug section: Write AI Budget Info In Planet Tooltips
  • If something seems off with the planet strengths and reinforcements, then this is a way to see what is going on under the hood.

• Improved the performance of how the game calculates tachyon, tractor, and gravity sources in the rollups. It's now substantially more precalculated than before, no longer having to iterate over any systems.
  • There's a small benefit to the strength counting code in this, too.
  • And actually, map generation in general seems notably faster with these changes in, despite the below change.

• The GetAIToPurchaseCostPresentForBudgetType() method is now far slower, but much more accurate (not lumping strikecraft and guardians together, for instance) and always up to the instant accurrate (not having to wait for the strength counting code to run).
  • This should solve several issues with the budgets on reinforcements being ignored or improperly overly strict, as the case may be.

• Found a place where it was seeding extra guardians per guard post, and took that out.

• During reconquest seeding, the AI no longer gets a bunch of guardians to go with every guard post.
  • Guard posts in general are not expected to be tied to guardians, and guardians will eventually be vastly more powerful than they are now.
  • This was causing some planets, like AI homeworlds, to get VASTLY more guardians than they should, blowing way past their budget for guardians.

• The way that AI reinforcement budgets are calculated is no longer based around the number of reinforcement points, but instead just a flat amount for the planet, which gets reduced (severely) by any lost reinforcement points.
  • Thus no matter how many reinforcement points there are, you don't have to suddenly worry about super high budgets on the AI planet, or strange spikes in budgets just because there are more guard posts.
  • Actually what this means, though, is two things: firstly, each reinforcement point is weaker on a planet with many of them (due to same number of units spread around more); but secondly, destroying a reinforcement point on a planet with fewer of them will do more (due to it reducing the cap of the planet by a larger percentage).

• There is a new ignore_guardian_restrictions_in_waves that we use on the royal AI type, which lets it use its full capacity in sending waves of guardians at you.

• When creating the budget for turrets and non-turret defenses, those will no longer increase based on the mark level of the planet or the fact that the planet is an AI homeworld.
  • This keeps them from having way too many of these things on high levels and next to nothing on lower ones.

• When creating the budget for guardians, it's no longer doubled for the AI homeworlds.
  • This keeps THOSE from becoming so absurdly high.

• There is a new multiplier_for_starting_guardian_budget_on_reconquest on AI types which makes it so that there CAN be some guardians added back onto planets, per-AI-type, during a reconquest of that planet.
  • For most AIs this will just be 0.015, which is an eighth of an eighth (the significance of that will be relevant in a bit).
  • This lets the AIs MAYBE get some of their guardians back right as they capture a planet, partialiarly moreso later in the campaign, but often it will be too paltry for them to get anything.
  • For the Royal AI, it is set to 0.001 since it has such a higher budget of guardians in general. This may mean they practically get nothing, ever, in those circumstances; but better than too much and we can always tune later.

• There are then other new multipliers on AI types: multiplier_for_game_starting_guardians_from_total_budget, multiplier_for_game_starting_turrets_from_total_budget, multiplier_for_game_starting_non_turret_defenses_from_total_budget, and multiplier_for_game_starting_strikecraft_from_total_budget.
  • These all affect how much of the AI's budget for each planet they start with when the game is at the very zeroth second still in mapgen.
  • In the past, we always gave -- for some reason -- fully HALF of the budget cap to each planet, which did not give much room for them to expand and get really huge if you ignore them for too long. ;) Most any planet could do would be to double in power, aside from things like the Hunter or other third parties coming in and making it temporarily stronger.
  • Now we've got this set to 0.125, which is an eighth of the full budget or a quarter of what the old starting strength was. This lets us multiply the final budget by 4x to still have the same starting strength (and we have done that), but now the starting strength can get 8x stronger if you leave them alone for THAT long. And that's before you get into the (very small, as noted in prior notes) increases based on time elapsed and AIP.
  • So the AI has more growth potential, BUT this is measured against the fact that your neutering of them is incredibly powerful.
    • If they had 4 guard posts and a command station, and you kill the guard posts for 0 AIP cost, you'll reduce their max cap to 1/5th of whatever its max would have been.
    • If they had 10 guard posts and a command station, and you kill the guard posts for 0 AIP cost, you'll reduce their max cap to 1/11th of whatever its max would have been. Wowzers.
    • In both cases this keeps you from neutering things to be TOO absolutely weak, but also gives an incentive for popping guard posts when you can that are not related to your main objectives but might threaten you in the future. Aka a lot like the first game.

• Added the fields always_is_ai_turret_spawn_point and always_is_ai_non_turret_defense_spawn_point, both bools, to game entities (ships only).
  • This lets us override the logic that says "only primary keys of modulus 6 get turrets around them" and things of that nature.
  • This is now used for the AI overlord, to always let it be surrounded by both types of things (phase 1 only).
  • Note that these fields only work for ships that are already a spawn point (mainly guard posts and command stations).

• The Turtle AI type now has 4x the turret budget of other AI types.
  • Fortress Baron has 3x the turret budget.
  • Peacemaker has 2x the turret budget.
  • These heavier-turret variants are certainly interesting to run into and give the game a very different feel. These are the more defensive-oriented AIs, after all.

• Added a new is_reinforcement_location bool field. This lets us make things other than command stations and guard posts into reinforcement points.
  • Now that reinforcement points don't actually cause the AI to get more budget, but rather just have it spread out more, it's far more interesting to have this.
  • Plus it makes it so you can do even harder neutering to certain planets, since the total number of reinforcement points will be higher by definition, which is good for you as a player.
  • But it also makes it so that isolated units with this flag on it will now be more protected than before, possibly with turrets around them, which is in itself quite interesting.
  • BUT that still means that forces are being spread more thin around the planet, potentially, so there are pros and cons to you strategically in general with this.
  • AI structures that thus now act as reinforcement points:
    • Warden Fleet Base (again -- back to the same as the prior version that was last public anyway).
    • Data Center
    • Fortified Data Center
    • Major Data Center
    • Plasma Eye
    • Ion Eye
    • Troop Accelerator
    • AI Fortress
    • Raid Engine
    • Alarm Post
    • Magnifier
    • Instigator Base
    • Astro Train Depot
    • Risk Analyzer
    • All of those new ones above also now have always_is_ai_turret_spawn_point="true" on them. Yet more texture in the planets, as well as giving them more inherent defenses.

• Guardians, as well as anything marked as a reinforcement location, can no longer be transported or put inside a guard post.
  • Older savegames may have some of them in there.
  • This causes FAR more guardians to be out and patrolling around now than were before. Some of them were just sitting inside guard posts in a very boring fashion before, rather than doing their patrol thing from what we can tell.

• The tooltips for planets on the galaxy map now show you how many reinforcement points the AI has there out of how many total there have ever been there if it's an AI planet.

• Added modulus_for_turrets_at_reinforcement_location_lower_is_more_frequent (default 6) and modulus_for_non_turret_defenses_at_reinforcement_location_lower_is_more_frequent (default 3) as fields to the AI type. Previously these values were hardcoded in, but now they can be changed for various AI types. This will make turrets appear around more structures for those AI types, or non-turret-defenses do the same.
  • Turtle now uses 1 and 2 instead of 6 and 3.
  • Fortress Baron now uses 2 and 3 instead of 6 and 3.
  • Peace Maker now uses 2 and 3 instead of 3 and 3.
  • This makes it so that their turrets are more spread out on their planets rather than being clumped in super-crazy places on just some locations.

• Added a variety of new levers that determine now how budgets are distributed intra faction or inter faction, nor what the caps or starting amounts are... but instead affect how bonuses (or penalties) work to various AI types. These can be regular floating point numbers with three decimal points of precision (0.001)
  • multiplier_for_budget_reinforcement, multiplier_for_budget_wave, multiplier_for_budget_cpa, multiplier_for_budget_warden_fleet, multiplier_for_budget_reconquest, multiplier_for_budget_hunter_fleet.
  • These don't have any effect on other parts of these AIs -- there are other mechanisms for choosing how much budget goes where, but this lets us set general scales on a per-AI basis on certain types of budget. This is pretty importance for us to be able to balance things reasonably so that there are things like appropriate growth rates of AI budget without you feeling like it starts out with too much, or has too low of a final cap, etc.
  • Most of these are just set to 1 for now, but multiplier_for_budget_reinforcement is 2 for almost all AIs. multiplier_for_budget_wave is 2.2 for the Vicious Raider, and multiplier_for_budget_reinforcement is 4 on the Turtle.
  • We'll undoubtably balance things more using this in the future, but for now this is a nice new lever for us to be able to use to give AIs their own unique characters as well as simply making them not have anemic defenses 30 minutes in even if their defenses 1 second in are smaller now.

• The way that the AI tries to spend its funds on reinforcements DURING gameplay is absolutely reworked from scratch.
  • It was doing a strange thing where it would kind of roll a die and depending on the results try to reinforce certain things with more or less priority, and this often led to some funky results. Potentially it resulted in under-spending at times, and sometimes it may have meant a larger portion of the budget went to non-turret defenses than was at all warranted. And sometimes there were no turrets being put in at all. The reasoning was sound, really, but it was old and didn't fit with the modern economy of the AIs in the game.
  • Now it instead goes through a complicated set of calculations of percentages of what goes where, within random tolerances, dividing out budgets in a certain priority between strikecraft, turrets, non-turret defenses (NTDs), and guardians. If something will get lower amounts of funding, then other things naturally will pick up the slack in a pretty sensible order of priority. It then tries to spend its money more wisely once it has sub-budgets allocated, and rolls any excesses into guardians first (to give more of a chance of buying one), and then into strikecraft (to try to fully deplete the budget if at all possible.

• Changed multiplier_for_starting_guardian_budget_on_reconquest to be 0.125 instead of 0.015.
  • This will substantially hurt. The AI is kind of taking a beating on some of the econ changes lately, so this seems warranted.

• Changed all the various multiplier_for_game_starting_whatever_from_total_budget to be twice what they were before, or therefore a quarter of the max starting budget in most cases rather than an eighth.
  • This should eliminate the sense that you're able to just bumrush planets in the early game before they can reinforce. We could have upped the actual caps of the AIs, but then the late game would have swung too much in their favor if the game runs really long.
  • We'll see what happens; if the starts are still too easy, then we'll be upping the starting caps instead of the percentage again. More than a quarter of the cap at the start seems like planets will just be far too cramped.

• The "defensive budget multiplier" that comes from the AI difficulty is now split into ongoing and initial. This lets us make the lower-difficulty starting amounts not SO anemic that they are pathetic, and then as we get into difficulties higher than 7 not have them be so ludicrously overpowered right at the start. Difficulty 7 is also toned down to 90% of its ongoing defensive budget when it comes to initial seeding, now.

Completely Revised Way Of Seeding Guard Posts and Command Stations

• There's a new AIGuardPostAndCommandPlacer set of xml data that lets us define a lot of different ways that guard posts and command stations can be arranged on planets beyond what has been the basic prior to now (one one each metal generation point).
  • These can be varied by mark level ranges of planets, and have different sets for the homeworlds of AIs. They can easily be modded in or added to like map types or whatnot.

• The way that human homeworlds have their home command station seeded is now a bit more randomized than before, but also does a better job of keeping itself away from wormholes.
  • This should make your starts slightly less predictable.

• The AI Homeworld was set to always put its command station dead center. That's no longer the case. This will make some games easier, others harder, and is fine with Chris.

• Over the years, the concept of what a "guard post" is has changed quite a lot. Originally in the first AI War, they were literally just a gathering point for other ships. Then in 4.0+ of that game we started making them scary weapons in their own right.
  • This sequel has always had the armed variant, but that causes some problems in balance with them sometimes overshadowing the actual ships that are at their location, and in many cases making it impossible for you to fight just a single guard post or two at a time with the way that their weapon ranges were so large that they could pick you off.
  • Thus we've hybridized the old and new concepts, making a new "Unarmed Guard Post" type (and Ghost and Swarmer variants), and then adding in a chance per post for it to be armed versus not armed now.
  • We've split it out so that normal and home AI planets each have their own chance, per AI type: chance_out_of_100_for_armed_guard_post_normal_planet and chance_out_of_100_for_armed_guard_post_home_planet.
  • Bear in mind that, prior to this build, it was always 100 for each one, essentially.
  • Old numbers: Now for most AIs it is 15 and 60, turtle is 60 and 90, Fortress Baron 50 and 80, Peace Maker 30 and 60.
  • Please note that these are not the pure percentages of guard posts on a planet that will be armed: rather, at each guard post it essentially rolls a 100-sided die and if the number is lower than what is stated there, it will be armed.
    • So you'll see all sorts of funky distributions, ranging from completely unarmed guard post planets to completely armed ones.
  • This DOES make things easier for the player, but mainly it gives other units a chance to shine and makes the armed guard posts more interesting in that they are more rare.
    • Ideally we'll be able to make guardians scarier in their stead, but one thing at a time right now. This release has a lot of changes already!

• The way that unarmed guard posts were seeding has been changed yet again. There's now a 100% chance of armed guard posts on mark 7 worlds and homeworlds, and then a per-AI setting for what the percentage chance is for every mark level below that. The percentages are generally much higher than they were before, making for far fewer unarmed guard posts as the game progresses and in general fewer overall.

• The "initial reinforcements" that get seeded into/around reinforcement points now happens as the absolutely last thing, which means that things that should have turrets or whatever around them from the very start, or which are not guard posts but act kind of like them and are added normally during the "special entity seeding" period of mapgen will now get their initial followers properly.

• Usurpers now have to be on the target planet for 10 seconds before they can reclaim it, otherwise you never even see the usurper if you don't have a defending force.

• When a reconquest of a planet happens by the AI, it now uses only armed guard posts regardless of the ratio of armed and unarmed it would have previously used.

• Previously there was mostly just the AI seeding guard posts one metal deposit spots, which is boooring. Now that we have the ability to do more, we have a variety of new types:
  • Guarding Wormholes Generally: this can start at mark 1 and go all the way to mark 7 (not homeworlds, though).
    • These are highly aggressive stances that make it hard to get into the planets, and on very high marks they wind up putting 2-3 guard posts PER wormhole. Talk about ow. If there are too few spots for their posts at just wormholes, the rest are spread out very ambiently.
  • Guarding Wormholes Harshly: this can start at mark 3 and go all the way to mark 7 (not homeworlds, though). They should be VERY infrequent based on their weight. These are deathtrap worlds.
    • These start out with 2 guard posts per wormhole, and only go up from there -- by mark 7, it's freaking 5 guard posts per wormhole. Just entering the planet is leaping into death, more or less. But that's part of the fun of having a rare extra difficult guard post design, and bear in mind that it doesn't make for more reinforcements and so the total firepower of the planet doesn't get a boost per se (well, guard post firepower itself aside -- which can be huge on higher marks, admittedly, but... well, have fun with those!).
  • One Single Mass: this is another super rare one, and can start at mark 2 and up, but not homeworlds.
    • This puts all of the guard posts pretty much in one big clump somewhere on the planet. Depending on randomness, the clump can be kind of strung out, or more circular, or very tight. In many ways this makes them into one super-guard-post, which is potentially like trying to crack an old-school fortress in AIWC. These have randomized ranges of guard posts per mark level of planet, with 2 on mark 2 to, from 3-4 on mark 3 up to 9-12 on mark 7. This is another intense one.
  • Spread Out Guard Posts
  • This is a variety of ones that are much more lightweight and which get seeded much more commonly: basically just randomly putting guard posts around the whole planet, but pretty far away from one another to make them easier to approach. The numbers vary a lot, and most planets will use one of these.
  • Guarding Metal Deposits: moderately low chance of coming in on any mark 3 and up, but not homeworlds.
    • Places one guard post on every metal deposit, and then no more. This is similar to old behavior, except that it doesn't try to add more if there are fewer metal spots than an "ideal" for the mark level. Consequently the difficulty of these will vary a lot, but stealth guard posts remain easy to find because they're just on the metal spots (that was a big giveaway in the past, cough).
  • Spread Out Guard Posts And Two By Command
    • These ones start kicking in on mark 4 worlds and up, and one of the two homeworld variants has this, too.
    • This basically puts two VERY close to the command station, guarding it in a ferocious fashion, but then the rest spread very far around.
  • We can always code more of these as we think of them, and these are easy to add in as part of mods or expansions or whatever as well.
    • Extra logic could be added to seed specific extra structures at certain guard posts if we really wanted to, although that's not my favorite and it's not by default possible in the moment. But the possibilities for future additions are pretty endless if we have sufficiently interesting ideas. A lot of the other things are better off being a bit random is the current feeling, though, as it plays into these nicely.

• Added the ability to have certain guard post layouts only be for certain AI difficulty ranges (based on the max AI difficulty, not the difficulty of the AI at that planet).
  • Additionally, based on the max AI difficulty, the ability to have a certain added weight to guard post layouts per difficulty above some cap. For now we're using that in the following ways:
    • (Standard weight for something appearing neutrally frequently is 100, please note.)
    • GuardingMetalDeposits (bit hard) base weight was 20, but it now gets +5 for every difficulty 6 and above. (6=25,7=30,10=50 etc).
    • GuardingWormholesGenerally (quite hard) base weight was 10, but it now gets +5 for every difficulty 5 and above. (5=15,7=25,10=45 etc).
    • GuardingWormholesHarshly (super hard) base weight was 2, but it now gets +3 for every difficulty 6 and above. (6=5,7=8,10=17 etc).
    • OneSingleMasss (super hard) base weight was 2, but it now gets +3 for every difficulty 6 and above. (6=5,7=8,10=17 etc).
    • ThreeSpreadOutGuardPosts (super easy) base weight was 100, but it now gets -10 for every difficulty 5 and above. (5=90,7=70,10=40 etc).
    • FourSpreadOutGuardPosts (super easy) base weight was 100, but it now gets -10 for every difficulty 5 and above. (5=90,7=70,10=40 etc).
    • SixSpreadOutGuardPosts (easy) base weight was 100, but it now gets -10 for every difficulty 6 and above. (6=90,7=80,10=50 etc).
    • SixSpreadOutGuardPosts_AndTwoByCommand (moderate) base weight was 50, but it now gets +5 for every difficulty 6 and above. (6=55,7=60,10=80 etc).
    • EightSpreadOutGuardPosts (moderate) base weight was 100, but it now gets -10 for every difficulty 7 and above. (7=90,10=60 etc).
    • EightSpreadOutGuardPosts_AndTwoByCommand (hard) base weight was 50, but it now gets +5 for every difficulty 7 and above. (7=55,10=75 etc).
    • TenSpreadOutGuardPosts now only appears on difficulty 5 and up.
    • TwelveSpreadOutGuardPosts now only appears on difficulty 6 and up.
    • AIHome_TwelveSpreadOutGuardPosts now only appears up to difficulty 8.
    • AIHome_TenSpreadOutGuardPostsAndTwoByCommand now only appears on difficulty 6 and up.
  • All of this combines to give a much more richly-textured scary landscape for the higher difficulties, while keeping things notably simpler at easier difficulties even at the level of a cursory glance.
    • Looking at a difficulty 5, 7, and 10 game, you can see that this is NOT a subtle effect. As we theoretically add more types of seeding patterns, or other people think up seeding patterns, we can make an even richer tapestry.

• If you have map gen logging on, you can now see entries for "Guard post style for planet" that shows what mark the planet is and what kind of thing it is seeding.

Bugfixes

• Adjusted the "BUG: Ship is on burningAndDying list but has not exploded" message to instead just mark the ship as exploded, as there are too many ways to get to that state.
  • Thanks to ArnaudB for reporting.

• Fixed a nullref exception that could happen in DetachVisObjectFromSim on ship squads.
  • Thanks to ArnaudB for reporting.

• Fixed a nullref exception that could happen in StartReconquestDefenseSeeding for AIs types that do not use non-dire guardians for some reason.
  • Thanks to ArnaudB for reporting.

• Fixed a nullref exception that could happen in BattlefieldVisualSingleton.HandleSquadAndShipUpdates, and made it so that it self-repairs when it can or self-reports when it can't. Either way it continues to draw things and update them properly rather than having the display get all strange if such an exception occurs.
  • Thanks to Daniexpert for the report.

• Improved the "find a safe space to be" code for ships so that they are now more likely to find a CLOSE space to be.

• For guard posts in particular, it does an extra good job of trying to keep it close to the intended point (whatever that is in the given schema).

• Finally fixed a really annoying bug wherein command stations that got shot to remains and then rebuilt did not count properly (thus not letting anything else be built or rebuilt at their planet) until you saved and loaded the game.
  • Thanks to Badger, ArnaudB, Asteroid, KDR_11k, Puffin, Sigma7, Ryulong, Core, and GrimerX for reporting and helping to find it.
  • Special thanks to Ryulong for the recent savegame that let us reliably reproduce this.

• Fixed a bug where some achievements relating to killing specific AIs was not triggering because it was trying to match the internal name to the display name. Now it checks both display name and internal name to be doubly sure.
  • This makes Full Ensemble in particular now properly trigger when you beat them.
  • Thanks to ArnaudB and DEMOCRACY_DEMOCRACY for reporting.

• If you have existing saves where you already beat the game, loading those savegames will now trigger the achievements for you that you properly earned (just load them, unpause, and wait at least 2 seconds).
  • It's much better this way, versus having to dig up a savegame from right before you won, etc, if you're going back to get achievements that you earned but didn't log because you were offline, or there was a bug, or whatever factor.

• Fix a typo in the hover planet text
  • Thanks to Sigma7 for reporting

• Improve the readability of some Instigator base hovertexts
  • Thanks to Daniexpert for reporting

• Since it is now possible for non-combatant ships to contain lots of combatant ships (unarmed guard posts on the AI side, but frankly also your own transports), the game now takes great pains to make sure that it isn't overlooking the combatant-nature of ships contained within non-combatant ships when checking things like strength.
  • Compared to prior versions of the game (where all guard posts were combatants) this doesn't fix or change anything, but it might make player combat strength more accurate in the case of transports if there was some issue there (though there's no sure evidence that was a problem).

• When ships are dying, you no longer get a bunch of red "null fleet" messages hovering over them, unless you have debug info turned on for tooltips.

• The game should now say "release" to show a more or less detailed tooltip on the various screens if you're already holding down the button to make it do whatever it's doing (you can invert the behavior, so which is held and released should match that).
  • Thanks to Admiral for reporting.

• Clarify the tooltip for Risk Analyzer Notifications
  • Thanks to Thotimx for the bug report

• Completely reworked how the long range planning threads keep track of how long it has been since they have run, so that they should probably run at appropriate intervals when the game is running faster than 1x speed now. Previously these were running slower the faster the game ran, which made the AI stupider at 10x speed than 1x speed.

Fixes For XML Modding

Example tiny mods and discussion are here: https://bugtracker.arcengames.com/view.php?id=22433

• Several different things were not staying properly on ships when using an is_partial_record="true" to mod them:
  • exp_to_grant_on_death
  • watch_planets_at_X_hops
  • tags (ow this would cause many problems)
  • capturable_seed_weight (again very problematic)
  • capturable_max_per_galaxy
  • capturable_can_seed_at_all
  • Thanks to NRSirLimbo and ArnaudB for reporting.

• Fixed a couple of things that would complain they could not be found properly on ships when using an is_partial_record="true" to mod them (but in reality these were carrying over fine from the base version being modded):
  • ship_or_structure_explosion_sfx
  • ship_or_structure_explosion_if_on_other_planet_sfx
  • Thanks to NRSirLimbo and ArnaudB for reporting.

• If outgoing_damage_modifier or incoming_damage_modifier entries are duplicated in the list of rows for a system or entity (respectively), whether that be through mods or just in the original definition, it now only uses the last-to-apply version. This last-to-apply one is always going to be a mod version if there is a mod version.
  • This makes it so that you can't have two different modifiers on the same weapon that both are based off of the hull health of a ship, for example, but I don't think we're doing that anywhere and it would be messy in the UI if we were, anyway.
  • This then fixes the issue with various weapon bonuses and the like duplicating themselves when you are using an is_partial_record entry to mod a weapon.
  • It's worth noting at this point that xml modding is inherently slightly fraught in terms of minor bugs or oversights like this which can have major repercussions. Please just let us know on a case by case basis what you find, ideally with the xml you're using and a savegame that shows the wrong behavior, and we can likely fix it up pretty fast.
  • Thanks to ArnaudB for reporting.

• Both ai_ship_group_membership and fleet_membership now properly adjust the existing membership when there is a duplicate entry entered for them (from a mod or whatever else) linking a given ship type to a given template or group. It now adjusts the weight and so on in the template or group, rather than adding a duplicate entry.
  • Note that if you change the category for a template, it will assume you mean it to be a duplicate and will add that accordingly. There really should never be any valid reason to mod the category of a ship, but if you must then you can just 0 out the min and max of the old one maybe?
  • Thanks to Flypaste for reporting something next to this, although not exactly this.

• Creating a mod to replace or redefine parts of the fleet design templates (like the starting fleets) now works properly rather than creating duplicate entries or extra counts or both.
  • For an example of a mod that works with this new function, the raw xml bits are here: https://bugtracker.arcengames.com/view.php?id=22136
  • Note that if you choose to change the category of ships from HERE, that will work fine. You just can't change categories of fleet template items from within the game entity side.
  • Also please note that this change now prevents you from having duplicate lines of the exact same type of ship in a starting fleet. So something with two lines of fusion bombers would not work anymore, for instance, even with no mods in play, and would just take the count of the last fusion bomber entry and use that.
    • This doesn't stop you from using multiple duplicate ship lines in-game of course, but it does stop it in the starting fleet designs, none of which (that are still active) were using that function anyhow.
  • Thanks to Flypaste for reporting.