AI War 2:0.850 Raw Chris Changelog

In general, Chris wanted to be able to document the sequential progress of things since this release took an insanely huge amount of time. But at the same time, for the final release notes they needed to be cut down and edited. So here is the original, and the cut-down version is here:

AI_War_2:_The_Arrival_of_Fleets

March 5th Through April 17th

• 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.

• The main xml file for build sidebar categories now explains what the heck those are for -- and what they are NOT.

• The AI ship group categories now have an xml comment explaining themselves.

• The AI ship groups now have an xml comment explaining themselves, and also use the more verbose sub-node approach rather than the comma-delimited strings list.
  • Here again, clarity trumps brevity, and it should make things vastly easier to read and understand long-term.

• Put in a bit better error handling for when things are set up wrong in the UI XML data or their backend classes.
  • The actual errors that we have right now are because of certain work just not being finished, but it will help us and modders in the future to have the error handling better.

• The various MobileSupportFleet flagships now are able to get upgraded from Mark1 to higher marks based on their fleets being upgraded. They have no techs that benefit them directly.
  • This fixes an issue with them referencing an Engineer tech that was nonexistent.

• ai_ship_groups_i_am_part_of and fleet_design_templates_i_am_part_of have both been removed, as they were really very hard to read.
  • They have been replaced with child nodes of the entity, instead, named ai_ship_group_membership and fleet_membership, respectively.
  • The data is all the same, but labeled better, so the new changes should be self-explanatory if you've read the notes on the prior versions.
  • Just in the process of converting this data over, we found and fixed a ton of bugs.

• Discovered that attributes and nodes WERE being passed to children via copy_from even when we thought they were not. What we were actually messing up was is_partial_record entries, oops.
  • Added a new AddToChildXMLNodesNotToCopy() method that lets us prevent copying of child nodes, and for entities we're now preventing the copy of:
    • ai_ship_group_membership
    • fleet_membership
  • Added a new AddToChildXMLAttributesNotToCopy() method that lets us prevent copying of attributes from the parent to the child, and for entities we're now preventing the copy of:
    • tags (This may temporarily cause some bugs, or fix some bugs, we shall see; probably both)
    • fleet_design_templates_i_always_grant
    • fleet_design_logic_i_grant_one_from
    • fleet_design_template_i_use_for_drones (this may cause some bugs, temporarily)
    • Ones that we have NOT put in here, aka we are allowing them to propagate, as previously noted:
      • tech_upgrades_that_benefit_me
      • build_sidebar_categories_i_am_part_of

• There are now fleets associated with each faction as their "loose" fleet.
  • For AIs and NPCs, this is just used for all their ships, more or less, and doesn't really get used for much. Drones don't go in there, but that's it. Actual useful fleets can be created as-desired in the future, but for anything not using something specific, it uses this.
  • For the players, there is a PlayerLoose fleet, which is basically "remainder units" that are not in a fleet. Odds are that this won't be used, but it's an overflow valve in case we have a truly odd case or potentially even a bug that we want to fail more gracefully.
    • Oh! Actually, we are using this now for ships that are being captured via zombification. So there you go, a use for it already.

• There are now fleets associated with each PlanetFaction as their "fleet of that planet."
  • For AIs and NPCs, this is just a reference to their parent loose fleet from the faction itself.
  • For the players, these are unique fleets that are what the command stations go into and put their stuff into.
    • It's entirely possible for a command station of a player to die, but in those cases the fleet must live on.

• When the game creates a new ship/structure, it now REQUIRES that the appropriate Fleet.Membership be passed into it.
  • This solves all sorts of bugs where fleet membership was never being set previously.
  • In the case of fleet leaders or ships that create drones, it ignores this membership, however, and creates and populates its own fleet.

• Both on_death_revert_to_entity and on_claim_change_to_entity have been removed, since these were purely for derelict golems.
  • That was a wonky mechanic as it was, and heavy on the xml and on the potential code bugs, so getting rid of the mechanic will make certain things easier.
  • Nothing was using it anyhow now, recently.

• Whenever a PlayerMobile or PlayerPlanetaryDefense fleet leader is switched between factions, it now switches the faction of the parent fleet as well, and also the faction of any members of the fleet.

• Observation: the fleets that the resource nodes belong to are those of the planet of the original owner of the planet. This may be problematic.
  • Actually the claim logic may already handle them properly.

• In general if a ship is in the loose or planet fleet for a faction, and it gets claimed, it will now switch to the loose or planet faction (as appropriate) for the new faction it's at.
  • Hopefully that works out well. And this is only speaking about non-fleet-centerpieces.

• The marauder outposts, when spawned, now get their own fleet (of type NPC) created for them.
  • Any turrets or raiders spawned for them then get put in that fleet. It's then possible to query for a list of things created by that outpost (that are still alive) with ease.
  • However, there is one place where some marauders are spawned that don't seem related to outposts at all, so those just go in the "loose" fleet of the marauder faction. There's nothing wrong with this.
  • Right now nothing is ever checking on the number of raiders that were created by a given outpost, though, so that part is kind of pointless at the moment. Badger, this may require further discussion as to what you were wanting to do here.

• Metal harvesters are now markless, rather than being upgradeable. This solves an issue with them being funky upgrade levels on enemy planets, and in general the ability to upgrade them is something that I was iffy about in the current system anyway. It was likely to be too powerful.

• Rather than having one AIKingUnit special type, that has been split into AIKingCommandStation -- which takes planet ownerships, and is the phase 1 -- and AIKingMobile, which is not allowed to take planet ownership and is phase 2.
  • There was a legitimate paradox before in that these two phases work differently and the special type rules could not work for one without breaking the other. Now we have two different types to handle the cases.
  • Thanks to Puffin for finding this.

