AI War 2:The Arrival of Fleets

Known Issues

• The lobby interface is currently temporary, and undergoing a complete overhaul.
  • It's suggested that you use the quick start option instead.

• Various bugs on mantis: https://bugtracker.arcengames.com/view_all_bug_page.php

• Multiplayer is temporarily disabled while we focus on tightening up the single-player loop.

• There are a variety of ships/units that don't have final graphics at the moment, though they all have their icons.

• We're in progress with a major revamp of some systems based on cumulative feedback in order to push the game even more towards the feel of the original game... despite further divergence from it at a mechanical level.

What's this phase all about?

After 3 months of Early Access and 2+ years of development, we've reached a point where we know what we want the 1.0 version of the game to look like. SO very much about this game already works well, but there are some major deficits coming into this phase when comparing this sequel to the original game. The aim of this phase is to close those gaps and make this clearly the superior product in terms of playability, fun factor, the amount of fun thinking-about-interesting-challenges you do during gameplay, and so on.

There's also of course still more polish and bugfixing that we want to get done, and the lobby redo is still scheduled of course (but quick starts are an awesome alternative, and have helped us to defer a final design for the lobby as we formed up some other bits of the game first), but we're feeling really good about this final sprint toward 1.0. We still do need to also finish some graphics for the existing ships, but they all have their icons.

There is some more content coming as part of this phase, kind of by definition -- fleets as a concept Change Everything in a good way -- but the focus is on taking what is a pretty awesome game with a lot of depth and pushing it to a level that we hope beats the pants off the original, finally. Stay tuned.

Version 0.850

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

We are breaking all the savegames again, sorry about that. This should be the last time for real for real, although we've said that before. It's not our practice to do this sort of thing at all, typically, but this game has been going through a lot more pre-release evolution than most of our titles have. The old savegames won't even make sense in the new version, really.

• Science Labs, Hackers and Scouts are removed. Scout functions of the Sentinel Frigate and Sentry Starship are removed.

• Sentry Starships are now per-planet cap, cannot use wormholes, are built directly (like turrets) and die to remains.
  • They're effectively Decloakers from Classic, but far more convenient.

• Dyson Spheres will remain antagonized much longer after hacks.
  • More hacks against a Dyson Sphere will increase the antagonization time.

• Allow the AI to spawn Dyson Antagonizers in the galaxy. Only Dyson factions with high enough intensity can spawn antagonizers.
  • Antagonizers affect all Dyson Factions, so if you've enabled 3 dyson factions, the AI will spawn antagonizers for each dyson faction, and you have to kill all the antagonizers before they will become friendly again.
  • Dyson Antagonizers follow similar spawning rules to Instigator Bases; they need to spawn close to the player at lower AIPs, and at high AIP can spawn anywhere.

• Engineers are per-planet cap, cap reduced significantly and can't use Wormholes.
  • The new Combat Engineers are able to use Wormholes and are a type of Strikecraft instead.

• Mobile Space Dock and Mobile Builder are not unlockable or buildable, and are instead capturables.

• Remains Rebuilders are removed. Command Stations and Mobile Builders do this now.

• Gives some units unused voice lines, and the Dyson ships the Zenith voice.
  • Engineers and other similar civilian ships now actually talk!

AI Behaviour Changes

• The AI will now be less worried about distant mobile enemy forces.
• The AI will no longer mistakenly count Guard units as Threat in some code paths
• Make some improvements to hunter/warden fleet routing logic
  • Thanks to zeusalmighty for the Hunter/Warden save game

• Each AI faction now has its own Hunter/Warden fleets. The units of each Hunter/Warden will just show as "Hunter Fleet" or "Warden Fleet", but there will now be multiple fleets acting independently. The goal of this is to make those fleets much more flexible in how they deal with enemies.
  • Only one Hunter and one Warden are visible in the game lobby. The other hunter/wardens will copy the colours but not the settings of the visible Hunter/Warden.

• Add a highly experimental option to the Game Lobby, "AI Civil War". This will make all of the AI factions hostile to eachother. The Warden and Hunter Fleets will remain friendly with all the AIs.
  • This is intended for testing purposes and for people who like playing AIW2 as a sandbox simulator.
  • To balance having variable numbers of AIs in the game, the rule is "Each AI's default income is divided by the number of AI's Friendly to it in the game". Note that enabling the civil war will consequently make each AI much more powerful.

• The targeting code now treats XML-based importances as more important than 'amount of damage I can do'; this makes it less likely for units to ignore Command Stations and other high-value targets in favour of fleetships

• Change how overkill is calculated; only count units that are actually in range of the target
  • This makes ships less likely to dance between multiple targets, unable to pick which one to attack.

• Don't throw away Distance to Target information when choosing a target
  • This also makes ships much less likely to do the "can't decide on a target" dance

Map Changes

• Several map types have been improved by Draco.
  • Thanks Draco!

• Make the Simple and Realistic map types more interesting by fixing a dumb bug in them.

• The Max/Min number of planets in the galaxy is now defined on a per-map type basis rather than a global (since some maps scale up to larger galaxies better than others)
  • Some map types go up as high as 500 planets, others are capped at an AIWC-like 120 planets

Hacking changes

• Science Extraction hacking will now show the total cost for the remaining science on the planet in the tooltip
  • Requested by Ecthelon on Steam
• Hacking has been feeling a bit too easy these days, so include AIP when calculating how strong the hacking response should be for hacks against the AI.
  • The formula is now NewHackingResponse = oldHacking Response + (oldHackingResponse * AIPMultiplier * CurrentAIP)

• Add the Sabotage hack
  • This will kill a random NormalPlanetNastyPick structure on a planet. Many people have asked for this.

• Allow hacks to be done against planets, not just structures
• Allow hacks to be done without a local hacker on the planet
• Allow the AI to launch an attack against the player after hacking is completed
  • These can be set on any hack with an XML tag. So all the previous hacking mechanics can continue to function as usual, but new options are now available.

Bug Fixes

• Fix a bug in the entity hovering ui where it was incorrectly identifying energy overdrive as an attack penalty
  • Thanks to Democracy for the bug report

• Fix a bug where the Zenith Trader (Traitor!) was allowing the AI to buy way too many goodies
  • Thanks to lots of people for reporting this, including Jannik2099 and Ovalcircle

• Fix a null reference exception when handling GameCommands
  • Thanks to jannik for the bug report

• Fix a problem where v-wings were having damage multipliers based on buildings lack of engines
  • Thanks to weaponmaster for the bug report

• Correctly flag the "Download Dyson Sphere Ship" hack as unavailable after that hack has been completed
  • Thanks to Ecthelon on steam

• Fix a bug where vengeance generators were warping in already vulnerable to damage
  • Thanks to WeaponMaster and zeusalmighty for the reports

• Add an Objective for hacking the Spire Archive
  • Thanks to settemio for the reminder

• Only seed one spire archive per AI
  • Thanks to WeaponMaster for the report

• Spire Archive isn't invulnerable to all damage, meaning it properly dies after being hacked.
  • Thanks to Democracy for reporting.

• Spire Archives now show on the galaxy map.

• The Superterminal now explodes after the hack finishes, instead of using a kludgy and bug prone mechanism to prevent it from being hacked multiple times
  • Thanks to Lifestrider and zeusalmighty for bug reports

• Fix a typo in the settings menu for multiple AI types
  • Thanks to coldrage101 for reporting

Renaming

• Cleaned up all entity names, from in the past when they changed function (i.e LaserTurret to NucleophilicTurret).
• Also cleaned up and standardised all the entity system names, and cleaned out a few that were redundant.
  • This should make it a bit cleaner to work with in future, as there's no weird cases of there being a WidowGuardian, which is really the Paralysis Guardian, but it shows up as the Widow in all the internal files!

• The Widow Mine is now the Paralysis Mine, and the Grenade Launcher fleetship is now Grenade Launcher Corvette - seeing as it has the Corvette icon and all.

