AI War 2:The Final Cycle

From Arcen Wiki
Jump to navigation Jump to search

Known Issues

  • Any bugs or requests should go to our mantis bugtracker
    • If you need to submit log files, those can generally be found under your PlayerData folder in the folder your game is installed in. The most relevant one is called ArcenDebugLog.txt. You can send us the whole thing, or just strip out relevant parts.
    • In rare cases, mainly if your entire game crashes (that almost never happens), we will need your unity player log. That gets overwritten the next time you run the game after a crash, unlike the other log. These can be found here:
      • Windows: C:\Users\username\AppData\LocalLow\Arcen Games, LLC\AIWar2\Player.log
      • macOS: ~/Library/Logs/Arcen Games, LLC/AIWar2/Player.log
      • Linux: ~/.config/unity3d/Arcen Games, LLC/AIWar2/Player.log

What Does Multiplayer Beta Mean?

Please see this link for details on multiplayer. This wound up taking up too much space in this document, so all of the multiplayer-relevant bits have been moved to the other page.

What's this phase all about?

We finally got out of the endless beta of The Great Refactor, and DLC1 has been majorly beefed-up and multiplayer is better than ever. That said, multiplayer is still in the very last stages of its own beta.

With this new phase, we have fully shifted back to working on DLC3 (The Neinzul Abyss), which will be the final DLC for the game. The various remaining kickstarter items will also be taken care of, plus some other bits that we just always wanted to add for the game, and after that we'll be moving on to other projects aside from bugfixes and balance tweaks and modder-support throughout 2022.

The target release for DLC3 is in April of 2022, and that is when we'll also have the AI War 2 Complete Edition. After that, it will just be fixing material defects, and supporting modders. We expect it to have a long life if AI War Classic is anything to go by. The game is in a really good state and only getting better, and doing a refactor of this scale near the end of the project development cycle is a sign of our commitment to that longevity. Even if you aren't giving us more money in the future for this title, we want you to be able to enjoy it for years and years.

4.004

(Not Yet Released)

  • Remove an unneeded game lobby setting from the Spire Infused Empire.
  • Adjusted the expert, logistician, and challenger tooltips to reflect the fact that reduced resources (for hacking) starts out on challenger mode, and corrected things to note that beacons are only unavailable starting on logistician mode.
    • Additionally, the lobby tooltip for Expert no longer mentions having many fronts you must defend, but logistician now does.
    • Thanks to Strategic Sage for requesting.
  • Added a new setting to the game section of personal settings: No Ironman
    • If a campaign would normally be ironman, this will force it to NOT be ironman. Great for testing, but does make any save that would normally be ironman flag itself as being in cheat mode (so no achievements, etc). In multiplayer, this only matters on the host.
  • When modules on a ship line are changed around, all the ships in that line are paralyzed for 10 seconds.
    • Thematically, this is them doing their retrofitting. Functionally, this hopefully removes any incentive to drive yourself crazy microing the modules on and off during battle.
    • Thanks to motai for suggesting.
  • The cheat code "I don't even see the code" can now be entered without the apostrophe, and optionally without the second parameter (it then just gives you 400 HaP). You can also use the command "hacking" for short.
  • The game now supports reading in custom fields as "true" or "false" and converting those into bool values as you would expect, versus before it freaked out in an inscrutable way if you didn't remember to say "0" or "1". Now if it freaks out, it also gives you clarity on why.

Hacking Response Tweaks

  • Hacking responses were incorrectly including a Fallen Spire component even when they should not. This was leading to drastically inflated hacking responses
  • Hacking estimates for hacks with a strong post-completion response could be undercounted if completing the hack would bump you up one response tier (ie from 'Very Easy' to 'Easy')
  • The hacking estimate should now include the Exo response strength (where appropriate)
  • With the Hacking Debug setting enabled, the hack tooltip will tell you a bunch of information about how the estimate ie generated. This is for debugging/development use only
  • Thanks to Strategic Sage for a bug report