• Normally it's nice to only have... one way to do things when setting up the XML, right? I mean, that's the most clear thing, eh?
  • However, in a few cases it is sometimes nice to be able to have parents talk about their children, rather than children always being the ones talking about their parents.
  • This is most notable for hand-designed fleet templates, where we don't want auto-modded stuff to be added in a bunch.
  • Thankfully, we can do both things, with both coexisting and neither acting in exclusion of the other.
    • Basically, NORMALLY, you should definitely still use the fleet_membership nodes on ships in order to get them into fleets. This is more modder friendly and more flexible in general.
    • THAT said, now you can also define ship_membership nodes in the fleets themselves, which basically are just the inverse of a fleet_membership node. They say all the same things, but say "a specific ship is being added to my fleet," versus the other way around with a ship adding itself to a specific fleet.
    • This is now in use in a new CMP_StartingFleetDesigns.xml file, which uses a new design_logic of InitialPlayerFleet.
      • Basically: we want to have 5-7 starting player fleets that are hand-designed including what their centerpiece is as well as what their ship compositions are. This lets players start off the game with something they are excited about, and move forward with whatever they find procedurally generated after that.

• There's a new append_each_ship_description_to_main_description bool flag which we can use on these new InitialPlayerFleet fleet designs so that their descriptions are fully fleshed out and clear for the lobby.
  • Thanks to this, we can just show the player the DisplayName and the Description of the FleetDesignTemplateTable.InitialPlayerFleets list, and we then know enough to say what to choose.

• Added a new Cloaked Ark One variant, and this one is ONLY available via a new "Cloaked Fleet" (CloakedStartingFleet) that players can get in the lobby at the start of the game.
  • This offensive fleet is one of the first that players can choose from, and it's powerful and invisible and likely to make them feel quite powerful.
  • Led by the Cloaked Ark One, this has Raptors, Agravic Pods, Gunbots, and then Warbird Frigates.

• Added a new Mugger variant of the Assault Frigate that gets parasitism (this needs to be tested).
  • This is ONLY available via the new "Parasitic Fleet" that players can choose at the start of the game.
  • The parasitic fleet in general is weak and small by comparison to others when it comes to direct firepower... but of course they create a bunch of zombies to work for them. Uh, and yeah there's a Botnet Golem at the center. So weaker might not be accurate after all.
  • Led by the Botnet Golem, these have 60 Parasites and 2 Muggers. This is by far the smallest ship cap fleet you can start with... until you start creating zombies.

• Added a new Classic Fleet that players can start with.
  • This classic mix isn't good at any one particular thing, but is well-rounded against any foe. The forcefields just make things even better.
  • It's V-Wings, Fusion Bombers, Concussion Corvettes, and then a Forcefield Frigate, with the centerpiece being an Armored Golem.
  • This is a nod both to the first game as well as the classic starting loadout of ships in this game itself, which is now absent.

• Added a new Raid Fleet for the starting player options, which also has a new "Agile Cursed Golem Ark" that is the Cursed Golem but with way faster engines.
  • The whole purpose of this fleet is being able to rapidly move around faster than any other purely offensive fleet in the game.
  • It also includes a new "Turbo Stingray" ship that is a faster version of regular Stringrays, and then Velociraptors and Daggers, which are normally already super fast.
  • All of these things share the same base (very high) speed except for the last and obligatory part of the fleet, Raid Frigates. These are able to move EVEN FASTER, and so can go off on their own away from the main body if you so desire.

• Added a new "Doorkicker Fleet" as another starting fleet option.
  • Mostly focused on crowd control, but with siege frigates along to punch giant holes in large targets when required.
  • Basically this is the taking the idea of the Attritioner archetype, but giving one bit of counterbalance to it. Led by a black widow golem, this has MLRS Corvettes, Grenade Launcher Corvettes, Inhibiting Tesla Corvettes, and then Siege Frigates.

• The game now makes use of its special starting fleets, of which at the moment there are 5 handcrafted ones. The player can choose which one they want in the game lobby, just like they could with Arks.

• Working on making the tooltips for ships substantially more brief while still conveying the important information. Some of them are getting ridiculous for sure.

• Got rid of the (very elegant, sadly) "tech view" version of tooltips that showed all the ways a ship would be upgraded by gaining a mark level.
  • That was overwhelming as an amount of information, but also there's just no place where we'd actually be asking you to see that anymore. Now you upgrade techs that hit a bunch of ships at once, and so this per-ship-type comparison stuff just has no place in there anymore.

• You can now see what fleet ships are in, and what the fleet contents are of fleet holders. A lot of this is temp-y at the moment, but we'll get the tooltips nicer in the future. For now we can see why there are no actual ships being put in the starting fleets for the player, for instance (null ForMarks and empty effective ship caps).

• In cases where the game has a null fleetmembership for a ship -- which is a bug -- it now tells you that in the tooltips versus having a bunch of errors.

• Fixed a bug with fleets not being centrally registered, and thus a whole bunch of things not working properly with them.
  • Now the factories are correctly churning out ships for fleets on their planet and ajacent planets, the ships are rallying to their fleet centerpieces, and so on.
  • At this point it's worth noting just how insanely much more powerful the human players are (which was needed!).
    • The starting fleet, which is only one of... I dunno, 5-10ish that the player will capture over the course of a game... basically has the entire firepower and ship cap of what the players were able to muster in prior versions of this game.
    • This feels waaay more like AIWC in terms of the number of ships running around even in the early game, and capturing a new fleet is going to have a really visceral and obvious effect in terms of how many ships are suddenly running aroun, and what kind they are.
    • The only downside, if that really is one, is that this means that now the AI is going to need to get some beefing up in response to the player actually being properly capable.

• The game now does a much better job of noticing when there is a problem with fleet memberships during setup of a new ship or structure, and lets you know right away.

• The GeneralCommandStation special type has been removed, and replaced by NormalAICommandStation and NormalHumanCommandStation.
  • The former is not a fleet leader, while the latter is, among other differences.

• Human command stations now properly take ownership of the planet fleet of the planet that they belong to. AI command stations just get added to the main fleet of the AI.