• Sentinel Frigates are now Sentinel Gunboats.
  • Anything in future, like Lightning Torpedo Frigate will use the term Gunboat instead.

• Fleetships are now called Strikecraft, and Starships are now called Frigates.

• Space Docks are now simply called Factories, Mobile Space Dock is Mobile Factory, and the Starship Constructor doesn't exist at all now.
  • Both Strikecraft and Frigates come out of the same building.

• Not a rename, but a recolour. Human Resistance Fighters and Marauders have a primary green that shows up better in game, and matches what it is in the lobby.
  • Thanks to TechSY730 for reporting.

• Advanced Factory is now the Intra-Galactic Coordinator.

Ship Variants

• Adds the "Harasser" variant of the MLRS Corvette.

• Adds the "Porcupine" variant of the Pike Corvette.

• Adds the "Ablative Troll" variant of the Ablative Gatling.

• Adds the "Dagger" variant of the Raider.

• Adds the "Gunbot" variant of the Autocannon Minipod.

• Adds the "Velociraptor" variant of the Raptor.

• Adds the "Stalker" variant of the Eyebot.

• Adds the "Tripper" variant of the Sniper.

• Adds the "Railpod" variant of the Sniper.

• Adds the "Pulsar Punk" variant of the Pulsar Tank.

• Adds the "Aggressor" variant of the Agravic Pod.

• Adds the "Mirage" variant of the Space Plane.

• Adds the "Hydra" variant of the Vanguard.

• Adds the "Zapper" variant of the Inhibiting Tesla Corvette.

• Adds the "Terrier" variant of the Spider.

• Adds the "Molotov" variant of the Grenade Launcher Corvette.

• Adds the "Ranger" variant of the Sentinel Gunboat.

• Adds the "Medic Gunboat" variant of the Sentinel Gunboat.

• Adds the "Absorber" variant of the Vampire Claw.

• Adds the "Thief" variant of the Etherjet.

• Adds the "Paralyser" variant of the Stingray.

• Adds the "Cluster" variant of the Auto Bomb.

• Adds the "Nanoswarm" variant of the Auto Bomb.

• Adds the "Persuader" variant of the Parasite.

• Adds the "Ripper" variant of the Warbird Frigate.

• Adds the "Brawler" variant of the Assault Frigate.

• Adds the "Devastator" variant of the Siege Frigate.

• Adds the "Siphoner" variant of the Shield Frigate.

Balance Tweaks

• Tesla-class structures (Guardians, turrets, etc) now reduce incoming damage from far away by 99% instead of 100%. This allows the targeting code to identify Tesla units as potential targets (instead of ignoring them as if they were Invulnerable). Units in FRD (and minor factions) should now be able to actually attack Tesla turrets.
  • Many people have complained about this, including TechSY730 and Democracy.

• Ark Energy Overdrive is removed for now. Find another place for it (likely in a changed form).

• Sniper damage bonus requirement reduced from speed 1200 to 1000.

• Sniper: Starting bonus multiplier 5x -> 8x.

• Space Plane gets the damage resistance to anything beyond range 4600 instead of 5600 now.
  • Basically you have to be closer to it to do full damage. Also means that when using Pursuit, they try to stay beyond that.

• MLRS units have half the shots per salvo, but reload in half the time.
  • Helps them retarget more often.

• MLRS units get their damage bonus at 30% enemy hull remaining, instead of only 20%.

• Vanguard, Pulsar Tank: Albedo 0.7 -> 0.3.

• Vanguard, Pulsar Tank, Inhibiting Tesla Corvette, Grenade Launcher Corvette: Mass 0.21x -> 0.3x.

• Vanguard: EngineGx 8 -> 7.

• Raptors, Autocannon Minipods, Space Planes, Agravic Pods, Vampire Claw, Raid Frigate, Warbird Frigate, Eyebot, Stealth Guardian: Albedeo increased to 0.7.

• Concussion Corvette, Sentinel Gunboats, Snipers, Siege Frigate, Tritium Frigate, Warbird Frigate, Tritium Guardian, Concussion Guardian, Plasma Guardian: Armour reduced to 40.

• Concussion Corvette: Shields 2,800 -> 1,800, EngineGx 8 -> 14.

• Vampire Claw: Armour 40 -> 70, Life Leech reduced from 1.5x to 1x.

• Raptor: EngineGx 7 -> 10.

• Raptor Hull: 2900 -> 1900.

• Stingray, Etherjet, Metabolizing Gangsaw: EngineGx 7 -> 14.

• Inhibiting Tesla Corvette only applies reload penalty to armour below 60.

• Siege Frigate: Damage 2500 -> 25,000, spreads it among targets instead of hitting 10 for full damage, range 10,100 -> 12,000.

• Grenade Launcher Corvette, Vanguard, Pulsar Tank (main gun only): Range changed to 4200.

• Grenade Launcher Corvette, Vanguard: Speed reduced to 400.

• Grenade Launcher Corvette: Hull 1,000 -> 1,400, shields 1,000 -> 1,600, EngineGx 8 -> 7.

• Grenade Launcher Corvette, Inhibiting Tesla Corvette: Armour increased to 110.

• Inhibiting Tesla Corvette: Shields 2,000 -> 3,000.

• Etherjet: Damage 30 -> 20.

• Fortified Tesla Turrets have a similar damage bonus to Ablative Gatlings now.
  • Makes them a bit more interesting, and also some room for other changes.

• V-Wing: Hull/Shields changed from 500/3500 to 2000/2000.

• Pike Corvette: Armour 50 -> 70, range 8,000 -> 6,000, shields 200 -> 800, speed 700 -> 500.

• Eyebot: Hull/Shields 1,000/1,000 -> 800/800, armour 50 -> 60.

• Agravic Pod: Armour 50 -> 70.

• Dark Spire get a bit less energy if they're the ones that killed something.

• Nucleophilic Guardian: Armour 90 -> 50, albedo 0.7 -> 0.3.

• Concussion Guardian: Hull/Shields changed from 20,000/20,000 to 10,000/30,000, EngineGx 12 -> 14.

• Spider Guardian, Paralysis Guardian: Speed 1,400 -> 400.

• Spider Guardian: Range 15,000 -> 8,000, Armour 90 -> 40.

• Paralysis Guardian: EngineGx 13 -> 7, Armour 90 -> 110, range 8,000 -> 5,000.

• Grenade Launcher Guardian: Albedo 0.4 -> 0.3, EngineGx 14 -> 7.

• Pike Guardian: Armour 50 -> 70, EngineGx 14 -> 7, range 8,000 -> 6,000.

• Tractor Guardian: Albedo 0.7 -> 0.3.

• Gravity Guardian: Albedo 0.7 -> 0.4.

• Reintroduce the Plasma Turret.
  • Closer to Heavy Beams than the rest.

• All Turrets except Beam and Plasma have 10% lower health, but 15% greater damage in exchange.
  • Turrets felt like they slap the enemy to death slowly while outlasting everything. This is minor, but speeds it up a tad.

• Slow the increase in cost for Science hacking multiple planets
  • Thanks to Ecthelon on Steam for the suggestion

• Minefields are now all one use. Damage increased for normal and Area mines to compensate, Paralysis mines have a longer effect as well.
  • This fixes numerous problems with them, including somehow surviving and the AI being confused, being repaired mid-combat, overkill or Military Command Station boosts having weird effects, etc.
  • Also lets us put damage bonuses on more cleanly without worsening any of those previous problems.

• Marauders have a per-outpost cap on the Raiders they can produce. Unfortunately, stacking causes raiders to lose information about their spawning outpost. As a backup, also introduce a global cap on the number of raiders that the marauders can have.
  • This should dramatically tamp down the power of high intensity Marauders late game, especially in sandbox games.

Achievements