Dire CPAs

  • Dire CPAs are now in the base game. It's a galaxy setting one enables in the galaxy lobby.
    • When enabled, every so often CPA Bunkers will be spawned on the map. When a CPA is launched the CPA bunkers will release extra ships to make CPAs even scarier.
    • This just makes the game more challenging, and is on by default for some of modes harder than HA.
  • The CPA announcement now includes the strength of the Dire CPA component (if any)
    • Thanks to Strategic Sage for suggesting this

Return Of Faction Beacons (The First, Anyway)

  • Beacon hacking returns! At the moment, it's just for the nanocaust, but that's simply because that's all the xml I have set up thus far.
    • This can be set up, using only xml, to work with any faction or combination of multiple factions, and you can give any number of options for hacking them. With the nanocaust, I have 18 different options set, with intensities 5-10 of hostile to all, hostile to player, and friendly to player as options. When it's friendly to player, it also has them spawn near to you. Each hacking option is a fixed set of faction options, but so it's not truly freeform, but it does not have to be decided in the lobby, which is really nice.
    • There's a ton more power here than in the old beacon system, but one of the biggest improvements is to performance. In the past, this was having to include the entire faction, but just turn it off, when it was present. This was a huge performance drain, and also when many beacon factions are eventually added as options, particularly in mods, it would literally not fit in savegames. The new approach adds no factions until you choose to hack to meet them, and thereby lets you control the amount of insanity that is involved.
    • I will be making some more changes tomorrow, and adding in more beacons and beacon factions, but this is an excellent starting spot.