• There is a new CalculateEffectiveFullFleetStrength() method on fleets, which really only makes sense for the various non-loose player fleets, and not any of the AI or NPC fleets. But in general this lets us do comparisons of how strong fleets are AT FULL CAPACITY, not how strong they are at their current actual filled capacity.
  • We can use this sort of thing for having the AI have a negative reaction to too many too-powerful fleets at a planet, potentially. There are a variety of things we can do based on this, although the nature of the fleet is probably something we need to take into consideration.
    • Basically if there's a fleet of type PlayerPlanetaryCommand (aka command station) on a planet, then probably the AI should not consider it or care how powerful it is, because the player can't really control that in the way they can their other types.
    • And by the same token, if there's a single super strong fleet of type PlayerMobile on a planet... well, frankly the AI Eyes already react to an abundance of strength, but what we're now trying to work on is the player having multiple super strong fleets of either PlayerMobile or PlayerPlanetaryDefense (aka Battlestations) all stacked up in one location, THEN the AI should care. But if the player has several weak PlayerPlanetaryDefense Battlestation fleets at one planet, then that shouldn't be bothering the AI, either.
    • The amount of complexity we could find ourselves in is kinda crazy with this, so we should probably start simple and build from there.
  • Fun fact: the Classic Fleet that the humans can start with has a strength of freaking TWENTY FIVE even at mark 1, so that's a great sign right there of how much more the player is able to bring in terms of power. AI planets may need some immediate beefing-up to deal with that, we shall see.

• All of the non-drone ship caps for strikecraft have now been pretty much been reduced to 1/3 of their prior values across the board (for player fleets, both starting and otherwise).
  • This makes it so that there is more room for players to notice the growth of their forces as they gain more ship cap via increasing the mark of their ships, for one thing.
  • It also makes it so that the player fleets are not so immediately ridiculously overpowering, and so that refleeting doesn't take so dang long.
  • It's entirely possible that the centerpieces are still too strong on their own, because things like the Armored Golem still make the Classic player starting fleet have a strength of 26. That's... ouch.
  • Puffin, this may be something you could look at, potentially? This way the centerpieces (Golems and Arks) are somethng that are strong and interesting, but not something that solo dominate their entire fleet. I presume that that's already the case for Arks, though I've not tested it since the rework here. But for the non-AI variants of golems, I suspect they are hilariously overpowered even still.
  • And as for the ship caps, please nobody worry -- these fleets will still grow substantially as they rank up in mark levels, as well as in general you getting more fleets. The individual baseline ship caps for fleets are no longer "astronomically devastating," though. ;)

• Fixed a variety of bugs with ships rallying to their fleet centerpiece (which is the only type of rally that now exists).
  • They should rally to where the centerpiece either is or is heading, and they'll stop rallying once they get very close to where the centerpiece is.
  • They stay in rally mode, continually updating their destination, until they reach the target. Initially the target can only be on the planet they are on or an adjacent planet, but it's possible that the target will move even further away while they are chasing it, and they should adjust to follow. That has been tested except when moving more than one planet away while they chase.
  • Note that you can't set the rallying directly at all, unlike prior versions of the games. Factories just make whatever is needed in order to bring a local fleet up to full fighting force, and those things automatically rally to their respective fleets. "Local" means on this or an adjacent planet.
  • On arrival, the rallying ships should take up the disposition of the ships that are at the other end, but that remains to be seen if that works as the interface for that bit isn't there yet. If you see problems with us, please do let us know.

• As part of this release, we had switched to writing our savegames in a binary format. However, this wasn't really working fully properly because it was trying to transcode that into unicode, which in turn would sometimes complain with the "Unable to translate Unicode character XXX at index YYY" error.
  • This was also notably less efficient in terms of GC usage. Now we're just directly writing the binary file.
  • In fact, now we're writing a BuzzsawBinaryByteArray, which is 449kb where even the binary array was 3.2mb, and the char buffer was even larger.

• Added a new "Write Savegame Serialization Logs" setting into the debug section of the game settings.
  • When saving a game, write WorldSerialization.txt, and when loading it write WorldDeserialization.txt -- both in the PlayerData folder. The only real reason to turn this on is if a savegame won't load for some reason; this lets us do a diff of the two files and figure out where they are diverging.
  • Note that this won't help with an existing broken savegame. This will only help if you have it turned on prior to creating a savegame you expect to be broken. This is basically a way for us to test the savegame creation and load process, which otherwise can be incredibly opaque and take a lot of time to hunt down.
  • It's hard to understate just how big a deal this tool is. This is an area that could have us searching for hours or days for a problem, and now we can find it in minutes, potentially.
    • The specific genesis of the feature was in fact Chris spending hours searching for something and not finding a solution, and finally thinking there had to be a better way. We should have thought of this 10 years ago, honestly.

• Savegames now work again! It turns out that this was a bug in our deserialization code for binary and buzzsaw binary formats.
  • Basically the very last character or number or whatever can't be read back properly due to some sort of error. We are able to verify that the rest of the file is read in absolutely impeccably thanks to the new ArcenSerializationTester class work, so as a workaround we are just writing "EOF" at the end of the file and then not actually bothering to read that back in. Boom, problem solved. It's slightly tacky, but it gets the job done and lets us focus on more important things.
  • Keith had previously observed that the binary arrays were causing some issues in savegames being sent across the network, and this is probably the same issue. We can solve the problem there the same way that we solve this one, most likely, but we'll see what happens.
  • In some ways this whole saga was a bit of a waste of time since we hadn't made any true errors in serialization. However, this actually will let us make the initial multiplayer syncs VASTLY faster for people, which is welcome, and it also inspired us to create a tool that lets us verify correctness of savegames and solve potential future problems far simpler than we have in the past. So it's a big win for our tooling and the engine in general.

• Fixed a funny bug where the AIs were using guardians at all times instead of strikecraft. This should prove much more correct in new savegames.

• Thanks to a boolean inversion typo, all ships would get crippled if they were not allowed to be crippled, while those that are allowed to be crippled would not.
  • Although that was only halfway true. The crippled status was showing on anything non-crippleable whenever they had less than 10% health, and cripple-able units were never being crippled. However, cripple-able units were properly unable to die, while non-crippleable units died properly. So it was half right, half wrong, fully confusing.

• The variable MarkLevel on planets is now named MarkLevelForAIOnly internally, which makes it a lot more clear.
  • With this change in place and a few related code changes to actually make it work as expected, now the other factions (dyson, nanocaust, etc) no longer start out buffed up to a higher mark just because they are on a planet that is a higher mark level for the AI.