• Add Achievements for winning a game with each AI type enabled
• Add Achievements for winning a game with some of the Minor factions enabled
• Add Achievements for winning a game with various galaxy sizes
• Add Achievements for controlling a given number of planets in a game
• Add Achievements of the form "Have > X Metal/Energy/Hacking points"
• Add Achievements of the form "Kill > X units", "Lose > X units" and "Kill > X && Lose > Y units"
• Add Achievements of the form "Have a campaign X hours long"
  • Note that the above types of Achievements can be added to the game with only XML changes
  • TODO: Add a UI to show the player which Achievements have been earned

Big List Of Game-Tech Changes

• The science and hacking scales, which were 1000 and 15 previously, have now been removed.
  • Now there are science and hacking amounts per planet, and those are now 2000 and 30. Same as before, but more directly set now.

• Similarly, the starting science and hacking amounts are now just set directly rather than being a matter of a multiplier. This just makes things more clear.

• The Balance_TechCosts stuff, xml and otherwise, has been removed.

• A new TechUpgrades table has been added instead.
  • This has the ability to have fleet-specific upgrades and upgrades that benefit ships in a variety of fleets.

• Ark Upgrade Points and Destruction Points are both confusing and have been removed from the game as a concept.
  • But never fear, something very similar with a clearer name and purpose is being added back: Fleet Experience Points.

• Formations, which were in early versions of AI War 2 and tied to control groups at the time, have been renamed Fleet Formations and are actually coming back!
  • This is pretty exciting, as they can have custom code of whatever manner, so if you have some way you want to organize things, you can set it up that way. We may not do much with this for a while, but it's a huge returning tool.

• Build Queue Policies, which were in early versions of AI War 2 and tied to control groups, are being phased out. Along with the metal budget policies.
  • Also the underlying old style of build queues are going away.

• can_only_be_placed_on has been removed, as it no longer really needed.
  • Same with sensor ranges and sensor scramblers.

• cap_is_per_planet has been removed, and fleet_membership has been added instead. It has the values: CrossPlanetary (default), and Planetary.
  • cannot_traverse_wormholes has also been removed, and now anything that is Planetary simply can't cross away from the current planet.

• can_be_built_on_enemy_planets has been removed, as that is now something that is based around the fleet that the type belongs to at the time. It's all contextual now, in other words.

• testing_ship_line_unlocks_to_start_with has been removed, since the unlocks don't really work that way anymore.
  • Same with starting_unlocked_ship_lines.

• Colony ships have been removed from the game, since that was a level of indirection that was not needed.
  • Similarly, hackers are gone, as are mobile builders in the classic sense.

• Starships are now called Frigates, including in the codebase itself. Docks are now called Factories in the codebase.

• Design Template Servers in the codebase are now gone. The concept of warheads, in the codebase, is now gone.

• In the SpecialEntityType lookup, the differentiations for Golems and Arks are now both gone. Instead they are both just classed as Flagships. From a mechanical stantpoint there's now no difference between them in a general way.
  • Additionally, things like mobile builders are gone in a special type sense, and are now just considered Battlestations.

• Each mobile fleet of the player, which is centered around a flagship of whatever sort, now calculates a list of all the Factories (formerly Space Docks) that are on the same or adjacent planets to the flagship. These are the docks that will produce units for that factory.

• Rather than being inferred from the build menu (in a rather inefficient way, actually), drones, are now a new SpecialEntityType.

• A variety of data that was previously specified various ways (am I a command station, etc) in the xml has all been normalized to use the SpecialType now.

• The MetalFlowPurpose of BuildingShipsInternally is now FactoryConstructionForPlayerMobileFleets instead.

• EntityContentsRecord, which has been used only for drones for a while now (wellll... mostly), has been removed entirely. Drones are now handled as fleets like anything else.

• "BuildMenus" are now gone, and their (unused) build patterns.
  • The way that these are handled is now as FleetDesignTemplates instead.

• For organization of the Build part of the sidebar, there are now BuildSidebarCategory tables.
  • These handle odd cases like command stations, command station upgrades, and the Zenith Trader a little bit better than before.
  • These are separate from the Fleet Design Templates, since these are about UI organization, which is different from the underlying data providers now (before those were unified in a way that was not helpful).

• drone_build_menus has been removed, and now is replaced by fleet_design_template_i_use_for_drones.

• built_by and tech_cost have both been removed, and are now replaced by:
  • fleet_design_templates_i_am_part_of, tech_upgrades_that_benefit_me, and build_sidebar_categories_i_am_part_of.

• build_menus has been removed, and is now replaced by the following pair: fleet_design_templates_i_grant_one_of and fleet_design_templates_i_always_grant.

• Really key new limitation for drones, for the sake of sanity and not having nested fleets. This really only applies to player ships, in the main:
  • The drone producer must also be the fleet leader. So if we're talking about a player ship, it needs to be the Battlestation or Flagship of a fleet, and not something like a random Frigate as part of it.
  • On the AI and NPC sides, they don't really use fleets the same way normally, so anything that is a drone generator just becomes in charge of a new Drone fleet type.
  • This is probably going to be the source of some "fun" bugs. It will start spewing errors like crazy when this happens (once per second per ship that has this issue during gameplay), if it happens. It's possible to set this up with bad xml, basically.

• Player profile stuff relating to choosing a default Ark type is now removed under the hood. It hasn't been on the front-end for quite some time now.
  • Note that a lot of the stuff with Arks having a story and a portrait image are thus now gone, although again this isn't new on the front-end. Arks simply have a new role now.

• There is a new List<RefPair<GameEntityTypeData, int>> AIReinforcementPointContents on squads, which basically replaces the main usage of the EntityContents that was previously there in a non-drones capacity.
  • This allows for reinforcement points to continue to accrue reinforcements as they always did, without it getting odd or into a Fleet-based situation.
  • The reason for this being separate is that this was a smaller amount of code, to be honest, and also it doesn't have anything in common with being a fleet once the ships are actually deployed.

• Any ships that are attempted to be used as drones but that have a type that isn't special_type="Drone" now won't actually be built.
  • I'm sure THAT won't ever confuse anyone...

• For drones, their squad caps are now used to define how many drones of their type can be held at a given drone fleet.
  • Aka, a drone producer can now produce one cap's worth of whatever type of drones it has within its fleet type.
  • All that business with max_drone_strength_in_caps and max_drone_strength_in_caps_added_per_mark_level is thus gone. It was confusing an indirect, holy cow.

• Optional new multiplied_frigate_ship_cap_for_drones (FInt) and multiplied_nonfrigate_ship_cap_for_drones (FInt) have been added, which let you make certain types of drone controllers stronger than others.
  • You can have multiplied_nonfrigate_ship_cap_for_drones="1.5" to make it so that all of the caps for any of its non-frigate-style ships are now 1.5x more than baseline, for one example.
  • Given that most ships that would be drones are either frigates or strikecraft, but that strikecraft are not super well defined in code (kind of being "it's a strikecraft if it's not something else"), this lets us be a little more specific than just having an overall multiplier, without going crazy wuith multiplier counts.

• SquadCap is now GeneralSquadCap, since that's now more of a guideline than anything else. It's now a lot more fleet-specific.

• StrengthPerCap has been removed, since that's no longer... something that makes any sense in the new system. It was based around SquadCap.

• The Remains Rebuilder has been removed, and the RebuildingRemains metal_flow has now been granted to all of the player command stations and the player mobile builders. It's no longer something that is assist-line-distance-based, nor is it something that requires a dedicated unit to run around doing things with.
  • This is one of those streamlining bits that people have requested for a while, but Chris in particular was noting that engineers and rebuilders need to be two separate functions (and they do). But making this instead essentially work like claimables and "just happen" solves the issue that people were complaining about without getting into territory of making the AI for the engineers likely to be bonkers.
  • Later we will need for all of our battlestation types to have this, most likely, or things will get funky at times. This last is a note for Puffin.

• Some confusing stuff in metal flows with recipients versus potential recipients has been simplified into simply one list (for squads), and now also has a separate list for fleet memberships.
  • There may have been some bugs in this area previously, but the code was so hard to read it's hard to be sure. If there were bugs, they should now be fixed.