Bugfixes

  • The tooltips for ships now show a lot more details for any auto-targeting targets they have for each of their systems.
    • Additionally, it now shows which auto-targeting group they are a part of.
    • Thanks to Tim_Fragmagnet for a report that inspired us to have more information visible here.
  • The way that auto-targeting groups are calculated is now done centrally, and it's no longer possible for units to potentially get lost in the shuffle and not get auto-targeting orders.
    • Thanks to Tim_Fragmagnet for a report where this was probably what was happening.
  • The way that "incoming shots" are tracked on ships, which is used in overkill detection, has been improved a lot.
    • First of all, it's more efficient now, and tracked internally only, and has more granular cross-threading protection rather than allowing for a cross-threading error to interrupt the entire process.
    • Secondly, any incoming shot now times out after 10 game seconds, so nothing can get stuck in a "it's going to die because of incoming damage" state where enemy units won't fire on it. Not sure if this was happening, but it's possible, and now it should not be.
    • The "Show incoming-shot debug data in unit tooltips" debug setting has been removed, as the individual shots are no longer interesting to see in the same way.
    • The tooltips now show how much damage the ship is expected to take from incoming shots, or if there are incoming shots but no damage, then it also shows that.
    • It is likely this will fix some bugs, or it's possible it might just make things more clear if a bug in this area resurfaces.
    • Thanks to Tim_Fragmagnet for the related report.
  • Adjusted targeting logic so that if a unit is not fully claimed, but belongs to a player, it is now valid to be shot. Previously, some metal harvesters that were half-alive were not being shot further, which looked like a bug. Now they get pasted instantly.
    • Thanks to Tim_Fragmagnet for reporting.
  • Fixed three more sets of tooltip errors that could happen right when units were dying.
    • Thanks to Lord Of Nothing for reporting.
  • The "bonus for sitting on a planet for a while" tooltip text was cut off and had some other oddities.
    • When this is a ship owned by nobody, it now just tells you about it in the abstract, as if you were not looking at a specific ship (so, if you capture this, here's how it would work).
    • When it's a ship owned by an NPC, it doesn't show this at all.
    • If this is not showing the first half of the sentence, it makes sure not to write the last half of the sentence (such as with cloaked flagships).
    • Thanks to Zer0h1nder and Strategic Sage for reporting.
  • In the event that a wave timer would be negative or zero (aka, it thinks the wave should already have landed, but it has not yet), it now says "SOON" on the notification, and "any second now... but the exact timing may be a surprise" in the tooltip for it.
    • Usually waves will launch on time, but there are cases where the game is running the AI threads more slowly because of load, or the "only run every X seconds" logic is there anyway, and so the exact timing is just not actually exact in all cases.
    • It doesn't really make any sense to try to make the timing more exact, since this flexibility is one of the things that helps performance, and not knowing down to the second when a wave is going to arrive is mildly interesting anyhow. So now it's simply handled in a way that makes it not look like a bug.
    • Thanks to Daniexpert and NRSirLimbo for reporting.
  • The description of Showdown Devices now more correctly matches their behaviour
  • Put in error handling for CalculateMatchesOnBackgroundThread, since I ran into an exception on that background thread in the internal version for some reason.
  • Fixed an exception that could happen when getting the faction's internal display name after a fairly specific set of operations involving adding a faction and then going back to the menu and back into the game. Likely it was also triggerable by other circumstances, but it's hard to be sure.

Mod Updates

  • Update to More System Defenders. Now allows players to choose a version of the Stormfront Ark to lead their Ark Empire within that game mode.

4.003 A Bit Too Chromatic Horrifying

(Released March 9th, 2022)

  • CPA Bunkers now try not to spawn on planets with a CPA bunker already. Remove the AIP cost for killing them
    • Suggested by Strategic Sage
  • The starting data structures and the first test xml has been set up for the return of beacon factions. It's not wired up to do anything yet, but the data is pretty much fully described for the nanocaust as a first test case, so this should then open up the rest of things for getting things to be beacon-ready.
    • The new data format is pretty cool, as it can set any custom fields as part of the beacon options, and it can also include multiple factions from a single beacon if we want to. The main purpose of that is really for multi-faction factions (there are a number of those), but it could in theory also be used for something like a beacon that calls in two warring factions that explicitly hate one another, or whatever else.
    • Unlike the prior beacons, this is something that is really mod-friendly, or it will be once the feature is completed, so that's also pretty exciting.

DLC1

  • The fallen spire and the spire infused empire should now use shared logic for determining whether to have the dark spire enter conquest mode
    • Strategic Sage indicated there was a problem
  • Add a new Galaxy Setting to allow players to prevent the Chromatic Horror from moving player structures around.
    • This is untested
    • Requested by Crawlers

DLC3

  • The Necromancer rifts journal clarifies that rifts will continue to spawn over time
  • Rift hacks can now grant 30 essence instead of 15, since people considered 15 to be too low
    • From a balance discussion on discord
  • Rift hacks to increase bodyguard caps now give double the number of bodyguards
    • From a bug report by pmm5000_1
  • Rework how Templar mark levels are chosen. Each wave leader picks a random mark level based on the AIP/Templar difficulty (at the moment, >= 180 AIP means every wave leader will be between 5 and 7; so you might get 1 mark 5, 1 mark 6 and 2 mark 7s.
  • All Templar ships that spawn from a structure (either as part of a regular wave, hacking response wave or to defend their territory, will take the mark level of the structure they spawn from. So a mark 5 castle will spawn mark 5 ships
  • Add the concept of 'Corrosion Damage'. Corrosion damage sticks on the enemy ship, and applies over time.
    • Every second the target has some of its remaining, unapplied Corrosion Damage happens to the unit; something like 8% (minumum 8 damage). This damage goes directly to the target's hull.
    • An entity-system can have an an additional flat amount of corrosion damage with the XML tags corrosion_damage=X and corrosion_damage_added_per_mark=Y
    • An entity-system can all say all_damage_is_corrosive="true", in which case it will all be corrosive.
      • Add a Corrosive Guardian to DLC3 as an example for using this new mechanic.
      • Corrosion damage example. I have 50 corrosion damage on me. Next second I take 8 damage, and there's 42 damage left. Someone hits me for 100 additional corrosion damage. I now have 142 corrosion damage and take 15 next second; there's 127 corrosion damage left on me

Bugfixes

  • Add some debugging code to GetWaveComposition
    • From a bug report by henry700
  • Added a new ThrowawayDrawBagCanMemLeak data type, and this internally uses our existing ThrowawayListCanMemLeak type (which is mostly used in mapgen until now).
    • These are used for very short periods of time, and are meant to be thrown to the garbage collector. I had wanted to avoid this sort of thing, but we've been having persistent intermittent issues with cross-threading issues on certain worker methods (like for wave spawn), and the RapidAntiLeakPoolable approach that I had developed is just not robust enough. I also worry about that contention on that leading to slowdown in larger games.
    • I am going to build out some more of these kinds of throwaway collections and probably will phase out a lot of the RapidAntiLeakPoolable thing since it seems to only be causing problems.
    • There is also a new interface called IDrawBag<T>, which can be used to manipulate either kind of draw bag without knowing or caring which kind it is.
      • I actually am not yet using that on any methods, because on the methods where it would be relevant, I actually want to signal that only a throwaway draw bag should be used, because the sorts of manipulations that are being done in those methods are not for permanent data.
    • As an aside, this should not be taken as a signal by modders/developers to just use the throwaway collections willy-nilly. There are many better code patterns, such as not using a collection at all and instead using an iterator/dofor, which have the benefit of both performance and better memory usage, while still having the same amount of readability.
      • This is essentially something that should be used in place of places where we were using RapidAntiLeakPoolable stuff before, because that had its own performance implications and occasional cross-threading issues. If you can refactor slightly to avoid the need for any of this, and just use an iterator, then so much the better.
    • Thanks to henry700 for the most recent report of an exception in ChooseWaveTarget.
  • A new version of StringBuilder has been added into Arcen.Universal, which is slightly more efficient than the one that microsoft provides, while providing the same functionality (the subset we use, anyhow).
    • Referencing System.Text is now something that will cause ambiguous references between our version and theirs, so just removing that reference will solve the issue for any mods that are affected.
  • Fixed exceptions that could happen in the quick start screen if your local player profile happened to be null at the current time.
    • Thanks to Dismiss for reporting.
  • Fixed an issue where the game was limiting you to only one Battlestation on Challenger+, when it should have been on Expert.
    • Thanks to Strategic Sage for reporting.
  • Fixed an exception that could happen in tooltip generation if the ship you were hovering over died at just the wrong moment.
    • Thanks to Relay Bot for reporting.
  • For purposes of movement and panning, the camera now clamps its maximum "frame delta time" to be the equivalent of 20fps, or a twentieth of a second. If there is a very large single frame (garbage collector, waiting on disk, whatever), it will thus no longer cause your zoom to shoot all the way in because of getting a very large d/t for a frame where you were rolling the mouse wheel.
    • The one potential downside of this is that if someone legitimately has ongoing performance that is worse than 20fps, their mouse inputs will be slowed to whatever the ratio is to 20fps. So for example if someone had ongoing 15 fps, their mouse inputs would be sluggish at 75% of the normal speed. At 10fps, it would be sluggish at 50% of normal responsiveness.
      • Since I'm not aware of anyone routinely running that low (and anything at 20fps or higher will perform with normal responsiveness), this seems like a safe thing to do.
      • I could have clamped this at 10fps, but part of the thing is that some mice have quite a sensitive wheel that can be rolled or spun very far in a short amount of time, and a tenth of a second will probably still allow for more zoom-in at once than is desirable. That's one of the main reasons I haven't done anything about this issue despite it being around since 2017.
    • Thanks to Mac for the most recent reminder on this.
  • In the event that a unit was supposed to repair another unit, but that other unit already has been healed full by whatever means, it now just silently skips that versus... throwing an error, which was an odd choice.
    • Thanks to Daniexpert for reporting.
  • Added more code to make absolutely sure that DoOnAnyDeathLogic_HostOnly_AfterFullDeathOrPartOfStackDeath is not ever run on MP clients.
    • Thanks to Badger for reporting.
  • Since gamecommands are coming through as scrambled to clients in multiplayer some of the time, but the canary code after them is not being hit, it is very likely that they are being sent in an improper fashion by the host. The host is executing them perfectly, so it must be something that is changing during the actual send, it seems like. With that in mind, I've put extra gating on the host (and on the client just to be extra careful) to make sure that they never overrun themselves in the same method there, since that seems to be the most likely source of this sort of error. If this doesn't work on its own, I can put in some more detailed logging, but after yet another code review, this seems to be the most likely culprit.
    • Thanks to Badger for the most recent report.
  • When a planet is taken over by a new AI (from reconquest seeding via an Usurper), it's possible that a new AI is moving in compared to the AI that originally owned the planet. Either way, it now shuffles around the types of units to spawn there based on the AI taking over, so that the planet will have a fresh set of units that it prefers to seed there.
    • When it comes to the same AI taking over, this is not really a big deal, but makes for some minor variety. When it's a different AI taking over, this is actually a really big deal, because the new AI type might not be intended to use the same ship types as the first AI type.
    • Thanks to GreatYng for this report, with investigations on their part going back several years actually.
  • In multi-AI games, it's possible for AIs to launch waves or border aggression from planets that belong to other AIs. Normally border aggression or wave contents is determined by the AI groups chosen at that planet, but when it's from a different AI, it may not be intended to share that AI group. In those cases, it now finds a different random AI group that it is supposed to have to use to populate the wave or the border aggression.
    • In multi-AI games, this should keep AIs with unique ship types from sharing those with their partner (or enemy) AIs that coexist with them.
    • This, like the other adjustment to AIs after reconquest seeding, is untested but should work.
    • Big thanks to GreatYng, again, for chasing this down over about a three year period.

4.002 Macrophage Live!

(Released March 8th, 2022)

  • The encyclopedia now honors the "pause when opening escape menu" options that are in settings.
    • Additionally, when you are in-game and looking at it, the header of it now says "game still running" in cyan, or "game is paused" in the same orange that the resource bar uses.
    • Thanks to trabbo for suggesting.
  • When you have a necromancer in the game, some types of AI defensive structures can be used to produce near-infinite Skeletons, Wights or Mummies. The game now swaps these structures for AI Fortresses, which should still make the planet a challenge
    • To apply this to new structures, add a tag "SwapOutForNecromancer" to those AI Defenses. With this tag the game will replace those structures with AI Fortresses when there is a Necromancer.
  • Rejigger the Necromancer starting ships to not include variants. I was worried it would encourage players to spec science into things they don't have access to, and potentially overwhelm a novice. Instead you get a lot of Base skeletons and wights.
    • This is intended to be power neutral for the player.

Bugfixes

  • Fixed an issue where two legacy xml files were removed (rather than just blanked out) as part of the 4.0 upgrade, and so installing into the existing folder the game was already in would lead to errors. These files have now returned, but are empty, and thus overwrite the old files, allowing people to install things over-top of their existing installation.
    • Also, this winds up then not relying on Steam or GOG Galaxy to properly delete the missing files, because they don't always do that. Once a file exists in the wild, we try never to remove it, only to deprecate it.
    • Thanks to trabbo for reporting.
  • Some errors were happening related to drones moving between different fleets of the AI, which I think is something that happens when you kill the drone producer. This error no longer happens, and it no longer considers that and a few other cases an error at all.
    • If the error does come up now, it also give a bit more information than before.
    • Also if this error does come up now, it properly sets things up to not endlessly spam errors about any single unit.
    • Thanks to [LA] Talderius for reporting.
  • More firmly fix a problem where Necropolises were rebuilding on planets with AI Reconquest Command Stations
    • Thanks to daniexpert for reporting
  • Add some additional randomness to the Grid map type's random connections
    • Reported by Tim_Fragmagnet on discord
  • Add some defensive code to brownout notifiers
  • Fix a typo in the fuel description
    • Reported by Tim_Fragmagnet on discord
  • Fix a flicker in the hacking difficulty estimate colour
    • Thanks to Zer0h1nder for reporting
  • Player-allied ZA Castras can no longer be hacked
    • Thanks to Zer0h1nder for reporting
  • Fixed an issue where GameCommands were using a custom ConcurrentQueue solution instead of an actual proper pool, and that was probably leading to some game commands getting added in twice (there was no protection against that, unlike in the proper pooling solutions), and thus this is likely the culprit for some of the deserialization issues that we were seeing on MP clients. It's probable that this was also causing other issues.
    • As part of this, I consolidated things to one pool rather than one pool per game command type (this was something that was required based on the nature of the pool initializer methods). A side effect of this is lower memory usage from commands in general, and fewer of them in existence during the game. Originally I had split it because I was worried about contention between multiple threads, but we're really an order of magnitude away from having to worry about that, which is good. A lot of those original design choices were because I made the changes here very early on into the refactor before I had truly tested out every aspect of performance and behavior that came over the 8 months after that. And then I just never noticed that this was a bit off.
    • Thanks to Badger, ptarth, and likely others for reporting.
  • Fixed a bug that effectively made the Macrophage never try to build Telia
    • Thanks to Relay Bot for the report
  • Fixed a bug where Macrophage wouldn't return metal to their Telia if they were being challenged to fisticuffs by a tanky hostile ship
    • Thanks to Relay Bot and Zer0h1nder for the report

Mod Updates

  • An XML property tag was renamed in the base game. This in turn broke some station keeping entities within More System Defenders (MSD) as the name of the property being set was no longer the same. This is now fixed to again call the right property.
    • Essentially the tag in question is for keeping certain station-keepers off of battlestation and citadel grants from the ODSS. Same logic is used in DLC2 for the various drone hangars.

4.001 Autobuild Automation

(Released March 7th, 2022)

  • Moved the unit encyclopedia link to the far right of the top bar.
    • Thanks to Zer0h1nder and Strategic Sage for suggesting.
  • In the event that there are too many drones created by an NPC faction, it will start deleting the excess of drones now. Additionally, it will not produce drones or release them if it would put them over cap.
    • Drone guns, on the other hand, will still fire in these cases; most likely the outcome will be older drones dying off inexplicably rapidly when that happens.
    • Thanks to Mysais for reporting.
  • A new "Raid" category has been added for planet importance options.
    • Thanks to Bummeri for suggesting.

Marauders

  • Due to report from voidlily on the Discord about Marauders exceeding drone caps some changes have been made.
    • Marauder V-Wing and Bomber drones now have 4x costs, health, and damage compared to normal.
    • Marauder drones now attrition by 15% per second when the host is lost instead of 1%.
    • Marauder Outposts now only have 5 each of both types of drones instead of 20 each.
    • Marauder Drone Frigates now only have 2 each of both drones instead of 5 each.
  • Also went ahead and adjusted Marauder Constants and Marauder Outposts.
    • Marauder Outposts now have some of their turret ring weapons baked into the outpost.
      • These would be equivalent to 5x Concussion Turrets, and 4x Fusion Turrets.
      • The Fusion Turret equivalent has a minimum mark level of two to function. Which is when outposts normally gain turrets of this type.
    • Marauder Constants now only have new outposts spawn in with 5 Concussion Turrets instead of 10. And on first mark up they only gain an additional 4 turrets protecting them instead of 8.
      • This is an average savings of 18 less turrets spawned on ally controlled worlds and 36 less turrets per world the marauders have primary ownership of.
  • For existing games this will slightly be imbalanced towards Marauders unless their now excess counts of planetary turrets get cleaned out. New games will get the full benefit of having less entities in play.

Auto-Building

  • More autobuilding changes and improvements:
    • Ships can individually override the values used for auto-spawn with XML entries:
    • autoplacement_use_custom_parameters (bool, default is false) determines whether any of the below actually matters, or if the game should attempt to place this unit by whatever thing it seems to be.
    • autoplacement_anchor (values: CenterEntity, CenterOfPlanet, GravityWell, default is CenterEntity) determines where something should be placed. For automated building the CenterEntity is the command station.
    • autoplacement_distances_adapt_with_gravwell_size (values: Static, ReduceIfBelow, IncreaseIfAbove, AlwaysAdapt, default: Static) determines whether or not the next few distances (min/max/absolute max) scale with the default gravity well size of 52k, to be held proportional to the planet size.
    • autoplacement_min_distance (int, >=0, default 0), autoplacement_max_distance (int, >autoplacement_min_distance, default 1000), autoplacement_absolute_max_distance (int, >autoplacement_max_distance default 99999999), this determines how far from the anchor something is attempted or allowed to be placed.
    • autoplacement_variance_add (FInt, >=1, default 1.01), autoplacement_variance_sub (FInt, <=1 & >=0, default 0.99), this determines how much the min/max distance requirements are relaxed each (failed) attempt.
      • So autoplacement_variance_sub="0.99" would mean that the autoplacement_min_distance would decrease by 1% each attempt. The more this value differs from FInt.One the quicker placement locations will be found, at the cost of usually being further outside of the initial anchor min/max distances.
    • autoplacement_max_tries (int, >0, default 100) is how many attempts are made in general. The more, the longer the code may run but the more chances this has to find a location at all.
      • Finding the perfect values for this is difficult, but unless there is a very specific placement needed or the space near anchor is already littered with things the code should never have to run for too long. And even if, this is all on a background thread.
    • Autobuilding is now on its own background host-only thread, so it will not block sim threads or some special global player logic (which is where it was before). Even if placing a turret takes ages the game will continue.
    • Implemented Sniper Turret Ring building. For now this is experimental (and marked as such), but in tests it works very well.
  • Building forcefields, engineers and factories no longer counts as building (weaponized) defenses, thus the helper journal for enabling these functions should now appear again if needed.

DLC3

  • Overshot how metal intensive Sapper strikecraft should be. Pulling metal costs back down a bit so they replenish faster but aren't as fast at building as they were before the buffs.
  • Fix a bug with the necropolis-swap hack
    • Thanks to Daniexpert for reporting
  • Skeleton homes now grant more bodyguards; +2 bodyguards (archer/warrior/rogue), +1 bodyguard (mage/lord)
  • For Necropolises, there was a hole where the AI might build a reconquest command station on a planet with a crippled necropolis, then the player could rebuild the necropolis, so you could have a functioning Necropolis and an AI Command station on a planet at the same time.
    • Untested, for feedback. Thanks to Daniexpert for reporting
  • Necropolis modules now do necromantic damage
    • Thanks to Pmm5000 for reminding me of this
  • Feeble Elderlings grant a bit more Essence.
  • The Necromancer can now use the Sabotage hack, just like the human empire
  • If you don't have Igors already unlocked, Igors will be available in the second rift
  • If you don't have Banshees already unlocked, Banshees will be available in the second rift
  • The first rift will also offer you a skeleton type or a wight type you don't have yet
  • Fix a bug where Elderlings were not laying eggs
    • Thanks to Sage for reporting
  • The 'move necropolis' hack no longer lists the necropolis you want to move as an option.
    • Thanks to Daniexpert for reporting
  • Decrease the skeleton lord's bonus damage
    • From Daniexpert's feedback
  • Templar Constructors are now much slower and more powerful. In addition they grant a good amount of Science and Hacking.
    • The goal is to strongly reward good strategy (killing these constructors will really limit the Templar's expansion), buffing the player strategically and with resources.
  • There have been a number of buffs to the Necromancer in the last couple patches, due to feedback that the Necromancer was a little more challenging than we wanted. I've tried playing with a number of balance-dials in part to try to figure out how much impact each one has. If it turns out that (say) additional bodyguards is a really big buff, that's good to know.
    • I also went (perhaps) a bit overboard with the buffs, but I'd like to know that player feedback as a much stronger necromancer makes the game more fun. Right now the game is harder than HA according to testers, so I'd like to see what people think about the game being a bit easier than HA; if it's just way more fun to feel Powerful as the necromancer then we can lean into it to find the sweet spot.
    • If it turns out that these buffs are not enough to make the game feel easier I'll make more changes, because I really would like to know how a Buffed Necromancer feels
  • Added seeding of Necromancer Utility building at the start of the game.

Bugfixes

  • Fixed a very confusing issue where if your fleet was in hold fire mode and you tried to build a command station, it would just silently fail.
    • Now hold fire mode does not block construction at all.
    • Additionally, if you don't have any builders present (or all of them are crippled or otherwise disabled), a message pops into the chat area that states that.
    • Thanks to Dismiss for reporting.
  • Fixed the tooltip on the "starting metal" option in the lobby to include the text: Default is 2.5 million (that is also the maximum, because adding more would not fit in the storage capacity of your starting command station).
    • Thanks to Incognito and Strategic Sage for reporting.
  • Fixed a couple of places in the per-second sim repair where in super duper large games it could wind up assigning the wrong unit to the central registry, as that unit died in the middle of being checked on that thread.
    • Thanks to Mysais for the save that demonstrates this.
  • Fixed an issue with the display in the escape menu claiming there were a much larger active number of shots than there really were. What it was counting was actually the number of shots that were ever registered in the current session, and that list can indeed get to be hundreds of thousands or millions of entries long, without it being a performance concern. The number of shots actually flying in the air right now is a much larger concern.
    • Thanks to SirLimbo for reporting.
  • Fixed a handful of typos.
    • Thanks to Strategic Sage for reporting, and Dvd as well.
  • Potentially fixed an issue at SetParentEntity in entity systems.
    • Thanks to Alivaril for reporting.
  • Previously, if you hacked a Zenith Miner to turn a planet nomadic, and you did not have any other nomadic planet,s it would just throw an error instead.
    • The game now has a game command for belatedly adding factions to the game (this will be the exact thing required for beacon factions to return, actually!), and it uses this to add in the nomadic planet faction, thus letting the hack work properly.
    • Confirmed that the nomadic planets work properly after addition, as part of this. This was also impacting the nomadic galaxy option.
    • Thanks to The Beast of Bognor and Incognito for reporting.
  • Fixed a bug where tachyon planning could still have a cross-threading exception.
    • Thanks to Zer0h1nder for reporting.
  • The game is now much better about enforcing two AIs when your campaign type requires it (Expert and upward).
    • If you are starting a quickstart in Expert+, it now copies the first AI if there is only one, and uses those settings for the second AI.
    • Also fixed a bug where it was not even setting the quick start to the desired value when you started a quickstart (it was always whatever was baked into the quickstart).
    • Thanks to Strategic Sage for reporting.
  • Updated A Twisted Enemy from DLC1 to be a newer copy of the quickstart that is not on the honeycomb map.
    • Thanks to Strategic Sage for reporting.

Prior Release Notes

AI War 2: The Great Refactor

Retrieved from "https://wiki.arcengames.com/index.php?title=AI_War_2:The_Final_Cycle&oldid=46106"