• The fleets for Battlestations now have default names that are "[NameOfTheirPlanet]'s Champions"
  • These can be renamed later by players.

• The fleets for mobile fleets now have default names that are pulled from folders [FleetNames_Mobile_P1]+[FleetNames_Mobile_P2]. If anyone reading wants to add to these after this build is out, that's certainly welcome.
  • This wasn't a high priority item, but Chris needed a small mental break when starting the morning. ;)
  • These can be renamed later by players.

• The tooltip for science has been improved to be more accurate and also more descriptive:
  • Spend Science to unlock higher-level units and structures. It is gained primarily by claiming new planets and holding them for a while.
  • There is a limited amount that scientists can learn from what they find in each system, so you'll need to keep finding new research targets for them.
  • A single ship type can be upgraded by multiple tech upgrades as well as from its parent fleet gaining experience, so be sure to consider your options carefully.
  • More techs will appear in the tech sidebar as you capture fleets with ships that can benefit from them.

• The tech sidebar is once again functional, and allows for you to unlock techs that benefits various ships that you have.
  • It looks and works a lot more like the hacking sidebar instead of the build sidebar, now, since the type of data it needs to show is very different. This makes it a lot more text-heavy and showing related costs and the mark levels of ships in a really clear and concise fashion. Yay! It does mean no real icons on here, though.
  • The tooltips for techs that you can upgrade are also now completely redone, and it shows you which ships will benefit as well as how many of them you have. It doesn't show you the mark level of the ships, because you might have several different mark levels of each ship type since they may be upgraded by fleet upgrades.
  • This was certainly needed in order to make the game all that playable in 0.850, but in terms of why we did it right now versus after the build menu, it's mainly because this was simpler and was therefore a nice dry run for the more complicated menus.

• PlanetTypeData now loads faster, and uses less memory, as it doesn't load from the PlanetNames folder repeatedly.
  • This is a minor addition, but we saw it and it took all of 2 minutes to implement.

• Ok! So we've already learned quite a bit about techs and how people will wind up using them. Clearly the new system works well, but is going to need refinement; chief among that is just how many upgrades a given line can grant.
  • One of the other things that was immediately most clear was that "Ark" as a technology was really not cutting it. This was way too broadly useful, and "Battlestation" was almost as bad.
  • First of all, these need to be more pricey, but some Arks should cost more than others, and some Arks should share techs, but not ALL Arks.
  • With that in mind, there's a new schema in place for various Arks and Battlestations broken out as follows:
    • Ark Spirit (most basic stuff), Ark Heart (happy helpful stuff, less dangerous), Ark Armor (beefcakes you need to really pay for), Ark Fist (holy smokes these things are powerful, and thus expensive, and only have 3 marks rather than 4).
    • Battlestation Shelter (protection-oriented), Battlestation Hand (grabbing or slowing enemies), Battlestation Architect (engineering or construction).
  • And it's worth noting that Battlestations are really oriented into those as well as the previously-were-fortresses Citadels that are way more combat-oriented, so splitting those also matters:
    • Citadel Executioner (kill a lot of things), Citadel Protector (yeah, hurt them, but protect other stuff as the primary), Citadel Consumer (eat or steal the enemies).
  • And then there's the Spire Frigates, which really don't need to be lumped in with Arks or Battlestations or Citadels. I'm sure these will expand in the future, but for now we just have the new "Spire Core" (for all three types of Spire Frigate), and they're super expensive but can be upgraded 4 times.
  • The overall lesson here is that we CAN have more techs than we maybe were once thinking, particularly since they only show up conditionally. This also makes the Arks and Golems and so on a lot more unique in terms of how well they are upgraded (or not).
    • This will get more crowded in the tech tab with time, unfortunately, as you unlock a lot of ships. For that reason they are now down at the end of the list below all the actual main ship lines.
    • This may also hint that we want more tech lines in general for the other ships, and/or that they need some changes to their science costs, but we'll cross those bridges when we come to them.

• Something I talked about on the podcast is an new form of objectives, which is an idea that I've been refining since then (and had already been prior to then).
  • However, the "objectives" on the sidebar as they stand right now are not something I want to get rid of at all (most of them), given that they are kind of a "todo list of things you might want to do," and that's a pretty important tool to have.
  • With that in mind, the Objectives sidebar has instead been renamed to Intel, and over time we'll probably take out some things like the beginner tips and the primary objectives and so on. For the primary objectives we'll likely just recontextualize the same thing, but the beginner tips we'll probably fold into the new objectives (actual objectives system, separate from this intel system).
  • All of the really time-consuming-to-add and detailed "objectives" stuff about where we found things to capture and hack and kill, and where we should be scouting, etc, is all going to stay. It's just under the name "intel" instead, now. Really, that's what it is: information that lets you make decisions yourself, be that diverging from your main objectives or defying them or whatever else.

• constructor_name and constructor_description have both been removed, as they are no longer relevant to the game design given that there is no longer going to be a docks sidebar.

• display_name_for_sidebar has been added for entities, as it lets us give a more brief name to appear on the sidebar while still having a fuller name in tooltips.
  • This is optional and will just use the full name if it needs to. But if the sidebar is having bad wrapping of some text, then this should be filled with something shorter. Case in point is the home forcefield generator.

• The "Direct Build" sidebar has been completely reworked from scratch.
  • It's no longer based on icons and tiny buttons, but instead has much larger buttons in categories. This may lead to more scrolling in some cases, but it also should be way more legible AND in general the player should have fewer things that they can build at any given planet unless they've stacked a lot of battlestations and citadels there.
  • Each line item not only shows what type it is, but also has to include what fleet it goes with -- so if that's the planet fleet, or one of the battlestations or citadels, that is relevant.
    • Why is this relevant? Well, those things can be upgraded independently, for one. And for another note, it's possible that you might choose to move a battlestation or citadel to a new planet, thus making all of their units on this planet stop functioning. So it does play into the strategy if you plan on moving around your battlestations and/or citadels (as you likely will).
  • These also now show the cap directly in a 0/3 fashion or similar, with it showing how many have been built out of how many are possible. It's possible that you might have more built than are possible to build, which it will show properly, but with a red warning.
  • It also more directly shows the cost for construction -- super useful -- and grays out the text of any entities that you have already built to the full cap so that they are not so noticeable.
  • This whole setup is really geared around having many fewer TYPES of things that you can directly build at a given planet, and that's the intention for the long term. We don't really want dozens of options here, but rather a smaller and more interesting selection that you can build from contextually depending on the planet.
  • At this point you can actually construct new direct-placement units!