• The various types of "ships rally to X location after construction" are now gone, with instead all the ships from docks rallying to their fleet centerpiece, whereever that may be.
  • This is highly automated and much more the default thing we want to have happen.

• During direct placement of things like turrets, the mark level is not drawn on the icon, at least not for now.
  • It's not clear that this is really needed anyway, and right now it's mildly difficult to calculate. Remind us to add this back in if it bugs you (ArcenPlacementGimbal.cs).

• Okay... BuildMenus really were being used ALL OVER THE PLACE for a bunch of different purposes.
  • ai_ship_groups_i_am_part_of has been added, with a new AIShipGroup class that goes along with it. This should make things a little more clear in the xml and code, despite it being mildly duplicative with the fleet design templates. Odds are fair that those will continue to diverge anyway.

• TryToSpendBudget_CPA has had some updates to how it deploys ships from itself, since the way it stores ships is different from the start. This may or may not cause demonic fumes to erupt, so let us know.

• The gameplay settings for automatically building remains rebuilders and setting them to auto-FRD are both now gone, since so are remains rebuilders.

• The gameplay settings for "brave scouts" is also now gone, since scouts are also being removed and rejiggered.

• Design Template Servers have been removed. They were not exactly exciting, and they don't make sense in the new method of AIs working with unlocked ships/

• UnlockShipLineForAI() has been removed, as AIs don't work that way anymore, either.

• ship_lines_to_start_with and ship_lines_forbidden have been removed, as we're going to handle that aspect of AIs a bit differently, too.

• The ability to choose your starting bonus ship type has been removed from the lobby, as that is yet another thing that no longer makes any sense in the new tech/fleet setup style of the game.

• Schematic Servers (formerly ARSes) have been removed. Those also no longer make sense in the brave new world that is the new setup for fleets, etc.

• The idea of CorruptedAIDesigns has been removed, as that was something that people weren't really using and it doesn't fit well with the new approach to AIs and fleets.

• The concepts of destruction points and Ark Upgrade Points are both gone, and replaced by Fleet EXP instead. This works similarly to both of those other things, in that if your fleet centerpiece is on a planet with an enemy ship that dies to your forces, then that fleet gains some EXP. More for big-ticket items.

• The keybind for "select all scouts" has been removed, since scouts are removed.

• SelectNextUnitType and SelectPreviousUnitType have both been removed, as they were buggy like crazy in general, and also don't really make all that much sense in the new workflow of things.

• The default serialization style for things the game saves is now Byte arrays rather than the char arrays. This will make savegames vastly smaller than before, although not as legible (as if they were before) to edit by hand.
  • This is great for a variety of practical reasons, but among them it causes fewer transient garbage collector allocations. And it also makes it so that large integer numbers are no longer something that make the savegame larger. Rather than one char's worth of bytes per digit in the number (1-6 bits, per UTF-8 specs), it now just has a fixed 4 bytes for the number regardless of how many digits it has.
  • This breaks all the previous savegames, but they were already broken anyway.
  • Player profiles and settings are still using char arrays so that they can be edited by hand as desired.

• There was previously a "too smart for our own good" method for "compacting" integers down that were used as primary keys. This could cause all sorts of bugs when used incorrectly, and aside from known bugs that this fixes, we happened to see a few other bugs in passing as we were removing it.
  • Note that this was needed almost exclusively because of the char arrays serialization that we were using. Now that we're using byte arrays, this compacting is not just bug-prone it's actually not any more efficient in the first place. So it's really good to have that out of there in general.
  • Thanks to DEMOCRACY_DEMOCRACY for reporting a particular bug caused by this.

• Items that are truly deprecated, but that we still want some record of for whatever reason, are presently moved into a new GameData/Pre900Deprecated folder.
  • This way we still have the xml, but the game never looks at it. Normally the purpose of deprecating something is to make sure that savegames that are older can still be read in. With 0.900 we're breaking the savegames anyway, so clearing out the deprecated stuff is only natural.

• is_bonus_ship has been removed, as the concept no longer has any relevance in the new fleet style of unlocks.

• The general TechUpgrades xml data no longer has anything about fleet-specific upgrades in it, since that wouldn't make a whole lot of sense anyhow. Those will be handled through the interface elsewhere.

• The initial techs have been added, and applied to ships and turrets and whatnot.
  • This is, at best, a first pass for now. However, there are are present 14 distinct techs that you can upgrade that are more ship-abilities-focused, and which are generally shared between strikecraft, frigates, and turrets. This is the general intended design, even if exact matchings aren't correct or ideal right now.
  • The costs here are also potentially bonkers for real-world use. Additionally, there is a maximum number of times a given tech can be researched, and that is usually set at 4 right now, kind of arbitrarily. That does NOT mean that the max tech level of a ship is 4, however.
    • Ship tech levels are a combination of all the techs that benefit them (some have more than one), as well as any upgrades to the tech level of their specific fleet. So some are much easier to get to a VERY high mark now, whereas others are almost impossible to do.
  • There is now a new UpgradeMeFromFleetOnly tech that isn't shown on the menu, but which we use in cases where we want to denote that this IS something we can upgrade, but only at the fleet level rather than the ship level.
    • This is used for things like command stations, engineers, economic production units, and forcefields. That makes these things a lot more location-dependent in terms of how high quality your ships of those sorts are. This should be pretty interesting, actually, and it takes them out of contention for the main science upgrade costs more.
  • Overal the goal here is fewer science upgrades happening, but each one having a much larger impact. We may have gone too far in that direction with this first setup of the data, but at this point it's all an xml-based issue.
  • Note that all of these techs are based around upgrading all the ships that you have that subscribe to this tech via tech_upgrades_that_benefit_me, and that crosses fleets.
    • Badger: it would be nice if this benefitted mercenaries, although it's not clear right now if that's the case that it would. If it's a separate faction then it would not, probably. If mercs are their own faction, then I probably need to build a general way in that says "hey I inherit whatever techs from the player" on a per-faction-definition basis.
    • Puffin: I did base this loosely around your classes/roles document, but this is meant to be... slightly both more and less granular than that document, and to be multi-categorized in many cases. So your document is still relevant (mainly for fleet design), but it's just semi-related to this specific use.
  • It's also worth noting here that some ships/turrets/whatever have multiple tech_upgrades_that_benefit_me, and those are going to go up in tech quality FAST by comparison to their peers. Assuming that players unlock techs synergistically. So some of the ones like the Light, Heavy, etc, might need to be a lot more expensive than they are right now.
    • As noted already, the balance here is a bananas basic proof of concept right now, and I'm sure broken in a thousand ways. The only purpose of me throwing this together at the moment was to give a proof of concept unified design philosophy to look at, even if details are really wrong. This gives Puffin and others a chance to actually make it make a lot more sense while I move on to work on other things.
  • Note that the EXP concept doesn't come into play at ALL with these sorts of techs. These are purely science costs. The EXP is fleet-based stuff instead, and may not cost any science at all (fleets that auto-upgrade would be nice). But also spending some science on a specific fleet's upgrading would be nice, so that's something that will likely be possible. How that works at the planet level is still TBD, I have two different possible models for that and haven't been able to choose between them yet.
  • Also please note that for an individual ship/turret/whatever type, there's no risk of it going above its max mark level, which is either 7 or is explicitly defined as something lower, or is markless. If it subscribes to 2 techs that each have 1 upgrade, it would naturally be mark 3, unless it's capped at mark 2 in which case it will sit at mark 2. And if its fleet is also upgraded 3x, then it would be mark 6, unless it was capped lower.
  • A general note: This overall tech system has way fewer decision points than the old one, which is good because that makes them actually something that you can contemplate. However, as a byproduct of that, you'll often get some secondary stuff upgraded that you cared less about, and that actually provides opportunities for you to make new use of them in interesting ways if you so choose. Also also, you're a lot more likely to have really wide mark level disparities between parts of your empire (different planets and fleets), which is more in keeping with the first game albeit from a completely new angle. This is exciting.
  • Another general note: the overall ship caps per fleet will only be whatever they are, but the idea is to have larger effective ship caps for players by the late game because of a proliferation of fleets. In some cases in the late game you'll also have some fleets that are incredibly technologically superior to the AI, and other fleets that are incredibly behind the times. How this exactly plays out will be interesting to see from players, but in a theoretical sense there's nothing wrong with that; we may just have to adjust some balance dials over time to keep things from being TOO extra weak or strong, and/or to make the AI really reactive to overly-advanced forces if those exist. Here again this is an opportunity for more gameplay, rather than a real challenge in a negative sense.