• A whole bunch of changes have been made to the way the tooltips look in build mode for entities, and also to how things are hovered-over in the build menu and galaxy in terms of what highlights, when.
  • It's stuff we'll refine further with time, but if something seems off, please let us know.

• The home forcefield generator, which has existed since the first game as a last-ditch tool that you have until you lose it, is now something that you can rebuild.
  • It's also now markless and has its stats more directly set, so that you definitely never get more than one. It was kinda funky having it be mark 2 in this game from the start, and it also led you to having a cap of 2 instead of 1.
  • The whole purpose of this is so that you can rebuild it if it dies, since you don't otherwise inherently have access to any forcefield generators on your home planet at all, now. You have to put a battlestation or a citadel there in order to get a forcefield beyond the first, and depending on your playstyle you might choose not to do that.

• Fleets of type drone, or planetary command, are intentionally not saving their designs into savegames -- they are not procedural fleets, after all.
  • Now it properly recreates their designs from the latest and greatest data the xml has to offer when the savegames are loaded.

• Fixed an interesting... bug? Kind of a bug. Where basically we were treating and non-claimed entities as un-readable from squad wrappers. This was definitely an intentional decision on Chris's part at some point, but he wonders why. ;)

• Fleets now do a lot more self-analysis for correctness both when they are created and when they are loaded. We were having some odd cases of heavily duplicated fleets, etc, and no idea why yet. But at least it will correct itself now.

• There are a variety of cases where bad data is either identified, prevented, auto-fixed, or simply scrubbed now. In some cases these will be valid things, like a drone fleet that had its centerpiece die, and it for now will log this but doesn't complain visibly.

• Fixed a number of bugs with way too many drones (effectively infinite) being spawned inside drone fleets.
  • This also goes in and fixes any excesses retroactively if the excess is in non-deployed-but-paid-for items.

• The tooltips for fleet centerpieces now show how many items they actually have out of their individual item caps, rather than just showing the item caps. If there's a discrepancy, that's now something you can see,

• It was possible to have nanocaust intensities of 0 sometimes show up, which then would throw endless errors. Now it throws an error once and then fixes itself to 5. That lets you keep playing without completely sweeping it under the rug.
  • Similarly, if the allegiance is missing, they hate everyone now.

• The way that the "external data" (aka modder-type data or data that was being saved into the external projects) is saved used to be based on using a sub-serializer that then itself got written as a string back into the main serialization stream.
  • This was probably done as a way to isolate freaky bugs introduced into savegames by modders, but with our new serialization logging that's really no longer a worry. As it stands, the sub-serialization may have instead been preventing us from properly saving sub-data and getting it back reliably. Also it was vastly less efficient in the new context.
  • Anyway, given that the new context is such that doing the data saving of external data just fully inline without any wrappering is more efficient, that's now what we're doing. Based on the serialization logs, this seems to work great.

• Added a new "Write Mapgen Log" field in the debug part of the settings.
  • When generating a new map in the lobby, write MapGen.txt in the PlayerData folder. The only real reason to turn this on is if mapgen isn't really doing what you expect for some reason, or you just want some detailed insight into what is happening and in what order.
  • To hook into this as a modder for your own purposes, you simply write to MapgenLogger.Log(). If you're doing anything CPU-expensive or that involves string concatenation or similar, then you can wrap that inside an "if ( MapgenLogger.IsActive )" statement. This simply avoids slowing down mapgen at all when logging is not active.
  • There is some serious funkiness going on with some data being null when it should not be, and this is how we're going about figuring out when and why that is happening. But this also lets us see the results of maps that are generated without having to scan with our eyeballs all over a big map so much. Given how much has just changed in mapgen and elsewhere, this is handy, even if we didn't have an immediate bug issue.

• Fixed a "hilarious" bug that we thought was some sort of major serialization or other data problem, but was just an outdated xml entry. The mapgen logging code helped us figure this out, and will help us find similar things in the future.
  • The entire problem with the AI type being null at an unexpected time was because we renamed Vanilla to be FullEnsemble. That sort of lack of clarity in xml-based errors is hopefully something that we're getting fewer and fewer of, now.

• Fixed up some issues with SetupOnly_ResetForNewMapGeneration where it was not properly clearing fleets specifically, and then more generally was also not resetting the primary key generators. This was leading to primary keys that were stupidly high numbers if you were regenerating your maps a lot (this was not new), and it was also leading to fleet decommission messages that were harmless but slowed down the process (this was new).
  • We'll have to keep an eye on this, there are other things that may also be impacted by this, but for now it's good enough.

• Fixed a bug in the dyson sphere deserialization that was probably new in the internal versions, but was causing any game with a dyson sphere to not be able to deserialize because we were failing to serialize one particular integer.
  • This took about 4 minutes to find thanks to the new serialization testing code. Yay!

• Fixed a MAJOR oversight in the save/load system where we were not serializing a ton of stuff for minor factions. This was a CHRIS_TODO testing thing that he left in and had not gotten around to going back and taking out... and, well, it was what was breaking all the stuff with minor factions losing their minds after a reload. That should all work now.

• Fixed a number of bugs that could lead to flickering of tooltips and things like that, with enemy units on planets that we have intel for but it was checking specifically to see if GameSecondLastHadVision on that enemy's planet was the current second. There's always a few hundred ms out of every second where that is false, so the correct way to check that anyway would be to make sure that it isn't more than 1-2 seconds in the past.
  • That said, there are some other ways that vision can be granted to a planet (hacking, etc) that might not result in that being accurate (but probably will), so the safer method that is now globally used is GetDoHumansHaveVision(), which avoids any question of a subsecond flicker. It also now has a 2s cooldown before you lose vision on a planet where all your ships die, as a side note.

• Crippled constructors no longer contribute to the build sidebar tab. This would mostly apply to mobile fleets allowing construction of command stations, and prevents some cheese.

• Added a new ThirdPartySellerToPlayers special type, which is assigned to the Zenith Trader. This overall mechanic will allow for other merchants in the future if we ever so desire to have them.

• The conduct for "start with planets explored" has been removed, as that's really cutting out a core part of the game now.
  • The scouting being so much more automated now kind of makes it a bit different from other games where you can turn off fog of war. Despite the first game having the option to turn off fog of war, that really takes out the entire flow of the game when it comes to this game.
  • Scouting isn't some hassle thing "that you have to do but might want to skip" anymore, but now is part of the reward structure for capturing planets, and so turning that off just would have... a lot of balance issues, among other things.

• "Conducts" are now able to, and in fact required to have, a description.
  • They also now have tooltips in the lobby, which show these descriptions, thus explaining what the heck they do.

• Added the following description to the Experimental: AI Civil War conduct, which is the only pre-existing conduct currently remaining. This may or may not be fully accurate:
  • If there are multiple AI factions, they all hate each other and will fight each other. They still hate YOU, too, but all this chaos and infighting is assumedly to your beneit. Then again, you might just find yourself in the crossfire of AIs who are getting more powerful more rapidly due to aggroing each other... so it's anyones's guess as to how long you'll last.

• Added a new "Scout Adjacent Only" conduct, with the following description:
  • TLDR: This is harder and will make you take a lot of planets. For advanced players only.
  • Details: Normally when you capture a planet, all planets adjacent to ANY explored planets become explored. Unless the map is very narrow, this causes you to get exponentially more planets you can see as the game goes on. Even further than that, there is a minimum number of planets it will explore for you when you take a planet, depending on the number of planets in your galaxy, so that snake maps and other really narrow maps aren't unplayably hard.
  • With 'Scout Adjacent Only' enabled, it tosses all that out the window. Instead it just explores any planets adjacent to the planet you just captured. This will make snake maps almost impossible to play (so that's a bad combo), but on maps with more cross-connections it can lead to... a certain added strategic challenge. This still seems masochistic even in the best case, but have fun with that if you want.

• There is now a much easier way for checking if conducts are enabled based simply on their name. It is used like this: ConductTypeTable.GetIsConductEnabledByName( "ScoutAdjacentOnly" )

• The "explored" status for planets has been split into "explored by natural means" and "explored by distant hacking."
  • This mostly doesn't matter and isn't something we're making a big deal about in most places. But using spy nanites basically is no longer a way you can expand how much your empire gains in vision every time you capture a planet.
  • The "explore next to explored" logic basically ignores stuff that was spy nanites. Maybe there should be a conduct later that makes it not ignore that, since that ALSO would provide some interesting strategic options, but frankly for now that seems like overkill. We shall see.

• So long as you have a mobile fleet leader on a planet with no command station (enemy or otherwise), you can now capture it like you would have previously done with a colony ship.
  • Aka, just take any of your golems or Arks over to the enemy planet and destroy their command station and you're immediately ready to set up your own. Boom, simpler.

• Added a new type of control for our settings menu, which is an integer slider. This is preferable to the textbox or dropdown for some cases.
  • We're now using that for the auto-build engineers, which also defaults to 2 now instead of 0.
  • We're also now using that for the various volume controls, which were inexplicably textboxes before.
  • We're also now using this for the minimum autosaves to keep, and the autosaves interval.

• When planets are explored via you having just capturing a planet or whatever, it now shows a message log entry saying what planets were discovered and how many of them there were. This way it's clear that scouting is even happening!

• Fixed a bug where self-building units could go over their stated caps, or otherwise bypass restrictions placed on them, after telling you about the failure but then just keeping on trucking under the hood. Oops! Not sure if this was new or not.

• Fixed a few issues in the latest builds of the game with engineers auto-building and similar things to that.

• The game now properly unpauses itself after you close the escape menu, if it paused itself going into there.

• The science intel message is now more brief in the sidebar, and more informative in the tooltip. Now everything fits.

• Command Stations should now never leave remains. This was funky. Have not tested to make sure it works.

• The fleet concentration AIP penalties will now only kick in at 3 fleets on an AI planet, and 5 on a player planet, rather than 2 and 4 respectively.

• The game now properly checks for ships that are not in a fleet, and moves them to the LooseFleet of their faction while also throwing up an error message to the player. This should never happen, and doesn't seem to be happening anymore at the moment, but for a while it was happening and causing all sorts of downstream issues. Now if it ever happens again, we'll know the root cause (well, closer to the root cause) and be able to fix that.

• Drone production was disabled in recent internal builds because it was causing exceptions to be thrown related to fleets incorrectly being null. Now that the other bugs are fixed, drone production is back on. So hive golems and so on should presumably work again, but that hasn't been tested yet.

• The old quickstarts have all been moved to QuickStartsOld, since they no longer function with the new system in general.
  • Because of the way Steam updates work, the QuickStarts from now on will be loaded from QuickStarts2 instead, which is presently empty and needs to be for the next little while. But at least it won't be throwing errors when players try to start quickstarts in the new build.

• Previously if there were multiple Zenith Traders in one galaxy, then they would get very confused about what their previous paths had been, and would give lots of spammy sidebar messages about being ready to trade on specific planets if they are on your planets.
  • They just were not originally designed to have more than one per galaxy, but now they are.

• The fleet centerpiece "repairs" no longer get dumped to the log unless a new debug setting is enabled. This was essentially just spamming the log for no good reason at the moment, but it's useful to be able to see it in some limited cases, hence the new option.

• The Zenith Traders now properly set their actual entity to be the centerpiece for their NPC fleet, thus allowing them to populate their fleet membership and offer wares for sale as expected.

• There is a new NPCFactionCenterpiece special entity type that should go onto things like marauder outposts so that their centerpiece status gets automatically correctly reset.

• A bunch of logic has been put in place that lets Zenith Traders use ship counts from the local player planet.

• Even after all the prep work, the Zenith Traders were a nightmare to get functioning for players to be able to purchase from, but oh well -- it all works now!
  • When a Zenith Trader is visiting, you'll see a bunch of stuff on the sidebar under various categories, noted in pink as being from the Zenith Trader.
  • This is different from past versions of the game where there was a specific category for all the Zenith Trader stuff regardless of what its function was. This actually makes it a lot easier to find things by function, particularly if the amount of wares on offer goes up a lot in the future.
  • For things like the Station-Keepers (Chained Dark Spire Eidolon), there is now a per-planet cap higher than 1 for these. That's pretty nifty, and it works!
  • Note that even if you don't have the metal for these projects NOW, while the trader is visiting, you can start the projects and pay for them over time. This is as before and is by design. The UI might be a bit confusing on this, not sure.
  • Currently we have no idea if the Zenith Trader will sell to the AIs or not. Chris hasn't looked into that code at all, and doesn't plan to anytime soon, since it's a very secondary function and there's a lot more pressing stuff to look into.
    • Badger ed: The "AI purchases from zenith trader" code basically just gets the AI periodic NormalPlanetNastyPick's on planets. It should be unaffected by what you are doing.

• Sentry Frigates are now part of the Station Keepers sidebar instead of Other Defenses.
  • This is meant to be the case for anything that is mobile, essentially.

• A new Station-Keeping Assault Frigate has been added to the loadout of military and home command stations (2x each), and logistical command stations (1x each).
  • As with the pike turrets that all the command stations now have, this gives you some more defensive options without having a fleet or a battlestation around.
  • Unlike the turrets, these don't require any placement planning, since they are mobile and able to roam around and hit enemies. Seemed like this would get around a variety of frustrating situations that even having turrets would not solve.

• The mapgen log-writing code is now way more in depth, and gives much more info on where special things are being seeded.

• The warden special forces hideouts were previously always seeding 4, but now it's sometimes more based on the size of the galaxy being larger.

• The game is now able to seed multiple entities on certain planets if we so desire, during mapgen.
  • As the sole use of this so far, we're now seeding two battlestations/citadels on any planets that have those, to make those a lot more attractive as targets and also thus provide more firepower for defensive purposes for players without them having to capture QUITE so many planets for each of these that they get.

• Did a fair bit of rework on some of the mapgen logic where it is trying to seed things close to the player homeworlds.
  • A while back we had some problems where things were frequently seeding too close, so we put in code to counter that. That was in turn preventing us from intentionally putting stuff there more recently.
  • Now there's a healthy balance between us being able to do that while still avoiding the old bug, and in general things seem to be working well.

• There was some other funkiness with it being really unlikely to seed certain things very near to you.
  • That has been fixed, to start with, but then beyond that it also now tries to seed half the flagships and battlestations kind of in the middle-distance for you on the map.
  • In general this now gives you way more options for middle-game goals for making yourself stronger.

• The way that the "too many fleets on a planet" code works has been reworked a fair bit, but not tested:
  • It now looks at all the human ships that are part of a mobile (flagship) fleet or a battlestation/citadel fleet. Before it was just looking at the fleet centerpieces, meaning you could have your centerpiece hide on an adjacent planet and send its ships in and the AI wouldn't notice.
  • It also now only looks at the ships that are actually on the planet, and not the total strength of the fleet. The strength must be at least 2 in order for it to care at all about it for these purposes. If you send in 10 fleets of strength 1 -- or a slice of them that is strength 1 -- then it won't care.
    • This latter thing will probably encourage all sorts of bad behavior, but we'll figure that out in the future. For now it should feel more natural in general, but it will likely need further iterating.

• In the tooltips, you can now see how many ships and what strength is contained inside a guard post, as you used to be pre-fleets. HOWEVER, you can also now see exactly how many of each type of ship is inside there, to see what mix the AI is using at that planet without having to go aggro a guard post.

• Fixed that issue with the fullscreen resolution not being settable in recent internal builds.
  • Note that there is still some issue that may make you need to alt-f4 the program after changing between fullscreen resolutions or fullscreen to not-fullscreen, but it then shows up properly after that. I expect an upgrade to the unity engine, due in the next month or so, will probably fix that one part. And that one part probably isn't new. But the new part that was broken is now fixed.

• Put in a buuuunch of debugging code for figuring out where excess notifications that hang out at the top of your screen are coming from.
  • The tooltips for the excess notifications should now explain what the problem is.

• Added back a new Hackers EntityRollupType that just gives command stations and mobile fleet flagships, since those do the hacking. It's a more efficient way to loop over potential hackers.

• Fixed a bug that was causing blank-ish notifications to appear at the top of the screen in internal builds for every mobile fleet flagship and command station you control, because they might be working on a hack but likely were not.

• The Battlestation special entity type has been split into two: BattlestationBasic and BattlestationCitadel.

• The MobileFleetFlagships special entity type has been split into three: MobileCombatFleetFlagship, MobileSupportFleetFlagship, and MobileLoneWolfFleetFlagship.
  • The third in this category is for the things that don't have a fleet with them, namely right now the spire frigates.

• The seeding for battlestations and mobile fleet flagships has been updated, as you might guess.
  • The existing logic for mobile fleet flagships now applies to MobileCombatFleetFlagships, and MobileSupportFleetFlagships still also work the same.
  • The existing logic for battlestations now applies to BattlestationBasic.
  • MobileLoneWolfFleetFlagship is now seeded "kinda wherever" and is both rarer but also no longer counts against the normal combat fleet flagships.
  • BattlestationCitadel is following the general pattern of the basic battlestations, but with the following differences:
    • It only ever seeds one on a planet, not two at a time.
    • It seeds one within 2 hops of a player starting planet if possible.
    • It then seeds a smaller number of citadels out in the galaxy, mixed between the middle-distance and far out. These are in addition to the basic battlestations, not in place of them.
  • With all this, there's a better sense of control of what exactly the player can look forward to out there, but also in general there are yet more capturables out there, and they can continue to be balanced in their niches: we can add more lone wolf stuff without swamping the main mobile flagships, and we can add more citadels or regular battlestations without affecting their relative mixes.

• The way that fleets are named has been improved a bit, so that they are more consistent and interesting and descriptive now.
  • This only affects new savegames.

• Added a whole bunch of ways to calculate the strength and health percentages of fleets based on their type, which is more complicated than you might think.
  • For command station fleets, or the battlestation ones, it's based around the total power out of what you've DECIDED to build (and what has died to remains or is hurt or whatever).
  • For drones and mobile fleets, it's out of the total things that would be auto-built, since you get no decision-making in whether to fully stock those fleets or not (aside from keeping them away from docks).
  • This is surprisingly complex when it comes to things like the ships being transported in fleets, or undeployed drones, etc, etc.

• The docks tab is gone, and a new fleets tab has taken its place.
  • The fleets tab has a bunch of sections which show first your fleets at the current planet, and then all of your fleets in the entire galaxy, by category, after that.
  • The categories, in order, are:
    • Current Planet
      • A quick view of all your fleets at the current planet.
    • Mobile Combat
      • The most versatile of your fighting forces: generally intended for offense, but quite able to come and defend your own planets as need be.
    • Mobile Support
      • Unusual supporting fleets that are able to either act as a force multiplier for your offensive or defensive fleets, provide remote supply on deep strikes, or perform surprising other secondary duties.
    • Lone
      • Unusual single 'lone wolf' massive ships that forego having attending ships in exchange for a simply awe-inspiring amount of direct power. Use them offensively or defensively, as you see fit.
    • Battlestations
      • General battlestations that are useful for either defending your planets or for setting up offensive beachheads on enemy planets.
    • Citadels
      • Citadels that are much stronger versions of your general battlestations, packing a huge punch in their own right as well as providing access to defenses for your planets or for offensive beachheads on enemy planets.
    • Planet Cmd Stations
      • Each command station you have on a planet has a small force of mostly basic, utility, or economic nature. However, if you've made purchases from the Zenith Trader or found other unique capturables throughout the galaxy, you might have some fixed-position weapons of surprising power here, too.
  • For the time being, the tooltips over the actual fleets just shows the tooltip for their centerpiece. This won't always be the case; they'll later have their own unique tooltips that are more informative.
  • For the time being as well, clicking these does nothing but show you a message saying that the fleet management interface is coming soon.
  • The individual fleet entries show the name of the fleets, their health percentage, their total ships out of their EFFECTIVE ship cap (for the stationary things, that's out of what you've deployed), their planet name, and their total effective strength if they were fully powered at the level that is chosen for them.

• A new destroys_self_until_not_over_ship_cap_if_planetary_command xml tag has been added.
  • This is used only in a really narrow set of circumstances: it was a planet that a human player controlled with one kind of command station, and they now have a different kind of command station there.
  • Basically, different types of command stations give you different numbers of engineers, basic turrets, energy collectors, etc. This prevents you from having too many left over after you switch from a military to an economic command station, for instance; there were all sorts of games you could play with that to exploit things.
  • What this does NOT do is destroy units after your command station has died on a planet; in those circumstances, whatever is there continues to live on until you build a new command station. Presuming you rebuild as the same type, nothing gets destroyed.
  • This flag is also explicitly NOT on certain units like the human home forcefields and the various things you get from the Zenith Trader. They will frequently be over-cap (since their command station type doesn't always include it but you might have bought it separately), and so these are always assumed to be valid.
  • Confusing? Basically this just shuts down an exploit and doesn't affect much else.

• We recently (in this giant build group) redid how the repair costs were working for ships, and it's unclear how that changed things cost-wise compared to what the costs used to be (the costs as they used to be were super unclear).
  • What IS clear is that we changed it to just be the equivalent to rebuilding the unit, aka repairing it 50% is the same as building half a new unit. This was by design and we didn't think much about it, but it is definitely something that was eating through metal prodigiously.
  • What's also clear is that we were charging this FULL amount for repairing shields, health, and engine health -- ouch. So really if you were at half engine health, half shield health, and half hull health, you'd spend 150% of what it would cost to just build a new unit. Not good! We'd much rather encourage repair in general.
  • We now have a variety of dials in the xml external constants to affect the percentage of the full metal cost that it will cost for various repair types:
    • balance_repair_cost_multiplier_for_hull_points: 50% cost for repairing hulls.
    • balance_repair_cost_multiplier_for_personal_shields: 20% cost for repairing personal shields.
    • balance_repair_cost_multiplier_for_bubble_forcefields: 75% cost for repairing bubble forcefields.
    • balance_repair_cost_multiplier_for_engines: 10% cost for repairing engine damage.
  • This should make things quite a bit less constrained on the player income-wise (it was feeling pretty tight at certain points in the early game because of your much larger forces), and also encourages reuse rather than just refleeting.

• The galaxy map now has more of a "military screen" style look to it again, although this doesn't yet apply to the actual icons and lines and so on. But it has that same sort of scanline effect and whatnot as in the first game, though more involved now and fancier with some hexagons, etc.

• When you don't have vision of a planet, there is now a fancy distortion effect that is part grainy-tv and part slow-matrixy-refraction.
  • There's not a way to disable this effect, because it shouldn't be fast enough to make anyone nauseous, and there's no real point in looking at planets that you can't see anything at, anyway. This just makes it clear why you can't see those planets (the sidebar says no vision, but why did all the ships just disappear?)

• The hotkey for opening the tech tab now only opens that, versus opening that or the hacking tab contextually.
  • Given that the docks tab is gone, the build hotkey now only opens the build sidebar directly as well, kind of implicitly.

• There are now separate hotkeys for opening the hacking (H) and fleet (R) tabs.

• The "split selection" keybind that was previously L in this game and the original is now semicolon.

• The "Unload Transports" (U) hotkey has had its description reworked as follows:
  • Any mobile fleet flagships that you have selected will immediately unload any ships they are presently transporting.

• Added a new hotkey (L): Load Transports
  • Any ships that you have selected which are part of a mobile fleet will immediately get inside their flagship for transport if their flagship is on the same planet.
  • Note that the need for this to be separate for unload is that it will be common to have partially-loaded transports and you don't want to get into funky toggle situations with ships getting in and out when you really meant "keep getting in" or "keep getting out."

• The tooltips for fleet centerpieces and what they have in them as far as ships go is now cleaner and also larger, and doesn't bother listing the centerpiece. It also now notes very nicely if any units are being transported inside the fleet centerpiece, since that's the way transports work now.