• The Mobile Builder is now the Basic Battlestation.
  • Puffin: This is something that we'll want to actually make copies of and have 4-5 variants that actually have unique qualities, and ditch the basic version.

• The Mobile Factory is now the CombatFactory.
  • Puffin: We may want a couple of variants of this, up to you. One that is more heavy on the factory-ish nature of itself, and one that is more about spawning a metric ton of combat engineers, for instance?

• The Fortress is now a form of Battlestation.
  • Puffin: this is only kinda-sorta set up in the xml, and needs more work.

• On factions, there is now a InheritsTechUpgradesFromPlayerFactions serialized bool that should be set to true for any factions that the designer wishes to recieve all of the upgrades for the player techs.
  • Aka, if two players each have upgrades to Tech A, then the faction will get the largest of the two, not the combined value of them.
  • Badger: this should be set to true on Mercenaries. I haven't done that bit yet.

• Implemented GetCanUnlockTech, which is based around the concept of GetCanUpgradeOrUnlockShipLine from pre-0.9, but is based on the new logic instead.
  • Similarly, implemented UnlockTech, which replaces UpgradeOrUnlockShipLine.

• The ship_cap_multiplier actually works now in the new system. It won't increase the caps for anything with a cap of 1, though, just FYI. It also can't be used to reduce the cap.
  • Puffin: We need a better name for AdvancedFactory, and should adjust the code and xml accordingly to have the new name. It's confusing now in general because of our nomenclature changes and because it's the same name as something from the first game but works differently.

• question: when ships die to remains, do they wind up going back into the same fleet as before?
  • better question: do they wind up taking up the fleet management space that they did when they were alive? They should. Otherwise ship counts are going to get odd.
  • I'm guessing that this works, but I've not traced the code to see, and it will need testing once this goes live.

• Added a new IsConsideredOutOfSupplyOfParentFleetCenterpiece bool, which is calculated based on ships within a human mobile or defensive fleet not being on the planet of their centerpiece.
  • This is done separately because that way it can only be calculated once per second, which is a lot more efficient.
  • This then gets used by things that are checking to see if ship systems are disabled -- aka guns, engineers, etc. These ships can still move, but they're neutered on purpose.
  • If the centerpiece is itself kind of hobbling along half-dead, it's okay because the ships are still able to draw supply.
  • For the stuff that is either considered "loose" or part of a command station's fleet, these things don't have the concept of supply at all, because their fleet leaders can legitimately be destroyed permanently and they need to still function. Or the loose ones don't even have a fleet leader.
  • The goal of the fleet leaders thing is to keep the mobile fleets, and the battlestation stuff, remotely in the same area as one another. You can't start segmenting your fleets and sending them off to fight WAY off, only raiding neighboring planets. This is for balance purposes more than anything else, and is similar in reasoning to the old Supply concept from AIWC. Funny how things like that come back around!

• Battlestations and Mobile Fleet Flagships are now automatically something that cannot ever die, per se -- instead they become "crippled" when their health is less than 10% of its maximum value.
  • This solves a whole heck of a lot of problems that we otherwise have, such as where ships should rally to, and it also avoids the "corpse run" problem.
    • If there are lone golems that players are capturing that die to remains, or other similar things that are not fleet leaders in that way, then those can still be a source of corpse runs, so it's not like that mechanic went away. It's simply not being a major focus for these types of ships.
    • For a while, we were having things like Arks (which fall into this new category) automatically warp back away to some sort of safe space, but that's no longer a thing, which is good.
  • Their weapons and other systems all go offline when they have less than 10% health now, which is actually a pretty new limiter on them since it gives them only 90% of their health in which to work, although there's no longer the risk of them dying if you're not paying attention. But for balance purposes it's worth noting that we may wind up needing to beef these out slightly.
  • Enemy ships will consider them an uninteresting target if they are already crippled. It's possible that actually shots won't do any more damage when hitting them and they are crippled, which if so is a bug I need to fix later. But them not bothering to target the enemy seemed to be the most important thing for now. If you have a savegame with shots not damaging these ships, then please let us know.
  • It's also possible that there will be some edge cases where these things actually DO die rather than being crippled, in which cases repro saves will be very welcome.
  • Mobile fleets with a crippled centerpiece now have an effective remaining cap of 0 for all the ships that factories might be sending to them.
    • This makes it so that factories won't supply new things for them anymore until there is an un-crippling of the centerpiece. Otherwise there's no reason to bring said centerpiece home for repairs, it's just this strange invincible vessel to which lots of ships rally.
    • The metal spent on partial construction of ships is not refunded, but rather is stored at the fleet and as soon as the centerpiece is un-crippled things will come back online and resume wherever they were.
  • Note that if any ships are set to reverts_to_neutral_on_death="true" in xml while being of one of these two types, that really won't matter because they should never die. So those should probably be removed.

• Added a new AIShipGroupCategory table.
  • This is a new layer of indirection connecting AI ship groups into one or more categories that AI types then subscribe to.
  • This makes it far easier for multiple AI types to share the same ship group, and for modders to add ship groups.
  • The ultimate goal is for a modder or us devs to be able to add a ton of different intelligently-crafted groups of AI ship types for various purposes, and for AI types to then use those as appropriate, thematically.
  • These also have different weightings on them, so that the AIShipGroups can be more or less frequent depending on how hard or annoying or whatever they are.

• ai_ship_groups_i_am_part_of now uses weights so that you can specify how frequently a ship type comes up inside an AIGroup relative to other stuff in that group.

• The previous methods for some of the map seeding of AI things are also being... phased out in some ways, and made a lot more centralized and thus flexible.
  • This in turn lets us make the various AI planets a lot more unique, and lets modders add to things without replacing them.

• The Hydra is now the Vanguard Hydra, and there's a new Stringray Hydra type to keep it company.
  • The Stingray version is markedly more strong in the sense that it subdivides but doesn't have worse stats. It's a quick bit of variance for planets or waves that are replicant-heavy.

• Also added a Parasite Hydra to round it out even more, although made them thankfully lexss frequent.

-question: is MiniCluster actually used by anything in the new setup? I don't see how it could be.

• Added Ghost Grenade Launcher Corvette and Ghost Concussion Corvettes, to round out the ghost strikecraft category a bit.

• Basic definitions for ai ship groups and ai ship categories have been implemented. These are based around the excellent document that Puffin set up on the subject, but with some changes and additions here and there.
  • Note that this is ai_ship_groups_i_am_part_of, and it refers exclusively to how the AI uses ships. This isn't meaningful at all to fleet design stuff for players, which is a separate topic.
  • This also doesn't affect minor factions, although there's nothing stopping minor factions from adopting this new pattern in the future.
  • At the moment this also only describes strikecraft and frigates, and not turrets or other things of that nature. Those are coming soon. Puffin, if you want to set up the other categories and groups based on this starting template, probably ignoring the "singular freaky surprises" stuff, then please feel free as it would save me some time.
  • The overall rule with this usage of ships in groups is that anything that is a variant of something else shouldn't be in the same group with it. This is just a design thought, not a technical restriction. Warden and Hunter fleets will wind up having all sorts of strange mixing and matching, but by keeping to this rule we will ensure that planets and waves otherwise don't have that sort of strange mixing.
  • You'll also notice that for the ship group categories that are specific to certain AI types, like Turtle or Cloaking-Heavy or whatever, those also include some sub-groups that are unrelated to their type, but which will provide some... well, variety. Aka sometimes instead of being a cloaking-heavy wave, it will by an anti-structures wave. Sneaky! There's nothing worse than a predictable AI type, so having some variety in what they do, even if they are thematically heavy, is good.
  • It's also worth noting how the "draw bags" work, in this context. Essentially the number after the things that are included say "how many raffle tickets do I put into the draw bag?" And depending on how many other total raffle tickets have been put in, that's how likely it is to come out.
    • In order to allow for granularity in definitions, our default number of tickets to add is 100. That way we can say "only do this 1% as often as most stuff" by putting in 1 ticket instead of 100.
    • But even there, the odds of it coming out are not 1%, because it depends on what else is put into the bag. And by very definition, what is put into the bag is something that is meant to be unknowable at design time, since it can be modded, and expanded in the future. So we simply use something like "100" to mean "regular frequency, whatever that is," and then the other numbers like "25" to mean "about a quarter as often as usual, whatever that is."
    • It is worth noting that not putting too many types inside a single draw bag is probably good in MOST cases, because it means that players will be facing a planet or a wave that has some sort of coherency to it that they can plan around. I'd say that 3 types is a sweet spot for waves, but sometimes having many more or fewer types is okay. Variety being the spice of life, it's okay that many of the things drift off the "normal" design parameters.
    • Overall we'll find some situations where people go "wow there's way too many xyz unit in this circumstance," and we'll deal with that as need be. But most of these groups are intended for things that are not strictly numbers-bound (aka more than a handful of forcefields on a planet is terrible, so using them in these groups would be a Very Bad Idea since it would lead to occasional bouts of player dismay).
      • Most of the time, we are likely to wind up with something like "holy cow that one planet is a nest of sniper like I've never seen in my life," and we just kind of sit back and go "yep! That will happen, in extremely rare cases. Either deal with it or go around, but that's the fun of this." The prior system was leading to a feeling of samey-ness on all the various planets, and so this is meant to break things up more into various thematic niches, some of which are more rare than others due to being either annoying or scary or hard or whatever. But we still want those rare outliers to happen, because those are either the places where good stories happen during AARs, or where the player's eyebrows can shoot up as they go "I'm glad I don't have to go THERE." Or sometimes it's just going to be the Wave From Hell that surprises players before going away again.
  • This whole thing is going to take a lot more defining and redefining over time, but it's really well set up for having lots of ship variants and strange outliers. In a lot of ways, this is intentionally pushing planets and waves a bit more in the direction of a RogueLite, where you never quite know what you're going to find. Chris was really missing some of the sense of exploration, and this is his way of trying to capture that again.
    • And note that this is completely parallel to the player fleet waves and such, so the nice thing is that the AI, other factions, and players can all be thought of using completely separate structures and in completely different terms. As it should be.

• Okay, I went ahead and set up the guardians - royal, dire, swarmer, tutorial, and so on. Their weights are all just set to 100 in their categories, but this should be pretty decently correct in terms of what is in what categories.
  • One thing that I'm changing up a fair bit is making it so that normally the AIs won't use guardians in their waves anymore. The royal AI type is actually going to be an unusual exception on that. And the general restriction on AIs not using Starships (now Frigates) is also gone.
  • The entire way that we're calculating what goes into waves, and what populates AI planets, is different now, so why not.

• Added a new SimpleWaves and SimpleReinforcements set of ai ship group categories, per Badger's suggestion.
  • These don't use any of the more esoteric variants of strikecraft and frigate groups that the main AnyWaves and AnyReinforcements use, so that keeps the game vastly simpler.
  • These DO still use some of the basic variants that have some of the more complex ships -- just not the variants of those ships. But even these are set to be really low-incidence, so that while there will be a few surprises here and there for someone playing against the Simple AI, it's going to be several orders of magnitude fewer surprises for them compared to the Any AI version.

• There is a new field, cost_for_ai_to_purchase, which is an integer that replaces the old_strength values.
  • This is now what AIs use to purchase units, and it is separate from how strong the unit is seen as.
  • This is problably way out of balance for now, but it at least is something we can tune directly from now on.
  • "Strength" in the game is now properly only used for evaluating, well, how strong something is. Aka how the AI acts, or as information for the player.
  • This is NOT something that goes up by mark level anymore, unlike before, and that's by design as well. The AI should be able to afford equal numbers of ship type X on a mark 1 or a mark 4 planet. That's how things were in AIWC, but it was oddly not at all like that here.

• There are a bunch of other related changes to making the game use the CostForAIToPurchase field instead of the Strength field -- and remember that this is on the TypeData rather than the ForMark data, and that this is by design.
  • This is probably buggy as eff. There's a ton of code in this area, written by a bunch of people over a long period of time. So AIs will probably wind up making some pretty strange purchases for a little while, until we find and fix whatever bugs there are, aside from the inherent data issues.
  • Nonetheless, now was the time to go ahead and make this change, because it was a fundamental deterrent to us being able to balance what the AI builds separately from how strong the AIs and players view a unit as being. And that was one primary driver behind all things being a very similar cost-to-benefit ratio, at least on paper... and ongoing headache for Puffin, with that. The headaches won't end because of this change alone, but they will shift to a new sort: balancing each of those two things independently of one another ("does the strength stated for that unit seem to match how scary the AI and players should think it is?" and "does that cost an appropriate amount for the AI in most contexts, or is it too cheap or too expensive for them?").
  • But in the short term, this will be extra complicated by the fact that the math probably has some bugs in it because probably some things that should be using the new AI budget stuff are still using the strength data. I would be shocked if that's not the case, despite looking at it very carefully until I was cross-eyed.
  • And then the other question of "how much should this cost" is now out of date compared to what the strength values were, so even if the math is all perfect we're going to have bonkers data for a bit. That part I do leave to Puffin for the most part, sorry about that. ;)
  • As a general design note, both the players and the AIs have been having fewer ships than I would prefer, thus far. For players it was because of the way the ship caps were -- pre-fleets. For the AIs, it was because of the way they were being "charged more" for higher-mark stuff when looking at their own budgets. At the start of the game, a mark 3 planet and a mark 4 planet should have the same relative amount of budget spent, but one gets better stuff from it. Previously, unlike AIWC, the mark 4 planet was getting charged a premium and so felt anemic by comparison to the mark 3 planet.
    • This may in turn wind up with the AI having waaaay too many ships for a while, but if we pack those into the guard posts as contents that are not deployed yet, that should have zero performance impact. And it will be good for the humans who suddenly have a lot more firepower at their disposal. Overall the goal coming up is for everyone to have a whole heck of a lot more shooty things, but having them more spread out so that the mega-battles aren't individually any larger than they are now. It will take us a little while to get that part perfect, so please bear with us.

• Wormhole Sentinels have been removed, for now, as they really just kind of get in the way of the player being able to set up shop in a system and do something.

• The Stealth Wormhole Sentinels have been set up as something that only show up rarely, now that scouting is going to be working differently. This is useful for making planets feel a lot more varied, and not all planets so hard to sneak your stealth ships into.

• Added a new Basic Minefield Wormhole Sentinels, possibly against our better judgement, to let a tiny minority of wormholes actually have mines around them that players can stumble into.
  • Since these should only really show up once, with the AI not rebuilding them, this should be an interesting thing for the player to run into well under 1% of the time. Thanks to Puffin for suggesting this; this should provide for some interesting traps without being too frustratingly common.

• Actually jacked up the default NobodyHereWormholeSentinels draw bag count to 1000, and the StealthWormholeSentinels to 50, so that the 1 of BasicMinefieldWormholeSentinels is EVEN MORE RARE. Hopefully players run into one or zero minefields during a given campaign, thus making it more exciting.
  • Of course, if someone wants to make a minefield-heavy AI type, that is straightforward to do, now.

• Additionally, there are now 5 different kinds of wormhole sentinel setups that are based around using tractor arrays and turrets, tesla turrets, gravity weapons and pike turrets, and whatever else.
  • These are also in the minority in terms of how frequently they will seed, but are way more common than the minefields and should make it so that some of the wormholes are a lot more interesting to face, now.
  • This gets back a bit more back to the original design of the original game, which is only possible now because of how some of the scouting changes will interact with the game here. We had had to move away from this because of tedium of automated scouting in other circumstnaces.
  • There are still quite a few wormholes that won't be directly defended at all, and it's possible for us to set up way more wormhole defensive types as desired in the future; these are mostly a proof of concept.
  • Note that with the sentinels at wormholes, the idea is that these will exist from the start of the game and never get upgraded or reinforced, unlike what happens at guard posts.

• All of the turrets have been sorted in general into some ship groups and categories for the various AI types to use them, now.
  • Right now these are just kind of freeform jumbles, but we can easily make themed groups out of these so that some planets have some sets of turrets, while others have others. Long-term that might feel more fun.
  • Also did the same work with the "non turret defenses," which are things like gravity generators and tractor arrays that are used at the AI's reinforcement points rather than as wormhole sentinels. The statement "just a jumble" for these probably doesn't apply too much, though, since that's inherent in these.
  • Also did this for guard posts and dire guard posts, and these ones are also just a pure jumble for now. Like the turrets, getting slightly more thematic verstions than just the "free for all" bags that exist now probably would make sense. But isn't a priority, honestly.
    • The turtle guard posts are presently just set up to be a copy of the regular guard posts, but later that can be split.

• Set up new "singular freaky surprises" that includes how golems are seeded for the Golemite now, and actually gives a very rare chance that some regular planets will sometimes have an AI golem.

• The Vanilla AI type has been renamed to "Full Ensemble," referening the fact how it is basically the most well-rounded AI type that presently exists. It has the most varied surprises up its sleeves.

• Added a new Simple Ensemble AI variant: Like the full ensemble in most respects, but minus some of the more esoteric ship variants. There's plenty going on here, but not quite so much craziness to discover as you explore.

• The Starfleet Commander AI type has been removed, as now all the AIs kind of do what it was doing before. It no longer stands out as unique.

• The Everything AI type has been removed, as it was kind of redundant now, and wouldn't have made for coherent gameplay anyhow.

• Added in a completely untested new Thief AI type that was kinda-sorta defined previously but seemed to be missing, nonetheless.

• Also added a completely untested new Zombifier AI type that uses a bunch of zombifying ships and other nasty things. It was kinda-sorta previously defined but again still seemed to be missing.

• In general there were very few AI types removed, and instead they are all just a whole heck of a lot more vibrant, and we actually added a few.

• AIs no longer have any concept of "unlock points," and they don't unlock new ship types over the course of the game.
  • This was a neat concept in AI War Classic, kinda-sorta, but in a long campaign it just meant more chaos, honestly.
  • The original intent was to make it so that there was a feeling of progression and the AI doing new things with new tools as you go through the game, and that is now handled far better via the ship groups instead, and the planets being more unique, etc.

• When the budget for a wave is over 3k, the AI no longer randomly gets guardians added in as a thing they can buy for the wave. Instead things are more hand-designed than that.

• Each planet belonging to an AI now seeds a single entity from SingularFreakySurprisesAIShipGroup on each of their planets at the start.
  • Note that this includes a fair bit of blank space, and that if it chooses blank space that is considered A-OK. So it won't really be every planet, and the frequency is actually determined in the xml rather than the code.
  • This lets things like the Golemite be set up a lot more directly, and without using tags.
  • The ONE downside of this is that the frequency can no longer be based around things like what the AI difficulty level is. But frankly, that's something that makes the AIs feel less unique and not just easier; if the game is meant to be easier, the player should still be facing the unique foes of that AI nonetheless.
    • As part of this, the explicit seeding code for the Golemite to seed its golems has been removed, and it now uses the new central xml-based function.
    • Note that, if we want to, there's nothing stopping us from using both the old method and the new one at the same time. The new one is mainly a convenience that makes for some powerful new xml-only modding capabilities that don't need to touch C# to add cool stuff to an AI.

• required_aip_level_in_planets_worth has been removed from the MarkLevel definition, and the whole RequiredAIPLevel bit has been removed from ships in general.
  • This again was to unlock things over time for the AI, but now that is so much more contextual that this makes no sense anymore.

• Planets now remember what specific ShipGroup out of a ShipGroupCategory they are using for a given faction. This is where the theming comes in for these planets.
  • For the wormhole sentinels, it's actually only seeded at the start of the game, and each wormhole is unique rather than being homogeneous per planet. So those don't get remembered.

• The entire way that AIs choose their "draw bags" for how to populate a planet's guard posts, strikecraft, turrets, or whatever, has been redone; but also the same is redone for waves and CPAs and the like. It's all using the new AIShipGroups and AIShipGroupCategories.

• balance_planet_seconds_of_metal_to_claim has been removed, and is now just metal_to_claim.

• Intra-Squad Formations have been removed, as have the concept of squads, the counts of "visual things per subsquad," and so on.
  • The whole "squads" idea was mainly to have more ships without having more ships, and that just wasn't working out for a variety of reasons. Now it's just ships instead.

• The balance_base_hp_scale (value 500) is gone, and now things are more direct on their costs.
  • This may well have broken how much regenerators cost in order to regenerate the ships they were bringing back, but the old value was basically nonsensical, essentially being StrengthPerSquad * 500 on the ship that was dying. Now it's just HullPoints of the ship that is dying.

• balance_starting_metal_in_planet_seconds="540" is now just balance_starting_metal="540000"
  • Yes that is a huge amount, but that's what it's been for a while evidently. All this indirection makes things pretty confusing, eh? But so much less now.

• balance_base_aip_scale="20" has been removed, and now the values that would use that are just set directly.

• To sum up, all of these are gone and we are hopefully directly setting the values properly where they were previously used:
  • balance_base_aip_scale="20"
  • balance_base_energy_scale="1000"
  • balance_base_power_scale="1000"
  • balance_base_metal_scale="1000"
  • balance_base_hp_scale="500"

• large_ship_scale_multiplier has been removed, so that all marks of a starship or whatever are now the same size. This lets us define them in ways that are best for being able to see them without them getting too stupidly huge.

• A bunch of logic for how fleets are selected and moved around, which was previously related to control groups, is now in place.
  • The logic for how to assign fleets to keybind indices (fleet groups, essentially) for now is going to be clicking-the-interface-only, since that's really confusing in keybinds. We may wind up reintroducing keybinds for this at some point in the future, but more likely would be a better interface for organizing fleets into the keybinds directly, since this would avoid the confusion factor for players.
  • The big sticky spot for confusion is people thinking they're making a control group of ships, when really it is of fleets, in essence. Even this explanation is confusing. ;)

• You are no longer asked to pick a Chief Adviser at the start of the game for your profile. That was a lot of confusion an un-needed choice on something rather trivial, and got in the way of getting you to the actual game.
  • Now it just has a screen for profiles that asks for a name and your default colors and that's it.

• Rather than having an overall "Ark" voice group that plays whatever chief adviser you have chosen, each Ark is now able to have their own chief adviser.
  • In general, for the Golems that are also considered fleet leaders, we're just treating those like Arks now. They each now have voice groups set, kind of at random, matching chief advsiers voices to them.
  • As we add more Arks and other offensive mobile fleet leaders, we can apportion out the Ark voices as desired.

• A bunch of stuff relating to Golems the way they used to be, including the entire Broken Golems faction, has been removed.
  • Golems are now another form of Ark, basically, and are capturable in that fashion.

• Fixed a minor bug where the HRF Raiders were never spawning because of a typo in their tag.

• fleet_design_templates_i_grant_one_of is now fleet_design_logic_i_grant_one_from, and the valid values for that are MobileCombatFleet, MobileSupportFleet, and Planetary.

• In order to solve a whole heck of a lot of extra xml that was having to be put in, and in general make things clearer, the following xml tags are no longer inherited with copy_from, and thus no longer need to be set to some variant of Unused to avoid things like having a new AI variant suddenly showing up in player fleets by mistake:
  • fleet_design_templates_i_am_part_of
  • fleet_design_templates_i_always_grant
  • fleet_design_logic_i_grant_one_from
  • fleet_design_template_i_use_for_drones
  • ai_ship_groups_i_am_part_of
  • tags -- actually this was already the case for this one, but it's worth noting that this functions this way.
  • By the same token, it's worth noting that tech_upgrades_that_benefit_me and build_sidebar_categories_i_am_part_of DO both still propagate to children.
    • The tech upgrades we commonly want to upgrade variants just the same as the base, unless we explicitly overwrite them. And at any rate, this either has no effect on AI stuff, or it has an appropriate effect on AI/Merc stuff based on tags set up elsewhere. Anyway, it certainly won't cause any confusion to the player that a ship is mistakenly benefiting from a tech if no techs are assigned to it. That would usually be invisible to the players and quite possibly have no gameplay effect. But we do frequently rely on the cascading of tech upgrades for the variants to function at all, so hence this design.
    • Same with the build_sidebar_categories_i_am_part_of, since that's just organizational. Rarely would that be different for a child compared to the parent, and it has no effect unless they player is able to build the thing in the first place. This doesn't actually let the player build anything, it just says where it would show in the build menus if they could. So having this cascade definitely makes sense.
  • All of the other things don't cascade because they are some of the chief things we're typically changing in the copy_from children. They denote where and how a ship is used, and having that accidentally and invisibly copy over has been a source of bugs for the last year.

• There were a variety of ships/turrets/etc that had the name "EnemyWhatever" and were a copy_from variant of something that players or the AI normally used, but then these variants were used by the HRF, Marauders, Instigators, Astro Trains, or whatever.
  • These have all been changed to actually say "HRFWhatever" and similar instead, since that's way cleaner and clearer. In the few cases (like 3) where multiple factions used the same copy_from, two variants are now in place. That will let them safely diverge in the future, anyway.

• In the build sidebar, turrets and "other defenses" have now been properly split out. Before they were all kind of mixed together in "defenses," which got confusing.

• The various things that you can purchase from the Zenith Trader are all now planet-bound, even if they are normally mobile. They go into the fleet of that planet, and are on permanent station-keeping there.
  • In theory we could later have something that can let you purchase new ships for mobile fleets from the Zenith Trader or otherwise, but that would need a new UI and new general mechanics. That would be fun, but in terms of replicating the experience of the Zenith Trader thus far, here's how it needs to work for this part.

• For the build category sidebars, there is no longer a special section for the Zenith Trader. Instead it's already going to be categorized under the Zenith Trader as the constructor, so they are subcategorized by infrastructure, station-keepers, other defenses, turrets, etc.

• fleet_design_templates_i_am_part_of have been set up for pretty much most things, as well as the actual templates.
  • The format in these lists is: name, category, weight, min cap, max cap.
  • The category is always Strike, Frigate, Turret, or OtherDefense. These never show up visibly in the game, but are based around the min_strikecraft_types="2" max_strikecraft_types="3" and so forth for the fleets actually appearing.

• The various kinds of command stations now each come with their own hand-designed fleet styles, which are of the type that just use the max cap of each type they can have inside of their categories. That way they are always predictable per type, but you get more forcefields with a military command compared to economic, etc.
  • Things like minefields and the gravity generators don't go with any of these, but rather have to be gotten via battlestations.
  • When it comes to factories, some of the command station types grant more factories per planet than others.

• The battlestations in general are set up, although most of them just seed randomized template-based fleets. The Ensnarer one has an example instead of a specific type of fleet that it uses in place of a template.
  • Bear in mind that there are several different ways to set up how a fleet leader (battlestation or mobile) might have its fleet design created, and if none of them are set up then you'll have a lonely empty fleet. Right now the game doesn't warn the designers about that.
  • In general there is a looooot more that could be done here in terms of making new and unique things, but right now the procedural fleets themselves are enough that probably that's not a big priority.

• The general strikecraft and frigates are all now set up so that they'll populate some interesting different procedural fleet designs in (currently) 9 different overall flavors. But even within those 9 flavors, there's a huge amount of variety likely to be found.

• Added a new capturable_seed_weight (CapturableSeedWeight) that does NOT propagate via copy_from, since once again this is basically a "where things go" piece of logic, and those shouldn't go to children.
  • Same with a new capturable_max_per_galaxy (CapturableMaxPerGalaxy), which prevents you from ever having more than a single botnet golem ark in the galaxy, among other things.
    • This flag will also be useful for one-off backer-designed custom Arks with their own handcrafted fleets if that is something some people want to do. It lets us have unique and/or powerful things, without having them be too plentiful.

• The game now actually seeds the battlestations and fleet flagships, and makes sure that they have their fleet designs populated right from mapgen start.
  • First it tries to seed 1 item with tag "MobileCombatFleetArkOrGolem" on a planet directly adjacent to a player homeworld.
  • Then it tries to seed 1 more two hops out from a player homeworld.
  • Then it tries to seed at least eight more, but up to 1 per 25 planets, throughout the rest of the galaxy at least 3 hops from the player and 2 hops from the AI homeworlds.
  • It's possible that it won't have enough types or will run into blockages, and that's A-OK to happen.
  • Next it repeats the process by trying to put 1 battlestation (based on the SpecialEntityType directly) on a planet directly adjacent to a player homeworld.
  • Then it tries to seed at least five more, but up to 1 per 50 planets, throughout the rest of the galaxy at least 3 hops from the player and 2 hops from the AI homeworlds.
  • In both cases, if it couldn't seed a thing closer in, then it will retry with it further out. This is mostly only relevant for snake maps and other things with very few direct and secondary connections from planets.
  • Next it repeats the process by trying to put 1 item with tag "MobileSupportFleetFlagship" on a planet two hops out from a player homeworld.
  • Then it tries to seed at least two more, but up to 1 per 150 planets, throughout the rest of the galaxy at least 3 hops from the player and 2 hops from the AI homeworlds.
  • The reason it uses the SpecialEntityType directly for Battlestations is because that's the most direct thing. For the other two categories, those both have a MobileFleetFlagship type, and so those tags help specify a bit more if they are regular (and thus more common), or are "support" (and thus less common and further out).

• Okay, I started today (Apr 3) by making a trio of videos trying to explain things on how fleets and whatnot work from a modder/dev perspective, and realized that there are some bits that are just too complicated to be convenient to use. It is stuff that's going to lead to questions for a long time, and have a lot of typos.
  • So rather than having a bunch of stuff that needs direct parsing out of giant long xml attribute lists, I'm switching these over to have sub-nodes instead. Kind of like what we do with systems or metal flows.
  • This is a lot more verbose in the xml, but also way easier to read and also lets us make some of the options... well, optional. And allows for future expansion if need be. It also drastically reduces our chances of typos or of misreading one number's purpose versus another number.
  • So far this has been applied to just the fleet designs themselves, in the FleetDesignTemplate folder. This will be applied to other things coming up, too.
  • Going along with that, some comments have been left in the xml to explain what the heck each of these things are about, and thus reduce the need for videos explaining all of it. More will need to be done, but it's something that is a step in the right direction.
  • This was worth taking a step back and working on now, because trying to redo this after it goes live was going to be extra hard. Much as I'd like for people to have their hands on this sooner than later, Puffin had brought up some very good points about how hard this was to understand as a developer/modder, and these changes aim to make it easier to manage for all of us. Heck, in the process of doing just this first batch, I found some typos of my own that were completely invisible, so it's already paying dividends.

Prior Release Notes

AI War 2: Early Access Starts!