Difference between revisions of "AI War 2:Multiplayer Alpha And Beta"

From Arcen Wiki
Jump to navigation Jump to search
 
(587 intermediate revisions by 9 users not shown)
Line 18: Line 18:
 
== What's this phase all about? ==
 
== What's this phase all about? ==
  
We've been preparing for this for months, tightening up the codebase and getting everything ready as much as possibleNow it's time to start having machines actually talk to one another, and then refine from thereAt this point, LiteNetLib, Steam, and GOG Galaxy are all fully working as communication frameworks, and the game is in an alpha state (as of September 9th) where not all of the functionality is there, but the game can be played together.
+
Multiplayer is fully playable at this point, but still has a variety of glitches and doesn't have all of the features that we intend to have in the long termSo hence it still being in alpha statusBut we greatly welcome folks to play, and hopefully give us reports on what is going wrong if something does go wrong.
  
It's important to remember what an alpha is!  There are glitches and inefficiencies, and we'd like to know more about those.  There are also glaringly missing features.  Beta means feature-complete but not bug-free, and we're not there yet.  Please don't assume that we will implement some feature you want, like the ability to share X between players.  If you're testing the alpha and want something, please do drop us a message and ask for it, just in case.
+
We expect to be to a fully-polished non-beta status for multiplayer in November or December, if things continue as they have.
  
We expect to be into beta of multiplayer in late SeptemberHopefully the alpha and beta periods are both short due to all the work of the last phase, but we shall see how it shakes out.
+
Our second expansion for the game, Zenith Onslaught, has a whole heck of a lot of it completed, but still needs more doingBadger has done all of his parts for it, and has [[AI_War_2:Sunset_of_The_Badger_Era#The_Badger_And_Puffin_Legacy|retired like Puffin before him]], so at this point we are down to basically a one-person show again (me, Chris) on bugfixing, finishing multiplayer, finishing my parts of DLC2, and finishing the last of the kickstarter obligations.  So if the schedule slips some, it's likely because I had trouble juggling that, or wanted extra time to make things truly shine, whichever.  But at the start of this phase, things are feeling very positive.
  
Once we get into a stable beta period for multiplayer, then we'll let the clock run a bit and Chris will work on adding interplanetary weapons to the base game as a free update (that's the last of the kickstarter stretch goals).  This phase should wrap up all our kickstarter promises (including a laundry list of other smaller items).
+
== Version 2.639 ==
 
 
Badger has already done the bulk of his work for the second expansion, Zenith Onslaught.  Chris has done none of his work for that, as yet.  Once multiplayer is in the "let it exist in beta and have people bang on it" phase, then Chris can circle in and get his work done for DLC2 along with those base game bits for interplanetary weapons, etc.  The full version of multiplayer should launch alongside of DLC2, but we're not sure exactly when.  October?
 
 
 
Either way, multiplayer will be in a solid state that is "beta but just because we want more time with more people testing it" for a month or so while the DLC2 work from Chris's end happens.  None of the actual multiplayer stuff is delayed in any fashion for DLC2, it's been the other way around.
 
 
 
== Version 2.509 ==
 
 
(Not yet released -- we're still working on it!)
 
(Not yet released -- we're still working on it!)
  
== Version 2.508 Waverider ==
+
* Fix a bug where the Incoming Exo Notifier would show the wrong % when it was sync'd with something
(Released September 19th, 2020)
+
** Thanks to afterthought for reporting
  
* Fixed a couple of places in the metal flows tooltip where it was stating the left and right mouse buttons backwards.  (There were three places in all, and we had only changed one of them).
+
=== New PKIDs Approach For Multiplayer ===
** Thanks to Daniexpert for reporting.
 
  
* Fixed a rare exception that could happen inside GetControllingOrInfluencingFaction() when exiting the game either to the OS or to the main menu.
+
* '''WARNING TO MODDERS!'''  We don't suggest you just do a global search and replace for your various places in the code that are now calling methods marked as obsolete.
 +
** As tedious as it is, you should go through those line-by-line and swap them over to the new non-obsolete variant, which will note that it returns null in MP.
 +
** With all of these calls, it's up to you to check to make sure that if the method you just called returns null, you ignore whatever happens next.
 +
** In general, if there's anything that is changing more data about the entity that was just created only-on-the-server-but-null-on-the-client, then have it skip that logic, but do all the rest of the logic.  A general return out of the method you are in is not usually the desired approach (but it does vary by situation).
 +
** The faction data will catch up on the client either way, and all of those changes you make to the entity after the null-return-point will be passed over to the client as well.  However, if you don't handle the null-return-point, then players will get nullref exceptions in your mod only in multiplayer, which will be frustrating for everybody.
 +
** The one exception is CreateNew_DuringMapgen.  You can just search and replace for that with CreateNew_ReturnNullIfMPClient unless you were using it wrong to begin with.
 +
** There may be entire methods now where you want to check if ArcenNetworkAuthority.DesiredStatus == DesiredMultiplayerStatus.Client and just return before it even thinks about making any entities.  See things like ReactToPowerLevel() on the AI for examples.
 +
** TLDR: This is a minor pain in the rear right now, and looks a bit tedious to do.  But this is far simpler and far less tedious than getting bug reports from MP players that you have to chase down for your mod in the future.
 +
*** If you wind up with questions, then @ chris on the Arcen discord channel.
  
* Fix a bug where waves were not spawning any units. This affected regular waves and hacking responses.
+
* Added a rather complex new ArcenDelayedDeserializationBurst class, which uses a really efficient way to store network message for future deserialization.
** Thanks to weapon master, CRCGamer, DaniExpert, ArnaudB, Gott365 and probably others for reporting
+
** We normally reuse our deserialization buffers, so it's an extra delicate class.  As long as nobody ever tries to use this in some new way beyond the way it is currently used, all will be well. The code is filled with dire warnings in the comments.
 +
** The capability that this adds is essentially for us to have slightly time-delayed execution of network data unpacking from the host to clients, if the host is a bit more than 1 sim frame ahead of the client.
  
* The Zenith Trader no longer sells AIP-increasing black hole machines to the player
+
* The MayCreateEntities bool has been marked as obsolete, and is never set now, as all threads (even long-range planning ones) are now considered A-OK for immedidately creating entities as much as players want to.
** Thanks to TechSY730 for reporting
 
  
* The Zenith Trader will no longer sell things to dead AI factions
+
* SpawnEntity and SpawnEntityOrReturnNull have both been marked as obsolete (and will block modders from compiling against them), but will still for the moment keep working with existing compiled mods.
** Thanks to GreatYng for reporting
+
** This is how we're going to try from now on to handle when we change the specifications of things that would break mods, where we can.  It gives modders a chance to catch up.
 +
** In this case, it now wants you to use the new SpawnEntity_ReturnNullIfMPClient() method.
 +
** The same is true for the various CreateSquad methods, all of which now want you to use CreateNew_ReturnNullIfMPClient.
  
* Really fix that Macrophage null reference in LRP bug that's been annoying badger
+
* GlobalLastSquadIDSourcePrimaryKeyID no longer exists in savegames.
  
* Some performance improvements for fireteams in general (and some extra improvements for hunters) in late  game scenarios
+
* The ability to generate PKIDs for speed groups, fleets, squads, shots, and otherIDs are all now exclusively host abilities.
** Thanks to a giant save from crawlers for letting me see what was going on
+
** If a client tries to call these, it now returns -1 for the client and throws a visible error message on the client.
 +
** A bunch of cases where we were syncing these over to the clients are removed.  We no longer care, for the most part.
  
* When you see the name of a song in the Escape Menu, it should now be formatted in a more readable way. For example, it now shows "Waking To Darkness" instead of "WakingToDarkness"
+
* The game now has a new "Fast Blast of Created Objects" that the host sends to clients.
 +
** In these cases, essentially when you go and try to create something that requires a PKID that would be consistent on the clients and the host, the clients just skip doing it, but the host does it and then sends it to the clients asap.
 +
** The host is usually a few hundred ms ahead of the client at minimum, and so if it's on a future frame number from them, then it tells them at which frame to unpack its new data.
 +
*** If the client is closer to the host in time, and the frame gets there late, it still just unpacks it and can sort out minor discrepancies later.
 +
** The idea here is that a LOT more things are just being done on the host, and skipped on the client, and the client is getting the information in small download packages that it inserts into its own sim at the appropriate time.
 +
*** There is some very slight divergence in sync caused by this, but it's pretty darn slight in most cases.
 +
*** The great news is that this uses less network data, and substantially less CPU power, on clients than having wrong IDs assigned does. This lets us just send the correct object once, rather than creating the wrong object, discovering it, requesting a fix, getting the correct object, and deleting the wrong object.
 +
** This is a fundamentally different approach to object creation, and in some ways this has a bit more in common with an MMO architecture, except things are faster and more responsive than your average MMO.  But this is now blending a third general model of network code into our existing interesting stew of models.  It pairs really well with the other bits.
  
* Improve the text of several "You can't hack this because of...." messages
+
* On GameCommands, we now have the ability to specify how many entities of various sorts we plan on creating (or potentially creating), and then the host provides available IDs that will be consistent on the client and the host before the execution happens.
** Thanks to GreatYng for reporting
+
** This is yet ANOTHER approach, but is one of those cases where we take the most efficient networking approach for any given type of data event. That is surprisingly optimal, it turns out.
 +
** The idea is that which networking model is superior is really contextual, so we look at the context and use the best one in any given circumstance.  Any errors we make are already handled by the sync code (that's not new), but this cuts down on the number of errors.
  
* The experimental "Astro trains get stronger after you kill some of them" code is now enabled for everyone, and the setting is removed
+
* Added a new "Log Decoded Network 'Fast Blast' Sync Data To Disk" setting to the network section, which does what it says on the tin.
** I've heard reports that it works okay
 
  
* Allow the HRF to flush enemies from command stations and guard posts
+
=== Other Multiplayer Miscellany ===
** Thanks to GreatYng for requesting
 
  
* The "This faction has no allies, not even itself" message is cleared up; this was being triggered by dead AIs, usually after the civil war started
+
* Unrelated to the rest of this, the clients now send their GameCommands completely separately from their "finished a sim frame" messages.
** Thanks to a number of people for reporting
+
** This lets the client send the GameCommands in a more timely fashion, thus reducing command lag on the clients.
  
=== Dark Spire Tweaks ===
+
* Fixed an issue that we don't think anyone hit, but where if you were playing one multiplayer game and moved to another one it could execute some commands from the prior game on a delay.
  
* Fix a bug that was preventing the Dark Spire from being suitably aggressive in late game situations
+
* Fixed a wide array of minor glitches and annoyances that would give clients warnings or errors (visible or otherwise) in multiplayer.
** Thanks to crawlers and Gott365 for the bug reports
 
  
* Other factions will now actively go after Dark Spire Conquest mode VGs
+
* A lot of classes serialize themselves more clearly, ranging from shots to wormholes to gamecommands and beyond.
** This should give some counterplay against the Dark Spire
 
  
* To compensate for the fact that Conquest Mode VGs will be targeted more, they are also tankier
+
* In the event that the host sends over world data that errors, the client should now wind up back on the main menu.
  
* In conquest mode, the Dark Spire will get a bit more energy
+
== Version 2.638 Why Do We Fall, Master Wayne? ==
 +
(Released November 25th, 2020)
  
== Version 2.507 Bugfixes ==
+
* strength_multiplier_for_turrets has been 2 since we added this, but that seems to overestimate their power a bit.
(Released September 16th, 2020)
+
** We've adjusted this value to 1.55, per discussion on discord and a suggestion by TechSY730.
  
* Fix a bug where player-allied nanocausts that aren't allowed to kill command stations weren't properly expanding. Add a journal entry to point out to the player that this leaves their allied nanocaust vulnerable
+
* Added a new strength_multiplier_for_armed_guard_posts, which lets us adjust up the strength of guard posts to be more accurate if it seems to be undervalued.
** Pointed out to me on discord
+
** We're starting this off at 1.25.
 
+
** Thanks to TechSY730 for suggesting.
* Fix a bug where the render vengeance generator hack wasn't completing
 
** Thanks to a number of people for reporting, including jradishurr, Magiik and Gott365
 
 
 
* Fixed several cases where cross-threading issues could lead to some issues in the selected-ships counter.
 
** Thanks to MasterGeese and GreatYng for reporting.
 
 
 
* Fixed several cross-threading bugs that could happen in GetIsWithinRangeOf() or GetIsWithinRangeOf_VeryBasicCheckOnly().
 
** Thanks to GreatYng for reporting.
 
 
 
* Fixed a bug introduced in the prior build that made it impossible to save most games that had outguard in them (all of them...?), and probably was messing with initial multiplayer sync, too.  This was not seeming to affect every last save, but nonetheless was not good.
 
** Thanks to Badger for reporting.
 
 
 
* The "long range planning" code for the Macrophage now includes a lot more instrumentation for more detailed error messages.  We started having some sort of error in at least some games starting the last release.
 
** But after putting in the instrumentation (and having fixed the outguard serialization bug that also manifested in the same savegame), we no longer can duplicate the problem.  So for now there's nothing more to do, but if it comes up again we'll at least know where it is.
 
** Thanks to Badger for reporting.
 
 
 
== Beta 2.506 ExternalData Overhaul Two ==
 
(Released September 15th, 2020)
 
 
 
'''This is kind of a nasty one, in that we're fixing a ton of things but potentially also breaking more things.  External code-based mods are definitely broken again (sigh).  But a bunch of things that were question marks for multiplayer are either now working properly for the first time (a few dozens of things), or are now verified-correct (even more dozens of things).  So we're dropping back to beta briefly, to let people test things and let us know if there are any bugs that make this unplayable for some reason.  Once folks have been through it sufficiently, we'll move back to the non-beta branch.'''
 
 
 
* Previously, the dark spire ships that you could hack for had a starting mark level of X, and a max mark level of 4.  Now they all start at mark 1 and level up like normal, but have a max mark level of 7 (because why not).
 
** Essentially, tech unlocks for players probably did not work terribly well when the starting mark level of a player unit is greater than 1.  And having a low mark cap on top of that can be frustrating for folks.
 
** Specter used to start at mark3, now is 1.
 
** Phantom was already mark1 at the start, but still is.
 
** Okay, wraith was already mark1 at the start, and still is.
 
** Anyhow, the level caps were a big part of what was messing with people, probably.
 
** Thanks to crawlers and CRCGamer for reporting.
 
 
 
* Fixed a potential nullref that could happen in CheckForInternalShipDeployment_DroneProducers_FromSimBGThread(), probably more likely on multiplayer clients than elsewhere, but definitely possible anywhere.
 
** Thanks to Puffin for reporting.
 
 
 
* Fixed a strange capitalization issue in the logging for faction deserialization where MinFIreteam and MaxFIreteam would thus show up as diffs.
 
** Thanks to Puffin for the report.
 
 
 
* New debugging command added: <code>dump data tables</code>
 
** This causes all computers involved in the current game (so not just the local machine in multiplayer) to immediately dump all their data in the same way that happens from "Dump All Data Tables After Load" from the debug section of the settings menu. 
 
** ''Please be advised that this will cause all of the computers involved in this game to freeze for something like 20-60 seconds, depending on their relative speeds, how many expansions and mods are installed, and so on.  It's a good idea to warn people before you run this comment.'''
 
** Aka, this writes a text file for each in-memory data table into a DataTableExports subfolder in the PlayerData folder. 
 
*** The purpose of this is mainly to use with diffing tools between one run of the game and another, to see what sort of data changes happened.  If you are modding and made changes to some ships and want to see how those changes cascaded, this would be one way to do that.  This is also a way for us to verify correctness when we make structural changes internally.
 
*** In multiplayer, this can also be used to compare the contents of these folders between the host and various clients, to check for things that might be amiss thanks to mods or other local changes.
 
*** To compare folders at a time, you'd need to share the contents of these folders between machines (zip and email, etc), and then run a folder-wide diffing tool like WinMerge to find any discrepancies.
 
*** Lastly, if you're a mod author and concerned that your mod is adding to the data tables incorrectly over time, then you can use this to get snapshots of what those look like as you are playing.  Normally this data should not be changing after the initial load of the application.
 
** Never considered a cheat.
 
 
 
=== Multiplayer And ExternalData Continued Improvements (Breaks Code-Style Mods Temporarily) ===
 
 
 
* There are some issues with the data table dumps now actually dumping some game data.
 
** To combat this, the ArcenOverLinkedList and ArcenLessLinkedList both no longer dump their firstItem and lastItem fields.
 
** Hopefully we will still see the count of items in these, but that's really all we can do right now without getting into circular references by the very nature of these linked lists.
 
 
 
* This also finally pushed us over the edge when it came to IArcenExternalDataPatternImplementation, and this is now becoming an ArcenExternalDataPatternImplementationBase abstract class that we can control a bit better in several different ways.
 
** In general this will be a help for us with multiplayer sync, among other issues.
 
** This class should never be directly inherited-from by things in External or mods, however.
 
** Added a new ArcenExternalDataPatternImplementationBase_World, which is for use with things being attached to worlds.
 
** And also a new ArcenExternalDataPatternImplementationBase_Faction, for things being attached to factions.
 
** And a new ArcenExternalDataPatternImplementationBase_Squad for things being attached to ships.
 
 
 
* Took this chance to fix a number of data structures that might not be multiplayer client-sync safe based on the fact that MP sync data might be missing and might need a catch-up:
 
** AIReservesData (constructor updates, DeserializeExternalData updates).
 
** Okay, 33 other classes needed the same update pattern, so we'll save you the list of going through all of those again.
 
** Added a new ArcenExternalSubManagedData class, which all 34 of those classes now inherit from.
 
*** This lets the increasingly-complex central logic from DeserializeExternalData be written only once, not 34 times.
 
**** This is all handled, for the default case, via the new generic method DeserializeExternalDataAsArcenExternalSubManagedData().
 
*** Also worth noting, we can no longer use constructors with arguments on this, because of how the logic is centralized.  The default constructor is always called now, and then DeseerializeIntoSelf() is called after that if needed.
 
**** This is doubly worth noting, since it makes sure that there are no cases where object initializations from the default constructor are not called.
 
 
 
* While we are at it, we're marking the various lists and other collections as readonly in ArcenExternalSubManagedData-inheriting classes.
 
** This helps us avoid ambiguity and extra code, and is a double reminder for us to review places where we could get into infinitely-expanding lists on multiplayer clients.
 
*** Fixed the following infinite-expanding collections for multiplayer clients:
 
**** The FinalComposition dictionary on PlannedWaves was going to infinitely expand while waves were incoming.
 
*** Fixed the following "accidental data churn from throwing away collections on multiplayer clients":
 
**** The DZPerUnitData ConversionList and ConversionBag.
 
**** The metalByTier on DysonData.
 
 
 
* Added a new ArcenExternalSubSubUnmanagedData abstract class for classes that is for the sub-data types that a few things use, like DarkSpirePerPlanet.
 
** This adds some structure, but is not as fully managed as the main classes above it.  These again help us to avoid some bad habits that can lead to memory leaks on clients.
 
 
 
* Fixed a general cross-threading issue that could happen with Loci_ForUI in the dark spire.  This could happen in single player or multiplayer, and we found it because of the new code rigor enforced by these new abstract classes.
 
 
 
* The DeserializeDictionary utility method, and a few similar ones, no longer take their dictionaries as a ref parameter.  That's now allowed syntactically for readonly dictionary fields, and it's not needed logically at all for dictionaries as a whole, which are reference objects and thus always passed by reference no matter what.
 
** Same deal with ArcenRandomDrawBags, for the same reasons.
 
** And same for some various working methods that were passing generic List<>s with ref explicit.  It doesn't matter if the contents of the list are a value type, the list itself is still a reference type.
 
 
 
* Fixed a client-only bug where certain things were being cleared incorrectly on the DLC2 "ZM" faction data object during faction sync, but now are not.
 
** In that same faction, fixed another of the "ForUI" list cross-threading issues.
 
 
 
* Added a ClearAndCopyFrom() method onto ArcenSparseLookup, which does what it says on the tin.
 
** This is useful in places where we are no longer shuffling around sparse lookups by reference (think pointer), but instead are now keeping the lookups but needing to copy from one to another.
 
** The need for this is pretty rare, but it's used in wave planning.
 
 
 
* Discovered a rather dire issue from the last week or so, and have fixed it.
 
** Essentially, the objects that previously inherited from IArcenExternalDataPatternImplementation (and now from a descendant of ArcenExternalDataPatternImplementationBase) are NOT UNIQUE per object.
 
** So the fact that we were starting to store the ParentWorld and ParentSquad and so on on those was actually a major problem, and probably a source of some sort of random bugs in single player and multiplayer.
 
** We were mostly saved by the fact that we ignored those properties and were using the Source object cast properly, which is what was supposed to happen.
 
** But upon refactoring things, we ran into increasing problems with this.  It has now been corrected, and this should hopefully also prevent us (or a modder) from making the same error in the future.
 
 
 
* With the new way that we are using readonly for collections on the ArcenExternalSubManagedData and ArcenExternalSubSubUnmanagedData, we have to initialize all those collections properly in the constructor, which was not always happening before.
 
** We now are just initializing them as part of their definition itself, which is easier to check for correctness and has the same end result and performance.
 
** If we missed any of these, or heck if we made any typos in the many many other changes list above, then there will be errors when loading certain savegames or when during certain parts of gameplay.
 
** We should be able to fix such issues very quickly, and for now we're not seeing any issues, but we'd definitely appreciate testers in both singleplayer and multiplayer.
 
 
 
* It goes without saying, perhaps, that this breaks all of the code-style external mods again.  We will probably break those a few more times in the coming weeks as we get things multiplayer-safe, and then will stop that.
 
 
 
== Version 2.505 Multiplayer Alpha Starts, Take Two ==
 
(Released September 14th, 2020)
 
 
 
'''Let's try this again!  This is one big reason we did a "soft launch" into MP alpha.  If anyone is able to test tonight and let us know how it goes for you, then we will probably make the official "hey there's multiplayer alpha now!" posts tomorrow, unless new showstoppers are found.  At this point there's the periodic minor "waiting for players" micro-hitching annoyance, but beyond that being a small thing, Chris was able to play for 18 minutes between two computers across Valve's network tonight.  No permanent sync issues, no degradation in performance, nothing that seemed glaringly off. There will be more bugs, but the core stuff -- knock on wood -- seems to be working.  [[:Category:AI_War_2:_All_About_Multiplayer#Selected_Short_Term_Todo_List|There's a good list of things that need to be done in the near term here]], and that's just in terms of general functionality, not MP-specific features.'''
 
 
 
* Fixed a bug where "??? Name" was showing up incorrectly in the factions list in the prior build.
 
** Thanks to Badger for finding the typo.
 
 
 
=== Multiplayer Sync Initial Implementation Now Tests Out Initially Working ===
 
 
 
* Followed several paths of code trying to fix the ship sync, but ultimately wound up reverting a lot of that code after we found the actual cause.
 
  
* Found a one-line typo that was leading to infinite duplication of every fleet on the client every few seconds.
+
* We also added a new strength_multiplier_for_non_combatants, which lets us adjust down the strength of anything that doesn't have any guns.
** Essentially every fleet was trying to match to fleet 0, and never finding it, and then creating a new one.
+
** Sometimes things without guns still have a lot of health and shields, and that's really not something we want to consider as strongly since it can't hurt you directly.
** This was leading to a really devastating amount of duplicate data, and confusing everything on the client.
+
** This would affect forcefields, any sort of captured buildings, and things like unarmed transports.
 +
** We're starting this at 0.4.
  
* Manually reviewed the code for all similar things, including factions and planets, and all of those seem good for now.
+
* A new balance_seconds_after_transport_change_before_can_switch_back has been added, with default value of 3, that prevents players from putting ships into and out of the same transport more frequently than within 3 seconds.
 +
** In multiplayer, we need a small bit of time to refill the list of pooled IDs for upcoming player transports.  In reality that only takes a second or two to refill, but potentially less than a quarter second.
 +
** Originally we had thought to have this be an even larger window, like 30 seconds to prevent players from messing with the AI by popping in and out of transports, but there's already a 5 second no-firing time limit that covers that.  And folks on discord made their feelings about that change pretty clear (it was not welcome).
  
* Discovered that it was possible for extra fleets to wind up on the client just hanging around after a full fleet syncThose extras (usually were only one or two) now delete themselves.
+
* Home forcefield generators can now be scrapped just like all other FF generators.  From back in the pre-fleet days they were not scrappable because at the time you could never then rebuild themNow you should be able to rebuild them, so you can also scrap them.
 +
** Thanks to Democracy for reporting.
  
* The clients no longer automatically add 1000 to all of the PKIDs that they are syncing from the host.  We welcome the extra conflicts at this point... maybe... as it will also lead to some sometimes-correct things that don't need to sync.
+
* Updated AMU
** This was something we were doing as of a couple of versions ago in order to try to prevent things from fighting over the same dictionary spot.
+
** Now uses all the new Icons for Metal, Energy, Hacking, Science and Strength
 +
** Removed the SimpleStringBuffer as it is now less efficient compared to the ArcenCharacterBuffer and ArcenDoubleCharacterBuffer
 +
** Gave the latter two 35 new functions, most of them adaptions from the SSB or shortcuts from formating inside the AMU Core
 +
** Thanks to NR SirLimbo for adding.
  
* At this point we have far fewer syncs needing to happen between the host and client, which is awesome.
+
* Updated Kaizers Marauders
** The number of ships and fleets is consistent between the client and host, and the energy usage is also consistent, and so on (though energy usage may be misleading since that gets synced from the host as part of the ultra-frequent processing).
+
** Tooltips, based on the above logic, are now faster and produce less GC Churn
** A bunch of ships are showing up as invisible on the client for whatever reason, we know for certain, but those ships that are showing up maintain sync properly.
+
** Also dynamically rounded the percentages in the outpost description to show up to, but not always 3 decimals
** There are still some extra ships in ship fleet lines on the client that should not be there, and may just be duplicate references to existing ships.
+
** Removed an extra line inside the Player-Owned Kaizer full descriptions.
** Overall the total stats on the number and size of messages sent and received on the clients and the server seem to be incorrect, although sub-parts are often correct.
+
** Thanks to NR SirLimbo for adding.
  
* The "Deletion Time!" header in the ship sync details log now only appears when there is actually something to delete, which is not all that frequently anymore.
+
* When a stack dies and is going to spawn something on death (such as hydra heads as one example), then the new things that are created come out pre-stacked in the same ratios as the original.
 +
** So for instance, if a stack of 3 is vaporized, then a stack of 3 heads is created.  If each should create 2 heads on death, then 2 stacks of 3 heads are created.
 +
** This is a lot kinder to the CPU and performance in general during heavy death situations with hydras aand similar.
  
* Fixed a bug on the client and host in multiplayer where the total messages received, and the total bytes of them that were received, were far too low. A filter based on message type was incorrectly being applied to these overall counts, where no filter should have been applied.
+
* Before you can start hack, the game checks that you have enough hacking points. This check now also counts active hacks.
 +
** The goal is to make it harder for players to wind up with negative hacking points.
 +
*** Thanks to ultamashot and NRSirLimbo for reporting
  
* Fixed the remainder of the network messages still not being properly logged, in size or number.  There are two places where filters applied, and we missed the second one at first.
+
* A ship in an exogalactic strikeforce now shows "Exogalactic Strikeforce" instead of its faction name when hovered over
 +
** Previously it was really hard to tell if a unit was in an Exo or not.
  
* Fixed an issue where ships that were network-synced were properly added to fleets and the global registry, but NOT to the planet faction (and thus faction) registries.  So they were showing up as invisible, despite syncing properly as of today.
+
* Rework the way Exogalactic War Unit spawn locations are chosen to prevent the case where the AI was accumulating large numbers of Exogalactic War Units on its homeworld, if they were required to go after factions with other things in the way.
** Now the ships show up just fine!
+
** If the War Unit is against the player, the war unit spawns at the AI homeworld.
 +
** If it is against a non-player faction then if there's a safe path for the war unit to get to the target faction from the AI homeworld, it will spawn at the homeworld.  
 +
** If not it tries to find any warp gate with a safe path to the target.
 +
** If it can't find a safe path at all then it will spawn directly on a suitable target. Minimally tested but seems to work
 +
** Only applies to newly spawned Exogalactic War Units
 +
*** Thanks to a number of people for pointing out that Exogalactic War Units could get stuck, most recently zharmad and ArnaudB
  
* Previously we had put some logic in place to not delete ships too fast on the client if they were not discussed by the host in a sync pass.  But now that the sync passes are working, this is no longer needed (and in fact actively makes things look wrong for seconds at a time).
+
* Since we are not actually using the SquadIDSources, it makes sense to provide older methods that the various code mods like Civilian Industries were looking forStarKelp is not able to update that this week anyhow, so we made some changes to make sure that his stuff still is compatible with the new version of the game anyhow. So far as we can tell, Civilian Industries seems to work again.
** The game now does a much quicker job of removing these extras, and consequently there are not as frequently extra ships that should not exist in the fleet memberships sitting around.
 
** It's worth noting that for 3ish seconds at a time right now, it is possible for these ships to hang around (but they only appear on the client, and can't be given any orders, which is confusing and annoying but a comparably minor thing and will be tamed soon when we improve how PKIDs are allocated so that fewer clashes happen.
 
 
 
== Version 2.504 Clarity And Fair Play ==
 
(Released September 14th, 2020)
 
 
 
'''We're no longer on the beta branch, because we don't think that this will negatively affect the single player experienceHowever, multiplayer's alpha is still not ready to go.  This build is focused on fixing things up to get things back working properly for single player (which of course also affects MP), and we'll be resuming work on getting MP ready now that this is out.'''
 
 
 
* If a player-allied faction kills something that would grant rewards (science, hacking, metal), the game now sees if there were player ships on the planet too. If so then it grants the rewards to the strongest player on the planet.
 
** This seems the path of least frustration for players
 
** Thanks to Ymir for the bug report, and others for a spirited discussion on steam.
 
  
 
=== Bugfixes ===
 
=== Bugfixes ===
  
* When placing wormholes on a planet, the game now makes an effort to make sure they aren't on top of eachother. In very rare cases, some map types could wind up with wormholes that basically overlapped eachother, which was very hard to work with.
+
* Improved the error handling on incoming_damage_modifier to be more clear.
** Thanks to Mac for pointing this out.
+
** Thanks to NR SirLimbo for reporting.
  
* Fixed a longstanding issue with the number of entities contained within a ship where it was showing much lower numbers than appropriate, because we were indexing into the wrong array of display numbers.  Above 100 units, it should now show much more appropriate numbers.
+
* Fixed an exception where any damage modifiers that were hull only would throw an exception when you tried to apply them.
** Thanks to TechSY730 for the report that finally tipped us off to the potential cause of his strange area.
+
** Thanks to NR SirLimbo for reporting.
  
* Fixed an issue that could cause exceptions in the target list sorting if ships died at just the wrong moment.
+
* Fixed an unusual error that was possible to happen in ReinforceSpecificPlanet().  Not sure why this was happening, but there's a vague chance it may have been related to mods.  At any rate, it's no longer possible to get the exception.
** Thanks to CRCGamer for reporting.
+
** Thanks to Isiel for reporting.
  
* Fixed a very unexpected bug that our recent extra-strict ExternalData checking logic let us find.  Essentially it was somehow possible to get a second Praetorian Guard faction for a single AI, although we're not quite sure how.  The game now actively clears those out when it is loading a savegame or settings as a template, to keep you from having double-strength PG forces for no apparent reason.
+
* Fixed an issue where cluster bombs would not spawn more bombs because they were not dying from enemy fire.  Now the only reason that sub-bombs won't be created from things like this is from a unit intentionally being scrapped.
** Thanks to Deathlymad and Metrekec for reporting, and for providing the savegame that let us practice testing and fixing the issue.
+
** Thanks to Puffin for figuring out what this problem was, and to ArnaudB, Isiel, and Democracy for reporting.
  
* Fixed an exception that could happen at various times if the spire debris data was null when it was thinking about making notifications relating to them.
+
* Fixed an issue with the name generation for multi-owner factions so that it now properly says the names of the multiple owners.  Previously, each party was incorrectly just seeing their own name as the owner.  Of course, in these situations it's best of all to give your empire a specific name, but you don't have to.
** Thanks to jradishurr for reporting.
 
  
* Fixed a minor visual error where it would say "ERROR: my FleetMembership is null!" if you were viewing a tooltip or popup window with a ship in it that had died.  It now will say "This ship has died." instead, if the ship properly died (which is likely to be the case).
+
* Spire cities should now work if they are on planets owned by other Players
** Thanks to GreatYng for reporting.
+
** Reported by NeverZero
  
* Preventatively 'fixed' theoretically-possible-but-not-encountered bugs (that might not actually have been bugs in the end relating to the following, all based on the new ExternalData changes:
+
=== Improvements To Error Handling ===
** Winning a game and getting a superterminal achievement (probably not likely).
 
** Exceptions in notifications about wormhole invasions (this one probably would have been hit eventually).
 
** Exception in notification tooltip about spire debris (again was likely to be hit).
 
** Exception in notification tooltip about instigators (very unlikely).
 
** Two exceptions in notification tooltip about astro trains (somewhat likely).
 
** Exception in notification tooltip about relic trains (unlikely except maybe for multiplayer client).
 
** Exceptions in five tooltips for DLC2 (likely to be hit).
 
** One other exception relating to DLC2.
 
** Possible exception with the Shark B plot on.
 
** Several possible exceptions in writing out the list of AI factions and their subtypes (most were very unlikely, except maybe in multiplayer on clients).
 
  
* Fixed a pretty huge bug where if certain entities died to remains (rather than permadeath), they would give AIP every time they died to remains, but when the normal permadeath setting was on they gave no AIPThis was the opposite of our intention and has apparently been incorrect since July 23rd.
+
* Put in a bunch of wrapper methods for various faction methods that are commonly used by mod factions.  These wrapper methods let us gracefully catch exceptions from the mods and then disable that part of the modded faction so that the game can continue without you having an endless spiral of exceptions.
** This meant that things like GCAs, etc, would not give their proper AIP on death.
+
** For instance, in this build of the game we have broken both Kaiser's Marauders, the AMU, and Civilian Industries.  Rather than having those be absolutely unplayable savegames with infinitely logging errors, it now pops up some errors the first time, then shuts off the brains of those particular factionsSo you'll see those factions stop working and just kind of sit around (or use whatever intelligence there is that is coming from the central NPC logic), but the savegame itself won't be a total loss.
** Thanks to ParadoxSong, Strategic Sage, crawlers, Isiel, and Puffin for reporting and helping track this down.
+
** It's still best to stop playing after you have exceptions like these, but it doesn't make you completely dead in the water.
 +
** We also implemented a neat new thing where we are able to detect even caught exceptions inside these methods, so if the mod author is doing their own error handling, we still find out about the error and shut off that faction.
 +
** It's worth noting that this applies to base game and expansion factions just as much as it does to mods, frankly.  In general this is pretty handy for letting parts of the game essentially have a stroke and die without turning off the rest of the game or leading to endless errors that cause lag.
  
* Regular engineers are no longer part of the fleet membership selections for anything that you can get via battlestations or citadels.  Instead, combat engineers are used for those cases.
+
* In the list of factions in the escape menu, if a faction has had any sort of fatal error, it now shows "FATAL ERROR IN FACTION" next to it, with animated red and orange colors going past.
** This will not affect existing savegames, only new ones.
 
** Thanks to ultamashot for the report.
 
  
* On September 6, we added the following: "QoL tweak for repair. Any ships on a planet where you outnumber the enemies 10 to 1, or the enemies have less that .2 strength are eligible to be repaired immediately. The previous rule was 'Any ships on a planet without enemies'"
+
* Whenever you have an error message popup, it's only showing you the most recent error out of potentially a long series of errors. Now the game has a first line there that is "Errors since start," and that counts up as more errors are loggedIt may count up while you're reading an exception, for that matter.
** This now only applies to ships and structures of factions that are friendly to the humansAny neutral or enemy factions will now use the old style of logic that existed prior to September 6th.
+
** The idea is to make it so that people don't just see the last error and think that's it.
** This prevents the AI and Exos in particular from developing invincible shields when they have overwhelming firepower against you, among some other unintended consequences.
 
** Thanks to TechSY730, crawlers, and MasterGeese for reporting.
 
  
=== Fireteam dynamic resizing ===
+
* If you have had an exception happen in your game in the last 5-10 seconds, then it now shows the count of errors since the start in the chat sidebar.  This way you can't miss the fact that errors have been happening recently, and if you're in the unfortunate situation of having ongoing errors every few seconds then you will see that counting up and be aware of it. Sometimes people would hit "ignore all" and not realize why their disk was still being slammed by errors, and the fact that things were probably not working quite right. Now it will be impossible to miss.
 
* In the late game, powerful factions can have hundreds or thousands of fireteams, which can make LRP threads run very slowly.
 
* Each faction using fireteams has some variables that control 'how large should my fireteams be'.
 
* Now for every 50 fireteams a faction has, it will require future fireteams be larger 1.5x larger. If a faction starts losing fireteams, the size requirements will go back down
 
** The end result is fewer but larger fireteams, which should be a nice performance boost. Note this won't really help existing games as much as it will help new games to never have that many fireteams at all. Applies to all factions that use fireteams except the Imperial Spire, since that ends the game quickly
 
  
=== AI Difficulty Description Rewrites ===
+
* Similarly, if any factions that have partially shut down from having errors, it now has a count that just won't go away up in the chat area that says "Factions Shut Down From Fatal Errors: 3" or whatever the number is.  This is not so obtrusive that you can't keep playing, but it's obtrusive enough that maybe you'll realize you should stop playing if you care about those factions doing anything.
  
* The tooltip descriptions for AI difficulties have been updated after folks have given us indication that there was some confusion based on the old ones (particularly sometimes players felt bad for playing too low, or did not understand the true purpose of difficulty 10, etc):
+
=== Failed Experiment: PKID Generation Revisions For MP Client Smoothness ===
** Difficulty 1:
 
*** Old: So easy it might be asleep.
 
*** New: The AI is effectively dormant; this difficulty is good for practicing the game without any real opposition.
 
** Difficulty 2:
 
*** Old: Actively does stupid things.
 
*** New: The AI will only utilize its most basic subroutines. Retaliation will be minimal in response to your efforts.
 
** Difficulty 3:
 
*** Old: Excellent if you're just wanting to mess around with no stress and you've never seen an RTS, ever, before.
 
*** New: The AI is conscious, but will operate primarily in a reactive capacity. Most of your opposition will be in the form of defensive AI forces in enemy territory.
 
** Difficulty 4:
 
*** Old: If you're only vaguely familiar with RTS games, this might give you an interesting time.  But bear in mind all the cool and clever tricks aren't remotely here for the AI yet.
 
*** New: If you’re ready for a little push-back from the AI and some confrontation on the homefront, this will be a good introduction to some of the behavior you can expect from higher difficulties.
 
** Difficulty 5:
 
*** Old: If you're here for the first time, but know your way around RTS games, this isn't an awful place to start.  The AI is partially brain-dead still, but it should give you an interesting time.  But if the game seems too easy, you'll know why.
 
*** New: The AI takes your presence a bit more seriously. You may find your attention split from time to time and will have to more carefully consider the repercussions of your choices and how the enemy will react to them. Ongoing reckless expansion on your part has the potential to incite a deadly response from AI.
 
** Difficulty 6:
 
*** Old: If you're solid at RTS games, then this is what would typically be considered 'Normal' for you... potentially.  The AI doesn't have its full bag of tricks yet, but it's still pretty crafty and is starting to have some of its tricks.  This difficulty is also great to use if you're really wanting to have the AI be there, but some other factions be the MAIN threat.  This will keep the AI interesting but not on your back all the time.
 
*** New: Against a Difficulty 6 opponent, your choices are really starting to matter.  You will notice more devious tactics being used by the AI and will need to watch your back as you claim assets and territory.  Other factions have the potential to be more threatening depending on how you set them up, but the AI will continually make its presence known.
 
** Difficulty 7:
 
*** Old: Players in the first game had a saying, that 'the real game starts at difficulty 7.'  And while that is kind of... rude?... there is also some truth to that, in that the AI is finally fully unshackled.  There are a few truly nasty things for the AI that you would still need to turn on in the AI Behaviors section of the Options tab if you really want full pain, but this is a fully competent AI.  This is also the difficulty that Chris, the original developer of the games, plays at.  It's fun and he can play in a relaxed fashion and not be super focused on every detail, but still win only about a third of the time playing that way.  So if that gives you some measure.  He plays most other RTS games on their max difficulty or close, not that that's always saying much.
 
*** New: This is where the AI stops holding back and utilizes all of the strategies and resources at its disposal to try and keep you at bay as your power grows.  Its economic power is still somewhat limited, and while you can still get away with being a bit of a nuisance early on, the enemy won't hesitate to put you down if you make yourself too much of a threat.
 
** Difficulty 8:
 
*** Old: This is the sweet spot for veteran players.  The AI has all its tricks, and has a bit of a stronger economy and stronger responses, too.  You COULD make the argument that the economy of the AI at difficulty 7 is a bit on the weak side, so it's not that this is a cheaty AI or something.  For players who are really paying attention and managing all the small things and want to have a drag-out battle, this is the difficulty of choice.  If Chris really wanted to white-knuckle it, he could probably maintain his 30% winning streak at this level.  But he's not into that kind of stress.  There's a good chance you're better at RTS games than he is, though, if you're a veteran in particular, so maybe that's not so much stress for you.
 
*** New: If you take the fully-functional Difficulty 7 AI, provide it with a bit more fair allotment of assets, and make it more sensitive to your actions, this is where you end up.  Ideal for veteran players really looking to test themselves.
 
** Difficulty 9:
 
*** Old: Are you super awesome at RTS games in general, and this one in particular?  Difficulty 8 is just proving too passe?  This keeps all the tricks from before, but cranks up the economy and some of the frequency with which the AI will harass you.  You could argue that at this point it is getting to be slightly a 'cheating AI,' but frankly things are so lopsided it is hard to make that kind of distinction.  If you're so much better than the average player at managing your empire, then... I guess this is kind of taking away that advantage that would otherwise let you roll the 'fair' AI?  We get into murky waters here, but a subset of veteran players enjoy this difficulty, so here it is.
 
*** New: Making for an exceptionally tough adversary, Difficulty 9 stacks the odds in favor of the AI.  Armed with a robust economy, the enemy will be ruthless in their attacks and relentless in their harassment of your defenses.  To overcome this challenge, you will always need to be on full alert to prevent the AI from exploiting any weakness in your strategy.
 
** Difficulty 10:
 
*** Old: This difficulty level is not meant to be fair.  It's using all of the AI's legitimate tricks, and it has its economy and whatnot cranked up to 11.  If you win against this level of AI, that's something that we traditionally consider 'a bug.'  You are supposed to lose, every time.  Please file a bug report with how you won so we can fix it.  So why do we have this difficulty level?  There are some players who are just THAT GOOD, and they spend their time trying to find weaknesses in the AI despite its unfair advantage.  A lot of improvements to the AI have come about because of players on difficulty 10 telling us how they won.  We usually adjust unit balance or AI logic in response to difficulty 10 victories, we don't just make difficulty 10 harder.  That would defeat the point.
 
*** New: Economically, the 'SuperCat' AI gets a substantially unfair advantage.  Militarily, they still play fair but will be able to bring overwhelming force against you in most every situation, all the time.  A subset of dedicated players enjoy this difficulty level, but it is not fun for most.  Beating the SuperCat even once is considered a crowning achievement, and usually involves a player discovering an unbalanced tactic.  If you find yourself in the enviable position of being able to have your name added to those who win a 'pure' difficulty 10 win, please file a bug report with any tips you have on how we can (legitimately) upgrade the AI to counter your winning strategy.  This back-and-forth arms race between the players and the developers has led to some of the most interesting innovations for all levels of AI for the game (and its predecessor), and it is also a very specific style of brutal gauntlet that certain dedicated individuals enjoy throwing themselves into.
 
** Thanks to Tzarro for writing the new descriptions for us, except for the new difficulty 10 description.
 
  
== Beta 2.503 Multiplayer Not Quite Ready ==
+
* An older approach that we were going to take with Primary keys, with a new PKID struct and a PKIDGenerator class, has been stripped out.  It was going to be too unwieldly to implement, and would have made filesizes and network data a bit larger. We have come up with a better approach since coding that.  It was never used, but the plan was to use that to keep multiplayer sync in better shape.
(Released September 11th, 2020)
 
  
'''This remains on the beta branch in case there are more singleplayer issues. As far as multiplayer goes, things are not stable enough to do any real testing. There is an issue of some sort that causes fleets to infinitely multiply copies of themselves on the client, which leads to a lot of lag and other problems. There's also an issue with various ships syncing in and out of existence in funky ways, which essentially makes multiplayer unplayable. This is something that is going to take more hunting, but it's all one cluster of issues, and once it's resolved multiplayer should be pretty ready to goReally glad we did a soft launch! It would have been awesome to have people able to play multiplayer over the weekend, but we're just not quite there at the moment.  Hopefully in the first couple of days of next week we can figure this out, but for the moment our brains are friedMore to come soon!'''
+
* We only care about PKIDs for squads in terms of where things are diverging so much, so we've got a new SquadIDSource class.
 +
** The squad creation methods (in the codebase, "squads" are all ships and buildings and units) now mostly require a SquadIDSource to be passed in.
 +
** These sources keep some certain number of "for future use" PKIDs either for the faction or some other scope, and usually for some sort of sub-purpose on a faction.
 +
** These are serialized to disk and across the network, and every sim step have their pools replenished and synced over to other players from the host.
 +
** In the event that a source has run out of IDs to distribute, it has a fallback source which is usually the "failover" pool of IDs on the faction in question.
 +
*** This first level of failover means that it is more likely to not have collisions when trying to find something to fill in for a source that was too thinly populated at the time of being called. 
 +
**** A single faction is more likely to mostly be synchronous relative to itself in terms of actions, so desyncs between clients are less likely.
 +
**** But additionally, even if it is a desync, it winds up limiting the scope of the cascade of desyncs to mostly be limited to that one faction rather than affecting many factions all at once.
 +
** In the event that the failover has ALSO run out of IDs to distribute, then it goes back to the main central ID generator that has always been used up until now.   
 +
*** This is almost certainly going to cause a minor desync, or several minor ones, in multiplayer. However, these are going to be corrected by the same process that currently corrects multiplayer and makes it work as smoothly as it does.
 +
*** Right now, MP clients are seeing things like every new ship that is spawned getting duplicated and then recreated, or just shifting spots.  This is annoying in terms of how constant it is, but overall even with it having a desync EVERY time something is created, it's not that in-your-face that you can't play just fine.
 +
*** So at any rate, there are multiple levels of prevention aimed at stopping this in the first place, but when it does happen it's not the end of the world and the game just recovers and keeps going like it has in all the MP versions prior to now.
 +
** The goal with all of this is to make things more smooth for clients, particularly when they are building ships from a factory or placing turrets and similar directlyAnd a secondary goal is to reduce some extra sync fix network traffic.  But in the grand scheme, long-term sync is already assured by all the other characteristics of our multiplayer engine.
  
* There's now extra error handling in the "stage 3" faction logic, to keep that from ending the entire game when those happenIt reads:
+
* To support the new SquadIDSource class, there are a wide variety of sources that are placed throughout the codebase for various purposes.
** DoPerSecondLogic_Stage3Main_OnMainThreadAndPartOfSim Error for faction [name] (index [a number]). Consider restarting the game, as many other things may now go wrong because of this first error.  And please report this! Error: [error text]
+
** As noted, all of the CreateSquad() and SpawnSquad() methods now require a SquadIDSource to be passed in, but if you don't then they will work out how best to get an ID to work around that lack.
** This will probably solve things like paralysis counters not counting down when there are such errors, but you're still likely to have a strange time.
+
** However, for modders and faction coders, the way to update your code is relatively straightforward.
** Thanks to StarKelp, Mac, and gigastar for reporting.
+
*** If you are doing something in the "long range planning" that creates a squad directly, just know that you're already immediately creating a desync, since that only runs on the host.
 +
**** The game will recover from this automatically, but it will be wrong on the client with these new units you just created for 1-5 seconds, and may be wrong with some other units created around the same timeSo ideally don't do that.
 +
*** If you are creating squads directly in the "stage 2 or 3" methods, then you will now want to almost always use CreateNew_ForFactionBackgroundGeneration().
 +
**** That method gets its own SquadIDSource inside itself, and there are loads of queued IDs in that source, so your risk of causing any desyncs at all with this is remarkably low.  And if any do happen, it's probably not going to bleed over to something the player notices very easily.
 +
**** There is also a version on faction that is SpawnNewUnit_ForFactionBackgroundGeneration() that takes the place of what was SpawnNewUnit() before.
 +
*** If you are creating squads during part of mapgen, such as initial seeding logic for instance, then you should use the CreateNew_DuringMapgen() method.
 +
**** This method entirely bypasses the SquadIDSource class, and just generates IDs directly.  Mapgen only happens on the host, prior to syncing to everyone else, so there's no need for those sort of ID queues there.
 +
**** If you mess up and have a method that uses CreateNew_DuringMapgen() both during mapgen and after mapgen, then you've probably introduced a minor desync with whatever is created, but again it's something the game will auto-correct within 1-5 seconds.  The good news is that it should not really affect any other units than the ones you used this way.
 +
**** Conversely, if you mess up and use CreateNew_ForFactionBackgroundGeneration() or similar during mapgen, then it will just do things as normal with not even any slight ill effects.
  
* Fixed a bunch of places in notifications where it was still looking to the old locations for an out of date iconWe will have real icons in the future for those, but for now the placeholder will no longer throw an exception.
+
* In single player and multiplayer, you can now see the ID stores and the statistics about the ID usage in the memory pooling section of the escape menu.
** Thanks to jrad for reporting.
+
** All savegames are a bit bigger now, maybe about 100kb or soIt's a fairly small addition in general, but in one example save we have an extra 65 thousand IDs pre-generated for use in specific scenarios.  We can see even in a single-player game if it's ever hitting the central stores, etc.
 +
** You might wonder why we are also using this in single-player, but in general this does not cause a performance hit, and we have always tended to do everything the same between single and multiplayer even if that's not strictly required, so that we could maintain as few differences and as consistent of performance as possible.
  
* Fixed an exception that could happen when killing instigator bases, in the notification tooltip for them.
+
* The PKID Sources are now fully synced over the network in multiplayer, and they are centrally stored for reuse and assignment within savegame and across the network.
** This is another regression... kind of... from the last few betas.  This actually will make clients more robust in multiplayer, though, so it's better than just a straight regression fix.
 
** Thanks to TechSY730 and jradishurr for reporting.
 
  
* The Civilian Industries mod has been updated to be compatible with the new versions of the game.
+
==== The Actual Result, With Intriguing Data ====
  
=== Multiplayer Ship Sync Fixes ===
+
* For now, after all the immense amount of work to get SquadIDSources working (and the two days after it to figure out the one-line networking error --which wound up having us greatly expand a bunch of debugging tools for multiplayer in general at least), we're currently choosing not to bother filling the SquadIDSource objects at all.
 +
** With this in place, they wind up adding an incredibly minor amount of overhead, but no actual functionality.
 +
** The fundamental premise of these is to try to reduce collisions of PKIDs between the clients and the host by having them queued up and ready to go, but that... really doesn't seem to happen.  There are too many things in motion constantly, perhaps?  It's honestly kind of hard to say exactly why this doesn't work, at the moment.
 +
*** The most obvious answer is that the timing is too tight, but the Sources being filled with a certain number of values in advance really should be working around that.  So that would seem to indicate that maybe there's some secondary problem, like the order of the queues getting messed up during sync, or something like that.
 +
*** A more subtle answer, which is probably the correct one, is that we have two different timescales of network communications.  On the one hand, we have the network sync info, which gets applied immediately.  On the other, we have GameCommands, which get applied 100-200ms later.  It's seeming likely that the sync of the queues is removing key entries from the client before the client can actually make use of them, since the client may be on a 100ish ms lag from the host.  This could be solved in a variety of ways, but would need more testing.
 +
*** However, seeing these in practice, the savegame sizes go up dramatically, and there is a notable slowdown in performance on the clients, which we didn't really expect.  Part of it just has to do with how many factions can be in the game, particularly factions that are minor-use or only have a few units in them (tamed macrophage, etc, which may not even be active).  This whole thing adds a definite per-faction extra cost in terms of data usage, and running out predictions for a long games is fine... but doesn't really feel great.  What's notable is that turning this off feels like a breath of fresh air in terms of performance immediately after, so that says something right there about how advisable this is.  Is this worth fixing?
 +
*** Deciding if this is worth fixing or not is not something we want to decide late at night after three very frustrating days of staring at this and related problems, so for now we're just leaving it empty and pushing out this release so that folks can have the many many other fixes that we put in this build.  This build has been delayed long enough by this blasted feature.
 +
*** If this particular approach for PKIDs isn't used, then what do we do?  Well, there are a variety of options.
 +
**** On the one hand, we could do nothing.  The sync code already corrects divergences, and is doing so with a minimum of bandwidth and no extra savegame file size, etc.  However, it does cause minor jitter on new ships on the clients, which we don't like.  So that' not our first choice.  It seems like a lot of people don't notice this much, but at the very least for directly-placed human ships we can do better.
 +
**** So, on that note, we can adjust the way that units are created.  Right now, there are many places where the simulation creates a unit, and it tries to do that in lockstep on the clients and the host.  This... may simply be not the way to go.  We've contemplated this before, for a long time in fact.  It may be a lot more tenable to make it so that the "create unit" code actually only runs on the host, and then that data gets synced over to the clients asap.
 +
***** Originally this was something we had discarded because it would require a huge refactoring of all of the code for all of the external factions and mods.  Not just a search-and-replace sort of change, but a really deep dive shift in the creation of all units.  That is highly undesirable for many reasons.  One of the reasons is that it would negatively affect the feel of the game on the host, and in single-player, because in theory we would be creating new units via GameCommand, which is something that happens on a delay.
 +
***** The thing is, creating units only on the host doesn't mean it has to happen in a GameCommand.  Actually one of the things that this entire code branch with the sources has demonstrated is how VERY fast we are able to get information over to the client.  Normally we want to have new things get created and sent to clients via GameCommands in an orderly fashion as part of the main sim loop... but the thing is, the sync code is really freaking good.  In almost all cases, if the ships actually appear 100-200ms early on clients, that matters... why?  In reality, it doesn't seem like it matters much at all.  If that causes a minor desync, it's still far more minor than the desync that we're getting right now with units having wildly wrong PKIDS.  Likely their position or other stats would be slightly off on the client, and that is REALLY trivial to fix within seconds, and happens automatically already.
 +
***** Overall, even though the PKID Sources approach was a complete dead end (probably) in a direct sense, this does provide some ways that we could theoretically reduce sync errors when it comes to even things like shots, which we've been concerned about for a while with IncomingShots being off since we don't consider shots worthy of sync (they last too short a time).  But if we used the back channel data to generate shots only on the host, and had those synced to the client only once, on creation, that might be very interesting indeed.  One of the possibilities with shots and even units is that we add a new SimFrameStartedExisting or something to that effect, and if that's in the future then the client just keeps them as invisible and not part of the client sim just yet.  That would allow the host to give early "hints" to clients, who then have data ready to go as soon as the appropriate sim frame rolls around.  Heck -- the clients don't even have to have fancy new logic for holding those units in abeyance.  They could simply keep the data in its packed form until the appropriate frame.  This would be very lightweight.
 +
***** Ironically, this even paints some ways in which the "only create ships from gamecommands" approach of the "long term planning" code that is host-only is something that we might need to do away with.  That would make things a bit simpler on modders if we go that way, and it would even allow us to in theory shift some of the per-faction processing onto non-sim-blocking threads.  The only reason that those need to be sim-blocking right now is in order to maintain sync in multiplayer.  But the thing is, we never expected for the general baseline sync to be this good... or for there to be such an effective faster-than-sim backchannel for the host to shuffle data over to the client.  Despite this being our third coded multiplayer model over the span of 7ish released multiplayer games, this one really takes the cake for being the most advanced, and it has revealed some interesting new avenues to consider.
 +
** So the bottom line is, at first this really felt like a huge waste of time, on top of being a monumental disappointment.  After taking a break for an hour or so and putting my kids to bed and thinking about it some more... this is actually pretty interesting data, and suggests that we may be able to be even more "fast and loose" with things than I ever expected, and thus really take the potential worry away from modders and faction designers, lower the network load, keep the savegame sizes small, and still improve sync.  Having the host be fully authoritative over PKIDs was not something that seemed like it would be possible without introducing input lag on both the client and the host... but we already have the most minute (100-200ms) of timing lags between the client and the host, so that actually opens up a ton of options.
 +
*** Crazy sidebar?  One of the things that particularly bugs me about playing multiplayer right now, as the client, is the input lag.  There's a lot of strictness that we have going on with trying to keep the client close to the host in timing, and making sure that GameCommands are executed at just the correct timestamps in the correct order, etc.  But what if... we didn't care?  Why not let the client instantly ask the host for things, and the host instantly execute them, and tell the client to also do the same?  Sure it would introduce some new timing inconsistencies, but... so what? 
 +
*** Also crazy, still sidebar?  This is even a way to potentially get around dropped packets and other situations with high latency or high ping.  Let the host just get ahead, who cares, have the client blunder on without permission and catch up with what the host wants in a few hundred ms after the network blockage has cleared.  This pulls the game further and further away from even pretending to be a lockstep multiplayer model, but to be frank, the performance that we're seeing, that we're able to get, is what makes that a feasible thing.
 +
*** Want to stay in crazy sidebars?  Things like FInt, our fixed-integer math struct and its related code, could largely be removed from the frequent sim calculations.  There are some MUCH faster floating-point math functions, several of which use SIMD, that we use right now only for non-sim purposes.  But it's already clear that the amount of drift we see in a few seconds is next to nil, and we're syncing things so frequently that any real drift that mattered would be correct within seconds, and typically would be smoothed out by the very awesome lerping that the vis layer does to keep things smooth in general.
 +
** So... yeah.  This experiment was a huge disaster, on the surface.  On the other hand, it took me through every piece of the code that creates units at the moment, and gave me an enormous amount of data on how some of the data is able to be passed around faster than game commands.  I will need to weigh my options carefully, and probably focus on gradual improvements over time since the baseline is already pretty good right now.  But making things more host-driven ought to be one easy quick improvement for sometime very soon.
  
* Added a setting to the networking section of the settings menu: Log Human-Readable Ship Network Syncs To Disk
+
=== More Multiplayer Technical Work ===
** Only relevant on multiplayer clients, not the host.  Will majorly slow the game down, but dumps a huge amount of networking info to the disk in the NetworkHumanReadablyShipSyncLog.txt file in the PlayerData folder.  This gives a message for each ship that was changed or deleted and why that was done, as well as what planet it was on and who owned it.  When syncs are doing funky things, this is a way to manually review it and find out why.
 
** This required us putting in a LOT of extra code to handle log
 
  
* The current sync cycle is now sent with the divergent data sets, hopefully leading to clients not deleting things they just fixed (because that was totally happening before. Logs are a magical thing.).
+
* Removed some debug lines on the network clients about wrong key syncs (which always showed as zero because we wound up never deciding to check for that).
 +
** The adaptive system for sync that has continued to evolve out of seeing real data basically made that irrelevant.
  
* Discovered a major oversight in our sync code, where basically once something had been synced once it was then being synced every sync cycle forever after that.
+
* The new sync of the PKID sources is now split out into its own separate sync cycle (for time slicing purposes mainly), separate from the faction sync.
** This was a huge cause of lag for multiplayer, and made things disappear inappropriately, probably.
+
** Also separated out the "external data" of factions rather than having that be in the "Faction basics" sync.
** There are still other things wrong with the ship sync, though, that we can see in the new logs.
 
  
* The sync code has been made more robust in general, now syncing the type of entities as well as what faction they belong to.
+
* The "Show Network Sync Details In Escape Menu" option in networking has been moved to the top of the other networking features, as it is the most helpful one by far.
** These are often incorrect, when there are catastrophic different uses of primary key IDs anyhow, so getting those right is a good thing.
+
** It has also been given the prefix "Helpful: ".
** It occurs to us that maybe this is overkill, since if these are wrong then probably the planet or at least the location would also be wrong?  But... let's leave it in for now, and maybe make an option later for skipping it.  It's not a lot of data to transmit or a lot of extra processing.
 
  
* Fixed a couple of issues with reusing entities as different ship types, where it will now properly add or remove or reassign system types on them.
+
* Added another new setting to the network section, as well: Log Decoded Network Faction Basics Sync Data To Disk
 +
** Description: Same as the 'Log All Decoded Network Sync Data To Disk' setting, but only writes data for the faction basics that are periodically synced.  If something gets awry with that data, this is a way to figure out why there's a discrepancy.
  
* Fixed some issues with reusing entities during sync where they were not being added back to the central lookup of entities, leading to future syncs to fail on them forever.
+
* Multiplayer sync messages are now numbered by the host, and the clients read the number out when they get the message.  This way, if a host sends out a sync message prior to a client joining, or a client misses a message or whatever else happens, the logs will still match  up on both ends and are something we can compare.
 +
** We were running into the baffling situation where the logs did not match in ways that should be impossible, but this was because the clients and host were being allowed to number their own messages independently.
  
* Put in some logic to improve the number of loops before we remove something that isn't being synced properly, to make it based on the number of loop counts rather than the amount of time something has been alive (since things that have been alive for a while can get fully synced later).
+
* ArcenExternalData-RowIndexNonSim is no longer logged in general, because it is specifically something that is non-sim and thus will be different on the clients and the host.  The matching isn't done based on it, so it's not a part of sync that matters.
  
* Fixed some conflicts that could happen with entities in the central lookup on the client in multiplayer, if the order of registering and unregistering entities gets out of sync.
+
* We slightly reduced the maximum fragment size that we're willing to send, from 512kb to 500kb, still minus 100 bytes in both cases.
 +
** We had one report of a user on Steam getting an exception when trying to connect with the prior limit and the new limit does not make much practical difference to anyone else.
 +
** Specifically it complained about 524,199 bytes, when 512kb is actually 524,288 bytes; with the new limit of 500kb, that is coincidentally 512,000 bytes, which is potentially the actual accidental number of casual-math bytes that Valve actually is limiting to.  We thought we remembered seeing in their code that it was 512 * 1024 that they defined their limiter as, but nonetheless that was only in a header file and so the internals might be defined differently.
 +
** Thanks to NRSirLimbo and CRZgatecrusher for reporting.
  
* Intentionally desyncing the PKIDs of ships, wormholes, and fleets on clients compared to the host.
+
* Fragmented error messages now give more informative error messages when something is off.
** Trying to reuse entity IDs was often causing some notable problems, and they were rarely in sync as it was.
+
** It's now vastly more common for savegames to be over the limit, since we now have all the pre-caching of PKIDs.  One small 275kb savegame changes to 527kb in the new version.
** This forces a sync cycle for every new ship and fleet that is created, but makes conflicts on the client a lot less likely.
+
** Good thing we spent so much time on data efficiency earlier this year, because we really require an abundance of extra data to make sure PKIDs come out nicely between the client and the host.
** This may not be a good long-term solution, but a refactor to avoid the conflict space is potentially where we're at, honestly.  That will take days, and add a lot of bugs temporarily, so it would be great to avoid it.
 
  
* At the moment the game creates infinite extra fleets on the client, slowing it down progressivelyThis makes it effectively unplayable.
+
* Completely re-wrote our custom packet fragmentation-and-reassembly code.  It's more efficient on the client now in general, and works properly.
** There are also about a thousand ships that it will routinely delete from the client, then re-add, then delete againAlso making things unplayableStill looking into it, but this is likely to be a Monday thing, as this is not a simple matter.
+
** We've tested this with a maximum allowance of 50kb  so that it fragments a variety of messages rather than just the initial savegameIt was all working well, now, so we've gone back to 500kb.
 +
** It turns out that, previously, we had an accidental game of Russian Roulette goingDepending on what bit the last of the fragment header ended on in its final byte, it might automatically advance to the next byte on its ownThat gave it a 1 in 8 chance of dying on a fragment by skipping one random byte of data.  That's no longer possible, but took us forever to track down.
  
== Beta 2.502 Regression Fixes ==
+
* ArcenSerializationTester, which was used as a single static-style class, has been removed.
(Released September 11th, 2020)
+
** Because of its static-class nature, it was not threadsafe, and we could not guarantee that we were not having mixed serializations or deserializations in one batch.
 +
** As part of this, we have replaced it with a new ArcenSerializationLogger class, which lives on actual serialization and deserialization buffers and thus can't be confused across threads.
 +
*** As part of THAT, we are also now making it always write directly to disk, rather than buffering in memory sometimes.  So the settings option "Write Savegame Serialization Logs In Realtime" has been removed, as it is now always true.
 +
** It is worth noting that this method of logging is somewhat less performant, and definitely wastes some RAM, but that's not of relevance to our purposes.  If you have this logging turned on, you're already in a debug mode that is going to have performance that suffers by its very nature.  What we prize most in that situation is accuracy.
 +
** This removes any doubt of any logs getting scrambled by simultaneous writes, or by overlapping requests to log, or things of that nature.
 +
*** As a side effect, if you enable several kinds of overlapping debugging at once, it is possible to get an exception now, but that's better than before where it would just scramble your log happily.
  
'''Note that this build is still in beta in order to let people have a chance to run into any more regressions that we may have introducedSo far none of the regressions have indicated any errors in older builds, which is a nice thingThough in the process of making the prior beta build, we did fix a number of "useless extra data" things, so even if we don't find any new bugs that were older, these regressions were still worth it to ensure data accuracy.  It is quite annoying in the short term, though, and we really appreciate the folks taking the time to test it out.'''
+
* Added a new setting to the network section: Log All Decoded Network Data To Disk
 +
** Will massively slow the game down, but dumps ALL messages as they are encored or decoded to the disk in files inside the PlayerData/NetworkSentDecodedData and PlayerData/NetworkReceivedDecodedData foldersThis covers absolutely all data, and includes message headers that other forms of decoded-data logging do notWith this logging enabled on both the client and host, you can compare the output and see what serialization problems are happening, if there are any.
 +
** This is a last resort sort of debug option!  Since ALL data is being actively decoded as it is written, it is far larger (and in plain text) than the actual data being sent across the network.  A typical ratio might be 40MB of decoded data for 500kb of actual network traffic.  You can have a few GB of data on your disk after just part of a minute of letting the game run in this fashion.
 +
** Warning: do not use with 'Log All Decoded Network Sync Data To Disk' or any of its sub-options also turned on, or you'll get errors.
  
* Add some new voice lines when the player is attacked by the Nanocaust
+
* The game now sends a unique 64bit messageID with every message from the sender, in sequential order of send, so that the sender and receiver are able to compare notes.
 +
** Full support for understanding the serialization of message headers is also now in place.
  
* Hopefully Zenith Forcefield Generators will now return after being pushed
+
* The game is now able to do some temporary buffering of serialization data to write to disk, prior to knowing what the name of the file should be, and then come in later after it has done a bit of deserialization and knows what to name its new message.
** Thanks to GreatYng for reporting, and Puffin for reminding us of the fix
 
  
* Fixed a bug from the last couple of builds where chat commands were failing in general.
+
* These new abilities combine to give some really rock-solid and overkill-style logging abilities that let us find bugs that otherwise escape us in the networking code.
** Thanks to Magiik, MasterGeese, gigastar, and Richard333 for reporting.
 
  
=== Fixes To Regressions From Prior Beta Build ===
+
* After about two days of wanting to tear his eyeballs out trying to find an incomprehensible error, Chris found the single-line typo that he was missing.
 +
** The PKID syncs work fine on clients now when it comes to things like building structures directly, but for most other purposes there are just as many catastrophic mismatches as ever.  Sigh.  This is going to take some doing.
  
* Fixed a bug in the latest beta build that was causing new games to constantly error out with autosave data not being added properly.
+
== Version 2.637 Threatfleet Conversion, Chat, And Clickable Planets ==
** This is one of those "externaldata is now more explicit" things, but this is an example of us choosing the wrong explicit option this time around.
+
(Released November 21st, 2020)
** Thanks to Puffin for reporting.
 
  
* Fixed an exception that could happen when trying to generate notifications about AI reserves before their data was initialized.  This was caused by the last beta, but is better to have it handled this new way (so, yay error, this time).
+
* The game now tracks a new BecameThreatfleetAtGameSecond on each entity.  When it is detected than an AI Sentinels ship is in Threat status (meaning it would show up as Threatfleet), it now logs the current game second so that it remembers how long it has been threat.
  
* When there are errors in generating a galaxy, it now no longer lets you into the galaxy to play (since that leads to many random errors after the real one with the map not generating).
+
* Added a new seconds_threat_exists_as_threat_before_joining_hunter_fleet on AI difficulty, which is currently set to 2x seconds_threat_waits_before_joining_hunter_fleet for all AI difficulties.
** Random things might include lots of planets belonging to no one, among other things.
+
** This sets a new and absolute timer on how long threat can be threatfleet for the AI Sentinels before getting transfer orders to the Hunter Fleet.
 +
** Previously, based on the other timer, if the AI Sentinels threatfleet is engaged in whatever activities, even if that activity is indecision, then it would never switch to the hunter side.
 +
** This makes it impossible for ultra-long-term threatfleet to remain in the galaxy, unless it is pointed at a non-human faction, or it is of a specific type that can't convert (usurper, overlord phase 2, drones, etc).
 +
** Overall in some edge case savegames, this makes it so that suddenly a bunch of idle threatfleet that was too stupid to figure out your particular empire now gets converted to the far-smarter hunter faction and joins teams dismantling you.
 +
** Thanks to TechSY730, Metrekec, ArnaudB, and Crabby for reporting.
  
* SeedStartingEntities_LaterEverythingElse during mapgen now has a lot of new exceptions it can throw if various data is missing that it is supposed to have.
+
* Previously, it was up to the host and the clients individually to tell when the game was won or lost.
** Mostly these are related to the AI and its subfactions (hunter, warden, and PG), but there's also one for if risk analyzer data is missing.
+
** Sometimes there is a tiny bit of a disconnect between an event happening on the client and the host, however, and the client has a part of a second where it might think that you've won. We're being vague here to avoid spoilers, but it's a pretty common result that would happen at the end of each game.
** Prior to the last beta, it seemed to have been just using blank data, although it's impossible to be sure.  And in the last beta, it was throwing an exception.
+
** At any rate, now the multiplayer host is exclusively in charge of saying when the game has been won or lost, since it never has any missing data even for a part of a second.
** We then tested all of the factions in the game and the first two DLC, and the only three types that threw exceptions in this area were the AI subfactions (hunter, warden, and PG).
+
** Thanks to Daniexpert for reporting.
*** We could use more robust testing of the game starting with various factions and them having various settings, though, to make sure that it's all going across properly (this is just in single player, not even multiplayer).
 
** Thanks to Puffin and jradishurr for reporting.
 
  
* Fixed four typos in the last beta that were not properly having the "related AI and subfactions" properly reach for one another, which led to missing or misapplied settings on game start.
+
* Made a number of changes to the in-game chat textbox to prevent it from capturing your input even after it was closed, thus leading to mysterious sends of extra keys as well as your keybindings in general not working while the capture was in place.
** This then left the Praetorian Guard still not working properly, because they have no custom fields in the lobby and thus were never having a reason to initialize.  That probably was not a problem, but to keep things consistent and safe we are now initializing it when the general "AIDifficulty" field is processed.
+
** Thanks to StarKelp, Puffin, Democracy, and Badger for reporting.
** For the record, prior to the most recent beta this means there were not actually any errors, but now we do have protection in place in case such an error pops up in the future.  But for the time being, these errors were just in the most recent beta, which is gratifying to know.
 
  
* Fixed a couple of logic errors with risk analyzers in the most recent beta that was causing their notification to show up wrong as well as also firing them immediately on game start.
+
* Also wound up re-plumbing the entire textbox input pipeline, because there were a number of cases of strange and annoying lag that could happen with them. So far all the ones we've tested are working great now and are more responsive.  But please do let us know if there's any that are funky for you.
** They now should work properly again, and if the notification is going to be wrong, it will be more informative in its wrongness.
+
** This could in some cases lead to race-condition-like behaviors, and repeat sends of messages.
** Also fixed the fact that this could happen when AI Risk Analyzers were not even enabled as a faction.
+
** Thanks to Sigma7 for reporting.
** Thanks to Puffin for reporting.
 
  
== Beta 2.501 First Raft Of Multiplayer Fixes ==
+
* Fixed issues where pressing the escape key while in a chat textbox would send the chat rather than erasing it. This is because of our use of OnEnterOrReturnPressed(), which apparently also fires on escape being pressed.  So now we have left notes in the code to that effect, and use a different method of detecting that enter is pressed to send chats.
(Released September 10th, 2020)
+
** Thanks to Sigma7 for reporting.
  
'''This one is on the beta branch on Steam and GOG because of how much we changed with the "ExternalData Accidental Creation Avoidance" sectionThere may be legitimately new bugs that we introduced from that, or there may be old bugs that now simply show themselves with error messagesEither way, we don't want to inflict that on everyone, so please use the beta branch to help us test this one out.'''
+
* Should finally have fixed the super annoying bug where sometimes a planet on the galaxy map is un-clickable.  We did this by making sure that the collider box for the planets is now way taller than anything else, and so things like the links between planets can't accidentally override them.
 +
** On the off chance that somehow the collider was actually being turned off for the planet icon, we actually are now always making sure that is on every frame, too.
 +
** If you were seeing some sort of other tooltip for something but unable to click the planet, and you see the problem again, please let us know what the tooltip is forIf you were seeing no tooltip at all, then that was probably the collider being disabled in some fashion.  We do turn off the colliders for icons that are supposed to be off, but that should never affect planetsIf it was affecting a planet icon previously, that should no longer affect a planet icon.
 +
** Thanks to Badger, TechSY730, GreatYng, CRCGamer, RedPine, denko, crawlers, Isiel, Cyborg, Asteroid, Kizor, Strategic Sage, and probably others for reporting.
  
* There is a '''list of known issues with multiplayer''' here: https://wiki.arcengames.com/index.php?title=Category:AI_War_2:_All_About_Multiplayer#Selected_Short_Term_Todo_List
+
== Version 2.636 Text Hotfixes ==
** It's debatable how playable the alpha is at the moment, given the issue with the client ships deleting themselves rather than syncing, and given some of the (essentially) client-side memory leaks.  Those two things will be my main priority tomorrow, unless something else more pressing comes up (like fixes to things broken by the ExternalData stuff).
+
(Released November 21st, 2020)
  
* A new button has been added on the main menu above the forum link that links directly to the AI War 2 discord channel.
+
* Shots now visually scale up at 6x the rate they previously did when you are zooming way out from a battle.  This should keep them visible in farther-off battles, while not being so large when closer in.
** Thanks to Metrekec for suggesting.
+
** They also now only start scaling up after a distance from the camera of 150, rather than 50, and their scale factor subtracts off the original 150 so that there is not a sudden jump in size when you cross that distance threshold.
 +
** Thanks to Badger for suggesting that these be scaled up better.
  
=== Better Default Screen Resolutions! ===
+
* Fixed a bug in the prior build with how integers and chars were being written using the revised ArcenDoubleCharacterBuffer.  It essentially either made numbers stay stale, or be outright invisible, in a wide variety of situations.  Other times they looked just fine, but it was dependent on exactly how the calling code worked.  From what we can tell, all instances of this are now fixed.
 +
** Thanks to Wuffell, ArnaudB, Daniexpert, TechSY730, Smaug, and Crabby for reporting.
  
* Fixed a bug where the fullscreen resolution was still being saved into newsettings.dat rather than graphicssettings.graphics.
+
* Fixed one other issue with the revised ArcenDoubleCharacterBuffer, where if the next string from the buffer was SUPPOSED to be blank, it would just return its most recent string instead.  So messages that were popping up various places but then should disappear when no longer relevant could not do so.  They could be replaced by a different message, but could not actually just fade to nothing.
** This meant that the fullscreen resolution was being sent over cloud sync, when really that should not be, since that is a machine-specific setting.
+
** Thanks to Wuffell, ArnaudB, Daniexpert, TechSY730, Smaug, and Crabby for reporting.
** This may wipe out your prior values for the fullscreen resolution, requiring you to set it again.
 
** Thanks to jrad for reporting.
 
  
* At long last, added a startup feature that folks have been wanting for a while: better default screen resolution, for a better first impression as people start the game for the first time.
+
* If an exception happens in FromServerToClient_PeriodicPlanetFactionSyncDataThatJustOverrides, we should now get far more useful error messages now.
** Previously, this particular game was just having a default of opening in windowed mode and 1024x768px, since that will fit on most monitors.
+
** In this method and in a variety of other network sync methods, it now also checks to see if the galaxy is null, and returns early if that is trueThis basically prevents errors from stray network syncs that are trying to be processed after the game is being disconnected.
** One of the reasons for this is that opening directly in fullscreen mode can cause bugs, particularly when settings are copied from one machine to another.  But we are using fullscreen windowed mode, which reduces the chance of fullscreen bugs, and we also have our graphics settings not set to cloud sync for the last year or so.
+
** Thanks to Daniexpert for reporting.
** With that said, now the game will automatically (first time opening it on this or future versions on any given computer) set itself to be fullscreen mode with your desktop resolution.
 
*** It also will set your windowed mode defaults to be your desktop resolution minus 80px width and 100px heightSo if you do flip it back to windowed mode, it should be at a size that feels sensible for your machine.
 
** If you are using a very high-DPI monitor on an underpowered machine (for instance how Chris is testing with a late 2013 MacBook Pro 15" that is below minimum specs for the game), then you may want to lower the fullscreen resolution to something that machine can handle more gracefully (for instance, with ship graphics off and only running at 720p, that below-specs machine runs the game great).
 
** Note: if you are already in fullscreen mode, then unity just reports what your current fullscreen resolution is.  So it will save itself to that, and then set your windowed mode resolutions to be a bit smaller than the current fullscreen mode.  Normally this game opens for the first time in windowed mode until this logic kicks in, so this only applies if you already have a current fullscreen setting active.
 
  
=== Multiplayer Fixes From First Alpha ===
+
== Version 2.635 AOE Visibility ==
 +
(Released November 20th, 2020)
  
* If there is a null result from FindArcenSteamClientConnectionByConnectionID in OnMessage on a Steam host, it now will write a more detailed and informative message as to why.
+
* Some improvements for frigate roll colouring in games created on this patch
** Additionally, in general OnMessage on the Steam server and client is now far more instrumented if those wind up with issues.
+
** Thanks to Daniexpert for suggesting
** This won't actually solve any problems, but for the case where there was a client disconnect on connect, this should tell us what is going on more.
 
** Thanks to StarKelp for reporting.
 
  
* The numerical order of the detailed networking sync logs is now better regardless of OS file sorting, as it gives leading zeroes where needed.
+
* Fix a bug where Discoverable factions weren't appearing in the Edit Factions screen
  
* While in the lobby, or while players are still connecting, the game no longer tries to run the general sync-correction code.  This was an oversight in general, and was leading to various errors that would keep popping up until the host saved in-game and clients disconnected and reconnected.
+
* Some minor UI improvements to the Active Metal Flows screen and the Brownout Notification
** This was the chief cause of the ""Fixed attempt to read more faction data than we had factions" error on the client.
 
** Sync was already being handled as well as it needed to be in the lobby in particular: all it needs to do is make sure that your UIs are consistent, which it does.  The actual underlying data about incomplete factions and such that can't be seen yet are really quite irrelevant at that point, and so it actually skips a lot of that data, which was incompatible with the full main-game-style sync.  As soon as you start a game from the lobby, it already doing a much more robust generation and transmission of the data.
 
** After loading into the game from the lobby, however, it seems that that initial sync is not as complete as we had hoped, so that's another area for us to now investigate.
 
** Thanks to StarKelp and his play group for reporting.
 
  
* Fixed a bug in deserializing player accounts, which was something that was leading to the immediately-after-lobby sync being broken.
+
* The descriptions for the AI Reserves unique units now mention they are used to combat player Deepstrikes
  
* Fixed a harmless extra blank fleetID that was being sent as part of the PeriodicWorldExtrasSync, which made them look inconsistent but did not cause other problems.
+
* Fixed a couple of exceptions that could happen if you were viewing the tooltip for an ship or structure right as you exited the game.  There were probably a few other cases that could also cause this.
 +
** Thanks to Corpserule for reporting.
  
* Fixed a larger bug that was actually preventing deserialization of divergent ships from working properly if the ship did not already exist on the client.
+
* Majorly reworked how the "time do die now" code paths work for ships and units in general, so that we can more accurately tell them when they should explode or when they should not explode.
** We had fixed this the other day, but made a mistake in the fix and had to do it over. Now it works!
+
** This solves the problems of ships exploding when they are removing one to add itself to a stack, as well as the problem of ships on MP clients exploding as they move to their proper position after a sync error (if the PKID itself was off).
 +
** It is likely that there may be some bugs resulting from this, but fingers crossed nothing too severe after we fix the initial raft of those issues.
  
* There are still some more issues with syncing divergent ships that have external data on them, and we're not sure why yet.
+
* The settings for screen edge panning have been moved higher in their respective camera controls sections, and have been renamed slightly to make it clear that it's only for the single camera type, not both cameras.
** The deserialization code for external data now has extra error handling in general, so that we can be more informed if something like that happens during sync or a load off of disk.
 
  
* On the ArcenSerializationTester, added AppendIfActive() and AppendLineIfActive(), which are basically like Append and AppendLine().
+
* Fixed an issue (that was probably not new) where when you had the camera low enough that gimbal icons for ships were not showing, those gimbal icons would still show their explosion animation when the ships under them died. Now you just properly see the explosion animation of the ship itself.
** These return a ArcenSerializationTesterWriter so that they can be chained into concisely readable calls like other parts of the code.
 
** We want to be able to write more complex data in for informational purposes without it being the full WriteHeaderStringIfActive(), and without having to do string concatenations that hit the GC.
 
  
* Several pieces of new logging are now in place to help us more easily identify problems syncing unit data, and external data in general.
+
* Fixed some minor bugs that may or may not have been present previously with srapping units not always showing them exploding as they do.
** We were seeing some mighty funky stuff on ExternalData syncs failing in multiplayer, and are trying to understand what is happening and why.
 
  
* A WHOLE lot of extra error handling and instrumentation has been put in place around ships and externaldata in general.
+
* The game will now complain if it can't find various materials and such that are used for things like under construction status, etcAt the moment, nothing complains.
** Basically if something goes wrong, we don't want it to do so semi-silentlyThe various problems that most people were seeing in the first multiplayer alpha version were really downstream issues from the real errors, which were largely silent.
 
  
* Found and fixed a part of the externaldata serialization that could be null in some cases, requiring us to instantiate it even on a partial sync.
+
* Fixed a very small parser error that was causing AOE effects to not show up at all, ever. This was introduced a bit ago when we improved the xml parser for modders.
** This is something that we had already guessed we would have to do, based on us doing the same thing with ships themselves last version, but the silent errors happening here took us several hours to figure out what was going on.  It's fixed now, but there will be more cases of this, probably.
 
** With this fixed, the divergent ships no longer throw any errors.  However, there are still some major differences between the client and the host that need to be looked at.
 
  
=== ExternalData Accidental Creation Avoidance ===
+
* When Autobombs blow up, they now have a flak-style effect that appears around them.
 +
** Same for all of the minefields.
  
* Put in several fixes to potentially remove ScourgePerUnitExternalData from accidentally being created on any unit that was part of a fireteam.
+
* Added a new xml flag, is_okay_with_null_aoe_effect_for_aoe_attack, which is used for the ExplosiveInvisible shot type, aka for Crusher turrets and weapons.
 +
** These are meant to be invisible AOE damage that crushes stuff near them, and so we don't want the (new) "usual" error of "hey there's a missing AOE visual effect when you are doing an AOE attack" to happen.
 +
** Actually, we wound up suppressing the error, because more things were hitting it than expected and it's not worth it.
  
* This is going to break code mods temporarily.
+
* The flak effects now appear again properly, we can now verifyThis being with grenade launchers most notablyThey're on the small side, but that's somewhat by design so they are not overwhelming the battlefield.
** GetCollectionByPatternIndex() on externaldata now takes a new ExternalDataRetrieval enum, which can either be CreateIfNotFound or ReturnNullIfNotFound.
+
** The tesla effects are also back, but again more thin and more reasonably sizedWe may need to look into scale on these some in the future at some point.
** The default used to always be CreateIfNotFound, which was nonobvious and was causing things like scourge data to appear on non-scouge unitsBut very likely it was also causing all sorts of other data to be erroneously initializedThis wouldn't have broken anything, but was certainly bloating savegames prior to this version.
+
** For the flak effects, they do seem to be strangely crunched down on themselves compared to what we were seeing in our videos, but we'll have to investigate that at some point in the future.
** For reference, all of the methods for getting these are expected to follow this sort of pattern: GetScourgePerUnitDataExt( this GameEntity_Squad ParentObject, ExternalDataRetrieval RetrievalRules )
+
** Thanks to TechSY730, Badger, Isiel, Puffin, and Corpserule for reporting.
*** In the main game and first two expansions, this led us to having to correct 112 locations in 26 files.  That in turn required another 705 secondary fixes.
 
**** This may seem excessive, but being able to verify that we are correctly initializing data only when needed is a worthwhile goal, and it makes code clarity so much greater.
 
*** There are a variety of places that this may make a difference based on our changes thus far (aside from whatever bugs we have introduced):
 
**** Reinforcement spawning may be more correct nowThere was previously some logic that may never have been hit if it was originally pointed at a non-sentinels faction, but now it will hit it.
 
**** AI sentinels data will no longer be put on every faction during the post-victory achievement check.  That was likely causing some problems (which someone had put a mantis report about post-victory slowdown and exceptions, so it's possibly related).
 
**** When checking faction intensity in general, a whole host of wrong data collections are no longer created on random factions.
 
**** Several things about astro trains can no longer cause accidental data on wrong factions.
 
**** If astro trains that should be spawning AI waves or adding to the AI budget are pointed at a wrong faction, the data no longer goes into the void but instead an actual error pops up.
 
**** Several hacks will now show exceptions rather than throwing their data into the void if they are pointed at wrong factions.
 
**** There are a wide variety of places where the AI difficulty or AIP of an AI were referenced, and which might now throw a nullref exception.  If any of those DO, then that is actually a good thing, because in the past those have silently been returning 0 for both rather than using real numbers.  If neither of those cause any errors, then that's even better because we know our other code has been correct already.  Fingers crossed for more of the latter than the former.
 
**** Any time any fireteam was disbanded, all of its units were assigned blank scourge external per-unit data.  Fixed.  Oh, actually every time it looped over the units in a fireteam.  Fixed that, too.
 
**** ExoData is no longer added to every last faction in the game (notifications checks were causing that).
 
**** It's possible that some tooltips or notifications might throw exceptiosn now, particularly if you load a savegame and mouseover them before unpausing.  If these throw exceptions, then basically this is a case where it would have been gibberish data previously, so it's still useful.
 
**** Various pieces of code like "don't run the nanocaust info if it's not set up" will now work as their programmers likely originally intended.
 
** This probably introduced a number of new bugs from typos, along with whatever bugs it uncovered, so this is why we're heading back into the beta branch temporarily.
 
  
== Version 2.500 Multiplayer Alpha Begins Now! ==
+
* Fixed a variety of sync exceptions for multiplayer that would cause duplication of various things on ships:
(Released September 9th, 2020)
+
** The ships granted if they are hackable, etc.
 +
** The amount of damage dealt to ships of various death-types.
 +
** Various data relating to AI reinforcement points (guard posts, etc).  This was not endlessly duplicating, but was causing some funkiness.
 +
** The incoming shots.
 +
** Various things with forcefields protecting a ship.
 +
** Various bits with where an AI ship thinks it is guarding something.
 +
** Any techs that were granted by hacking a ship.
 +
** This should handle all of the cases that people have reported, plus some things that were not visible to people directly.  Please do let us know if you see more of this!
 +
** Thanks to Puffin, Arides, Daniexpert, jrad, SilverLight, and others for reporting.
  
* Removed some extra code that was accidentally included that was preventing the new findp command from being able to cycle through planets properly if there were multiple matches.
+
=== More Performance Improvements ===
** Thanks to cml for reporting.
 
  
* PlayerAccounts are now also passed to cheats/commands (not to be confused with gamecommands), so that now if there are multiple people in charge of a single faction, commands that are sent can affect just one of the players if needed.
+
* A new version of our internal ArcenCharacterBuffer has been added, which now wrappers a StringBuilder and uses many of the benefits that has been added to that class over the years.  The performance of adds and updates should be a couple of orders of magnitude better than what we've had up until now, making large interface elements more responsive.
** This is now used for the findp command, which lets two players share control of a single faction without the findp of one player affecting the other.
+
** Though in fairness, we don't use too many ArcenCharacterBuffers, it's mostly another class which will also be updated.
 +
** Thanks to NR SirLimbo for benchmarking all this and figuring out where there were some major slowdowns with this.
  
=== Multiplayer Readiness In The UI ===
+
* A much more substantial performance boost has been achieved by replacing ArcenDoubleCharacterBuffer's internals with a new approach that uses a mix of StringBuilder and our own form of logging of "WrittenValues."
 +
** This makes really long text displays that are continually updated much faster (before they would take you down by 10-20 fps on a fast machine just for viewing them), and that includes really large tooltips.
 +
** This also seems to make the game load a bit faster, and also in general makes the UI generate faster all over the place.  It seems to be around an 8-10 fps bump on a very fast dev machine.  Slower CPUs should get more benefit.
 +
** On the escape menu, under the memory pooling section, there is now a "Texts saved" versus "texts new."  In under 1 minute of just sitting there and moving around a bit, we wind up with values of around 500 new, and 500,000 saved.  That's.. substantial.
 +
** Based on testing by NR SirLimbo, all use cases of this are faster, but in general the average improvement in speed is using 98% less processing power to draw text than we used to (and the processing power was nontrivial).  The load time of the game itself has also improved by at least 2 seconds for most of the faster machines, and maybe more for slower ones.
 +
** Thanks to NR SirLimbo for sparking this line of inquiry.
  
* The multiplayer button on the main menu now has a small bright "Now in public alpha!" tag on it, to make sure no one misses that.
+
=== Visual Improvements ===
  
* In the multiplayer section of the main menu, a new "Alpha Testers: Please Read!" button has been added.
+
* On February 4th, 2020, we had an accidental regression that caused the "ship placement" material, and the under-construction and under-construction-stalled materials to all lose their shaders and some of their textures.  So when we tried to draw units with these visual effects on them in the game, they would just be invisible (icon aside).
** This has a tooltip that says:
+
** This was during a larger purge of some unused shaders and textures, and had this as an unfortunate casualty.  We've now restored those items, and things from those areas should "just work" again in the next version.
*** Click to open a web browser that explains the current state of the multiplayer alpha (that changes almost by the day), as well as questions for testers (also get frequently updated), a history of recent improvements to multiplayer categorized by date, and a list of work items that are upcoming.
+
** Thanks to a lot of folks for pointing out that this had gone missing, including RabidSanity and Mckloshiv.
*** Most important of all: if you are running into problems, please take the time to report them to us, rather than assuming someone else will report it.  That is absolutely the most helpful thing we can ask for.
 
** And its link goes here: https://wiki.arcengames.com/index.php?title=AI_War_2:Multiplayer_Alpha_And_Beta#What_Does_Multiplayer_Alpha_Mean.3F
 
  
* At the top of the networking section of the personal settings menu, there used to be an option called "Enable Multiplayer Alpha"
+
* Arcen "Death Chain Effects" have long been used for things like flak hits and tesla attacks.  However, they were entirely scripted and robotic, before.  The only difference between one playback and the next was the rotation of the entire effect.
** This had warnings about how multiplayer alpha was not ready, but that you could click this to enable it anyway.
+
** We've now added a tremendous amount of randomization in how these play out, including to the position and scale of their sub-components, how fast they move through their animation per explosive, and things of that nature.
** This option has, happily, been removed!
+
** The end result is that we're now able to make a single death chain effect look a bit different every time it plays, for almost no extra processing power, and so the entire battlefield will look way more alive and unique when these things are happening in large numbers.
** Previously, if that option was not enabled, then clicking the Multiplayer button on the main menu would show a popup with a message from Chris explaining the current state of multiplayer and projected timelines.
 
*** That message has been removed, and clicking the multiplayer menu now just opens it, again, happily.
 
  
=== Included Mod: Civilian Industries Pre-Multiplayer Finalizations ===
+
* The shader that we use for our "death effects" for AOE damage, most notably flak explosions and lightning explosions, has been rewritten to use a custom lighting path rather than using surface lighting.
 +
** When we redid our lighting pipeline earlier this year, it unintentionally made all of our death effects of this sort look TERRIBLE. 
 +
*** Essentially, they were showing up for a bit before visually appearing, in kind of a ghostly form, and they were also then showing up a lot more white than they should have been.  This was them interacting with the HDRI reflection cubemaps that are now in the scene.
 +
** The new version of the shader looks better than the old one ever did even pre-lighting-update, and no longer has any of the above issues.
  
* Final optimizations for Multiplayer, touching up loose ends.
+
* The flak explosions have been completely reworked to the point that they are almost unrecognizable. 
 +
** All we've done is adjust the shaders and the randomization of the chain effect, but this went from an effect that made us cringe to one that we'd love to see in massive quantiles taking out our foes.
  
* Many nerfs in regards to AI Raids.
+
* Plasma AOE explosions are far simpler than the flak explosions, since they only have one main body of the explosion, but that's no reason for them not to look cool.
** A 20-40%, based on intensity, reduction to AI Raid strength.
+
** We've introduced some new variance into this effect, and in general made it look better, so that now it has a distinct "rush and pop and slowly fade into wisps" feel to it. With the speed and details being randomized, this definitely brings it to the next level.
** A roughly 100% longer warning before they fire.
 
** They now only spawn a singular wormhole per planet.
 
  
* Large scale Trade optimization
+
* The tesla AOE effects, both the "guardian" level and the "regular" ones, both look vastly better now and way more like lightning.
** The Grand Station will now output a larger amount of cargo ships on demand.
+
** We made a video showing off all the new effects in the editor!  https://www.youtube.com/watch?v=mhJjPabV3gM
** Many more Cargo Ships can accept trade routes every second.
 
** Trade Stations will no longer be built on planets that construction ships couldn't safely reach from the Grand Station's planet.
 
** They are now much smarter about stockpiling resources for local militia use before exporting them.
 
  
* Additionally, a large number of undocumented bugfixes that were lost in the surge of all these multiplayer-based updates.
+
* A new "Victory" fire text has been created, for purposes of being used like the "you have lost" text that can happen when you lose.
** The most notable fix is a fix to the Exception that could pop up when mousing over the Raid notification.
 
  
=== Multiplayer Sync V1.0 ===
+
* When you lose the game, it once again shows the "You have lost, humanity has perished" message in big burning letters.
 +
** That lasts for 7 seconds, and then immediately after that you go to the loss screen.  This makes it so that the transition to the loss screen is not so abrupt.  Plus people liked the text.
  
* Added AddBytesWithFormatAndColor() and AddBytesWithFormat() for writing bytes nicely to an ArcenDoubleCharacterBuffer.
+
* When you win the game, it now says "VICTORY" in giant fiery letters, rather like the "You have lost" for when you lose.
** This cuts down on our repeat code for easy formatting of things that might be in bytes, KB, or MB.
+
** This one waits only 4 seconds, and then transitions to the normal victory screen.  This again makes the transition a bit less abrupt.
  
* There is now some basic sync stats that will show in the escape menu during multiplayer, and then more detailed sync stats that can be turned on at will.
+
== Version 2.634 Multiplayer Solidification ==
 +
(Released November 18th, 2020)
  
* New setting in the network section of personal settings: Show Network Sync Details In Escape Menu
+
* A new planet naming scheme, Oddball, has been added to the game:
** Only applies when you are in multiplayer, and has different outputs on the host versus clients.  Gives statistics on how much the game has had to correct in terms of divergent data between the client and the host.
+
** Aims to give a sense of history. One heavy with warfare and bored scout captains. Created by Kizor. Thanks to Loweko, R. Jean Mathieu, Vornicus, McMartin, Reiver, Quasispace, Derakon, Kyoshyu, and the anonymous.
** Note: The PKIDs and squads are actually checked for divergences, and those are shown in more detail on the client than the host. All the other things are sent in a periodic overwriting fashion, without checking for divergences, as the bandwidth used (which you can see with this setting on) is less disruptive than the CPU cycles required to do divergence checks.
 
  
* The width of the columns in the escape menu are now a little wider.
+
* Several updates to journal entries for extra lore details.
 +
** Thanks to Puffin for writing these!
  
==== Fixes Based Off Testing Initial Implementation ====
+
* The sabotage hack, when there are multiple viable targets on one planet, now includes the text:
 +
** Whichever of these is closest to the hacking unit will be the one hacked, so park your hacker right near the target you intend.
 +
** Thanks to Daniexpert for suggesting.
  
* Fixed a bug where the client in multiplayer was incorrectly calling a host-style method when trying to tell the host about divergences in squad sync.
+
=== MP Performance Boost ===
  
* Fixed a bug in multiplayer sync where the squad sync stage would never complete or advance beyond the first 20th of the squads, instead just doing those ones over and over again.
+
* Previously we had a rate limiter in place for only checking if background work threads were done if it had been at least 50ms of time since the last check.  This is not a super expensive check in the grand scheme, and we'd rather react to these being done as fast as possible in order to avoid small timing discrepancies causing larger delays in sim cycles kicking off or moving to the next frame.  So for now we've just entirely taken the limiter off, which should have only positive effects from what we can tell.  The limiter was originally put in place out of an abundance of caution, when we were not sure how slow it was to call ThreadState on threads.
 +
** Update: apparently this actually majorly cuts down on multiplayer lag and small jitters.  This tiny bits of timing really add up when you have to wait on the other computers in particular.  What a lucky find!  This would have taken us ages to figure out if we'd actually been looking for it, but instead we found it while fixing the flickery dropdowns.
  
* Fixed a minor bug in multiplayer where the client was telling the server about mismatches even when there were none (just sending an empty list to them).
+
=== Bugfixes ===
  
* Fixed a one-line bug in multiplayer sync that hilariously just caused all of the ships on the client to be deleted within a few seconds of playing.
+
* When a client is getting sync correction data from a host about entities, there were several cases where it could detect some invalid data, and it would then throw a visible error... but it would also just keep trying to process this now-known-bad data, and thus run into further problems.
 +
** Now it actually stops processing all of the sync fix data from that batch, and logs warnings into the log silently.  This way we can go back and find them if need be, and certainly if your log is filling up with these that would be bad.  But these will not affect the running of the game (just how rapidly sync correction happens for this specific batch of units), so they are starting their lines with "Not fatal - just a warning" to be extra clear on that.
 +
** There were various errors that would show up after these, previously, that were simply a matter of "hey, bad data was sent, but we tried to parse it anyway, and of course that went about as well as you could expect."
 +
** Thanks to Daniexpert for reporting.
  
* Put in extra debugging for Client_AcceptDivergenceDataFromHost(), since it was having some exceptions happen.
+
* On the host in multiplayer, it now does a last-minute check to see if it's about to send the sort of mangled data for a ship that would cause the client to have to do the sort of toss-out of the entire batch that the clients were doing in the most recent fix.  If it finds that it is, then it should now just skip that unit and leave it for a future sync pass.
** In general at the moment, actual divergent ship data is coming across slightly garbled.
+
** At this stage, we can assume that maybe the unit JUST died on the host, and so within 2-4 seconds the client and the host should get synced up properly regarding it.  But in an abundance of caution, there's always the chance that actually this unit is still alive, but just was changing planets or something, so let's not tell the client to delete it just yet.
 +
** This sort of scenario should be an edge case, but the idea here is that we make it less likely than the client would have to throw out an entire batch of divergence data, and instead just the one problematic ship will get re-evaluated next cycle and we don't even need any bad log messages about it, etc.
 +
** Thanks to Daniexpert for reporting.
  
* Temporarily disabled the planet and world-extras sync steps in the multiplayer sync code, as those both were throwing errors on the client side.
+
* Fixed a minor bug in the macrophage, which nobody has ever even hit, where if the king was not found it could wind up having some pathing errors unless you had debug flags on.
** With those disabled, we can see that the ship sync, fleet sync, and "ultra frequent" sync all seem to be not only working great, but also not sending too much data and not slowing the game simulation down.
 
** The garbled divergent ship data is a bummer and does mess with things, but in general it just speaks to our need for better instrumentation in that area, and is not entirely unexpected.
 
  
* A new setting has been added to the networking section of personal settings: Log All Decoded Network Sync Data To Disk
+
* Fixed a really rare bug with the Zenith Trader where, two seconds into the game, it was theoretically possible for multiplayer clients to get a nullref exception when the trader was trying to spawnNo one actually hit this yet.
** Will majorly slow the game down, but dumps decoded sync messages to the disk in files inside the PlayerData/NetworkSyncMessages folder.  This only covers sync-style data, but with this logging enabled on both the client and host, this is a great way to see why serialization is failing, if it is. 
 
** Enable with care!  Since this data is being actively decoded as it is written, it is far larger (and in plain text) than the actual data being sent across the networkA typical ratio might be 40MB of decoded data for 500kb of actual network traffic.  You can have a few GB of data on your disk after just a few minutes of letting the game run in this fashion.
 
  
* Using this hefty new tool and some extra instrumentation, we were able to locate and fix the problem with the sending of divergent ship data from the host to the client.
+
* In multiplayer, on the client, if findHumanKing() cannot find a result, it no longer throws any form of error (they were silent errors in the log, before).
** We were simply omitting the primarykeyID for entities that were different, not deletedThings like that are easy to miss but almost impossible to find without a logging mechanism like this. Manual code review just leads you to look right past it, especially if you've been staring at it for days.
+
** Essentially, sync data must be slightly off, and that is fine and something that we should just ignoreThe host will take care of giving proper orders to ships, and the client will find out about that soon enough and have all its data corrected anyhow.
 +
** Same logic on findAIKing().
 +
** Thanks to Daniexpert for reporting.
  
* Did a bit of an overhaul on how some of the network sync data is logged, so that we can do a folder-at-a-time comparison to find differences where any may exist.
+
* Some of the data for how things that use internal build points (for things like viral shredders in particular) was being set up on the fleet memberships, and cached there as well.
 +
** Now it sets it up once only, at game start, in ComputeBalanceStats_OneTimeOnly().  This is more efficient, and also gives us errors on load if our xml is wrong, and also fixes a compatibility problem.
 +
*** There was previously a bug in multiplayer where viral shredders would lead to endless exceptions on the client because it was missing the extra cached data on the fleetmem, ouch.
 +
** As an additional bonus, we are no longer storing this data on fleet memberships in general, which means we no longer have to serialize and deserialize that.
 +
*** The fact that we WERE serializing it was making the question of the exceptions in multiplayer even more confusing, but at any rate now some sync data and all savegames will be a tiny bit smaller.
 +
** Thanks to Daniexpert for reporting.
  
* Server_SendBatchOfSyncsBasedOnCurrentSyncStage() now has extra debugging going on in itself, because we're experiencing some sort of errors in there on the host after a certain amount of time in multiplayer, now.
+
* MP clients in general will no longer throw any exceptions related to things with internal build points on their fleetmems.  If something is off, it will just let the host take care of that and inform them within a few seconds.
** Thus narrowed the problem down to Server_SendPeriodicFactionSyncDataThatJustOverrides(), and so instrumented that a lot more thoroughly... except actually the problem was in Server_SendBatchOfDivergentSquadsToFix(), we just read it wrong.  So that also got extra instrumentation.
+
** However, the error will still happen on the host if something is messed up, but it will be more informative and not block the rest of the execution of this fleetmem per-second cycle.
*** And that was, in turn, just a simple typo on one line. Logging and instrumentation makes the impossible and time-consuming very fast and easy -- after the initial setup time cost.  Very much worth it.
+
** And based on the fix above, this should now just work properly in general on clients, but we prefer an abundance of caution.
 +
** Thanks to Daniexpert for reporting.
  
* Found ourselves back with another error in Client_AcceptDivergenceDataFromHost-DivergencesSection.  But we can't quite use the logging as it currently exists to easily diff these on a folder level.
+
* Previously, in multiplayer if there was a reroll hack that was done, it would give a different result on the client and the host.
** In order to make that possible, we are switching away from using a central LogIndexThisSession Int64 for all message types being sent to StartNetworkSyncDataMessageLoggingIfNeeded, and instead are having an individual index for each FilenameBase string.
+
** That has been corrected by making it so that on the host it now calls FlagAsNeedingForcedFullSyncToClientsJustInCaseIfInMultiplayerAndWeAreHost() on completion of the hack, which is the general standard that we should be aiming for with this sort of information in the future.
*** This puts things slightly out of chronological order when we're talking global messaging, but that's because the client and server can be talking back and forth and have some different ordering between message types. We need the message types to always match up, and now they will.
+
** This applies to the ARS, FRS, TV, and GCA.
 +
** There is a slightly-more-automated fix for this that doesn't require individual mod-author (or faction-designer or unit-designer) input, but this is still a good idea to do.
 +
** Thanks to a variety of folks for reporting this, including Arides, Daniexpert, and others.
  
* Discovered that we were not properly sending the TypeData of the ships in the divergent ship fixes messages from the hostThis was then causing nonsensical errors later in the deserialization of those messages.
+
* Apparently it is possible to get an exception when hovering over a tech tooltip in multiplayer.  This has not yet been fixed, but now when it happens it will be sure not to be destructive to the rest of the game, and it will give a far more detailed error messageRight now we really have no idea what the actual error is, but this will at least contain it and let us fix it after we have a new report in the next release.
** Another great example of something we would not have found, potentially at all, without the new instrumentation.
+
** Thanks to Daniexpert for reporting.
  
* Discovered a harmless logging artifact that we introduced into the last few versions where the header for fireteam data was behind its id on one machine, but in front of it on the other.
+
* TextEmbededSprites now have a few new capabilities:
 +
** The scale float xml parameter allows you to set the scale of a sprite relative to what it would normally be (default is 1.0).
 +
** use_geometry_queue as an xml parameter allows for you to make a for-the-galaxy-map-by-planets-text version of sprites.
 +
*** If this is set to true, then those versions of the galaxy map sprites will be vastly more efficient and will dynamically batch as we set up last build.
 +
*** If this is set to false, then this is for use anywhere else in the GUI, including the header and tooltips and whatnot.  If this is set to true and you try to use it in the interface elsewhere, it will be invisible, as we discovered yesterday.
  
* Thanks to the logging, also discovered an inconsistency in how fleet data was being updated, which was causing those to choke and die on the client side.
+
* Using the above, strength icon is now properly batched on the galaxy map (as with last build) but all of the other sprites being drawn in the GUI now actually draw visibly again (unlike last build).
 +
** Also, while we were at it, we adjusted the scale of the strength icon to be 0.9, since it was a little bit on the large size in most text.
 +
** Thanks to Badger, Daniexpert, TechSY730, and Crabby for reporting the invisible icons in the GUI.
  
* Went ahead and re-enabled the world-extras and planet syncing, since those go wrong so quickly but we now have logging on for them.
+
=== MP Sync Improvements ===
** That immediately errored, but that is just fine for our purposes.  Can you tell logging makes us happy?
 
** This quickly revealed that there was something funky and inconsistent with how we were reading the planet's type.  That has been fixed to be consistent.
 
** That then revealed something a lot more complicated was wrong with how the external data patterns were being read in general, most notably on the world but definitely not limited to that.
 
*** We improved the logging and instrumentation on the external data pattern serialization in general, and this then solved the issue on the world and the larger issue as a whole that would have come back to bite us in many other areas later.
 
*** Then put in some more logging related to MDCExoDataExt, since it seemed to have an inconsistency.  We now are marking when ExternalData is complete in the log, to make that mistake harder to make.
 
** Then found and fixed yet more inconsistencies in how we were syncing squads.
 
*** Also we then stopped syncing some stuff that was set to "only save on the network" (and not to disk) for squads, but it was data that really really should not have been synced because it was working fields from other threads.
 
** And then also fixed a random extra float that we were sending after "world extras" sync.  It's the sort of thing you only see in a log, as it was invisible in the code.
 
  
* We are no longer syncing the IncomingShots on entities except during the initial world sync, because in general we are not syncing shots.
+
* During multiplayer, if there is a hack happening, then every second where something is changing, the host does an extra forced sync of the hacker and the hack target (if there is a hack target) to all clients, thus keeping them all in the loop.
** This is going to take some refactoring for targeting, possibly, but then again existing code will very possibly just adapt to it. 
+
** This is central and automated, and should probably actually catch cases like "something was different after a hack between the client and the host" even if the end programmer/modder/etc doesn't account for it fullyThis is just a handy new feature in general!
*** "Catastrophic" or "planet switch" styles of sync fixes are probably not frequent enough during combat for it to be too very wrong, but either way things will fix themselves within a rolling 3-4 second windowIt's interesting, because its constant attempts to heal itself in various places, while "in battle" with attrition is reminiscent of a scene with Wolverine in X-Men 3.  That's an amusing thing to realize about one's code.  (Let the record show that the devs really don't like X-Men 3, but that one scene was visually neat).
 
  
* Fixed some potential nullref exceptions in CalculateSpeed() on ships, which really at this point mainly would happen when ships or fleets or speedgroups or some combo of that were being updated at the same time as they had something going on in the background threads.
+
* When units are claimed, or when they complete construction for the first time, there is now an automatic forced full sync of that unit from the host to the clients.
** Basically there's a whole new nest of cross-threading errors that we can run into, but there's not much we can do about them except to harden individual methods as they come up with problems, and in general also add extra instrumentation to methods if we think they have the potential to be a problem again (this one does).
+
** This gets rid of a lot of potential desyncs that otherwise could linger for a bit.
** This is kind of an unavoidable element of the loose way that we handle threading, which is needed in order to get the maximum speed out of the simulation and all the various threads that are involved.  The client side of network sync is now a new source of these issues, but it's not remotely the first of them.  We'll probably be swatting this sort of thing down throughout the alpha and beta of multiplayer.  And then SirLimbo will somehow find a way to run into exceptions that no one else sees for the next two years. ;)
 
  
* At this point we can confirm, based on our detailed logging, that multiplayer is able to successfully run for a solid four or five minutes of gametime (at 5x sim speed) and come out with consistent results the entire time.
+
* The ability to set the importance of intel tab entries is now shared among players in multiplayer.
** This leads to about 2600 network log files for the sync messages, which are about 100MB per computer, and this substantially slows down the game from running at an unencumbered pace (the disk writes are heavy).
+
** This was previously set up to only be local, kind of by accident.
** Of course, as soon as we turned off the logging, we ran into some sort of new gameplay thing which caused issues in the ship sync codeSo there are still some goblins in there, probably related to certain types of data that are not on every ship.
+
** This has some code to keep it nice and responsive as if it was still just a local change, but if you click really rapidly on the same intel entry and cycle it through, you may see some slight funkiness to thatShould not be a big deal, but we'll see.
 +
** Thanks to Daniexpert for reporting.
  
* Added a new setting to the network section of personal settings: Log Decoded Network Ship Sync Data To Disk
+
* FlagAsNeedingForcedFullSyncToClientsJustInCaseIfInMultiplayerAndWeAreHost() has been renamed to FlagForForcedFullSyncToClients_FromHost().
** Same as the 'Log All Decoded Network Sync Data To Disk' setting, but only writes data for actual divergent ship fixesSince that is one of the more-likely-to-break areas of sync, but only something like 1/15th of the actual data being passed around, being able to isolate it to this is helpful.
+
** Added a new FlagForRequestedForcedFullSyncToAllClients_FromAnyClient(), which lets clients request updates on an entity rather than the host having to tell them.
 +
** Both of these calls remain utterly impact-free when we're talking about calling them repeatedly, or calling them during single-player.  They intelligently weed out extra requests, and don't do any substantial processing directly.
 +
** The FlagForRequestedForcedFullSyncToAllClients_FromAnyClient() method in particular throttles itself so that a fresh flag can only be set on a given entity on 1 second intervals.  So if the client is repeatedly asking the host for updates on an entity, that's just fine, but it will only get results on that given entity once per secondOther entities may be requested inside that timespan.
 +
** The upshot of this is that, whenever you look at a ship or structure as a client, by hovering over them to see the tooltip, you immediately get a refreshed copy from the host (within 100ms or so at the most, probably less, so too fast for you to notice), and then every 1 second after that you get further updated info.
 +
*** There's a lot of extra data that is stored normally only on the host.  That gets sent to you as a client when you first connect, but it's mostly stuff happening on background threads and affects faction decision-making.  Some of the DLC2 factions gather various resources that you can see in the tooltips, for instance.
 +
*** Previously, before this addition, clients would just have incomplete tooltips.  Now their tooltips are updated with host data as-needed, and already the behavior of those sorts of ships would be updated by the host (so if you're not hovering over something for a tooltip, it will still act correctly; and you don't need the extra data in the tooltip unless you were to hover over it).
 +
** The other side effect of this is that if you feel like maybe there's a sync error with some ship or structure, and you go to hover over it to check that out and see for sure... it's going to instantly fix itself.  So do be aware of that, though it's more or less a good thing.
  
* Fixed an issue where the current galaxy map display mode, and the current planet index you were viewing, would be reset by the sync data on clients in multiplayer.
+
=== UI Improvements And Fixes ===
** It now takes in that sync data only for non-local player accounts.  Clicking to another planet only to have your view bumped back a second or two later was MILDLY frustrating, heh.  And also slightly hilarious.
 
  
* Discovered and fixed an issue where if a partial sync was sent from the host to the client about a ship that the client had no knowledge of, then the client would try to read it as if it was an off-disk sync and thus read things incorrectly and fail.
+
* The concept of "Update Cycles" in the ArcenUI framework has been removed.
** This will probably be elsewhere in the code as well, so we will potentially need to review a lot of other data structures.
+
** Instead we are basing things on ArcenTime, which was developed after the initial design of the ArcenUI.
 +
** This in turn lets us have reactions which are framerate-independent, which is thus more consistent across machines.
  
== Beta 2.134 Searching For Planets ==
+
* Using the above shift, plus also an extension to allow dropdowns to properly handle tooltips even on their "off frames," we have fixed the flickering dropdown tooltips that were introduced in the last update of the game.
(Released September 7th, 2020)
+
** Thanks to Daniexpert for reporting.
  
'''This one is still on the beta branch on Steam and GOG, since we have continued making lots of substantial changes to the central serialization logic for the game in service of the multiplayer sync codeWe're now done with what would constitute V1 of the MP sync code, so we can come out of the beta branch tomorrow so long as no one runs into any problems with single player on this build. As for multiplayer itself, we have a fair bit of testing to do to make sure that the MP sync code is doing its job and not exploding RAM usage on the clients or harming performance, etc. Once that's verified and all the bugs we find in testing the MP sync code are fixed, then we're officially into an alpha status with multiplayer. Given that the V1 of our sync code turned out to be far more thorough than we originally planned, the multiplayer alpha period should hopefully be shorter than it would have been.'''
+
* Various lobby dropdowns have been improved as follows:
 +
** The tooltips for map type planet count entries still retain the header text of what you are doing.  Also, colors for the selected vs potential items has been added.
 +
** The tooltips for the planet naming types are a bit more clear in general, and it now shows the name in a line above the description for extra clarityAlso, colors for the selected vs potential items has been added.
 +
** The tooltips for the map types explain themselves a bit better, include the name of the map type, and have the new colorization.
 +
** Tooltips for the map linking flavor and planet layout and such now match the others in function and colorization, including showing the details of currently-selected item when you hover over the closed dropdown for the first time.
 +
*** Also discovered a special discrepancy in how these were being handled that was causing these to still flicker like crazy even after we fixed dropdowns in general.
 +
**** Also found and fixed this on all settings on the personal settings window, although all other windows seemed to be okay.
  
* Extragalactic war ships are no longer classed as 'small' when hovering the Planets Under Attack notification
+
* Put in a fix that will prevent dropdowns in general from using the code combination that leads to flicker:
** Thanks to crawlers for the bug report
+
** Essentially, HandleOverallMouseover() has been removed, and you should now use HandleMouseover() for that, and continue to use HandleItemMouseover() for items.
 +
** We are able to control how this flows properly and remove the flicker, whereas before if someone used HandleMouseover() by mistake -- when they were supposed to use HandleOverallMouseover() -- then they would get a flicker.
  
* The Dyson Sphere produces a small number of drones, as well as its usual ships. Those few drones no longer leave the sphere's planet
+
== Version 2.633 Roaring Performance ==
** Thanks to GreatYng for reporting
+
(Released November 17th, 2020)
  
* Update the time estimates for releasing multiplayer and DLC2
+
* Civilian Industries Update
** Thanks to ParadoxSong for reminding
+
** Put in some defensive code to prevent potential pathfinding lock ups when multiple civilian factions are in play.
  
* There's now a Journal entry for when the AI can send extragalactic war units, so they won't come as a surprise
+
* When hovering a Flagship, the 'max possible strength' value in the tooltip is now colour-coded to let you know what percentage of that strength currently exists. So if your fleet has taken heavy losses, the Strength colour will be darker. If you are at full strength it is brighter. This matches the behaviour of the tooltips for Factories.
** Suggested by zeusalmighty
 
  
* Fix a bug where the Helping Hands 2 quickstart was broken
+
=== Performance Improvements ===
** Thanks to Spook for reporting
 
  
* QoL tweak for repair. Any ships on a planet where you outnumber the enemies 10 to 1, or the enemies have less that .2 strength are eligible to be repaired immediately.
+
* On the main menu scene, improved the culling mask on the scene-view camera to greatly improve efficiency of that scene.
** The previous rule was 'Any ships on a planet without any enemies' which could be frustrating if you were trying to hunt down a few cloaked ships.
+
** It looks like the main menu may have been accidentally drawing 1.8 million tris rather than 800k tris because of this being set wrong.
** Thanks to crawlers and Isiel for suggesting
 
  
* Some minor tutorial tweaks
+
* The reflection probe on the main menu scene has also been updated to have an appropriate culling mask, for the same reason.
** Thanks to MasterGeese for reporting
+
** The reflection probe updates, which are quite heavy and frequent, should also thus be correspondingly faster and draw so many fewer triangles as well.
  
* The extragalactic war spawning notification message now uses 'a' and 'an' appropriately
+
* Poly few has been employed on the main menu scene to combine all of those meshes of the hangar into just a single mesh with 16 submeshes for the various materials.
** Thanks to Ovalcircle for reporting
+
** This cuts the number of draw calls on the main menu down from about 3000 to about 250.  The visual end result is identical.  The performance gain is potentially massive, but varies heavily by hardware.
  
* Update the Description for the snake map to mention that it's very hard
+
* We have historically had static and dynamic batching disabled for this game, because we use GPU instancing instead (which is far more efficient and direct).
** Prompted by a discussion on the forums
+
** However, when we made the new main menu, we had implemented things such that this type of batching would be useful there, so we turned it on.
 +
** We have now changed things around again to remove that, and so once again removed those from being on in the application as a whole.
 +
** It's quite possible that these were dragging down performance on some machines in general, as the game may have been spending some CPU cycles fruitlessly looking for things to dynamically batch during the main game itself.
 +
** It's irrelevant to the end result of how things look, but there's no chance of that popping in and impacting performance negatively anymore, which is good.  If it wasn't a performance impact, then no worries there, either.
  
When you have the galaxy setting for Adjacent Planets Watched, it now takes that as the baseline and is increased by things like Economic Command Stations and Spy Cradles.
+
* Using Blender, we've manually removed some off-screen sections of the main menu meshes. This has overall reduced our polygon count in the game on the main menu by another 300k or so triangles.
** So if you have "Watch 1 adjacent planet" then a military command station will watch 1, but an economic will watch 2
+
** This sort of hand-optimization is something that we had been saving until it was clear this is where the bottleneck was, and after it was clear that the new main menu was a winner (and that we had time aside for it).
** Thanks to ParadoxSong for suggestion
 
  
* Small update for MoreStartingOptions by AraudB:
+
* With these changes, on Chris's main two computers he sees:
** Inordinate had 10 plasma turrets rather than 2. Fixed the number of stations in the mod description too.
+
** On the main menu on his main dev machine (GTX 1070 and a few year old i7 laptop) a jump from about 55-60 fps to instead being about 100fps.
 +
** On the main menu on his MacBook Pro from late 2013 which has an i7 but does not meet the minimum system requirements in general, it jumps from 26fps to... 26 fps.  So there's a different limiting factor other than polygon count or draw calls on this ancient of hardware.
 +
** Most likely, any machines that are actually meeting the minimum system requirements, or vaguely approaching the recommended, environment, should see a substantial performance bump on the main menu. And for everyone, the disabling of the static and dynamic batching may improve performance beyond the main menu.
  
* Removed a blank "Fleet Experience" section from the tips window.
+
* In our main menu scene, the way that the reflection probe is update has been changed fairly substantially.
** Thanks to Isiel for reporting it.
+
** Previously it was every-frame every-face if you had at least 30fps, and every-frame individual-face if you had at least 15fps, and below that would not update over time.
 +
** The individual-face updates were really jarring, however, and not something that is a good idea for any sort of smooth feeling.
 +
** Now only if you have at least 50 fps will it do every-frame every-face updates, and below that it will just not update over time, instead only having the reflection from the initial onawake event.
 +
** On Chris's main machine this makes no difference since it runs at 100fps now, but on the under-min-specs OSX machine this brings performance up to 31fps from the previous 26fps.
  
* Several different spots that could throw errors if fleet membership was null now no longer do.
+
* On the main menu, a number of lights were set to affect more than just the Scenes layer.  This probably did not affect performance, but we are correcting that anyhow.
  
* DoEntityStepLogic_Ship now has better debug logging.
+
* On the main menu, we had one extra spot light that was drawn in a not-important weighting, and that was very dramatic and looked good in general BEFORE we started having ships with lights on them moving around.
 +
** Since having ships moving around, that spot light would disable itself as the spotlights overtook it, then re-enable itself, and the transitions were jarring.  It did not seem to affect performance much on the high-end or ultra-low-end machines, but in the middle-tier it might, also
 +
** This spot light is simply removed, as it was not needed for the new scene composition.
 +
** We experimented with turning off the point lights used on the ships, or even with turning off the reflection probe from being on at all, but the former gave 2fps on the super-old mac (from 31 to 33 fps), and the latter gave no boost at all.
 +
** Whatever is holding back the ancient below-specs mac is really not the sort of thing that is holding back the rest of the potential computing audience.  And this is one excellent reason why we have system requirements in the first place.  Not that 30fps is a cardinal sin; the original AI War was hard-locked to 20fps most of the time.
  
=== Multiplayer: Sync Correction V0.90 ===
+
* Added a new Performance tab option: Unrestricte UI Update Speeds
 +
** Normally, most UI windows only update their contents every 50-100 milliseconds.  If your framerate is much higher than this, however, you may prefer that the UI update at whatever your actual framerate is.
 +
** This will likely reduce your framerate, potentially substantially, but it leads to the ultimate in responsiveness.  Prior to version 2.633, and since sometime in the game's alpha, the UIs were all running on unrestribted update speeds.
 +
** We are not noticing any substantial benefit from this on our powerful machines, but on lower-end and middle-tier machines this may make more of a difference.
 +
** At the moment, things seem to perform equally well either way, but it's nice to put a lesser load on things where we can.  Since this does not seem to make a visual/feel difference that we can detect at the moment, this seems fine to have with a differing default from the past.
 +
** Thanks to Daniexpert for inspiring this change.
  
* Added a new SerializationCommandType, which has three values:
+
* In the ArcenUI_Element class, we have a SetActiveIfNeeded() method that long ago had some gating that was based on a cached wasLastActive in the class. 
** NormalFullType, Network_ContinuousPersistentSync, and Network_DuringDetailedNetworkSyncStage.
+
** This was working poorly, back in alpha or beta of the game, because of how unity handles commands to enable objects that are disabled in the heirarchy, and things like that.
** This is now used on Factions in order to differentiate the three major types of serialization that we might be doing.
+
** The game has now been updated to do a check against the activeInHierarchy property of the gameobject, which will always give the real result.  This should not result in bugs, and should in theory result in some slightly better performance in certain cases where large numbers of ui elements are turning on or off frequently.
 +
** We don't really see much of a difference based on this, but in general this was something we noticed that was an optimization we had wanted a long time ago, and being able to have a tamer version of that back in here now is nice.
 +
** Thanks to Daniexpert for inspiring this change.
  
* The ExternalData on factions is no longer synced as part of the "every frame" IsForNetworkContinuousPersistentSync.
+
* Over the last few months, as we've added functionality, the performance of the galaxy map has dropped notably.
** And actually a bunch of other stuff on factions is now limited out so that it's not over-saturating certain data while it IS still sending other things every frame auth.
+
** In combination with a much-more-recent performance drop related to how we draw sprites-in-text and how that affects the galaxy map only, full galaxy maps were down in the 25fps range and really choppy to move around, today.
** This is also of relevance because it means that any faction externaldata that is not fully optimized to not thrash the GC will inherently do less thrashing of the GC.  So that makes mods a little more safe in general in multiplayer.
+
** We've now restructured a lot of things to update in a time-sliced fashion, and the performance is now in the range of 90fps when zoomed all the way in, and 60fps when zoomed all the way out on a full map.
 
+
** There are still some performance improvements we need to pursue related to sprites-in-text in this specific instance, but those will be in the next build.
* Fixed several parts of the faction object to be efficient and not thrash the GC in the way that we were doing for the ExternalData last build:
+
*** We did experiment around with trying some things like adjusting the sprite-in-text shader to allow for GPU instancing, but that went absolutely bonkers in a way that we don't care to untangleThere's a better approach that we'll implement soon.
** TechHistoryEvent, HackingEvent.
+
** Thanks to Daniexpert for reporting.
 
 
* FromServerToClient_SendAllOtherSyncDataThatJustOverrides has been renamed to FromServerToClient_SendUltraFrequentSyncDataThatJustOverrides, because it no longer is "all the other data."  It's just the most common stuff.
 
** Added new new messages for time-sliced sending of the following: FromServerToClient_PeriodicFactionSyncDataThatJustOverrides, FromServerToClient_PeriodicFleetSyncDataThatJustOverrides, FromServerToClient_PeriodicPlanetSyncDataThatJustOverrides, and FromServerToClient_PeriodicWorldSyncDataThatJustOverrides.
 
 
 
* The full-faction-data sync even has been implemented on the client and the host, and now includes speed groups (which previously we felt like were too heavy to send on the ultrafrequent channel -- which was correct).
 
** This also means that we needed to make the SpeedGroups be nice to the GC on deserialization, so that's done.
 
** Also fixed several oversights that would have led to hard-to-diagnose endless inflation of array contents for various faction items.  Yow.  These sorts of things will be hard to find any other way than manual code review, and can be in mods or the main game and can cause massive slowdowns with no central way to diagnose itThese will be "fun" to find in the future.
 
*** Essentially lists like FactionIndicesIAmAlliedWith were being added to each frame without ever being cleared before the new set of data was put in.  This would only happen during multiplayer, and only on the client, but would start causing all sorts of problems.
 
  
* Planets and planetfactions and their externaldata have now gotten the same treatment that factions did.
+
* A whole messload of the new background images and other accents that are used in the new UI have been made vastly more efficient.
** Here again there were a couple of infinitely-expanding lists that are now fixed.
+
** This may actually vary by OS just how much more efficient they are, but in essence these are all now able to be stored in DXT1 format, and all of the ones where relevant now have mipmaps for more efficient drawing at smaller resolutions.
 +
** The amount of VRAM that this should save, and the extra load removed from the GPU pipeline, should be substantial.
 +
** Thanks to Daniexpert for getting us to look into this.
  
* Whew, okay, fleets and their memberships have also been updated to the new style.
+
* Discarded these changes: Rather than using raw "TextMeshPro" text renderers for the text that is shown all around the galaxy map, we are now using individual Unity GUI Canvases with embedded TextMeshProUGUI objects.
** This... is going to be very problematic, the way it currently exists.  This first checkin of the fleet memberships in particular is going to be very problematic indeed, for a whole lot of reasons, but it's a good start for refactoring.
+
** Visually this looks identical, but now we are able to take advantage of the compositing stages that unity canvases go through, and thus we can have things like strength icons be embedded directly in these canvases without them causing extra draw calls.
** Essentially, fleets are so bloody complicated the way that they exist right now (in terms of data structure under the hood) that they can't work cleanly in multiplayer without a bit of refactoringThe positive news is that we can make potentially even single-player slightly more efficient with this refactor, but it's going to require redoing drones and a few other things along those lines.
+
** At the moment we have one canvas per planet, with three text sections inside of thatThis is less efficient per update of text, but more efficient for drawing text, which is the more common operation.
** Edit: the below solves our issue for the time being, although we may still make some changes in this area in the future to make things easier.  We're no longer FORCED to, though, which is nice.
+
** None of these respond to mouse raycasts at all, so on the off chance that the occasional (could not click a planet on the galaxy map) was relating to these, that no longer is possible.
  
* Came up with what is hopefully a clever use of our existing sync infrastructure to handle the cascading wrong data that can happen from the current fleet structure.  This was something that has us stumped for a bit, because doing the most efficient sync style for fleet memberships could lead to units that were in the wrong membership after that.
+
* Replacement changes for the above: In the end we went back to raw TextMeshPro text renderers, as their performance was superior to anything we tried with an abundance of canvases.
** The simple solution is the fact that we do know when we are hitting such a case, and so we can just tell all those units to kill themselves on the clientThey will then naturally and fully re-sync from the host within 2-3 seconds.
+
** We did wind up also making it so that the shaders for TextMesh Pro sprites now use the Geometry queue instead of the Transparent Queue, which improves performance on rendering and also allows for batching.
** This is the sort of thing that we want to minimize, of course, but the worst case is having something be permanently wrong in a MP game and us not being able to fix itLater logic can always do something to sync these back quicker, or to minimize the number of times these are being hit if it is frequent, etc, etc.
+
** And for the various ship icons in both the main view and the galaxy view, those also now use the Geometry queueThose should generally get picked up by GPU instancing, but in the event they do not they will now get picked up by dynamic batching instead.
** For now we're just monitoring (in the UI) how often it happens, and we can make decisions based off of that... as people choose to share that data about their sessions with usWe may implement some sort of automated data reporting that people can opt into if things seem problematic, or if we think we're not getting reports on things like this but it does seem to be a problem for people.
+
** We actually have re-enabled dynamic batching for the game, but still left static batching off, and this seems to give the optimal performance when that's paired with these shader changes for the sprites.
** At any rate, priority one is making it work properly in the long term of a game even if there is a snafu for a few seconds on a client, and priority two is minimizing or erasing the snafus.
+
** Sprites used to always do perfect instancing, but now the sort order sometimes messes that up since there are multiple materials and it feels like it needs to handle them in proper order (really, z buffer ought to be sufficient and overdraw is probably preferred, but anyhow)The queue change makes these more likely to instance, and in the event they don't instance it makes them batch, thus leaning on the z buffer as noted.
 +
** The end performance boost on the top machine we have is now getting us back into the 90s fps on the galaxy map, up from the high 20s in the prior build, and still in the 90s on the main planet viewAnd both feel smooth rather than jittery, now, which is good.
 +
** Thanks to Daniexpert for reporting the performance loss observed lately.
  
* Various central world data is now synced from the host to clients every few seconds/
+
* On the galaxy map, we are now properly buffering text such that we don't put back in the same value into a field that just had that value.
** Among other things that were more intentional, this actually lets clients know the status of other clients pretty rapidly (aka, seeing that someone else is disconnected or connected).
+
** This was causing some needless thrashing and re-parsing of rich text tags.
** This should have all the central items of relevance nicely synced, although we are skipping the "world history" and "journal history."  For those, if they are really needed, we may just introduce a new sync stage to time-slice the processing of those.  But frankly they are not likely to get out of sync.
 
  
* At this point it will be time for us to test our sync code, which is utterly untested at the moment. But the design and implementation of V1, except for actually testing it, is complete.
+
== Version 2.632 Multiplayer Sharing ==
 +
(Released November 16th, 2020)
  
=== "Find Planet" Command ===
+
* Fix an XML parsing error related to the Human Marauders
 +
** Thanks to Crabby, zharmad and okonomichiyaki for reporting
  
* Added a new extension in our central ArcenStrings which lets us do a case-insensitive Contains() call (for purposes of searches, etc).
+
* Add a setting for 'Show Faction Ring Around Ship', which displays a circle around a ship of the colour of the faction.  
** This is useful for a variety of purposees, and lets us do partial comparisons (not just Equals()) calls) without having to cast to lowercase.
+
** This is intended to make it easier to follow how battles are going without icons on, since it looks really cool that way.
  
* Implemented a new [https://wiki.arcengames.com/index.php?title=AI_War_2:Cheats#Debugging command], "findp", which lets you search for planets via the chat command:
+
* Add some Red text to the Delete Campaign popup to make it a bit harder to do it by mistake
** Formatting is like this: "cmd:findp,gear" (minus the quotes).
+
** Prompted by the woes of Pat on the forums
*** This example would search for the text "gear," and would bring up results "Geary" and "Gearworld" and "geaRson" if all three of those existed in one galaxy.
 
** It tells you how many results there are, and if there is more than one result, then repeat entering of the same command (just press up and enter) will cycle you through them.  It tells you that it will cycle you through them if there are more than one.
 
** If you are on the planet view, it switches you to the planet view of that other planet.  If you are on the galaxy map view, it centers the galaxy map on that planet.
 
** Thanks to cml for the initial implementation of this as a mod.
 
  
* Added a new "Quick Tip" item, which shows up randomly on the starting screen as well as in that section in the tips section: Searching For Planets By Name
+
* Mod updates: Fixed Tugboat Drones always slowing enemies by 80%. Instead they now start at 20%, increased by 5% per mark beyond 1, ending up at 50%. Note that Tugboat Drones can still archive the maximum slow if their slow fields overlap.
** During the game, if you hit enter/return to bring up the chat window, and then type 'cmd:findp,yoursearchhere', you can search for planets by name.  If you type part of the name of a planet, then you can hit up and enter to issue the command repeatedly and cycle through multiple hits if there are any.
+
** Thanks to zeusalmighty428 for reporting.
  
== Beta 2.133 Hotfixes ==
+
* Micro Mod Collection fix/balance:
(Released September 4th, 2020)
+
** The Energy Converter no longer produces negative energy and instead consumes the same amount of power. It was causing errors when a bad brownout could turn the energy generation of the player negative.
 +
** Doubled the metal cost of the Research Expedition.
 +
*** From zeusalmighty428's balance feedback
  
'''This one is on the beta branch on Steam and GOG, since there were a number of problems with the prior build that prevented adequate testing.  Once we have confirmation of more people able to play this new version without incident, we can move back out of the beta branch.'''
+
=== Multiple Players Controlling A Single Faction In Multiplayer ===
  
* Fix typo in Full Badger tooltip
+
* In the lobby sidebar, you can now see on the client and the host if other people are in spectator mode, not just if you are personally.
** Thanks to Breach for reporting
+
** This is quite helpful for knowing if the multiplayer lobby is truly ready to start.
  
* Nanocaust now uses a darker border colour
+
* Under human player entries in the factions tab in the lobby and the factions screen in the main game, you can now add and remove players from factions.
** I forget who mentioned that this looks much better
+
** The tooltips make it pretty clear, but basically you can switch who is controlling what faction, or make someone just a spectator, or have two people share control of one faction, etc.
  
* The Nanocaust might now play a bit of defense
+
* Fixed an issue where regenerating maps was causing faction assignment auto-allocation previously.
  
* Improve the way a player's Overall Power Level is calculated
+
* Two players are now confirmed as being able to share the same faction, and both can order around the ships of it and see everything as if it was just controlled by one of them.
** A player can now have a high enough Overall Power Level to trigger Extragalactic War Units without allies if they are on difficulty >= 7
+
** What is not shared is the state of your GUI, such as what you are looking at or what you have selected, or what you are hovering-over, etc.
 +
** This is essentially the same as even really old RTS games like the original Age of Empires that would let you share a faction if you gave two players the same color.
 +
** However, with this you are able to still do text chat with the colors and the names of the individuals who are a part of the game, whether they have their own factions or no faction or share a faction.  This feels pretty awesome!
  
* Dark Spire ship line hacks no longer destroy the VG
+
* Joining a game late as a spectator is confirmed to still be possible, but now that's the only time it warns you that you are a spectator.
** Thanks to Sol for reporting.
+
** If you join the game in spectator mode during the lobby, or the world is regenerated while you are in the lobby, it doesn't show the "hey you're a spectator, is this on purpose" message.  That was really annoying when changing galaxy sections to have fewer factions or while someone was just intending to spectate.
  
* In Steam, the default launch style is now OpenGL, rather than Vulkan.
+
* New feature, after someone has joined a game late (or frankly, even if they have been there from the start):
** As noted, this is the preferred launch style, and more stable.
+
** You or they can unassign them from factions, and assign them to other factions or no faction.
** Thanks to TechSY730 for suggesting.
+
** This is great for having a game where you were playing solo, but now have some friends coming in as extra sets of hands.
 +
** But surprisingly, since this is so quick and so seamless of a way to pop over and see the perspective of another player, I can see this potentially being used as a "hey, look at my metal flows and such for a minute" type of view, too. You can do it while paused or unpaused, the game doesn't get interrupted while people change status or come and go in general, and overall this is just really smooth.
  
=== Fixes Relating To Prior Beta ===
+
== Version 2.631 Multiplayer Swaps And Performance ==
 +
(Released November 13th, 2020)
  
* Fixed several areas where trying to check a non-existing setting (potentially because it was from a mod or expansion you don't have installed) was causing issues.
+
* Fixes to when GetIntValueForCustomFieldOrDefaultValue or GetValueForCustomFieldOrDefaultValue have empty strings in them, to where they will now return the default values properly.
** This is a problem dating back months to when we changed how lookups to missing settings worked, but we're only now seeming to hit it in the most recent betas.
+
** Thanks to NR SirLimbo for identifying the problem and likely fix.
** Thanks to Badger and others for reporting.
 
  
* A variety of extra debugging info has been put into some of the high-level world serialization areas for our logs when problems happen.
+
* Kaizers Marauders fixes:
** Also put in a bunch more into fleets and fleet memberships for debugging purposes.
+
** Fixed another exception in relation to missing settings. Tracing the issue back lead to finding out that Vanilla GetValueForCustomFieldOrDefaultValue() sometimes still does not return the actual default value but an empty string. OnS0_KaizerUpdating() now detects this and produces an informational popup before correcting it to "Never" which is the actual default value.
 +
** Debugging lead to the discover of a bug in the Budget Updating logic where (due to the same issue) they would every second set the starting budget of [nothing] without ever beginning to accumulate budget. They now start with 0 and begin accumulating.
 +
*** Thanks to Isiel on Discord for reporting and delivering a save to reproduce these issues with.
  
* Identified two fields from fleet memberships that were not properly translated over into the new format in the last beta build, causing all new savegames in that beta to fail to load.
+
* Fixed an exception that could happen in RemoveInvalidatedOrdersAndReturnFirstValid_IncludingDecollision() somewhat at random on multiplayer clients, mainly as a race condition.
** Now that this is fixed, the broken savegames all seem to load just fine, which is always nice when that happens.
+
** Thanks to crawlers and Driftwood for reporting.
** Thanks to StarKelp, Sol, and ArnaudB for reporting.
 
  
* The "Civilian Industries" mod by StarKelp has been updated to function in the new code framework we introduced last build.
+
* For whatever exact reason, the Macrophage faction really doesn't work well if the client is also trying to calculate all the decisions for things in multiplayer.  This is referring to the DoPerSecondLogic_Stage3Main_OnMainThreadAndPartOfSim() method in general, but the telium spawning logic in particular.
** All of the mods we distribute with the game are again working at the moment, to our knowledge, nowCode-style mods from other sources (forums, etc) may not be updated yet to compatibility with this latest set of builds.
+
** Since this was a constant source of errors, and since the desync repair code should catch things like this quickly in general, for now we're just not running this on the client at all anymoreThis stops the errors, and any divergences should be quickly and easily picked up by the desync repair logic.
** Please note that we broke compatibility on purpose (not a typical thing), to add multiplayer functionality to mods and make sure that no mods would cause unpleasant spikes in memory usage on client machines in multiplayer.
+
** Thanks to crawlers and Driftwood for reporting.
  
== Beta 2.132 Exterior Leviathan ==
+
* Fixed potential exceptions that could happen in OnlyInMapgenOrInActuallyGettingRidOfEntities_ImmediatelyRemoveFromSim() in general during cross-threading, but most often on multiplayer clients.
(Released September 3rd, 2020)
+
** Thanks to crawlers and Deadwood for reporting.
  
'''This one is on the beta branch on Steam and GOG, because we made so many changes to some fundamentals of how the game works.  These are driving at improvements for multiplayer, for the partial syncs to be able to happen, but they break code-style mods for the game (including Civilian Industries as included in this version), and it's possible that they temporarily are breaking something else since we've changed several thousand lines of code in a few dozen files and may have made an error in any one of a number of places.  Some bits of multiplayer sync are a bit more hefty than we'd been thinking they might be for V1 of that, but then again we're getting more of it done upfront rather than later.  We'll be able to start actually testing the sync maybe tomorrow, unless a bunch of other things are broken by our changes.'''
+
* A variety of data that is only relevant in single-player or on MP hosts no longer shows up on MP clients in the escape menu sidebar.
  
* Dyson Spheres now must kill all the guard posts on a planet before they can kill a reconquest command station. This should prevent a buildup of guard posts.  
+
* Previously in MP, it was possible to get some errors like "Hey, we have generated drones from a ship of type CarrierGuardian that can never be properly deployed by the fleet it is not the centerpiece of, of type NonPlayerDrone" on the client in a spurious fashion.
** Thanks to TechSY730 and Khankar for reporting
+
** These are simply not written right now, and the natural sync process fixes those already within a couple of seconds.
  
* Fix some bugs with Usurpers owned by praetorians or other AI subfactions
+
=== Swapping Fleet Lines Between Multiplayer Players ===
** Reported by GreatYng
 
  
* Try harder to make sure waves against minor factions have ships
+
* Created the ability for players to swap out ship lines between each others fleets in multiplayer.
** Reported by GreatYng
+
** For the sake of convenience, every player can slot in every other player's ships into their fleet, or grant their own ships to any other player's fleet.
 +
*** In AIWC, we required players to actually gift ships or similar from themselves to someone else, but in this game you can outright take from others.  You're all on the same side, so divide up tasks how you will.
 +
** The owner of the fleet is included in the row of the swapping target so it's easy to see who owns it.
 +
** For balance reasons and to prevent technical hiccups, any ships that are swapped between players in this fashion get destroyed and have to be rebuilt by the player on the other side.
 +
*** This is fairly similar to how, when ship lines are swapped between fleets on different planets, the ships are scrapped and have to be rebuilt then, too.
 +
** It's worth noting that this sort of thing does allow for a lot of extreme focusing of tech lines in multiplayer, making MP even easier than it would have been before (you take all of the ships that benefit from tech X, give me all the ones that benefit from tech Y), but this was always a feature we were planning, regardless.  Player flexibility and the ability to coordinate is more important.
 +
*** We could implement punitive-style tech costs in MP, to make it so that it was more costly to use techs, but that would probably just encourage even more specialization.
 +
*** In general, it's simply worth noting that a MP game is substantially easier than the equivalent game played solo.  So either up the difficulty, or add more secondary foes to deal with, or enjoy the extra ease.
 +
*** The original AI War had a much more limited set of factions at the start, and only could ever have two AIs, etc.  So it was important for that game to scale the difficulty up as more players were added.  But in this sequel, the amount of other factions, and their power, make it so that you can really tailor it to your own needs, instead.
 +
** Huge thanks to NR SirLimbo for implementing this!  This was on our list to do, but to have a modder implement it for us in advance is a great time saver.
  
* Fixed some minor typos
+
=== Multiplayer Performance Improvements ===
** Reported by GreatYng
 
  
=== Multiplayer: Sync Correction V0.75 ===
+
* The multiplayer sync-repair of planets, with planet-factions included inside of them, was by far the largest amount of bandwidth being sent by the game during gameplay, and it has now been set up in a time-sliced fashion so as not to cause a bunch of lag on the client.
 +
** It's quite likely that, on some certain very heavy games on Steam, this was actually able to cause an exception where the amount of data being sent in one message was larger than what Steam allows.
 +
** At any rate, this was causing periodic lag on the client that was so severe in some games with larger counts of planets that it was making the entire game laggy.
 +
** We have not only started time-slicing the planets, but we actually split out the data for the planet factions themselves and also time slice THOSE now, too.
 +
** As a direct result, the performance of multiplayer games has skyrocketed when it's involving large number of planets and/or factions, but we're going to take this a bit further.
  
* New setting in the network tab of personal settings: Network Logging Includes Sync Checks
+
* Previously, we had a system where ALL of the various types of network sync repair work shared one large time-slice.
** During gameplay there are messages sent by the network as frequently as several every 100ms, and these are one of the largest sources of data usageThis lets you see the timing and payload size of those messages, if you think that potentially they are what is slowing things down in a networked environment.
+
** This really only worked when we had fewer types of sync repair, and when they didn't also internally have lots of time-slicing happening.
 +
** As we have added more types of sync repair, and have started wanting to time-slice those, this would otherwise mean that the really core stuff -- namely ships/units -- could fall further and further behind, which is not good.
 +
** Therefore, we've moved both the "ship sync checks" and the "divergent ship fixes" out of the central time slice group, and they are handled every sim frame instead.
 +
*** For ships, these were already time-sliced, and so those happen over the course of a couple of secondsProbably closer to 2 seconds now, rather than 4, but it depends on the number of ships in the game.
 +
*** For divergent ship fixes, those now don't wait on anything, and just get sent to clients asap after we realize that it is needed.  This makes that far more reactive in a good way, and ultimately the data is small enough not to be concerning.
 +
**** As we get to fewer PKID conflicts in the future, this will dwindle even further, but having it be nice and reactive is good.
  
* Stripped out a lot of old code that was related to an old style of sync (aimed at desync detection), and started building in the new sync framework (aimed at detecting micro desyncs and correcting those).
+
* Now that we don't have to share the time-slicing with the time-sensitive ship fixes, we can make some of the rest of the sync repair data happen on a more relaxed schedule.
** Decided to move this to a new AIWar2NetworkSync static class in its own file, as after just getting about a third of the way through this logic, it was clear that it was pretty sizeable and overwhelming the rest of the networking code's readability.
+
** This actually is a dramatic reduction in the amount of data transferred, and even more importantly is a dramatic reduction in the amount of CPU processing on clients required to handle this.
 +
** Planet Faction sync is by far the slowest stuff to sync, and has the most data, so we're time-slicing it over 20 frames now, which is about 2 seconds, rather than 4 frames like earlier in this build (before this build, it all happened in a single frame every two seconds or so).
 +
** Planet other-data sync is not exactly small, either, so it's being time-sliced over 8 frames now instead of 4 frames like earlier in this same build.  Again, prior to this build this AND the planet-faction data was all in a single giant laggy frame every 2 seconds in large games.
 +
** The data on these things is just not all that visible or important in this sort of time schedule, so cutting it down in this fashion keeps things from drifting over long periods of time without impacting game performance like it previously was.
 +
** We may add in extra time-slicing in the future if it really becomes needed, but at this stage it is seeming to be a good balance between keeping things up to date quickly and not draining performance.
 +
** Thanks to crawlers and Deadwood for providing an MP savegame where basically the performance was stop-and-start laggy; in this new version, we can run it at full sim speed with no waiting on the client, which is really awesome!
  
* Added in the logic for the server keeping a list of ships that the various clients have told it are divergent.
+
* Non-new ships on tier 3 planets now get synced FAR more slowly, and are counted as skip-syncs.
** The server could be getting overlapping reports from several clients, but we need only one copy of this, because we're going to err on the side of caution and tell every client about each bit of sync data that needs fixing.
+
** These catch up at a rate of roughly "one full sync cycle multiplied by 1/10th the number of planets, rounded up).  In practice in one large savegame with 12k stacked ships and 93k ships total on 120 planets, this winds up being about a delay of 68 seconds at most for any given ship.  If players moved onto a planet that is slightly stale on the clients, that planet would be immediately updated.
** We could always change this in the future if there seems to be a bandwidth benefit to this, but it would probably just mean extra processing on the host for more unique sends per-clientAt the moment we judge that to be the resource that is more scarce.
+
** The main cases where we might have a problem here is with strength calculations being off on planets where there are large numbers of reinforcements suddenly dumped into new ships.  The host would always be correct, but the client would have some slightly stale data in the galaxy map for up to 60 seconds, which would be annoying.
 +
** There are some ways we can adjust for this for specific ships as they are updated, though, and the next step is to add thatThis whole process at the moment does wind up saving a ton more bandwidth and CPU processing, though, which is excellent.
  
* The logic for removing ships on a client that were not part of the last sync cycle, but also not new during that cycle, has been put in place.
+
* Added two new methods to GameEntity_Squad for ships:
** The idea here is that these ships probably died on the server, and the client didn't know for some reason.
+
** FlagAsNeedingForcedFullSyncToClientsJustInCaseIfInMultiplayerAndWeAreHost() causes a ship to immediately be fully synced from the host to any clients.  It is unused on the client side.
 +
*** This is a great way for mods in particular to, after having updated some sort of special mod-only data (like resources they are carrying) to cause a full ship sync.
 +
*** This should not be done too frequently!  But if you have a mod that is gathering resources, and periodically updating information that would not normally be caught by the sim thread, then having this periodically called on the gatherers would keep the tooltips of clients up to date.
 +
*** In the escape menu networking details on the host, you can see how many of these have happened via the "Ship Syncs Forced" item.
 +
*** BUT, this may actually wind up never being needed, stay tuned.  We're going to make some additions so that anything a client is hovering over to get a tooltip gives them up to date info without you having to be predictive about it.
 +
** FlagAsNeedingFullSyncCheckIfInMultiplayerAndWeAreHost() is specifically to say "ignore my tier3 delayed status," to work around the feature we just added today where background ships get ignored a certain amount.
 +
*** This is mainly something to use when something unusual changes (other than a ship existing at all) that would be visible on the galaxy map for client player, without them clicking into the target planet.
 +
*** So for now this is something that happens whenever a ship marks up, and it also happens whenever the AIReinforcementPointContents contents are changed (increasing, decreasing, transferring, deploying).
 +
*** This should keep the galaxy map accurate for clients, while at the same time not having so darn much data transfer for ships on planets where players are not active.
  
* The logic for having the server do send check data for 1/20th of its ships (or stacks or whatever, as the case may be), but no more than 9000 per 100ms, is now in place.
+
== Version 2.630 Arbitrary Icon Inclusion And Weapon Exclusion ==
** This is the meat of the desync detection code, and it is based around only a very few factors:
+
(Released November 11th, 2020)
*** Health lost, shields lost, extra ships contained within (of ANY fashion), current planet, and current location.
 
*** We are generally making the assumption that if all of those things match between the client and the host, then the ship is probably in sync.
 
**** In the case of certain faction ships that do things like gather resources or whatnot, that will obviously be very incorrect, but it is correct for most combat ships.
 
**** For those cases where faction-specific data is potentially going to be wrong, it would be prohibitively expensive to add a bunch of checks based on that extra faction data, so we will build in separate tools for forcing sync of these non-combat factors.
 
**** Frankly, other things like fireteam history, which would be missing on the clients, could be synced via other methods later on if we really want to.  Though that's generally only used for debugging in most cases, so seems not to be worth doing.
 
  
* The logic for clients checking for mismatches with their local data compared to the server is now in, and it sends back the requests to the server to have divergent units corrected.
+
* Add death effect damage a unit has sustained into the tooltip for it at or above Medium detail.
 +
** Each type of damage is listed separately, and displays the current damage, and the amount required.
 +
** Thanks to Puffin for adding.
  
* On PlanetFactions, there is now FactionIndex and PlanetIndex directly in order to make it easier to quickly find those in case they have been reassigned.
+
* Fix a Macrophage typo
** Additionally, their Faction and Planet member variables are now exposed as get-only properties to keep unexpected things from happening there.
 
 
 
* The way that squads deserialize has been updated substantially to allow for several levels of partial deserialization for various sync scenarios.
 
** The sync fix code allows for normal-level same-planet sync fixes (which should hopefully look very nice with things sliding visually into new positions if positions differ).
 
** The sync fix code then also allows for normal-level different-planet sync fixes, which instantly disappears the old spot and puts it somewhere new.
 
** And finally, the sync fix code allows for catestrophic-level sync fixes, where the two entities aren't even the same (not matching faction or type), and it destroys the old one instantly and as invisibily as possible, and then puts in the new one where it should be.
 
*** This last category is for basically when the primary key ID generators are out of sync between the host and one or more clients.  These will be hit with some regularity, but they should not be hit over and over for the same unit.
 
 
 
* The deserialization logic for "fleet memberships" has been split in such a way that we can now sync just some of the data into them (for network purposes).
 
** We are not using this yet, but will once we get into the fleet sync phase of the sync cycle (outlined below).
 
 
 
* CalculateContentsCount() on squads now takes a required parameter IsForNetworkSyncCheck.
 
** If that is true, then it ignores any data that is not on the squad (but is usually on the fleet or the "fleet membership" areas.
 
** This is things like drones or transported ships, and city sockets.  These will be something we sync at the fleet level.
 
 
 
* Network_CurrentSyncCycleNonSer has been moved off of the World_AIW2 object and into the AIWar2NetworkSync class.
 
** Same with the OnServer_SquadsNeedingSyncFixes dictionary.
 
 
 
* The server now cycles through a series of "sync stages," where it will sync different things other than just squads.
 
** This is useful for us to be able to time-slice syncing of data of different sorts... for instance fleets and fleet memberships data.
 
** We actually are now going to use this for separating out the squad sync checks and the divergent squad fixes, too, since time-slicing that is good for smooth gameplay as well as also making sure that multiple clients with partially bad sync cause as few excess sends as possible (that's a ms timing thing).
 
*** The code for syncing the squads that were divergent is now in, as noted above.
 
 
 
* The data for factions, and for some of the Primary Key info, is now synchronized from the host to all of the clients every authorized network batch.
 
** On average this is probably anywhere from 10kb to maybe 40kb, at most.  It's easier just to keep this in sync.
 
** At the moment, for ExternalData on factions and squads, there is a huge amount of inefficiency on the clients in that it is completely recreating objects every network sync right now.  We are looking into various refactoring options.
 
 
 
* At the moment we are explicitly not syncing SpeedGroups, since those are complicated and may tend to diverge.
 
** We are probably going to wind up refactoring these to be by faction, or something along those lines.  In fact, there are several major refactors coming, and one of those may be that a lot of the PKIDs may become faction-specific in general.
 
 
 
* Turns out that adding the NetworkSyncStage as a concept was a really good idea, because we not only need to sync squads and fleets, but also planets and some data off the world, too.
 
** The faction sync is happening once every sync frame, but it's possible we might back off the frequency of some of that if it becomes too harsh.  Mainly for ExternalData stuff.  But for now we'll see how it does.
 
 
 
* Planet has now had its data split out like squads and fleet memberships and factions and some other classes to have its own DeserializedIntoSelf() method.
 
** Also PlanetFaction.  Whew, wow.  For this it doesn't sync the entities during the partial sync, of course, unlike during disk or main network sync.
 
 
 
==== "ExternalData" Updates That Affect Mods ====
 
 
 
* The ExternalData framework has gotten a few updates to allow for us to do partial-syncs like we now do with squads and such, versus always just creating something new.
 
** Any mods that use ExternalData will need to be updated to use the new pattern, although it's not a huge change.
 
 
 
* FireteamRequiredTarget has been updated to have a DeserializeNewFrom and DeserializedIntoSelf, to ensure that what we are doing is intentional.
 
** Since this is a class, not a struct, it's highly efficient for us to be able to write to an existing class rather than always replacing it, even in single-player.
 
 
 
* The following "external data" has been updated to be dramatically more efficient with syncs during multiplayer, employing a variety of strategies that we're using in the main game stuff:
 
** WormholeInvasionDataExternal (this one is basic and simple)
 
** AI_PlannedWave_Data (this one is complex in that it has a list of sub-objects and shows how to handle that properly. It even gets rid of theoretical extras on the client machines)
 
** DoomData (this is really old style in terms of the data, and is not used actively, but does show a way to handle the multi-part sub-data well).
 
** ExternalData_AIFactionCommon (this one is ridiculously complicated and used for a couple of factions)
 
*** ExtragalacticBudget and AIPChange as a part of this, and are good simple examples.  These don't even have the new bool passed to their sub-objects, because both the DeserializeNewFrom and DeserializedIntoSelf() methods can both validly be used as part of one during-game sync (depends on relative list length, see code).
 
*** StoredAIPurchaseCostByBudgetForSpecificUnits is a good example of where it's better to just use a bit of extra GC (especially with the new time-sliced GC unity now has) instead of doing extra CPU processing to be a hair more efficient with that memory.
 
*** Fireteams themselves have changed from having a constuctor for deserialization to having a DeserializeNewFrom method that makes it a bit more explicit what is happening.  We also pulled out the id deserialization so that we could reuse Fireteam objects as much as possible if they are being updated.
 
** DysonExternalData and DysonAntagonizerExternalData (another two examples of the simplest possible cases for updating a modder might have)
 
** MacrophageGlobalData, MacrophagePerTeliumExternalData, MacrophagePerSporeExternalData, and MacrophagePerHarvesterExternalData, which are also very simple examples.
 
** RiskAnalyzerData is even simpler, with no sub-objects to modify.
 
** AIReservesDataExt is seemingly simple, but is dodging accidentally creating two sparse lookups internally on each sync.
 
** AstroTrainsGlobalExternalData, AstroTrainsPerDepotExternalData, and AstroTrainsPerTrainExternalData are all pretty straightforward, although we saved ourselves a lookup load on AstroTrainsPerDepotData.
 
** AutosaveDataExt, even though it's not really even needed on the clients at all.  Since it has some sub-data that is in a list, and in string format, we're just not bothering to send that to clients at all during syncs since it is a waste of bandwidth.
 
** DarkSpireData, which has some complexities with the sub objects DarkSpirePerPlanet.  It has special notes in the code for any similar cases with a sparse lookup and sub-objects.
 
** Two "DZ" items for DLC2, which was wildly complicated to convert compared to most things.  It involved sub objects DZResourceConversion, and DZUpgrade, among other nested objects.  Mostly it was a good example of just following the existing principles on down, but there is one ConversionBag that was tricky enough that we're just clearing and refilling it in a somewhat GC-wasteful way rather than going into the extra complexity and perhaps incorrectness of doing it another way.
 
** AntiMinorFactionWaveDataExt, ExoDataExt, and MDCExoDataExt, which thankfully were all trivial examples of the common case.
 
** ExternalData_GroupTargetSorting, which has nothing formal to save or send.
 
** InstigatorPerUnitDataExternal and InstigatorDataExternal, which again the simple common case.
 
** SpawnAnimationData and DespawnAnimationData were very old and probably not used, but simple to upgrade.
 
** MarauderOutpostRaiderSpawnData is again the simple common case.
 
** MercenaryUnitExternalData and MercenaryGlobalExternalData, which had some more notable complexity.  MercenaryBeaconState upgraded with WorkingHasBeenUpdatedThisDeserializationCycle to handle its situation.  MercSpawnRequest just does it the inefficient way since these rarely exist, and only exist for a short period when they do.  SingleMercenaryGroupState is a strange bit of data, and gets handled in a novel way.  Thankfully MercenaryUnitData was a trivial case.
 
** ExternalData_FactionCommon is old and strange, but was not too hard to update.
 
** ExternalData_MinorFactionCommon was super old in its styling, but already was efficient enough.
 
** NanocaustMgrData, NanocaustPerUnitDataExt, and LastSpawnTimestamp are all extremely simple.  The old FrenzyFleet stuff is still kinda-sorta there, but never has data since it is legacy, so that shouldn't cause any GC churn.
 
** FallenSpireGlobalExternalData and FallenSpirePerUnitExternalData had a few quirks, but mostly were the common case with some minor array clearing and preservation.
 
** One "NP" item from DLC2 required pretty minimal updates to work with this, hooray.
 
** ScourgeGlobalExternalData and ScourgePerUnitExternalData were both the common case with a tiny bit of list/dict management.
 
** Two "ZA" items from DLC2 are mostly the common case but with some collection management added in.
 
** Two "ZM" items from DLC2 are also mostly the common case with a bit of collection management.
 
** HRFDataExt and MarauderDataExt both were also mostly the common case with a bit of list management.  There is a question mark about the regiments aimed at planets, on this and a few other locations, but they are at worst going to be inappropriately blanked out over and over again on clients in MP, which we can fix later.
 
 
 
* In general, any of the usages of IArcenExternalDataPatternImplementation in mods should be updated to follow the new examples in the main code.  The changes are not severe.
 
** The most important changes are the ones above, relating to SerializeExternalData() and DeserializeExternalData() taking an extra parameter, and then each handling a graceful DeserializedIntoSelf() sub-method (and choosing if there's some data not to sync across during gameplay if required).  But beyond that, there are some more changes:
 
** RelatedParentTypeName has been removed, as it was never used.  Same with GetShouldInitializeOn.
 
*** During InitializeData, the object ParentObject is being cast into an appropriate-type Parent object for general usage, (aka GameEntity_Squad, Faction, whatever) that people can then later use.  If the type is wrong, it will just come across as null, and we have it complaining if that's the case.  You can do the same or omit that part if you don't care.
 
 
 
=== Third Off-By-Default Mod: More Starting Options By ArnaudB ===
 
 
 
* The More Starting Options mod by ArnaudB is now included with the game by default (with permission), but disabled.
 
** Requires The Spire Rises expansion (DLC1).
 
** Pick between seven starting fleets and twenty starting battlestations for your custom games. These choices are balanced for regular play and are acceptable to use for achievements.
 
** The eight starting fleets will offer you a more varied combination of ships so you may explore more varied combinations of technologies and playstyles than those incentivised by the default options.
 
** The twenty starting battlestations will let you play and test every of the many turrets brought by The Spire Arise DLC, which are otherwise completely absent from the default starting options. You’ll find multiple combinations for both offensive and defensive playstyles, balanced for your enjoyment and giving you hints as to what synergies you could make with a few turrets or ships.
 
** This mod is off by default as to avoid paralyzing the player by offering too many choices.
 
** You can activate this as a new player unsatisfied with the default options, or as a veteran wishing to vary your experience of the game.
 
 
 
=== Mod: Civilian Industries Updates ===
 
 
 
* Civilian Industries 0.6.4
 
** Full update notes may be found on the forums: https://forums.arcengames.com/ai-war-ii-modding/civilian-industries/msg222774/#msg222774
 
*** A large number of code optimizations, directly mostly at performance and multiplayer readiness.
 
*** An overall nerf to Mobile Ship counts, but a simplified formula will allow easier future modification.
 
*** A rework to the Barracks. Now scales with Mark Level, Command Tech, and can even let you get more Protectors at mark 7.
 
*** Buffs to many Protectors. Balance for them is still being worked on.
 
*** Resources renamed across the board, and structures now state what technology works for what resource.
 
*** A notification will now show when a Raid is about to fire against your civilians, thanks to Chris' recent changes on the notifications front.
 
 
 
== Version 2.130 Redux: Dutch Cities and Softer Eyeballs ==
 
(Released August 31st, 2020)
 
 
 
'''We accidentally forgot to increment the version number in game.  So this would have been 2.131, but is just called 2.130 in the game.  Sorry about that, this is perhaps a first?'''
 
 
 
* New planet naming style added, with over 4000 names in it: Cities (Dutch)!
 
** Most Dutch cities, villages, and hamlets shorter than 10 characters; also includes many local spelling variations.  Created by GreatYng.
 
** Thanks to GreatYng for creating!
 
 
 
* Added a new xml tag, external_invulnerability_unit_required_count, which works with external_invulnerability_unit_type or external_invulnerability_unit_tag.
 
** This basically lets us say that a unit of whatever sort is still protected by others (such as guard posts), but only if there are more than the number specified.
 
** The default number is 0, which means the previous behavior of "any guard posts present make this invulnerable."
 
** For AI Eyes, the number is now 3, which means that if there are not at least 4 guard posts remaining on a planet, you can go kill the eye.
 
*** This is pretty huge, because you can now kill just part of the planet and then kill the eye before going to kill everything else.
 
** If we need to make further adjustments to the Eyes based on the relative ratios of strength of them versus enemies, we can do that in the future, but for now this is a solid start.
 
** Thanks to Lord Of Nothing and CRCGamer for reporting.
 
 
 
* Further balance adjustment: all AI Eyes are no longer Mark 7 at minimum.  They are now Mark 5 at minimum, and if their planet would have a higher mark (6 or 7) then they will instead have those higher marks.
 
** This should help to make a bit more variance with them, and eyes to be a bit less of a pain in general.
 
 
 
=== Bugfixes ===
 
 
 
* Fixed HRF Nucleophilic Defenders as well as other defender types not being loadable into transports. Additionally they now count as Frigates and benefit from their hull/shield/damage settings.
 
** Thanks to Darkshade for reporting and -NR- SirLimbo for fixing.
 
 
 
* Fixed a couple of issues relating to getMostCommonPlanetForRegiment() with fire teams, which were likely leading to who knows what other errors.
 
** The PlanetsForRegiment Dictionary was declared as static, and so all of the regiments were trying to use the same dictionary at once, leading to exceptions as well as probably wrong results.  Exactly how much chaos this could have caused is unclear, but with some of the LRP threads stalling out this is certainly not going to help (fingers crossed it was the whole thing).
 
** Now if getMostCommonPlanetForRegiment() is called again on the same regiment before it finishes, it will throw the error "BUG: called getMostCommonPlanetForRegiment() again for a fireteam regiment before the last call finished.  Will break both calls."  Hopefully we don't have people getting this, but if we do we need to know about it to fix that.  In that case, the workingPlanetsForRegiment dictionary can't work as a member variable at all.
 
** Additionally, if there's an exception in getMostCommonPlanetForRegiment() it will now throw an exception but then exit more gracefully, letting whatever calling code keep doing its thing.
 
** Thanks to CRCGamer and TechSY730 for reporting.
 
 
 
* A few versions back, we made some changes to how the icons are rendered on the galaxy map, including planet icons.  We made them keep their orientation better, but one of the things that was an unfortunate side effect of this is that the colliders on the lines between planets were often taking precedence over the actual planet or the ships at the planet.  That is now fixed.
 
** Thanks to TechSY730 and CRCGamer for reporting.
 
 
 
* Heavily reworked how Journal_TooMuchAIP calculates both how many planets you have paid AIP for, as well as how many planets are neutered.  It was triggering the journal entry far too early, previously.
 
** Please see the code or here for details: https://bugtracker.arcengames.com/view.php?id=23609
 
** Thanks to Sigma7 for reporting, and Badger for helping figure out what was wrong.
 
 
 
* Fixed old wording on the AI Eyes that still said "when there are enough fleets present on this planet" to instead read "when it is sufficiently outnumbered on this planet."
 
 
 
== Version 2.130 Civilian Industries ==
 
(Released August 29th, 2020)
 
 
 
* For determining what your performance is like, the game now uses only one second of data instead of ten seconds.
 
** This makes the sim speed average a lot more responsive and natural-feeling.
 
 
 
* The "suppress upgrade prompt" setting and keybind now both work on fleet upgrades and not just science tab upgrades.
 
** There is some extra info in the tooltips and popups to reflect this, as well.
 
** Thanks to Fritz1776 for suggesting.
 
 
 
=== Second Off-By-Default Mod: Civilian Industries By StarKelp ===
 
 
 
* The Civilian Industries mod by StarKelp is now included with the game by default (with permission), but disabled.
 
** This lets people simply enable the mod by clicking a button in the settings menu, rather than having to find and download the mod from elsewhere.
 
** StarKelp has been a volunteer contributor to the main codebase off and on for a while, and this mod contains both code and xml.
 
** Full description of the mod is included in the tooltips in the game, but also here:
 
*** Every empire is only as strong as the people within.
 
**** Protect your people, and they will help your empire flourish.
 
**** From collecting and processing various resource around the galaxy to bolster the economy, to taking up arms on their own to aid your survival, you'll find their help invaluable in the long term.
 
**** As they flourish, so do you.
 
*** Adds in the Civilian Industry faction, a potent defensive faction that can be allied to either a player, or a faction team.
 
**** They will expand alongside their respective ally, and produce a large number of defensive forces to aid their team.
 
**** They gain a new resource type per planet they expand to, and will work diligently to spread these resources throughout their empire.
 
*** When allied to the player; you will find your command station and battlestations have access to a few new structures that you can invest in to greatly incresae the power of your civilian economy.
 
*** Please check Galaxy Settings for many tweaks in regards to how they behave.
 
 
 
=== Bugfixes ===
 
 
 
* Fixed a bug in GetIsWithinRangeOf() that could happen in the selection logic (and probably other places) if a background thread marked a unit as deleted as it was doing the range check.
 
** Thanks to CRCGamer for reporting.
 
 
 
* It is now possible that your logs will wind up having the message "BUG: overriding speed limit for group X to [a negative number below -1].  Overflow?  Setting to -1 instead."
 
** If this is frequent, it may slow down your game, but the stack traces will let us know where we are going wrong and causing this to happen.
 
** We fixed one area where MAYBE this could be caused, but probably that was not possible in the place we fixed it.  Most likely the problem is in something that is calling GameCommand_CreateSpeedGroup with a command.RelatedIntegers[0] that is greater than the 32767.
 
*** With that in mind, anything that is larger than that being passed into that method is now automatically corrected down to 32766.  This may lead to some turbo speed groups, not sure, but at least they won't be erroring... and that IS what the calling code is asking for, so maybe it's intentional?
 
** At the same time, in some other places in the code where it was checking to apply the speed only if it was "not -1", it is now checking to apply the speed limit if it is "greater than 0."  This seems more like the correct intent, and hopefully won't break anything.
 
** And beyond that, prior to serialization, any speed groups with an OverrideSpeedLimit less than -1 will automatically just set their value to -1 silently and thus avoid popup errors that could be really annoying in savegames for folks.  This has been an issue on and off since July 24th, apparently.
 
** Thanks to Lord Of Nothing (twice over), TechSY730, GreatYng, and Apthorpe for reporting.
 
 
 
* Add a new time_must_have_been_on_planet_before_transforming_if_outnumbered_or_outnumbering, for use with transform_when_outnumbered and transform_when_outnumbering.
 
** This defaults to 0 seconds, which has been the behavior in the past.
 
** But now for all of the ships (mostly AI Eyes, but also some guardians) that use transform_when_outnumbering, it now has a value of 2.
 
** For those that use transform_when_outnumbered, it has a much higher value of 30, to keep them from downgrading their alertedness too easily.
 
** The AI eyes will still switch between alerted and unalerted status every so often in a general battle, since their alerted status increases the balance of battle in their favor so much, but now it won't be a constant thing and ships can continue targeting them in a reasonable fashion.
 
** Thanks to whakomatic, Ovalcircle, MasterGeese, Gdrk, and GreatYng for reporting.
 
 
 
* Additionally, previously anything that was transforming via one of those two methods was having its health and shields and cloaking points all reset to full.
 
** Now, however, when transformed via these two cases ONLY, it keeps the health and shields and cloaking point losses after transformation.
 
** This makes it so that battles with AI eyes are actually something you can win, even as they cycle back and forth between statuses.  And in general this just makes sense, and is important on the dire guardians that use this same sort of mechanic, too.
 
** Thanks to whakomatic, Ovalcircle, MasterGeese, Gdrk, and GreatYng for reporting.
 
 
 
=== Multiplayer Work ===
 
 
 
* GameCommandTypes are now serialized by index rather than name, which chops off the vast bulk of size from most GameCommands, leading to even snappier networking.
 
** Honestly this is a very small boost in most cases, but this also took like two minutes to add.
 
 
 
* The network traffic logs have all been updated to be able to actually report how many bytes were read in for each message that the host or clients receives.  Before it was saying ?? because we were checking prior to doing the reading.
 
** Note that depending on the networking platform in use, there is sometimes extra buffer data that was read from the socket, but if it wasn't part of the game, we just ignore all that.  This is also ignoring packet header sizes, so we're just talking payloads here (but that's consistent with the send records, too.
 
 
 
* In the escape menu, on clients and the host, it now has a new Multiplayer Stats section when you are in multiplayer mode only.
 
** At the moment, this shows how many messages have been sent or received in total, and how many bytes/kb/mb have been sent.
 
*** These all apply to the current session only.  So if you are the host, it is the stats since you loaded up the server and people started connecting.  If clients come and go, it's including all of that.  If you're the client, it's the amount since the last time you connected; if you disconnect and then come back, it starts over.
 
** This is pretty important information in terms of figuring out just how much data is actually being sent back and forth, and how it changes during gameplay, so that we can react to any unexpected spikes if there are any.
 
 
 
== Version 2.129 No Shrooms For Ships==
 
(Released August 28th, 2020)
 
 
 
* Nanocaust now prioritize holding planets adjacent to their homeworld
 
 
** Thanks to crawlers for reporting
 
** Thanks to crawlers for reporting
  
* The nanocaust units now prefer to spawn a bit further from their centers; it looked kinda weird when a giant Nanocaust ship would spawn right on top of a nanobot center.
+
* Fixed a bug in Astro Trains where they were looking for a nonexistent variable in their custom xml. This was always a harmless bug, but newly showed an error while in the past it was silent.
 
+
** Thanks to ussdefiant60 for reporting.
* Added a lot of extra instrumentation to the deserialization and serialization of factions, since there seems to be some sort of error in there with savegames from specific versions.
 
** Essentially with this sort of thing on, we can now manually look through the deserialization log and see if we notice where field data stops making sense.  It was obvious that it was getting something like "I am hostile to 20 thousand factions," which is nonsense data, but it was not clear where the data was going wrong prior to that.
 
** From this, we could then see that most of the data reads in the player faction seemed reasonable, but the faction right after them was immediately messed up.  This is after a lengthy code review turned up nothing wrong, so it's always possible that it's some sort of edge case that has been around for longer than we thought.
 
** Added in code to make it so that if an exception is thrown while deserializing a faction, we will now repeat that error better and stop doing further deserialization attempts.  It turns out that was what was happening, and a more careful reading of the log could have saved about an hour and a half of work (oh well, things in the future will be easier to debug).
 
** Thanks to Lord Of Nothing for a very challenging save that led to these changes.
 
 
 
* Fixed an issue with some savegames that had hacked dyson or dark spire ships, where the HackToGrantShipLine_DontDestroyTarget hack had been removed and split into several versions a few versions back.
 
** We now have added HackToGrantShipLine_DontDestroyTarget back in, in a deprecated fashion, so that old savegames with this data in it can load.
 
** Thanks to Lord Of Nothing for the save that let us find this.
 
 
 
* Fixed a bug in the prior build where the "flair" overlays for ships in the main view were either black (some machines) or a rotating color set of insanity (others).
 
** One line was accidentally omitted in the new build of the shader that we made.
 
** We also updated some calling code to the shader in a way that is harmless but not actually needed for this fix.
 
** Thanks to Strategic Sage, Isiel, CRCGamer, and TechSY730 for reporting.
 
 
 
* The "Icons Disappear When Camera Lower Than" setting in the main camera window has been updated as follows to have this note
 
** Note: this setting does nothing (icons always draw) if you have 'Skip Drawing Ship Models' turned on in the Performance section.
 
** (Also, this is how it actually now works).
 
 
 
* If a player is already on a planet viewing that planet, and a further command was sent to view that planet again (as if they were not already there), then funky stuff happened in various places, including the wormholes getting half-initialized and not drawing properly in scale.
 
** To solve this, it simply doesn't do anything if you try to re-open your view to the existing planet you are already on.
 
** Thanks to StarKelp for reporting.
 
 
 
== Version 2.128 Don't Lie About Distant Future Waves, AI ==
 
(Released August 27th, 2020)
 
 
 
* Fix a bug where the scourge would sometimes suicide into multiple layers of defensive planets in the (foolish) hope of hitting the weak target on the other side.
 
** This is an intelligence improvement for all factions using fireteams (Hunter, Warden, Nanocaust, Scourge, etc etc).
 
** Thanks to Crawlers for reporting
 
 
 
* Add some defensive code to the Fallen Spire.
 
 
 
* Put in extra logging for the SpeedGroup serialization and deserialization, to figure out where there are occasional exceptions being logged.
 
** Thanks to TechSY730 for reporting.
 
 
 
* Sniper Energy Wave on the Dark Spire Eidolon has been renamed to just be Energy Wave, since this is not an infinite-range weapon.
 
** Thanks to crawlers for reporting.
 
 
 
* DoForKnownWavesAgainstHumanHomeworlds in WaveUtils has been renamed to DoForKnownWavesAgainstHumanWorlds, which is what is accurate.
 
 
 
* A whole bunch of extra array indexing calls into QueuedWaves have been made more efficient in the AI HandleWavesForAI() method.
 
 
 
=== Interface Improvements ===
 
 
 
* The planet's tooltip has been updated to show the owner on the same line as the planet name, but positioned way over to the right.
 
** This keeps things pretty condensed, but avoids some clashes of words where it seemed to be saying something like "Permanently Watched Owner:" as one phrase.
 
 
 
* Previously, there was a chat message going out as soon as a wave was queued, but before it would become visible to the player in the actual interface (based on their chosen galaxy map settings for how much warning to get).
 
** Now it only shows the actual chat message from the AI as the wave is being revealed to players.
 
** This also fixes an issue where it was for some reason actually giving the wrong planet name that it was going to attack in some cases, since the announcement came before it finished changing its mind about the real target it wanted to hit.
 
*** This latter one may have been more common in multiplayer, but it's hard to be sure.  At any rate, it just tells you real information now.
 
 
 
* The second chat message that goes out (with the audio taunt) when waves are launched now also happens when they are revealed, and no longer duplicates when in multiplayer mode.
 
 
 
=== Mod Compatibility Improvements ===
 
 
 
* There is a new DoPerSecondNonSimNotificationUpdates_OnBackgroundNonSimThread_NonBlocking() method that gets called on each faction each frame, and which takes in a note which says if it is the first faction of its type this frame or not.
 
** This lets us move notifications for factions into their own files, which makes notifications modding-compatible.
 
** There are some other supporting methods that have been added to handle this, but understanding them is not required for using this,.
 
** It is worth noting that ALL of the existing DoPerSecondNonSimNotificationUpdates_OnBackgroundNonSimThread_NonBlocking() calls do happen in a loop prior to the new DoPerSecondNonSimNotificationUpdates_OnBackgroundNonSimThread_NonBlocking() being called.
 
** As an interesting side effect, this actually makes it so that notifications will now work for people in spectator mode in multiplayer for the first time.
 
** The nanocaust data has been moved out of the human file as an example of how to do the others.
 
*** Same for antagonized dyson spheres, and the dark spire.  It would be great to get the other factions moved over to their own files for the sake of cleanliness, but functionally there will be no difference for our things in the main game and expansions now.
 
** Thanks to StarKelp for requesting the ability to add notifications in mods.
 
 
 
* Added a new method DoPerSecondLogic_Stage0Clearing_OnMainThreadAndPartOfSim_OncePerFactionTypeEvenForFactionsNotInGame().
 
** This is called on the GetDefaultImplementationForLobbyOrClearingOnly() from the faction TYPES, which means it happens even for the factions not in a game.  Great and easy place to clean up, and we know it happens only once per cycle per faction type, and we also know that it happens even if a faction is not in the current campaign.
 
** This is useful for factions that had some data in a prior campaign, but the player loaded a new savegame and they are not in this one.
 
** All of the various data from these that was previously in the Human class and in DoPerSecondLogic_Stage1Clearing_OnMainThreadAndPartOfSim() has been moved to the new stage0 for each of the specific class types, which again is more mod-friendly and should prevent the issue of certain mods being unable to clean themselves up between campaign loads.
 
 
 
=== Multiplayer Work ===
 
 
 
* When the host is waiting on a client that is behind, it now shows a message saying which clients are behind and being waited on.
 
 
 
==== Bugfixing ====
 
 
 
* The galaxy map spacebox background is no longer serialized into savegames.  Instead it is deterministically calculated based on the map seed.
 
** This makes very little difference for single player, although you will notice that reloading the game or going back and forth to the map, or hitting regenerate map on the lobby no longer changes the space background.
 
** But for multiplayer, this keeps things consistent between all players.
 
** For existing savegames, you will notice that the spaceboxes become something new and stay that.
 
 
 
* It turns out that the planet spaceboxes were not being serialized at all in savegames before, but their rotations were.
 
** This was leading to very different planet background views in multiplayer, to a very distracting degree.
 
** This has been made deterministic, and we no longer store even the rotations in savegames.
 
** For single player there is no real change except that the savegames are a tiny bit smaller.
 
** For existing savegames, you will notice that the spaceboxes become something new and stay that.
 
 
 
* Fixed inconsistent sorting between runs of the game (and between differnt clients) for rows in the following tables:
 
** AIGuardPostAndCommandPlacerTable, FleetDesignTemplateTable, AIShipGroupCategoryTable, and SpaceboxDefinitionTable.
 
** These led to various MP inconsistencies, including the spaceboxes still being divergent on planets despite the math lining up.
 
 
 
* Fixed an issue where the home planets of other players in multiplayer games just looked like normal planets instead of homeworlds.
 
 
 
* There were a bunch of cases where human factions were still named wrong during multiplayer (and differently on the host and client), saying the wrong player's name or Unknown Player in various cases.  Fixed all of those.
 
** Additionally, in the case of multiple players owning a faction, if they did not choose an empire name, it now says all of their names together (but no more than three) as the faction name.
 
** If there are more than three players controlling a single faction, that gets too wordy, so it just says "and X more".
 
** When loading the single player games of other players, you will now see their chosen account names (from in AI War 2, not Steam or whatever) instead of your personal profile name.
 
 
 
==== Seeing Where Other Players (Or Spectators) Are Looking ====
 
 
 
* The way that the gimbal icons decide which diffuse color to use is now more efficient on the GPU (this is minor, but hey).
 
 
 
* It is now possible to have a secondary diffuse color for the flair (really used for selection circles now), which is multiplied by the main "other diffuse color" of the icon.
 
** This lets us do things like change the opacity or color of the selection ring around a ship or planet.
 
 
 
* When you are viewing a planet, the game's way of showing the selection circle around it is the same as it always has been.
 
** However, when someone else in multiplayer is viewing a planet other than the one you are viewing, it now shows a dimmer and more-transparent selection circle to show you that someone else is looking there.
 
** If someone else is looking at the same planet you are looking at, then it will show the normal bright selection circle in a faint green rather than white.
 
** This is something that is deceptively important, because we need to make sure that we know which planets are "tier 1" planets on clients and the host, which lets us verify that ViewedByPlayerAccounts_DuringGame is being set properly on all machines (it is). This keeps the game in the sync, which we can now tell is working properly.
 
** But also this is just a helpful indicator for players to help with coordination.  ("Check out this planet I am looking at in the northeast" is so much easier to say than trying to direct them to a name).
 
 
 
* As an added help, in the galaxy map view when you hover over a planet, it tells you which other players are viewing a planet.  This may be players in exclusive control of a faction, or one of several player players controlling a faction, or just a spectator, so it shows you their name as it would appear in chat.
 
** For games with more than two players, this is fairly important for purposes of clarity.  In a two player game it's easier to just infer what is going on.
 
 
 
* When a client is disconnected, other clients and the host can still see what planet that client WAS looking at, and that planet still counts as a Tier 1 planet for processing, but hovering over it will show the name of the player with (Disconnected) behind it on the host.
 
** Presently clients cannot see the status of other clients.
 
 
 
==== Disconnection And Re-connection Verified ====
 
 
 
* We can now verify that after a client disconnects in a disorderly way, the host notices a bit later and then continues on without them (they can choose to pause or not).
 
** We can FURTHER verify that the client can reconnect to that running game with only a few-seconds interruption to other players who are still going.  Even if the client had crashed and had to restart the game or their computer, they are able to get right back in there.
 
** The original AI War did not remotely have any of these capabilities, but this works on all three networking platforms.
 
 
 
== 2.127 Cranky AI Exceptions ==
 
(Released August 26th, 2020)
 
 
 
'''This was originally released as a beta on the 26th, but then changed to a main branch release on the morning of the 27th.'''
 
  
* The Dark Spire now responds properly to being hacked by being cranky
+
* GetDefaultValueOfWhateverSort() on the SpecialFactionData object has been updated to match the way that the default values were returned on the faction screens.
** Thanks to crawlers for the bug report
+
** Thanks to NR SirLimbo for reporting that this was not working consistently.
  
* Fix a bug where the AI was incorrectly combining some Hostile To All factions when spawning extragalactic war units.
+
* The CustomFieldValues array on faction objects is now private, so that people don't try to directly add or find data from it.
** This was leading to more extragalactic war units than one would want.
+
** Instead, mods and factions and whatnot should set data through SetCustomFieldValue (which works the same as before), and they should get data via either GetCurrentIntForCustomField() or GetCurrentStringForCustomField().
 +
** Both of those latter two methods have a method that lets you pass in the specific field (more efficient), or which just takes the name of the field (less efficient).
 +
** Either way, the idea is that there's never confusion with not getting the default value back when there is a blank present in the main data (which might be an old savegame or quickstart, or various other valid conditions).
 +
** Thanks to NR SirLimbo for finding this accidental modder-landmine for us.
  
=== Exception Fixes ===
+
* Fixes for Kaizers Marauders:
 +
** Instead of failing horribly when added as a Random Faction, or when loading older saves where old Marauders were enable (be it just as a beacon), which includes quickstarts they will now use somewhat defaulting values. It's not perfect, and not really intended for use this way (simply because of the sheer amount of options available) but it works.
 +
** Fixed a potential issue with Debugging global stuff for Marauders (such as logging Kaizer Updating or the Shared Planetary Cooldown List) where the debug could be turned on, but when only a specific Marauder Faction was set to be debugged it could re-overwrite with false later on, leading to no printouts.
  
* Added new debugging instrumentation into ImportIntoDynamicTable_XMLDirectory, so that we can find errors that may happen in there from time to time on some machines.
+
* Remove mentions of 'tiers' from the scourge unit hovertext, since it was confusing peoople. It was only ever a cosmetic thing.
** Also put in some code that should make it load faster for mods and expansions that don't have certain folders.
 
** Thanks to Ovalcircle for the report of something mysterious in this area on his system.
 
  
* Also expanded the debugging instrumentation on ReadXmlFileIntoBatchProcessingLists, same reason.
+
* Suppressed a pair of harmless-but-annoying exceptions that could show up in your log files if you were shutting down the game from the main menu in just the wrong way.  These were related to the Slate cutscenes trying to stop at the same time they were being eaten alive by your OS taking back its memory. All is well, no need for a dying scream.
** Ditto DoForXmlFolders.
 
** And finally, ditto ActuallyImportAllOfTheBatchedRows.
 
** Thanks to Ovalcircle for the report of something mysterious in this area on his system.
 
  
* ArcenXMLElement.GetNewFor has had its debugging instrumentation greatly expanded, and also has been split into one version that expects a data table, and a new GetNewForNonTable variant that does not expect a table.
+
=== Fix To Ship Weapons Mismatch ===
** The idea here is to catch various forms of errors early.
 
** This in turn caused a cascade of other changes to other methods needing variants of each other along these same lines, and having better instrumentation.
 
** Thanks to Ovalcircle for the report of something mysterious in this area on his system.
 
  
* Fixed another rare race condition that could happen with the vis code, this time in SetFormationPositionFromSquad.
+
* Added a new ArcenNonTableUniqueStringList class, which we can now use for keeping lists of arbitrary string that we want to serialize.
** Thanks to NRSirLimbo for reporting.
+
** We're going to be using this for entity systems.
  
* If for whatever reason the game was not able to proeprly write your settings data, it was still overwriting your settings file previously.  It will no longer do that.
+
* EntitySystemTypeDataTable has been removed, and EntitySystemTypeData no longer inherits from ArcenDynamicTableRow.
** Additionally, a lot of extra instrumentation has been put into GameSettting.SerializeGraphicsTo and GameSettting.SerializeTo, so that we will know better what is wrong if it is trying to save improperly.  These should also be more resistant to saving incorrectly in the first place.
+
** This was really old logic, and is the one instance in the codebase of us really not using dynamic table rows properly.
** Thanks to Isiel for reporting.
+
** The result was slow during startup, in the best of times, and more recently it has been actually scrambling up the data for systems between different ships!  That latter part may be new in the last few builds, or it might just be more common. Either way, this has needed a shift for a while.
 +
** The EntitySystemTypeData no longer has an InternalName, but instead has InternalName_Original (which is just the raw xml name like FusionBomb), and then an InternalName_Longer (which is the entity type appended in front of it, like "Mugger_FusionBomb").
 +
** The new serialization for these by index uses the shorter name, which just makes savegames a bit smaller.  But it doesn't really matter what is used in the longer-term effect, because these are no longer stored in one central lookup.  They are now properly full sub-entities of the GameEntityType.
  
* If a savegame has somehow been made that has a blank savegame in it, then it will try to load it with the info of the current version of the game, with a warning in the log that this may fail very badly.
+
* With this change, shockingly, we have still NOT solved the issue of things like Mugger frigates sometimes getting Brawler weapons.  So that's going to need even more investigation.
** Thanks to Isiel for reporting, and providing a save that was probably made while the game was in an invalid state.
+
** This overall change is still worthwhile, as it shrinks future savegames a bit (not ones from prior versions saved in the new build, though), and it also makes loading the initial game program a bit faster and less prone to potential issues... despite still having this particular issue.
 +
** Note from later: this actually solved 90% of the problem, but there was still a case of us managing something slightly wrong that let it keep bleeding over.  So the last 10% is below.
  
* Fixed a case where trying to load certain saves could fail silently as far as the interface was concerned.  Now it actually shows you a proper error message.
+
* The "copy_from" tag, which was never used on entity systems inside an entity, and which probably would not have worked well there if it had, has been removed.
** And then fixed a whole bunch of cases where certain code paths on almost-certainly-broken saves would return very genric and unhelpful errors when you tried to load them.
 
** This doesn't really help us actually load the savegames in question, but tells us more about what is wrong with them.
 
** Thanks to Isiel for reporting, and providing a save that was probably made while the game was in an invalid state.
 
  
* Suppressed a harmless popup that could happen in ReactToShotHittingSquad during cross-thread race conditions.  Now it just fixes the data and moves on.
+
* Fixed a bug where our "dump data tables on load" debug option was no longer working (the hotkey was, but not the on-start version).
** Thanks to CRCGamer for reporting.
 
  
== Beta 2.126 Dark Spire, Eyes, and Fixes ==
+
* Fixed a very peculiar issue that only affected a couple of unit in the prior version (in the main game and DLC, anyhow -- more may have been affected in mods) where if there was a unit that had its systems altered on a child, and there were then other co-children, the other children would sometimes get those altered stats and sometimes not.  Normally it should just pass to grandchildren and so forth, not to siblings.
(Released August 22nd, 2020)
+
** Essentially, the way that we handle partial records is normally very explicit  (is_partial_record="true").  And in fact, when we have a partial record like that, we WANT for it to inject itself into any other descendants later.
 +
** But in the case of entity systems, we have this kind of implicit "child partial record" system going on, where you just name the same system in the child as you had in the parent, and make some changes, and those changes then keep going in that lineage.
 +
** What we do NOT want to have happen is the siblings to also pick up those changes, which is what was sometimes happening here because of the funky way that we handle systems and systems alone in the game.
 +
** From looking at the raw data, without mods in play this mostly just affected muggers and brawlers, and a few spider turrets.  Most everything else was already consistent properly.  But if you play with mods on, you may have seen a lot of other chaos happening beyond these particular ones.
 +
** Thanks to crawlers, Ovalcircle, Spaz, Puffin, and Darkshade for reporting.
  
'''To play this version, please be sure to choose the current_beta branch on Steam. The central game loop changes we made in the prior version did not blow up, but a few other things did, so we're glad we went the beta route.  If for some reason this beta has problems but the prior one worked for you, we have temporarily made the most_recent_stable_beta active and pointing to 2.124.  But this version should actually be more stable (knock on wood).  We'll be back out of beta by mid-week the week of the 23rd.'''
+
=== Work To Allow Arbitrary Sprites In Game Text, Part 2 (Complete!) ===
  
* Fix a bug with DS Conquest VGs and the new hack
+
* The sprites in TextMeshPro have been updated so that their default index is 0, not -1.  That way if no sub-name or image is specified, we are still able to figure out where they are.
** Thanks to gigastar for reporting
 
  
* Fix a bug with the Full Metal notification
+
* We don't use the mspace monospacing markup, so we're keeping things simple and redefining that to mean "no advance"
** Thanks to a screenshot from Oval for making me aware of this
+
** This essentially lets us put <mspace>around things we want to all be on top of one another</mspace>, which is really useful for our compound icons.
  
* The AI should now attempt to play voice lines for Exogalactic Strikeforces, and when you spot the Nanocaust.
+
* Since we already use non-atlased sprites in every location in the UI, and have those present and available as needed, we're just going to go with that for the TextMeshPro sprite embeds as well.
 +
** There aren't any sprites that we only have in atlases but not also in asset bundles directly, although there are ones that are loose and not in bundles.
 +
** With that in mind, this lets us avoid the glyph metrics that were working so poorly with our sprite atlases, and the efficiency of the whole thing is not much changed given how compositing on the UI works and how infrequently (overall) we include extra sprites.
 +
** This actually turned out to be a particularly good move, because what we've discovered is that if there are two different sprites used in a single text area, the following happens:
 +
*** The draw order is based on the order of the first sprite dictionary used that is shared, not the order of the sprites in the text.
 +
*** When multiple sprites are in one dictionary, this can lead to funky results.  When there are single sprites per dictionary, the only time this can mess up is when there is a single sprite used more than once AND you want them to overlap one another.
 +
*** It's worth noting that we don't care about the order of sprite drawing, normally, except for the new mspace markup.
  
* The DS is no longer allowed to spawn Loci on planets with Dark Spire Wards
+
* The new custom TextMeshPro dll has been updated (by building the WorkingTextMeshPro project, as silly as that is) and the result has been put in ReliableDLLStorage so that we can compile against it and use those capabilities in ArcenUniversal, etc.
** Thanks to crawlers for reporting
 
  
* Make the Dark Spire more aggressive about spawning Loci
+
* The copies of TextMeshPro code for the other three main projects that use it have all been updated to match the new capabilities.
** Thanks to crawlers for suggesting
+
** This won't work in the main game build until it actually has a build done, though.
  
* The player can now choose the starting armory for player-allied scourge
+
* Added a new TextEmbededSprite and TextEmbededSpriteTable table, which are in ArcenUniversal and PARTLY filled by xml entries from the new TextEmbededSprites folder.
** Thanks to crawlers for suggesting
+
** The rest of these are able to be filled programmatically as we load sprites from other locations, specifically when it comes to ships by name.
 +
** The purpose of these are to define sprites that can be used inline in text for improved display purposes.  You can expect to see us doing more of this over time now that we finally have the capability.
 +
** It is possible for an auto-added sprite in here (such as for a specific unit type) to manually get some tweaks by adding xml for it.  The order of that happening does not matter, which makes the system extra flexible.
 +
*** This does mean that, because of the lack of order mattering, this table intentionally allows for malformed entries (those defining some metadata but having no actual sprite assigned).  That's a necessary byproduct, since other parts of the code are assumed to add those sprites later, but might not do so if they were themselves removed.
 +
** bundle_name and filename are optional, and specify the location of where to directly load the Unity Sprite or Texture2D from during game load.
 +
*** These are NOT used in cases where another class (like GameEntityTypeData) is creating new TextEmbededSprites on its own.  In those cases, the sprite or texture2D is sent from the other class.
 +
*** In the case where these ARE used, we need to know whether we can load it as a Sprite (ideal) or a Texture2D (slightly slower).  The xml tag bundle_target_is_texture2d defaults to false, and so tries to load the target as a sprite.  Anything used elsewhere in the UI would work this way.  But if you need to load a Texture2D and make a Unity Sprite out of it at runtime, you can set this to true.
  
* Improve the hovertext for some scourge units just a bit.
+
* Added a static CreateRuntimeSpriteFromTexture2D() method on the TextEmbededSpriteTable, which takes in a Texture2D and returns a Sprite.
 +
** This is something that is particularly useful, because it keeps track of ones that were previously created, and reuses them rather than creating extras.  This can only happen on the main thread.
  
* Fix a bug where new games in the beta weren't starting correctly
+
* About 50 initial sprites have been set up as text embedded sprites for use coming up.
** Thanks to Keith and Tynendir for reporting
+
** There is more metadata that we want to get in there, plus some other things to make these as simple as possible to call on, and we need to actually cross-wire this to the new TextMeshPro stuff that we worked so hard on.  But that will come tomorrow.
  
* Capturing an AI homeworld no longer generates AIP. This only applies to games creates on 2.125 or above.
+
* Fixed the AIW2ModdingAndGUI project so that it now has the proper TextMeshPro code embedded within it and so that it won't erase our customizations every time it is reopened in the unity editor.
** Thanks to GreatYng for suggesting
 
  
* AI Eyes now trigger based on whether you have more Strength on a planet, not off the number of fleets
+
* Fixed the WorkingTextMeshPro project so that it now has the proper TextMeshPro code embedded within it and so that it won't erase our customizations every time it is reopened in the unity editor. This is how we build our custom variations on that code, and now we're not at risk of random regressions from unity package manager automatically wiping our changes.
** This is not necessarily the final state for Eyes, but having them trigger off of 'number of fleets' didn't make any sense anymore. This is a functional stopgap until someone has a better idea
 
** Thanks to a number of people for discussing, including Flypaste, Asteroid, Democracy, GreatYng and others
 
  
* Fixed typo in multiplayer message.
+
* The following float options are now available on any of the text embedded sprites for manipulating how they fit into the text they are embedded in:
** Thanks to fwiffoforce for reporting.
+
** x_draw_offset, y_draw_offset, width_draw_offset, height_draw_offset, advance_draw_offset.
 +
*** All of those do the basics of what you might thing in tems of adjusting how the sprite draws, while advance says how much space to go over before the next character draws (or how it plays into word-wrapping or whatever else).
 +
*** All of these are in fairly abstract units, where roughly something like 100 is about the height of a line, regardless of how many pixels that line actually is.
 +
*** Most of the time you won't want to mess with these at all, but in some cases you may want to adjust the vertical centering by using y_draw_offset in particular.  Beyond that, most people would not use any of these.
 +
*** Frankly, to get the kerning of the strength icon working perfectly, we will probably add a few more dials to this soon.
  
== Beta 2.124 HRF Pacekeeping ==
+
* Our TextEmbededSprite sprites are actually loaded up into TextMeshPro sprites now, completing the main integration of arbitrary sprites.
(Released August 18th, 2020)
 
  
'''To play this version, please be sure to choose the current_beta branch on Steam. If this isn't blowing up in major ways, we'll move it back to the main branch within a few days.  If it is blowing up a lot, then it may be into next week before we come back from beta. We changed too many fundamental things with the game loop to just release this with no beta, even though we were careful.'''
+
* default_color_hex is a new string option available on the text embedded sprites, for allowing a default color to be applied to sprites.
 +
** Please note that, unlike sprites we had in the past that were based on vectorized glyphs inserted into a wingdings-like font, these sprites can be full-color to begin with.
 +
** The one "downside" is that these sprites can't be infinitely zoomed-in-on like a font, but that's hardly a downside given that we could render these crisply on an 8K monitor or more.
 +
** The default text colors are nice for purposes of things like resource icons that are embedded in text.
  
* Minor rework to minor faction hacks. Its now more expensive (in line with the previous hacks). The description no longer mentions an AI response. The DS and Dyson units are now upgradable, but not very much. These are intended to be 'cool little tidbits' but nothing to really swing the game
+
* For now, ArcenFormatting has been updated to stop using the old font-based resource sprites, and now use the new TextEmbededSprite sprites.
** Thanks to GreatYng and Lord of Nothing for bug reports and comments
+
** This is a major jump up in quality in general. Also, now all of the resource icons properly match all throughout the GUI.
 +
** One thing to note, however, is that these sprites no longer inherit the color from their parent font.
 +
*** So, in order to match the text color properly, we needed to add ArcenExternalUIUtilities.GetStrengthIconWithColor_Wasteful(), which hits the garbage colletor, and ArcenExternalUIUtilities.WriteStrengthIconWithColor(), which does not (use the latter if at all possible).
  
* Add a 'Full Metal' indicator in the metal bar
+
=== Main Menu Further Refinement And Expansion Logos ===
** Thanks to Nyarlathotep. Iä! Shub-Niggurath!
 
  
* The hovertext prompt that describes when swapping ship lines will scrap your units has been modified to describe the current behaviour correctly ("Your ships are scrapped if they are loaded, or the flagships are on different planets").  
+
* The planet that scrolls by in the background of the main menu sometimes has been removed, as it was having some glitchy effects on it that we definitely did not want.  In the end, we don't really need the planet in order for this to be a very interesting scene as it is.
** Thanks to StrategicSage and Ubifan for reporting
+
** Thanks to Badger and others for reporting the problem.
  
=== HRF Changes ===
+
* The material properties of the main game logo have been updated substantially so that they look more natural in the light and shadow of the main game.
 +
** Thanks to Badger for suggesting.
  
* The HRF ships now have some unique names.
+
* The main menu now has logos for all three of the current and upcoming expansions, and they are more lit-up if they are on (installed and enabled).
 +
** If they are not installed or not enabled at the moment, then they show much darker, but still with reflectivity of lights passing by.
 +
** Videos made during the making of this: https://youtu.be/p73bPBFsgoI and followup: https://youtu.be/K-uvfTH9tgk
  
* The HRF now create a structure at game start time that you can hack for a new ship line (using the backported DLC2 tech) and for 1K science
+
* The AIWarExternalCode library now links against ArcenThirdPartyCode so that it's able to make changes to certain things in the front-end game.
  
* Fix a longstanding bug where the Human Resistance Fighters would only say their 'defeat' voice lines, not their 'victory' voice lines.
+
* The main menu now uses a hook to go in and find our custom BetterRotationScript on the background that spins the space skybox, and slows it down substantially compared to prior releases.  This saves us the wait of a 40-minute rebuild process, and in theory actually would let us have a variety of random rotations if we felt like it.
** Thanks to Nyarlathotep. Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
+
** Thanks to Badger and Asteroid for suggesting.
  
* The HRF should now pack a bigger punch when they arrive, but they are a bit less likely to show up.
+
* In fact, since we can, the rotation of the stars in the main menu is now entirely random, but at a much lower overall speed than it was before.  It can rotate at a combined maximum velocity that is still only 3/4 of what the prior maximum speed was, and almost all of the time it will be vastly smaller than that.
  
=== Bugfixes And Tweaks ===
+
== Version 2.629 Ship Cap Hotfix ==
 +
(Released November 10th, 2020)
  
* Some minor improvements to the ability of vulnerable Vengeance Generators to be killed
+
* Corrected the OpenGL launcher script on GOG, thanks to GOG support (it was our error -- thanks to them for figuring it out!).
** Hopefully this helps. Thanks to Lord of Nothing for reporting, and Puffin for suggesting the improvements
+
** It appears that the issue didn't affect all flavors of linux, but it certainly did affect some.
 +
** Thanks to rudhek for reporting.
  
* Better enforce the 'can't repair ImmuneToRepairs' unit interactions. Still a bit weird.
+
* A simple typo was breaking all of the xml parsing for sub-lists of data of the following types (unless they had the requirement of IsUnique on): fint, arcenpoint, vector2, vector3,
** Thanks to MasterGeese for reporting
+
** Most of these were new or unused in general, but fint was not new and is used for the scaling of ship caps in the game, as well as for the engine stun seconds progression.
 +
** All of our other list parsing, which are more commonly used, were all working fine.
 +
** Thanks to Wuffell, ArnaudB, ThyReaper, and other for reporting.
  
* SerializeByInternalName and SerializeByIndex both now accept FieldName as an optional parameter so that we can see what is happening within them from a serialization logging standpoint.
+
== Version 2.628 Mod Proliferation ==
 +
(Released November 9th, 2020)
  
* A bunch of extra serialization logging has been added into the world and the faction configuration objects, to make finding errors there easier.
+
* Fixed a bug where the Tame Macrophage Hack was not correctly responding on certain Quickstarts.
** However, it turns out that there were no public errors on this, just an error in a working copy on one developer machine that had a save from between two updates from that same developer.
+
** In actuality, the Enraged subfaction was entirely missing from those quickstarts! Very bizarre.
 +
*** Thanks to Smidlee and Metrekec for the bug report and saves for testing, and StarKelp for fixing.
  
=== Milestone: Multiplayer Pacekeeping Functional ===
+
* Fixed Cloaked Transport Flagships from starting fleets having the default transport direct tech upgrade costs instead of the higher ones that captured cloaked transports do.
 
 
* In the event of a campaign switching which player is the host (this probably means one player manually emailing the game to another), the game now tries to do a better job of handling that.
 
** In the end this should work fine, but we haven't bothered testing this yet as this is probably kind of an edge case compared to most other things we're working on right now.
 
 
 
* All of the "frame number" information for sim frames is now just serialized on the network and never to disk.
 
** This information is really only useful within a single run of a campaign (aka after loading it off disk and playing until you exit to the main menu or the OS).
 
** Even if you go just back to the main menu and load back into the game directly after, there's no reason not to start those numbers off fresh again.
 
** We've thus switched to a number format for serializing these that will "only" allow for 160 hours of continuous realtime play in a given campaign, without exits to the main menu.  This is the definition of excessive, and could always be changed in the future if it was needed.
 
 
 
* A variety of variables that really are only for the network, and serialized but not to disk, now have the prefix Network_ so that we can tell those apart with ease.
 
 
 
* In multiplayer, the basics of "host waiting for clients to catch up" is now in place.  This prevents the strange lag that clients were seeing, which was happening because they were back in time.
 
** However, also in multiplayer, unlike the original AI War, it will not definitely wait around for players who are missing.  If those players are not connected, then you can unpause and play without them until they arrive.  Only once they are present do you have to wait for them to sync up.
 
*** If this latter choice turns out to be problematic for some reason, we can always add a toggle for that or change it.  But it seems friendly.  Chris remembers nights where 1 person out of 4 player game couldn't make it, so just keeping on playing without them would have been so nice versus having to go in and change the status of their account before playing.
 
 
 
* Various of our "simulation profile" variables that were set a loooong time ago in a different way for multiplayer and single player were making multi-player feel sluggish.  We've tightened up this some in order to feel better under a pretty general set of networking conditions.
 
** We may need to revisit this in the future (during alpha or beta) to make these things that people can configure if they are in a situation of, for instance, high packet loss or extremely high or low pings, to get the best possible experience at any given time.
 
 
 
* Various other changes have been made in order to make the client send over commands to the host as soon as possible, and then to make sure that the host causes those commadns to be executed on the FIRST simulation frame of the next batch, not the last frame of that next batch.
 
** All in all, the game now stays in time sync, across Valve's server relays and back, and things are snappy and responsive on both the client and the host.  There are moments of delay that cause a brief "waiting" message to flash up for maybe a quarter of a second every so often, but it's really a minor thing and is something that we can improve with tuning in the future.
 
** The overall functionality is there to the point that if background threads and floating point math were not knocking things out of sync, this would be a perfectly playable alpha.  As it stands, it's quite playable for a few minutes at a time, at least on Chris's two test machines, without things becoming noticeably off.
 
** It's also worth noting that the simulation speed on the host shows up as being something like 80% right after starting the game, which is misleading because it had one very long frame where it was waiting on the client to connect and sync up.  That will be fixed in the future, but it self-resolves the visual artifact within something like 20 seconds of starting, anyhow.
 
 
 
== Version 2.122 Empire Names ==
 
(Released August 17th, 2020)
 
 
 
* *Makeshift Drones now once again self-destruct when attacking instead of only self-attritioning slowly.
 
 
** Thanks to NR SirLimbo for fixing.
 
** Thanks to NR SirLimbo for fixing.
  
* The lobby now once again allows for you to zoom in and pan around, since some maps can be larger than you can comfortably see on a single screen.
+
* Adjusted the amount of Combat Engineers Support Factories get for both starter fleets and captured fleets, balancing them a bit and bringing both spawned and captured fleets more in line:
** However, every time you generate a new map, it will default to showing you the entire map completely zoomed out.
+
** Rejuvinator: 8-13 (starter fleet remains at 10)
** It also no longer EVER allows edge-panning in the lobby, as just general usage of the lobby will wind up with you accidentally panning the lobby around if that is in place.
+
** Overloader: 4-7 (starter fleet changed from 3 to 6)
** Thanks to CRCGamer for confirming our suspicion that we'd need to do this.
+
** Everything else stays the same, but the Combat Factory starter fleet goes up from 6 to 8 engineers
 +
** This hopefully kills the bug where Combat Fleets spawn in with 2 Sentry Frigates too.
 +
** Thanks to NR SirLimbo for making these changes.
  
* Fixed ANOTHER bug with the lines being offset from the planets in the galaxy map, this time when you were zoomed in.  The more zoomed in you were, the more off they got.
+
* Added 2 more tiers to Metabolization and Greater Metabolization in preparation to additions to ESV.
** This bug was caused by our latest fix to the lines being off when you were zoomed out. Now it should work at all zoom levels. This was an annoying one, to be sure, but we're glad to have it finally lining up all the time.
+
** To clarify: This is NO new types of Metabolization but simply new conversion ratios damage/shot -> Metabolization points. By default Gangsaws for example deal 10x as many Metabolization points as they dealt damage.
 +
** The new tiers are "BigMajor" for a conversion ratio of 5x, and "SupportWithoutDPS" for a conversion ratio of 50x.
 +
** Thanks to NR SirLimbo for adding.
  
* Fix a bug where player-allied scourge weren't building properly
+
* Some minor buffs to Shark B
  
=== Multiplayer Progress ===
+
* Fix a typo in the Mesopotamia planet list description
 +
** Thanks to Lord of Nothing for reporting
  
* Added a new Human Empire Name setting on player factions:
+
=== Included Mod Updates And Additions ===
** If left blank, will be the name of the first player controlling this faction.  If you want your empire to have a different name than your personal name, you can do that here.  If multiple players are sharing a faction, then they can give it a name that represents their shared interest in it.
 
** This can be edited during the game (like player colors can be), or in the lobby.
 
  
* When a new player joins as a client to a game, it now creates a slot for them and puts them in charge of it instead of them defaulting to spectator mode.
+
* For modders reference: rename BadgerFactionUtilityMethods to FactionUtilityMethods.
** It assigns their colors properly, and all of that sort of thing, too.
 
  
* Player accounts beyond the first are now removable, which lets players go back into spectator mode, or (later) control a single faction via multiple players helping.
+
* Disabled mods and/or expansions that are installed on your machine no longer temporarily show up as enabled for just a few moments during the initial load of the game.  That was confusing.
** This makes the default case (everybody has their own faction) set itself up by default, but then lets players back things out into the less-usual cases (shared factions, spectator mode, etc).
+
** The Settings from any installed-but-disabled mods and expansions ARE loaded, so that those can be kept properly if you are enabling and disabling mods over time, but those are the only parts loaded when they are disabled.
  
* Players beyond the first are now auto-assigned a starting planet somewhat at random, letting them choose something on their own later.
+
* KM / AMU mod fixes:
** A whole lot of logic that was very not-MP-safe is now MP-safe.
+
** Fixed a very strange bug about fireteam debugging where for some reason it couldn't find the Fireteam.GetDangerOfPath() function.
 +
** Hopefully fixed another very strange null ref exception in the Marauder LRP
  
* When loading a savegame or quickstart into the lobby, or loading the last settings for the lobby, it strips out all human players beyond the first.
+
* Civilian Industries mod:
** This is consistent with it then recreating player accounts as those come in, too.
+
** Fixed a bug where Fireteams were being rude and not letting civilians use their danger pathing code.
 +
** Optimized a few pieces of code to hopefully help with the performance issues some people have been recently having.
  
== Version 2.121 Savegame Hotfix ==
+
* Fixed a literal 1-symbol-bug in Kaizers Marauders where they would not accumulate AIP but instead reset their AIP to the most recent increase.
(Released August 17th, 2020)
+
** This also lead to the discovery of a bug for the Debug Mode where Marauders produce and use real AIP that multiply AIP by the number of AIs present.
 +
** Thanks to ussdefiant60 for noticing.
  
* Fixed a deserialization bug in the prior version that made any games saved with a dyson sphere in them not able to be loaded if they were saved in the prior version.
+
* New content for the Extended Ship Variants mod and its counterpart for Fallen Spire. Do note that the latter now requires the base ESV installed!
** The nature of the issue was such that those savegames will now load without issue, thankfully.
+
** Extended Ship Variants:
** Thanks to Lord Of Nothing, CRCGamer, fatcat__25, GreatYng, Djri123, Djri123, mekolab, and goz for reporting.
+
*** Added 4 new types of Transport Flagships: Engineering (hybrid between a stronger engineer and a transport), Vanguard (hybrid between a Vanguard and a transport), Tugboat (has small drones accelerating everything to at least 700 speed and can slow down enemies) and Target Painter (long-range beam that amplifies damage dealt to a single enemies)
 +
*** Added 3 more types of Mobile Factories: Metabolizing (launches Metabolizing drones), Rescue (creates rescue-beacons that can revive ships), Translocator (good AoE explosion that pushes small ships back and paralyzes them)
 +
*** Added 6 new mobile starter fleets with ESV ships and transports included into them.
 +
*** Added 5 new support starter fleets, 3 with ESV mobile factories and 2 with vanilla mobile factories that did not have a starter fleet before
 +
*** Buffed the Agile Transport: +25% speed on entering a new planet for 5 seconds, -50% damage if attacked from >= 5000 distance, 21 gx engine to resist Black Hole machines
 +
** Extended Ship Variants for Fallen Spire:
 +
*** New Transport Flagship: Cyber Command (reduced hacking response, much more expensive, much more fragile hull but decent shields)
 +
*** New Mobile Factory: Acidic (launches drones spreading acid onto enemies)
 +
*** New Mobile Starter Fleet: Hacker Fleet (designed to deal with AI hacking responses)
 +
*** New Support Starter Fleet: Combat Engineers and Acidic Factory
  
== Version 2.120 Improved Lobby Map Experience ==
+
* Increased the timer on Kaizer's derelict to allow for a longer time period to save him. Instead of 1% health per second he now loses only 0.3%, which grants 334 instead of 100 seconds time to save him if the player so desires.
(Released August 14th, 2020)
+
** From a discussion with SilverLight on Discord.
  
* Fix a bug where sometimes the AI's ships wouldn't be allowed to retreat
+
* Updated Kaizers Marauders to be compatible with this new AIW2 version (no functional change) so players should be able to hop back in as soon as the update drops, without having to wait for an update of the mod in response to an update of the game itself.
** Thanks to Sigma7 for reporting
+
** Updated the source files on AMU.
 +
** Worth noting that the Civilian Industries mod did not actually need an update for this new version because it didn't happen to be using the features that changed.
  
* Hopefully fixed a problem where sometimes allied scourge could kill AI Command Stations immediately after a game load
+
* Fixed a type mismatch now exposed through the new External Constant Loading in Kaizers Marauders: AIAlliedInvertedTechBonusFactor was declared as FInt, but loaded as int. Is now also declared an int so it works.
** Thanks to GreatYng and ZeusAlmighty for reporting
+
** Curiously this didn't seem to have any impact on the mod in any way... Strange, but ok.
  
* Fix a typo with the Spire and Marauder Beacons
+
* ExampleMod and ExampleMod2 have both been removed from the game, as they were utterly pointless at this point.
** Thanks to Apthorpe and Ovalcircle for reporting
+
** There are more and better ACTUAL mods of all sorts for you to look at if you're thinking of getting into modding.
  
* Fix a bug where hovering the Hacking resource bar entry would give a negative number during the superterminal hack
+
==== New Micro Mod Collection By NR SirLimbo! ====
** Thanks to GreatYng for reporting
 
  
* Improve the Hacking Resource bar hovertext for the case where you have multiple hackers. Note it still doesn't show hacks against planets.
+
* Added the Micro Mod Collection mod to the off-by-default mods.
** Thanks to Lord of Nothing for reporting
+
* Currently adds:
 +
** 4 types of Distribution Nodes: 6m metal for 1 AIP, 45 hacking points for 2 AIP, 3k science points for 3 AIP, 4m metal/30 hacking points/2k science points for 4 AIP.
 +
** Energy Converters (10 for Home Command, 5 for every Economic Command Station) that convert 50k energy to 150 metal/second
 +
** Research Expedition: Mobile science/hacking gatherer that can speed up gain on owned planets but also extract from allied/neutral worlds, scout adjacent planets and at higher levels decloak/cloak itself. Fragile, high-priority target for the AI, producing 20 AIP on death.
 +
** Reinforcement Seeder: AI ship dropping Minor Reinforcement Warp Gates that increase planetary reinforcements by 5% per gate.
 +
** 3 types of AI Command Stations with escalating levels of strength: Gravitic (slow aura), Tachyon (decloaking aura) and Pulsar (periodic paralysis aura).
 +
* Balance and general feedback required and sought after!
  
* The MDC hovertext no longer mentions Exos
+
=== Work To Allow Arbitrary Sprites In Game Text, Part 1 ===
** Thanks to Strategic Sage for reporting
 
  
* Exogalactic Strikeforce speed updates:
+
* Added a working testing project for altering TextMeshPro, while retaining compatibility with all the various unity scenarios in which we use it.
** Previously, Exos had travelled at 1800 speed (as of a few patches ago. Before that they didn't have a consistent speed).
+
** Attempted three different ways of updating it to have new sprite embeds, but so far those methods were all a bustGoing to try another method of injecting our own sprites, instead, and for that we need to start basing our things on having some sprites and then shoving them in.  Thankfully we have a nice little isolated test project for this, which now has some added info in it.
** Now Exos travel at "Average speed of their units + 20%" or "800", whichever is higher. This should feel less like they are speed-racing to your homeworld. For speed-context, 800 is the speed of a Parasite.
 
*** Thanks to GreatYng and Lord of Nothing for discussion
 
  
* Fix a typo in the hovertext for larger numbers of planets
+
* Added some code in ArcenXml that lets us parse xml directly from TextAssets, mainly for testing.
** Thanks to Lord of Nothing for reporting
+
** This is also used now in parsing the sprite dictionaries that we are creating via TexturePacker.
 +
** Also set things up so that we can now have sprite dictionaries that are a single sprite loaded directly from a unity-style sprite with borders, etc, intact.
 +
*** This is useful for some of the other new icons-in-text that we want to do.
 +
** The general purpose of this is partly for test loading sprites of two different categories in a way that we can start trying to get them into TextMeshPro programmatically, but this also would be used long-term once the testing phase is past.
  
* Remove a mention of Fleet Exp in a tooltip
+
* Made a change that makes it so that if a sprite material is destroyed (such as one that was created at runtime in the unity editor) it will now just display as a blank image rather than throwing errors inside TextMeshProUGUI.  This is mostly helpful for our own internal testing of our injection of our custom sprites into TextMeshPro's rendering pipeline.
** Thanks to Lord of Nothing for reporting.
 
  
* Take safest path through galaxy now uses the modifier key alt, while take shortest path now uses the hotkey ctrl.
+
* References to ArcenSprites are now stored on their parent ExternalIconDictionary.
** The prior hotkeys of X any Y conflicted with other functions and changed your unit stances or sidebar status, etc.
+
** We never needed this before, but now that we are translating entire dictionaries into use for TextMeshPro, it's a thing.
** Thanks to Sigma7 for reporting.
 
  
=== Ability To Reset Camera View To Default ===
+
* TextMeshPro has been expanded to allow for us to inject our own images at runtime, from any source (not just Resources, but rather asset bundles and whatever else).
 +
** We can inject unity Sprite objects, unity Texture2Ds, and our own custom ArcenSprites in their entire ExternalIconDictionary.
 +
** This new capability is set up so that we can also control things like how they are scaled and offset, and essentially how the kerning works.
 +
** Whether we use all those features or not is not really relevant, but it's good to have options.
 +
** This is far more powerful than our old method of drawing images in text in TextMeshPro, which was limited to a special "Arcen Icons" font where we had vectorized some of our icons into a font format and were using that to draw icons.
 +
*** In some respects that was nice because that gave us infinite zoom on those icons, and now we're using raster images with a fixed maximum resolution, but those other icons really did not behave well when it came to trying to line up with varied fonts.  Often the offsets and kerning were terrible, and updating them at all required a rebuild of the central game executable, which is time-consuming to say the least (that's about a 40 minute wait).
 +
** This new approach allows for images to be inserted into text by mods, let alone just our own code.
  
* New hotkey in the camera section: Reset Camera Rotation And Tilt
+
* We don't yet have the new TextMeshPro stuff integrated into the main game, but it should be tomorrow.
** Default ctrl+R.
+
** For now, we've got our new data formats and are testing the last of the capabilities we need, and trying to make sure that our sprite dictionaries translate properly to theirs, which is so far not quite working right but getting close.  Single images are working great.
** Press this button combo to reset the camera's rotation and tilt to the default values.
 
** Thanks to dv, Ovalcircle, Bobtree, and many others for requesting.
 
  
=== DLC2 Backports ===
+
=== Giant Overhaul Of Xml Parsing For Accuracy And Speed ===
  
* The Dyson Sphere Golem can now be hacked like an ARS for one of a small selection of Dyson ships. You only can use this hack once.
+
* exclude_children_from_copy was not an xml feature we were using, and it was slowing down xml parsing in general, so we've removed it.
  
* The Dark Spire Vengeance Generators can now be hacked like an ARS as well
+
* The way that child nodes and attributes are determined to NOT be copied in xml is now vastly more efficient, and doesn't involve any GC churn.
 +
** This should lead to more accuracy when we pair it with some other changes, as well as faster loading times in general once we finish with our changes.
  
* This is a backport of a DLC2 feature that allows for a minor faction to have a structure which can be hacked like an ARS for unique ships. This is usable by modders with only some XML.  
+
* Really substantial xml processing speed improvements during game load.  These have to do with our checks to make sure that the xml is correctly formatting and we are importing all the proper nodes.
  
* Approximate usage: in the minor faction GameEntity XML, for the ARS-equivalent, set the following
+
* The way that attribute-checking is logged and verified is now vastly more efficient than it was, so again loading is faster in the initial part of the game.
** Assign it the HackForShipType tag
 
** Make it eligible for the HackToGrantShipLine_DontDestroyTarget or HackToGrantShipLine hacks
 
** Then add the following additional  fields
 
*** grants_stuff_to_be_added_to_player_fleets="true"                                                                                                                                                                                                                                                     
 
*** grants_stuff_to_be_added_to_player_fleets_strikecraft_options="X"                                                                                                                                                                                                                                   
 
*** grants_stuff_to_be_added_to_player_fleets_frigate_options="Y" 
 
  
* Then for the ships you want to have available, set one of these
+
* The xml parsers that were able to give back a list of children no longer do; there are instead DoForChildren methods that don't require a hit to the garbage collector, and which also make it so that they don't have to be wrappered more than once.
**  <fleet_membership name="AddedToFleet_MinorFaction" ship_cap_group="Strike" weight="100" min="30" max="35" faction="factionName"/>                                                                                                                                                                                   
+
** This is substantially more efficient in several ways.
**  <fleet_membership name="AddedToFleet_MinorFaction" ship_cap_group="Frigate" weight="100" min="1" max="1" faction="factionName"/>
 
*** Note the FactionName in the fleet_membership must match the name of the faction (I believe it checks the TracingName for the faction, which is set in C#)
 
  
=== Dark Spire Improvements ===
+
* Instead of copying xml attributes and nodes from parents to children in partial records and copy-from records, these are now linked, and calls like GetBool() and similar are able to process through them much faster and with accuracy.
  
* There's now a preliminary Journal Entry for the Dark Spire when you first see them.
+
* Added a new EqualsCaseInvariant() overload to strings based on ArcenUniversal.
+
** It turns out that this is very slightly more efficient than doing a ToLower() and comparison to the lower-case version.
* There's now a Journal Entry for when the Dark Spire enter conquest mode (ie from the Fallen Spire campaign).
 
** This explains what Conquest Mode is, and it's much harder to miss.
 
  
* The tooltip for the Locus now prints different text in Conquest Mode.
+
* Our xml parsing now gives visible errors when trying to parse integers that are not valid integers.  Before, it was just failing silently and returning the default value.
 +
** GetInt32List was removed from our xml parsing, as it was inefficient and not something we've been using in AI War 2 in general.  This was generally used in some of our older titles.
 +
*** Same with GetInt16List, GetByteList, and GetFloatList.
 +
** Also, a variety of duplicative methods that were concerned with complaining if a value was missing-or-default have been folded into the main methods for getting from xml.  We also now only complain if the value is outright missing, as in basically any case where the default value is specified that is an intentional thing.
 +
*** We have now removed the ComplainIfAttributeNotFound() method, since that was only used when we were looking at complaints about "missing or default, but actually default is fine."  This makes for far cleaner code.
  
* Thanks to crawlers for the bug report that prompted these enhancements
+
* Our xml parsing of vector3s is now much more efficient, although we do not process those very often anyway.
 +
** Our xml parsing of FInts is now a bit more efficient, and that is processed extremely often.
 +
** Our xml parsing of enums is now a bit more efficient, and more normalized (same with FInt actually), as these are processed very frequently.
 +
*** One change that may affect mods is that FillEnumIfPresent has been removed, and is now just FillEnum.  Assuming you pass in false to ComplainIfMissing, it will act as you previously experienced.
 +
*** Another is that FillEnumAndComplainIfDefault has been removed, so now you'd just use FillEnum and pass in ComplainIfMissing as true.
 +
**** This is technically a difference in functionality, because this only checks to see if something is missing, not if it has a default value (usually None or whatever).
 +
**** Generally speaking, our experience has been that if someone sets up a default value in xml explicitly, then they probably have a reason to do so.  We've been having to work around this with reading in xml in general, and now it doesn't complain about explicitly-set defaults with other data types, either.
 +
**** This should not negatively affect anything current, as any xml that was "invalid" by the old standard would have been complained-about already and preventing clean game launch.  Any new xml that is created in such a fashion is probably on purpose.
 +
*** We also got rid of GetStringAndComplainIfMissing(), which had basically the same sort of issues.  Just use GetString() or FillString() and complain if it's missing, but if someone sent in an empty string from xml, they probably meant to.
  
=== Galaxy Map And Camera Display Work, Lobby Map Overhaul ===
+
* The way that we were previously handling "custom data sets" on xml rows was incredibly slow as well as kind of brittle, particularly when it came to modding.
 +
** This is seeing an entire rework, with the pattern for getting custom data becoming far simpler (but also more powerful, as mods and copy-from and partial records will now work correctly in all cases).
 +
** First of all, the CustomDataSet class and all its methods have been removed in general.  ParseCustomDataIntoSet() and GetCustomAttributeNames() have also been removed.  Also the CustomDataLookup class.
 +
** Custom attributes are instead something that code is able to parse as-needed later on from the xml, and the "requested attributes" code just ignores anything that begins with "custom_"
  
* The galaxy object now has a a FindSpatialCenterOfGalaxyInGalaxyCoordinates() method, which lets us find the center point of the galaxy based on however the planets were seeded.
+
* The ExternalCoreConstants, which was not actually used for anything, has been removed.
** Also added FindSpatialBoundariesOfGalaxyInGalaxyCoordinates() to let us find the overall bounds easily.
 
** But actually we're going to not bother using this, turns out.
 
  
* We were also working on a CenterGalaxyOnAllPlanets() method, but we've abandoned that for a different approach. The code is mostly complete and left in for now so that we can revisit it if we find a use for it.
+
* Vector2 xml processing is now consistent with Vector3, whereas before it had only a subset of the capabilities.
 +
** Same with ArcenPoint.
 +
** AngleDegrees has instead just been removed, as it's not something we use and we can store that in different formats more easily.
 +
** Loading DynamicTableRows from xml has also been given full parity, and in addition to that they are now able to take empty commands now to set null instead of the prior row reference.  This is a new ability.
  
* The old-style cameras have been disabled for a long time (years) in xml, but we've now removed them from the code as well.
+
* We were previously using various forms of XmlElement (which is a built-in-class) manipulation in order to handle copy-from and partial records cases.
 +
** This was not appearing to work as expected, and at any rate is generally something that is probably pretty slow.
 +
** We are removing our TotallyReplaceContentsOf, CopyAttributesIntoBlanksOf, and CopyChildrenTo methods entirely.
 +
*** The CopyChildrenTo, which affects child nodes, had some notable strangeness that it was overcoming when nodes were being copied from one document to another (aka two different xml files).  We just don't need that sort of hassle.
  
* Added extensions GetWorldSpaceBottomLeftCorner and GetWorldSpaceTopRightCorner for UI RectTransforms.
+
* The ArcenXMLElement RawElement entry on ArcenDynamicTableRows has been renamed to be OriginalXmlData instead. 
** The chat window in the right hand side of the lobby in multiplayer now uses this and a world space to camera transform to calculate its ScreenSpaceLeft, which lets us, regardless of your screen resolution, DPI, aspect ratio, or custom settings in this game itself, figure out where the UI ends and avoid underlappig it.
+
** This is far more clear, and is going to be very key for the later forms of parsing that we're doing.
** Same thing with a ScreenSpaceRight on the map tab left sidebar.
+
** ArcenXmlElements now have private DirectParentsICopiedFrom and PartialRecordsLaterAppliedToMeInOrder variables that get set as-needed.  Internal processing handles these properly so that end-user modders or developers don't have to think about these details.
** Same with ScreenSpaceTop on the footer controls, and ScreenSpaceBottom on the header controls.
+
*** These help to ensure that data is applied in the correct order, as intended, and that the data can be reconstructed as needed.
 +
** HasAttribute() has been removed from ArcenXMLElement, and instead we have GetMostRecentAttributeValueIncludingParentsAndPartials() and GetMostRecentAttributeValueFromSelfOnly().
 +
*** This will seem inconvenient in a variety of places for modders, but it saves us a ton of extra read calls into a potentially expensive method (especially now that we properly handle xml inheritance).  Just read the value once, if it's a string, and if it's blank or null then that's your answer.  Or use any of the fill methods and just say you don't mind blank entries (or only do if it's not a partial record, your choice).  It will fill things properly.
 +
** During the read of nodes, it now causes either RegisterMyDirectParentsICopiedFrom() or RegisterAPartialRecordAppliedToMe() to be called, and/or OriginalXmlData to be set.
 +
*** From looking at this, in the past versions, most likely OriginalXmlData (aka RawElement) was probably being overwritten improperly once a partial record was applied, and this was probably where our errors were coming from in parsing certain mods.
 +
** Additionally, if a single xml record is defined as being both a partial record and a copy-from record, it will now throw an exception.  That should not have actually been the case on any, but now it should check on them properly.
  
* For the galaxy map camera, the zoom now lets you go out farther in the lobby, and even farther in the multi-player lobby, so that it can always fit the map entirely in the main view screen.
+
* On ArcenAbstractExternalData and its descendant classes, like ExternalConstants for instance, there is now an ArcenXMLElement OriginalXmlData property.
** Tested this with the game at 900px wide, 1800px wide, and 2560 pixels wideIn all cases we now come out with a consistent result.
+
** This one works just like the one on rows, although in this case it's just used for partial records, mainly (there are not child nodes, and there's only one root node in these files).
 +
** This then lets us make direct calls to GetCustomFInt_Slow() on the ExternalConstants singleton and similar in order to get "custom" xml data that is added belatedly, as we see for a lot of the faction data and mod data.
 +
** This particular change will require changes to most mods, as the CustomData by namespace and all that is replaced by far more direct and efficient calls here, now.  Though if the results are checked with any frequency, you should still be caching them for sure.
 +
** We are using wrappered methods, rather than giving direct access to OriginalXmlData, in order to control error handling and make sure that if your mod is looking for a field and fails to find it, it will yell.
 +
*** Bear in mind these particular fields are not found at game launch, but rather whenever the faction or mod initializesSo typos are likely to be cause errors during first unpause with a faction present, rather than during load of the initial game like everything else.
 +
*** The extra error handling that is in this is absolute crazy, incidentally, so if you're not getting the result you expect, then you automatically get an entry in the log with the details of what was present so that you can figure out what your typo was.
  
* Fixed up a bit of logic for the dynamic zoom for resolutions smaller than 1200px x 900px.
+
* With external constants and similar dictionaries, it now ensures that the base data is now read in before any partial records are read.
 +
** It seems like someone was referring to this being hard to mod, and this would likely solve that.  At any rate, with our new more-strict reading this also became needed in general.
  
* In the lobby, the galaxy map camera no longer responds to mouse or keyboard input at all.  This is an overhaul that has been requested for years and years.
+
* With the new XML parsing, the game does a far better job of reporting problematic data from xml (aka something like a floating point number being imported into an integer field).
** Now the lobby always has the map as zoomed out as it can.
+
** Why this was not working properly before is a bit of a mystery, but it works now, which is the important thing.
** It is also centered in whatever the available space is (depending on if the right-hand sidebar is there or not, that may or may not be centered on the actual screen).
+
** There were several bits of rogue data that we've thus fixed, including the amount of extra intensity the scourge gets from human science amounts.  This may have some balance impact on the scourge, as those values were probably previously reading in as zero.
** This is extraordinarily useful, in that it lets you cycle through maps with ease, and there is typically not too much detail that you need to see in them like you would during an actual game.
 
  
* The math for how much the galaxy camera should be able to zoom out has been entirely re-coded from scratch, and is now vastly more efficient as well as something we can actually follow.
+
* Full list of data fields now corrected that were previously not reading in properly and thus probably affecting faction performance in some fashion:
** Instead of taking something like a thousand loops to get a kinda-bad answer, it now takes typically under 60 loops (often under 20) to get a highly accurate answer.
+
** Scourge difficulty:
 +
*** AllowedBuildersIncreasePerScienceUnit (was always 0 because of type mismatch)
 +
*** BuilderIncomeIncreasePerScienceUnit (was always 0 because of type mismatch)
 +
*** SpawnerIncomeIncreasePerScienceUnit (was always 0 because of type mismatch)
 +
** Human Resistance Fighters
 +
*** RatioForFriendlyPlanet (was always 0 because of a typo - RxatioForFriendlyPlanet)
  
* In the galaxy map display calculations, and number of strange magic numbers were removed, now that we have the proper math in here. Wow this was unexpectedly hard.
+
* In the event of partially-mangled data from entity systems, the game now does a bit better job of reporting clearly what the problem is with the xml and setting some general defaults rather than just starting in a completely invalid state.
 +
** This is most notably with a missing range being set on a system.
 +
** Additionally, we've added a new WriteSystemDataToLogDueToError() onto GameEntityTypeData, to let us see what the state of all systems on an entity are when a problem arises.
  
* At very long distance zooms, the planets were STILL being visually offset from their lines that they were above, it turns out.
+
* There was some funkiness in how some of the passive systems were looking for ranges that they did not need to have, in ComputeBalanceStats_OneTimeOnly(). Those have been corrected/
** This had to do with how we were offsetting the icons in order to avoid z-fighting, and how that was getting magnified by us scaling up the planets at further zoom distances.
+
** This is a case where we wonder how this was not causing errors in the past, but whatever.  Again, it works now.
** The fix for this might introduced some z fighting, but probably will not because of the way that we are rendering these as "cutout" style transparency, and with GPU instancing determining the order of draw.
 
  
* In the lobby, the planet you own is no longer ringed in white selection, as the in-game "planet you are on" is done. Now it just shows the planet color, plain and simple.
+
* Further cases of fields that had malformed xml and thus did not read in properly:
 +
** Settings:
 +
*** Windowed Mode Window Height maximum (typo of case Max instead of max led to it being infinite rather than 7000).
 +
*** Kaizer's Marauders Marauder_DebugID, same typo of Max.
 +
*** Hidden field of FullscreenHeight, same typo of Max.
 +
*** Kaizer's Marauders Marauder_FireteamDetailLevel, same typo of Max.
 +
** AI Types:
 +
*** SimpleEnsemble was not having its type_Difficulty read in, because it should have been type_difficulty
  
* In the lobby, if you have the setting "always show planet names" on, it still won't do that, because that will make the fixed-size galaxy map potentially impossible to read.
+
* The game now allows any fullscreen resolutions that your OS/hardware reports as being available.
  
* The galaxy map in general shows planet names that are un-owned as being far less blinding white in their text.
+
== Version 2.627 Hotfix ==
 +
(Released November 5th, 2020)
  
* In the lobby, it no longer shows the first owning player name under the name of the planet.
+
* Hopefully make Warden fleet ships less likely to turn to the Hunter when in combat
 +
** Noticed by a lot of people
  
* The visual scale of the actual planet spheres in the lobby is now about a two thirds what it previously was, but the text is almost as large as it was before.  If the text is too small, we can adjust it up.
+
* Make reconquista a bit less one-dimensional.
  
* In the lobby, hovering over a galaxy map link no longer highlights the two planets adjacent to it, since that is visually confusing in that context only.
+
* Fix a bug where the galaxy map was showing the wrong faction colour for enemy units.
  
* Added ShowTooltipNarrow() and ShowTooltipWide() to the IPresentationLayer and IBattlefieldHandler, so that we can trigger tooltips super-directly from deeper-in code.
+
* Fixed a bug in the prior version where the scrollbars and scrolling in any dropdowns was not working.
 +
** Thanks to JonnyH13, Karchedon, and Badger for reporting.
  
* In the lobby, hovering over planets now makes it show a tooltip at the mouse cursor that says the name of the planet (since that might be obscured by being very near the top of the screen, now), but also some other information.
+
* The selected status of the stance buttons in the bottom left of the screen have been adjusted once again in order to be dimmer and less distracting.
** It says how many wormholes there are, and gives a comment if that will be extra hard to defend.
+
** Thanks to Metrekec and crawlers for reporting.
** It also shows the name of any human  players who are going to have that as their starting planet, in their appropriate colors based on their faction color.
 
** There was some funky stuff in the hover logic for the galaxy map that made this super difficult.
 
  
* Fixed a funky bug relating to tooltips that were showing the same text as before, but had themselves cleared and then wouldn't keep showing the text anymore until it was given different text.
+
* Balance Adjustments to Kaizers Marauders:
** The first time this ever manifested was in giving tooltips on the lobby galaxy map, but it's an old old bug.
+
** Changed the budget income modifiers per intensity to be based off the 0.4 + (AI income/1.5):
 +
** Also increased higher-intensity base defense buildup cap: Medium Intensity from 40 strength to 50 strength, High Intensity from 70 strength to 125 strength to make them more defensive.
 +
** When their budget was increased gradually to compensate for the high growth of strength that high-ranking AIs had it made them too powerful when fighting lower-intensity AIs.
 +
** Now, hopefully, Kaizers Marauder intensity roughly follows the same scaling as AI difficulty, but lower ranks are still supposed to expand further and by comparison are stronger.
 +
** When picking the intensity for Kaizers Marauders I suggest: Think about their most likely adversary (the AI) and their difficulty as a base line, potentially increase to compensate higher-difficulty AI types and other minor factions to fight.
 +
** Kaizers Marauders definitely need balancing feedback!
  
* Fixed an issue in the lobby where it was not showing the names of planets automatically for planets owned by players other than yourself.
+
== Version 2.626 Kaizer's Marauders ==
 +
(Released November 4th, 2020)
  
* The map types list in the lobby has always been kind of randomly organized, which was annoying. More recently, it has been in a different order every time you start the game.
+
* Underlying mechanics now available for mods, but not used by any units at the moment:
** Now it is in the order Realistic, Simple, and then all the others alphabetically.
+
** Added the Classic (AI War 1 style) Hydra regeneration and Hydra Head mechanics.
 +
*** Regeneration is done with: seconds_to_fully_regenerate_hull="" and starts after the normal repair delay.
 +
***  Hydra Heads are done with build_points_per_damage_taken="" and unit_to_make_with_build_points_from_damage_taken=""
 +
*** A head will spawn when build points = total health, / current mark + 1. So a MK1 unit will spawn 1 head at 50% health, a MK2 will spawn every 33%, MK3 every 25%, so on.
 +
*** Current bugs with Hydra Heads: Build points are not serialised and so are lost on load. If a unit with a damage bonus shoots one of these, only the base damage adds to Build Points, not the bonus.
 +
** Thanks to Puffin for adding this.
  
* Fixed a bug when loading directly into the game and not visiting the lobby where it did not set the dynamic zoom properly in the last few internal builds.
+
* Drone Fleets (Support Fleets, but most importantly Hive Golems) will now load their drones if ordered so even if enemies are on the planet left.
 +
** Thanks to NR SirLimbo for implementing.
  
* Also fixed a boneheaded typo in the very most recent internal versions that was making the height of the dynamic zoom calculation slightly off.
+
* Journals now allow for the insertion of [playername] in them.
** There is still something a bit off with the squares map type and how it displays in the lobby (it is offset upwards and also shown too small), but all the other map types work and so this seems to be some sort of data issue with that map type and not a problem with our central algorithm.
+
** Thanks to Badger for adding.
  
== Version 2.117 Ion Cannons And Melee Units ==
+
* The FRS now uses a different icon from ARS, to avoid confusion and make it clear what is what.
(Released August 11th, 2020)
+
** Thanks to Badger for suggesting.
  
=== Balance Work ===
+
* Combat Factories of all sorts no longer use normal drones like before (those aggro guard posts in an annoying way).
 +
** Instead, hidden drone launchers trigger if there are enemies within a certain range of the combat factories.  Letting them defend themselves, but not aggro enemy guards just by being on their planet.
 +
** It's worth noting that existing savegames will still have both kinds of drones present -- those in the fleet, and those from the launchers.  So they will be double-powerful but still annoying.  Any new campaigns will just have the launchers properly.
 +
** Thanks to several people for bringing up this issue with combat factories, and Puffin for helping fix it.
  
* Ion Cannon Shots can now:
+
=== UI Reskinning Part 4 ===
** Damage both the personal shields and hull of a target in one shot (including killing it outright).
 
** Kill multiple ships in the same stack in one shot.
 
** Thanks to GreatYng for pointing out the oddity of Ion Cannons not being able to do these things.
 
  
* AOE shots can now hit any enemy bubble shield overlapping the explosion, rather than only being able to hit the shield if the generator (or something it's protecting) were physically within the explosion.
+
* There are still some little things we want to do with the UI, mostly in the "nice to have" category.  The general overhaul is complete, in terms of improving things that were already there.
** Thanks to NRSirLimbo for reporting and RocketAssistedPuffin for the save.
+
** There are a VERY few cases where the old resource icons are used in text, but that should still be easy enough to figure out.  We're going to sort that out with new icon-embedding capabilities sooner than later.
  
* Crippled units (i.e. player flagships) can now pass through enemy bubble shields and traverse wormholes covered by them, to avoid being stranded in hostile territory.
+
* Fixed an issue where the border bar on the selected ships window would move up and down as that window got larger or smaller.
** Thanks to tadrinth for reporting and RocketAssistedPuffin for the save.
 
 
 
* Melee units in attack-move mode will now go after units within a limited range (equivalent to a weapon with range=Normal1), so you have a middle-ground between "only attack your direct target or things actually touching you" and "pursue anything on the planet".
 
** Also, even when not in attack-move mode, player melee units without orders (and not in hold-fire mode) now automatically move to attack nearby targets. If all such targets die or move away, the melee unit goes back to where it was.
 
** Thanks to OzoneGrif, wm46, RocketAssistedPuffin, and Ubifan for the suggestions and saves leading to this change.
 
 
 
* Fixed a bug where deathgrip tackle drones had a gun that could shoot immobile targets, greatly confusing their logic. That gun now has the only_targets_mobile_units flag.
 
** Also fixed a bug where tackle-drone-launchers could give their spawned drones a direct attack order to go after an immobile unit.
 
** Thanks to tadrinth and RocketAssistedPuffin for the reports leading to these discoveries.
 
 
 
=== Bugfixes ===
 
 
 
* Scourge: fix a bug where player-allied scourge were building tons of Builders but no Fortresses (they were mistakenly thinking they were minor faction allied)
 
** A number of people on discord noticed the lack of Fortresses
 
 
 
* Potentially fix a bug where Regenerator Golems were regenerating things while crippled
 
** Thanks to crawlers for reporting.
 
 
 
* AI Reserves now will create anti-player zombies.
 
 
 
* Take another stab at 'adjacent planets watched'. Sigh.
 
 
 
* Fixed an issue where on computers without GOG Galaxy installed, they would get a harmless-but-annoying error message at game startup.
 
 
** Thanks to Badger for reporting.
 
** Thanks to Badger for reporting.
  
* Minor tweak to target list planning; use a case insensitive comparison for zombification.
+
* The glowing states of the following icons in the new UI has been dimmed some:
 +
** Attack move (leftmost item), pursuit mode, stop and shoot mode, hold fire mode, scrap button.  Group move has been left alone.
 +
** Thanks to Metrekec, crawlers, and Isiel for suggesting.
  
* The 'total units' count should now include stacks.
+
* We missed updating the map tab left panel in the lobby, but it now has a proper background and fonts.
  
* The AI "Great-Turrets" are now simply called "Turrets" again, as at this point balance-wise the player turrets and AI turrets are similar.
+
* Updated some prefab buttons so that things like the font in the Tips window now use the expected new font.
** Thanks to GreatYng and RocketAssistedPuffin for bringing this to our attention.
 
  
* Exogalactic War Units now use a better spawn-in message than before
+
* The visual style of dropdowns in the game has been updated to match the new style of buttons and other elements, and looks much more sleek.
** Thanks to zeusalmighty for reporting
 
  
* Fix a problem with the Custodian description text
+
* The visual style of horizontal sliders in the game has also been updated to match the rest of the new stuff.
** Thanks to GreatYng for reporting
 
  
* The semicolon was previously not supported by our chat log format (our "condensed ascii"), but now is.
+
* The tooltip backgrounds have in general been updated to look more like the rest of the new UI.
** Thanks to Badger and Sigma7 for reporting.
+
** We are opting not to do specific graphics for the planets versus the ships, at least not built into the UI panels per se.  We'll handle that stuff via image insertion in text, most likely.
  
=== Multiplayer And Lobby Work ===
+
* The icons for metal harvesters, and energy generation sources, have been updated to the new icons.
 +
** Same with science (not used as a ship icon anyhow) and "metal to energy," which is.
  
* Heartbeat messages from the client to the server and vice-versa are now omitted from all of the networking logs. They were making things far too cluttered for us to be able to see real information when we had network logging of various detail levels turned on.
+
* Color improvements to notifications in the top bar.
 +
** Essentially, notification colors being based on the faction that is discussed is something that looks like it means something else.  It looks like red is extra bad, or things like that.  We are using color to mean something with the backgrounds and icons up there, and so the text also having color is just problematic unfortunately.
 +
** We are largely moving the color that was on the text to instead be in the tooltip text.
 +
** Astro train faction color moved from notification text to tooltip text for notification.
 +
*** Ditto Dark Spire VG notification, although the timer colors are still there.
 +
*** Ditto Dark Spire Loci notification.
 +
** Things were fully changed with the color from the tooltip for the Dyson Antagonizer.
 +
*** Ditto exostrikes.
 +
*** Ditto exogalactic wormholes.
 +
*** Ditto AI eyes.
 +
*** Ditto raid engines.
 +
*** Ditto instigator bases.
 +
*** Ditto Zenith Trader.
 +
*** Ditto macrophages.
 +
*** Ditto AI relic trains.
 +
*** This was done previously for the Devourer.
 +
*** Relic search was already fine.
 +
*** Debris was already fine.
 +
*** Imperial Spire was already fine.
 +
*** Brownout was already fine.
 +
*** Nemesis was already fine.
 +
*** DLC2 AT civil war was already fine.
 +
*** DLC2 Nm were already fine.
 +
*** DLC2 Zm were already fine.
 +
*** DLC2 Zb were already fine.
 +
** AI Reserves are keeping their colors for now, in their countdown timer, but if it looks bad or you have feedback on them, please let us know with a savegame.
 +
*** The same is true for counterattacks.  Additionally, the icon on these grays out when the counterattack is stalling.  This may be confusing people, so we may change this up some.
 +
*** The same is true for hacking notifications.  Please let us know if the timer colors look tacky, but the faction bit got moved.
 +
*** Also same for risk analyzers.
 +
** The planet attack notifications actually show the colors of the attacker and the defender, so keeping those makes a fair bit of sense.  Let us know if it looks awful sometimes.
 +
** DLC2 AT warnings had some mild colorization based on severity, but we were already handling that with the background in recent versions, so the text color is now just always white.
 +
** Overall we need to do more things with the notification icons themselves very soon.  This has been on our list since prior to DLC1.
  
* Some excessive logging on GOG and Steam with regard to their send result statuses has been removed, as again this was clogging up our network logs.
+
=== Additional Space Backgrounds By Puffin ===
  
* The clients now have a secondary FromClientToServer_SignalDoneButHasNoCommands that they can send in place of the FromClientToServer_SendMyNextCommandBatch when they don't have any commands to send (which is most of the time, statistically).
+
* Thirty new space box backgrounds for planets created by Puffin have been added to the game.
  
* GameSpecificNetworking now has a DoPerFrameLogic() method, which lets us efficiently set some per-game settings like we do for the arcen debugging stuff.
+
* Six new space box backgrounds for the galaxy map created by Puffin have been added to the game.
  
* New setting in the Network section of the settings menu: Network Logging Includes Frame Auths.
+
=== Revised AIP Mark Level Thresholds By Difficulty ===
** In the lobby and during gameplay, there are messages sent by the network every 100ms or so to keep themselves in sync, and if you have them included they will tend to crowd out the rest of the messages that are sent.  So by default these are disabled.
 
  
* New setting in the Network section of the settings menu: Network Logging Includes Command Batches.
+
* The AIP amount required for an AI to go to a higher level used to be as follows: https://bugtracker.arcengames.com/file_download.php?file_id=15174&type=bug
** In the lobby and during gameplay, there are messages sent by the network as frequently as every 100ms, but more often some sporadic multiple of that.  This is how factions tell everyone what they want their ships to do, and how human players say the same.  There's very little that we can say about this in a meaninful way in the networking log level, and again this will tend to crowd out the other messages that happen.  So by default these are disabled, but bear in mind that most things that players actually cause to happen are being caused through these batch messages.
+
** We are making the following changes:
 +
*** Mark 3:
 +
**** Diff 4: 295 from 305
 +
**** Diff 5: 275 from 295
 +
**** Diff 6: 255 from 285
 +
**** Diff 7: 235 from 275
 +
**** Diff 8: 215 from 265
 +
**** Diff 9: 195 from 255
 +
**** Diff 10: 175 from 245
 +
*** Mark 4:
 +
**** Diff 4: 470 from 480
 +
**** Diff 5: 450 from 470
 +
**** Diff 6: 430 from 460
 +
**** Diff 7: 410 from 450
 +
**** Diff 8: 390 from 440
 +
**** Diff 9: 370 from 410
 +
**** Diff 10: 380 from 420
 +
*** Mark 5:
 +
**** Diff 5: 650 from 670
 +
**** Diff 6: 650 from 660
 +
**** Diff 7: 640 from 650
 +
**** Diff 8: 620 from 640
 +
**** Diff 9: 600 from 630
 +
**** Diff 10: 590 from 620
 +
*** Mark 6:
 +
**** Diff 5: 810 from 820
 +
**** Diff 6: 800 from 810
 +
**** Diff 7: 790 from 800
 +
**** Diff 8: 780 from 790
 +
**** Diff 9: 770 from 780
 +
**** Diff 10: 760 from 870 (the original was an error in general)
 +
*** Mark 7:
 +
**** Diff 6: 1100 from 1110
 +
**** Diff 7: 1080 from 1100
 +
**** Diff 8: 1060 from 1090
 +
**** Diff 9: 1010 from 1080
 +
**** Diff 10: 980 from 1070
 +
** Thanks to Ovalcircle for reporting the discrepancy, and to Badger for suggesting these numbers get a bit of a look in general.
  
* Found and fixed a general issue where the player accounts were not properly being cleared (and fully resetting the player account IDs) during all cases where a game is loaded into the lobby.  At a bare minimum, it was affecting the "open a custom game with my last settings."
+
=== New Included Mods By NR SirLimbo ===
** That would have eventually led to out of bounds exceptions, over time, and in general was cluttering up some areas important for multiplayer, but it had not had a negative impact on anyone so far.
 
  
* Fixed a bug that was causing all sorts of craziness on clients in multiplayer in the lobby, with them not getting their galaxies full cleared.
+
* Uploaded the AMU (AI War 2 Modding Utils) and Kaizers Marauders mods.
** This was leading to things not being properly in sync between the client and host, like planet names or locations, and things like extra planets or planets in old locations, or noninteractive planets at a whole other scale visually from the real planets. It was quite messy!  All of that is now corrected, thankfully.
+
** Kaizers Marauders is a new spin on an old faction gone, for lack of a better word, insane. Expect an entirely new Marauder minor faction with its own unique ships, turrets, superstructures, new and improved raiders and tons more. The forum thread is here: https://forums.arcengames.com/ai-war-ii-modding/mod-kaizers-marauders/
 +
*** It started out as a request to the AIW2 devs to include journals. So I wrote some mods. Months later it's turned out to be a full rework with TONS of special stuff added and everything is in - except for a hand full of journals. Wow.
 +
*** Some highlights: Unique Marauder ships, turrets, forcefields, etc. Most of these can be acquired by the player for themselves.
 +
*** Some featured mechanics: A realistic metal economy, defectors, super-smart fireteams, tech upgrading, and even an alternate victory condition.
 +
*** For more check the forum thread.
 +
** AMU is a requirement for Kaizers Marauders and consists out of modding functions to be used by various other mods, even further reworks I'm planning todo, as well as any other modder. It will get a full documentation and forum thread, but for now simply ping me on discord (-NR-SirLimbo) for debugging it. A partial documentation is already distributed, along with the C# project itself.
  
* In the lobby, when you change the number of human factions, it now regenerates the map immediately.  For other factions it does not bother, never has, because there's nothing different to see at this point in the galaxy.
+
=== Bugfixes ===
  
* The WorldSetup objects now have a readonly SetupTypeName on themselves, so that we can tell what they are.
+
* Fixed Lone Wolf fleets being excluded from the ability to load ships. If for whatever reason (mostly mods) ship lines end up in Lone Wolf fleets they will now obey loading/unloading orders entirely and not hug the centerpiece perpetually
** ChangedSinceLastMapGenCall on this same object is now a property, which lets us throw out debugging messages when it is being triggered for whatever reason.
+
** Thanks to NR SirLimbo for fixing.
** Something has been causing extra calls to be sent through the map generation pipeline in a redundant fashion that makes everything slower than it needs to be.
 
  
* Removed the ability to send a WorldSetup object via GameCommand, as that is actually highly antithetical to the way we edit that data as of the last year and a half or so.
+
* Updated StarKelp Civilian Industries for the latest version of the game.
** We specifically try never to adjust the entire thing, because several players at once could be editing different parts of it and we want those bits to all merge at once.
+
* Fixed a race condition that could occur when setting militia caps.
** Got rid of the SetupOnly_ChangeSetup GameCommand, which was set to use this sort of thing.
+
** Thanks to various people for reporting, most notably SirLimbo.
** Got rid of the LobbyWorking_HasBeenChangedAndShouldTransmitChanges() method on WorldSetup, which was being used by a loop in the footer to keep clients up to date.
 
*** The problem with this is that this was far older code, back from perhaps 2017, and it was using an older and more sledgehammer-y approach to try to keep clients and the host in sync.  When the lobby was redone in 2019, this became obsolete but was still hanging around and so caused some nontrivial chaos.
 
** LobbyWorking_HasBeenChanged() has also been removed, as it seemed duplicative and was no longer in use perhaps?
 
*** Oh goodness, this was actually how we were ever updating the long-term stored version of the game (as opposed to the lobby working copy).  This was not a good way to do it, but it was not quite as antiquated as we thought.
 
  
* Fixed a rare nullref exception that could happen in the ships sidebar if you were not properly on an actual planet.
+
* Fixed multiple places not having reservations for Lone Wolf fleets (both officer and golem):
 +
** CalculateContentsCount(bool IsForNetworkSyncCheck)
 +
** CalculateHasAnyContents()
 +
** GetStrengthOfContentsIfAny()
 +
** GetEnergyCostOfContentsIfAny()
 +
** Noticed and fixed by NR SirLimbo when unloading a fleet of Kaizer's Marauders-boarded ships began to cause brownouts...
  
* Fixed an issue from the last few months (probably) where if you had an error during map generation, it would still try to dump you into the world and then give you tons of other errors.  It should have been stopping you and making you fix whatever was wrong.
+
* For Extended Ship Variants: Fixed the Strike Wing having its damage bonus based on target time on planet, not its own time
** This is most common when there are not enough planets for all the factions you have chosen, or a few other rare cases.  One such case is just discovered internally, and that's you having a planet starting index that is higher than the number of planets currently in the world.
+
** Thanks to zeusalmighty428 for wondering why it was raid tech
  
* Helper_AssignHumanHomeworld() and the AI variant are now Helper_TryAssignHumanHomeworld() and an AI variant.
+
* Put in a fix for various of the new shaders for UI glows logging "doesn't have _Stencil property" warnings logged into the player.log.
** It was already quite possible for these to fail if the player had selected something invalid, such as previously having clicked a planet with an index above 40 and then choosing a map size of 40 planets.
+
** We aren't actually using this property, but then again we're not allowing for these buttons to interact with stencils and masks and so don't need it.
 +
** Thanks to Puffin for noticing this.
  
* The game now auto-assigns humans a planet that is valid if they don't have a valid option, and it does so in a multiplayer-compatible fashion.
+
== Beta 2.624 Revised Resource Bar ==
** Previously this tried to do the assignment, but did not do so in a way that worked, and even if it had worked it would have only worked for one player.
+
(Released October 30th, 2020)
** This also includes a new sub-gamecommand, StartingIndex_FromAutoAssignInMapgen, which efficiently lets the UI know what is happening without triggering an extra map generation cycle or accidentally overriding a distinct change made by the player.
 
  
* The lobby is now substantially more responsive even in single player, although it seems to be having some extra calls that we are still hunting down.
+
* When AI units with Metabolization kill something, the AI now uses its extra metal to boost its reinforcement budget
 +
** Prompted by a discord conversation led by TechSy730
  
* Fixed an annoying issue that was causing an extra regeneration of the map to happen when you first went into the lobby in single player or as the host, leading to the lobby load time being half a second or so longer than it should have been.
+
* Tsunami CPAs are now the default.
  
* Fixed an issue where if one person in the lobby adjusted the following fields, it would not be reflected for the other players in the GUI (but would in the map itself):
+
=== Roguelike Changes ===
** Planet naming style.
 
** Map type.
 
** All of the other map sidebar controls were showing things properly and also able to be controlled from any client or the host.
 
*** Do bear in mind that if you manually enter a map seed, it won't appear for the other players until you hit "Regenerate Map," but given that does not actually affect the map until that button is pressed, this should not be overly surprising.
 
** All of the faction controls and their sub-controls have been workign properly from the start, and still seem to be.
 
** Same thing with the galaxy option controls (all of them), which is pretty exciting.
 
  
* The "Campaign Name" is something that is only for savegame management, and thus is only relevant on the host side. The clients now see "Will be set by host" as the text in that box, and cannot change it.
+
* By default, the Esc menu no longer tells you what factions are in the galaxy until you actually encounter them in game. The goal is to give the game a stronger feeling of exploration and finding the unknown.  
 +
** You can have the old behaviour by enabling the Always Show Factions option under Scouting in the game lobby
  
* The "Start Game" button is also something that we are limiting to be host-only, for a variety of reasons. The biggest is that they need to set a campaign name, but that's entirely host-side.
+
* Add a new Quickstart, "The Rogue Badger" taking advantage of this. You won't know what factions are in the galaxy till you find them
** Clients clicking this button now get a message that asks them to wait for the host to do it.
+
** Please don't load this quickstart into a game lobby or it will ruin the surprise.
** Actually, for the sake of ease of use, the "Reset To Defaults" button and this one are just hidden on clients in multiplayer.  Clicking Reset to Defaults on a client results in an error for a lot of good reasons based on how it is trying to accomplish that.
 
  
* All of the lobby controls now seem to work properly for both the host and client.  There are still some things in chat that are messed up, and we're missing controls for making clients not always be spectators, but we can also get into the game.
+
=== Quality of Life ===
  
* Fixed the harmless but annoying "StartingIndexChanges: factionIndex 1 passed when faction count was 0" error message that would happen on clients after a host gave orders to start.
+
* In an ARS, GCA or fleet you could capture, the number of ships for a given ship line is now coloured to let you know how good the roll was
 +
** If the number is a bright green you rolled close to the upper-end of ships you could have. If its a dark green, you rolled closer to the lower end.
 +
*** Only applies to newly started games
 +
** Thanks to ParadoxSong for pointing me in this direction
  
* The campaign name and its textbox is now just plain invisible for clients in a multiplayer game, again to avoid confusion.
+
* Capturable flagships adjacent to the player homeworld will always get good RNG with how many ships it has.
 +
** The goal is to make sure the player gets something to be excited about early. Also to make it harder to have games that are screwed by bad RNG
  
* The right-hand sidebar in the lobby in multiplayer is now split into two scrolling parts.
+
* The selection window now shows the strength of the selected units
** The top part has information about the connected players and the factions that they are a part of, and never auto-scrolls around.
+
** Thanks to TechSY730 for suggesting
** The bottom one has the actual chat messages, and auto-scrolls to the bottom when new messages come in.
 
** The fonts of both are a bit smaller, from size 12 down to 10.
 
  
* From past changes, we can now verify that the proper name shows up for clients on the host, instead of it just saying "Player 2" for them.
+
* Improve the hovertext for factories for more clarity. The name of the fleet now indicates how many losses it needs to rebuild
** However, text messages from the client in the lobby show up with the color of the client but the name of the host?
 
  
* Hitting enter while in the chat textbox in the lobby now actually sends the chat properly, as already worked in the main game.
+
* Improve the AI Reserves notification
 +
** If there are no wormholes spawned, it gives you the countdown of seconds until a wormhole spawns
  
* In the multiplayer lobby, the top panel now shows the status of the various PlayerAccounts that are in a game.  Specifically it shows any who are connected or disconnected, or which ones are you, etc.
+
* Autosaves are now in a more readable format
** It also shows players that have an account in this game at the moment, but who are absent.
 
  
* Fixed a bug where player accounts were being created with the name of the host, not the connecting client, which was confusing all sorts of things.
+
* The objective hovertext for ARSs is now in a better style
  
* The preferred colors from the player profile on each local machine is now sent over and applied to their player account for later reference.  This was also causing endless new player accounts to be created, since there was never a match to the connecting client.
+
* If you double-click a fleet's keybinding while in the galaxy map, it now centers the galaxy map at that fleet
** A variety of pieces of code had to be updated to support this.
+
* Clicking a Planet Under Attack notification from the galaxy screen, it now centers you on that planet
** Apart from them selecting a color for their faction, this gives them a chosen color in text chat.
+
** Thanks to Vortex for these two bug reports
  
* Added a new OnEndEdit() event for text input boxes, which lets us trigger things when a player clicks out of a textbox.
+
=== UI Reskinning Part 3 ===
** This now happens for the map seed in the galaxy map, same as with hitting enter, as both now trigger an immediate regeneration of the map (without you having to hit regenerate map manually).
 
  
* Faction colors for player factions now come from the network data rather than just the local data, which is important for multiplayer.
+
* The bottom left icons on the main screen are no longer quite as glowy when you are not hovering over them.  They light up the same amount while hovered, though.
 +
** The idea is to make it less visually distracting when you are just checking the game clock.
 +
** Thanks to Badger for suggesting.
  
* Fixed the bugs with lobby chat messages not appearing properly on the client and host in various ways.
+
* The ship selection UI has been updated so that the icons are the same as before, but they now have similar glowy appearance to the buttons in the bottom left of the screen.
 +
** The "hotkey indicators" are now colored to match the button's general highlighted color, but the baseline color is now that same dull blue rather than bright white like it was before.
 +
** When these are highlighted, they now glow brightly in their specific color, and if they are moused over the same thing happens.
  
== Version 2.116 GOG Networking Done ==
+
* The sidebar backgounds have been reworked to better function with the different heights that they can all have, rather than looking really wrong and off when stretched.
(Released August 6th, 2020)
 
  
* Fix a bug where the 'Watch Extra Hops Worth Of Planets' code was being applied incorrectly
+
* In the top bar, the galaxy map icon has been reworked, and now looks like a galaxy rather than a map pin.  It also now glows and reacts to mouseover.
** Thanks to Tynendir for reporting.
+
** The hover for the planet name now also highlights the background of that button in the top bar in general.
 +
** The metal icon has been replaced (anvil becomes metal pieces).
 +
*** Note that metal harvester icons still need to be updated, and metal icons in text.
 +
** The energy icon, and science icon, and hacking icon, and threat icon have also all been updated.
 +
** The old threat icon is the new AIP icon.
 +
** Thanks to Badger, Puffin, -NR-SirLimbo, Tzarro, and zeusalmighty for all helping figure these out.
  
* Fixed a bug where Macrophage Spores don't move to new planets when loading a second save game.
+
* The various fonts in the sidebars have been updated to be more legibile at smaller sizes in particular.
** Thanks to GreatYng for reporting, and StarKelp for fixing.
+
** Some were returned to the way they previously were, others are new.
 +
** Thank to Strategic Sage for reporting the grainy appearance and eye fatigue with the other new bits we tried.
  
=== Milestone: GOG Galaxy Networking Integration Complete! ===
+
* In the top resource bar, all of the text and numbers are in a new font that is a bit clearer and quicker to read.
 +
** In times where the metal would say "Starving" in the past, it now says "Drain" to save space.
  
* The Arcen GOG Wrapper has been majorly updated to get your GOG Galaxy Friends list and the status of them so that you can play multiplayer with them if you want to.
+
* The hacking and tech sidebars now use the correct image, and also react to hovering with a glow.
  
* When you are in the GOG networking mode, it now shows the list of your friends, just like it does for Steam.
+
* The background from the load menu has been kept the same, but is now vastly darker rather than being bright and in your face.
** Basically all of the functionality is identical here, in terms of how it shows those who are online, offline, and in-game, and lets you filter between them, etc.
 
** The one difference is that in Steam we show the "in this same game" status as a light green (like Steam does), and in the GOG version we show that status in a purple color (to match their color theme).
 
  
* The host computer now is able to open up a lobby for friends when it says "open server."
+
* The background for the save menu has been made to match that of the load menu, and is also now darker like the other one is.  The other one was particualrly tacky and distracting.
** This works with all the various NAT punchthrough that GOG Galaxy supports, which we are not entirely clear on the details of.  This may be as robust as Steam, or slightly less so, but we honestly have no idea.  We'll be interested to hear from you!  But either way, it's out of our hands at that point, so it's just information gathering.
 
** The host is also now properly destroying the lobby when it shuts down, so that others won't try to connect to it and not see it.
 
  
* When clicking the Join menu in GOG, the client now sees lists of their friends with four categories instead of just three.
+
* Fixed a minor issue with the notifications not being properly rounded up in the top area.
** Friends who are in-game but not in a lobby right now are showed in a dull light purple.  Friends who are in game and have an open lobby show up with a bright purple status.
 
** You can also cycle through all friends, open lobbies, friends in this game, and online friends.
 
  
* In the listing of connections, for GOG it now shows a button that says "closed" instead of "connect" next to each friend who does not have an open lobby.
+
* The game has been updated to actually set and use the fancy new priority level backgrounds for the notifications in the top bar.
** With Steam, someone could be in offline status but still let you connect to them.  With GOG, we have to have a lobby ID to connect to, so there's no way to hide that and still even attempt a connection to someone.
+
** Bear in mind that this is something that we may tune over time based on feedback, in terms of what gets what notification priority level.
 +
** The notifications are now sorted by priority level from OMG, major, medium, minor, informational, and then hacking, prior to whatever the rest of their sorting would be.
  
* GOG clients are now able to search for lobbies and correlate those to their friends list, which under the hood is a several-step process.
+
* Wave notifications (of various sorts) now have the following notification levels:
** We are filtering out any potential rogue lobbies created by bad actors, and correlating them specifically to those owned by your friends.
+
** All CPAs are major for now.
** It's possible that a friend might jump from the status of being offline (prior to opening the lobby) to showing up as someone you can connect to (when they open the lobby), actually, so potentially this actually does allow for the same sort of quasi-stealth game connections that people can do using Steam.
+
** Any waves against not-a-player that are shown are considered minor for now.
** That said, since lobbies have to be advertised (to your friends) and we can't have a client just blindly try connecting by userID like in Steam, if you open a lobby and your other friends are actively in GOG looking to join a game of AI War 2, they would see that. Not a big thing, probably, but it's something we've noticed about the nature of these two differing systems.
+
** Reconquest waves are all major for now, unless they are not aimed at the player.
** You may find yourself having to hit refresh a few times on the client side in GOG, as there is a few seconds of lag before the lobby that the host creates shows up.  It seems to be under 4 seconds at the most in current tests.
+
** If a wave isn't one of the above and also is not targeting a planet, it's considered minor for now.
 +
** If a wave is headed to a planet, but that planet isn't allied to the local faction or has no owner, considered minor for now.
 +
** If the wave is weaker than 2/3 of the combatants friendly to the local faction at the planet, then this is minor.
 +
** If the wave is stronger than 200% of the combatants friendly to the local faction at the planet, AND this is a player home planet then this is OMG.
 +
** If the wave is stronger than 150% of the combatants friendly to the local faction at the planet, then this is major.
 +
** Otherwise this wave is considered a medium priority.
  
* GOG clients can now actually initiate connections to a host lobbyAnd it works!
+
* Regular notifications that are created by whatever other means are now required by code to specify their priority level when they are being created.
** The client is aware of getting into the lobby, although it takes a few seconds.
+
** Those shake out as follows for now:
** The client also does gracefully tell them that they are leaving the lobby, and the GOG servers and the host are both finding out about that properly.
+
*** AI Reserves notifications are always major for now, given reports on the difficulty of these by players lately.
 +
*** Dark Spire vengeance strikes and loci are medium and major respectively.
 +
*** Dyson antagonizers are major.
 +
*** Nanocaust frenzies got removed from the code, since those aren't a thing since fireteams anyhow!
 +
*** Wormhole Invasions are always OMG level at the moment, we may adjust this.
 +
*** Devourer Golem is informational if it's on a planet that is not owned by anyone or which is not friendly to youIt's minor if it's on a planet of you or ally.
 +
*** Zenith Trader is always informational.
 +
*** Hacking events are hacking priority.
 +
*** Spire Relic Train is informational, and so are risk analyzers.
 +
*** Spire relics and debris are also informational.  Same with imperial spire.
 +
*** Brownouts are OMG.
 +
*** Macrophage of 4 or more are medium, less than that are minor.
 +
*** Enemy nemesis is OMG, allied is now shown for the first time and is informational.
 +
*** DLC2 NP move is informational.
 +
*** DLC2 AT expansion is medium, civil war of it is major.
 +
*** DLC2 ZM mnrs > 0 is major, just probes is medium.
 +
*** DLC2 ZB are medium, unless all are in flight in which case are informational.
 +
*** When your planet is under attack, the priority is normally medium, unless:
 +
**** If it's a human homeworld, and enemies outnumber you and allies, then it's OMG.
 +
**** If it's a human homeworld, and enemies are more than 50% of your strength, then it's major (just in case).
 +
**** If it's a human homeworld, and enemies are less than 10% of your strength, then it's minor.
 +
**** On non-homeworlds, if you and allies are outnumbered 2:1 in strength, it's major.
 +
**** On non-homeworlds, if enemies are less than 50% of your strength, then it's minor.
 +
*** Exo strikes are major until they are 95% charged, at which point they turn OMG.  MDC exos no longer exist (they do something cooler), so the code for that is just scrubbed.
 +
*** Raid engines are medium, unless they are targeting a non-player faction in which case they are informational.
 +
*** AI Eyes, since they don't spawn anything, are rated minor.
 +
*** Counterattacks are:
 +
**** Minor if they are stalled
 +
**** Still minor if the strength of the counterattack plus all local enemies at that planet is less than all the local allies and own ships at that planet (aka you are outnumbering even if the counterattack launches).
 +
**** Major if the strength of all those enemy forces noted above is at least twice what the allied local forces mentioned are.
 +
**** Medium if it's in the middle range.
 +
*** Astro Trains are generally minor, but if one is headed to a depot that does something once X number of trains have reached it, and there X-1 trains have already reached it, then it jumps up to major.
 +
*** Instigators are generally medium, but if a given instigator has done its thing at least four times, then it upgrades to major status.
 +
** Huge thanks to zeus for suggesting most of these, and Badger for helping figure out details, and Ovalcircle and DEMOCRACY? DEMOCRACY! for helping a ton also. And Puffin!
  
* The GOG Galaxy networking client is absolutely fully implemented, now!
+
* GetIsHostileTowards(), GetIsNeutralTowards(), and GetIsFriendlyTowards() on the planet faction now take in variants with a faction directly.
** A huge amount of the actual send/read logic was able to be pretty much identical to Steam, which was not super far off from what we did with  LiteNetLib.
 
** Pro tip: if any other developer is ever wondering about SendP2P messages on the GOG network, those can take any size, not just stuff under 1200 bytes.  It handles all of the fragmentation and recombination extremely well, and just as fast as Steam or other services.
 
** The initial connection process to a lobby with GOG is a bit slower from North Carolina in the US than what we are seeing to Steam, ranging from 4-6 seconds on the first creation of a lobby on the run of a game to 2 seconds for ones after that.  But once the connection is established and brokered, it's easily as responsive for us as Steam.
 
** For us, this is routing through the internet and some firewalls, so the NAT punchthrough or relay servers or whatever it is in this case seem to be doing their job.  We certainly did not mess with any ports.
 
** Because of the nature of how data is read in from the buffers in GOG, we actually were able to get slightly more efficiency and speed with how we manage the heap compared to Steam or LiteNetLib.  It's probably not usually a huge advantage, but it is something that we appreciate the efficiency of.
 
** Essentially all three of the networking options have their own pros and cons a bit, but are all extremely good.  That's a real relief to see, and to see them all working.
 
** At this point it is now down to making the game networking actually work properly to have the game run, and that's a networking-framework-agnostic process.
 
*** In a lot of respects it feels like after a large move of house, where all our stuff is now out of the old house and into the new house, but we still have a lot of unpacking and arranging to do.  It still feels excellent to be done with the movers and have everything in one location now.
 
  
=== More Multiplayer Work ===
+
* On planets, there is a new GetStrengthOfFactions_HostileTo() that gets the strength of all enemies of a faction at a planet.
 +
** There is also a GetStrengthOfFactions_FriendlyTo(), which lets a faction include itself in that total or not, as well.
 +
** There is also a new GetStrengthOfFactions_Self() that gets it just for the faction in question.
  
* Removed some old and unused code that is from the Valley Without Wind versions of multiplayer, checking for disconnections due to inactivity.  We are handling that at a lower level, now.
+
* Fixed a pair of typos with astro train journals not firing properly.
  
* Got rid of some old code that was mainly in the older version of our engine pre-Raptor, which was checking for "pthread exceptions" that was never something that could happen in the newer engine that we've replaced it with.
+
* The devourer golem no longer shows its warning with the color of its faction directly in the notification.  That blends really poorly now in general.
 +
** In the tooltips it will now show that, but with deep blue in the tooltip it was a blurry smudge.  We will have to make some more changes to notifications over time to make this all more clear.
  
* The game now has some self-checking code in there for giving us some actual feedback when it decides that it can't run the simulation or show visuals for more than 3 seconds at a time.
+
== Beta 2.622 Hangar Ship Diversity ==
** This is a pretty rare case, but it was the "too many changes and the client machine goes to black screen and unresponsive" issue.
+
(Released October 28th, 2020)
** This may have fixed the issue, although there also seemed to be another issue that was related to this.
 
  
* Took out some other unused and old data.
+
* Fix a typo in one of the Tips for returning players
 
+
** Thanks to Breach for reporting
* The "UseSeed" command in the lobby no longer triggers the gamesettings to be saved.  That was not useful, and slowed it down for no good reason.
 
** It turns out that this was blanking out the settings data in a strange way a lot of the time, and causing the black and white view of the game after you reloaded.  It also was apparently directly the cause (somehow) of the infinite black screen on the client after this was triggered.
 
 
 
* Put in a lot of extra error handling for the steamworks networking in particular in case it has internal exceptions while trying to send something.
 
 
 
* The cumulative effect of a lot of these changes has basically fixed a ton of issues in the lobby, including:
 
** Clients not being able to use certain buttons or dropdowns.
 
** Certain dropdowns not showing the right values to clients.
 
** The client and the host getting a different view of things after certain buttons or dropdowns were used.
 
** For a while there I was thinking that I was maybe going to need to make some of the controls for the lobby host-only, but now that's definitely not the case!
 
 
 
== Version 2.115 Imperial Summons ==
 
(Released August 4th, 2020)
 
 
 
* You can now have multiple copies of the Devourer and Zenith Trader in a game
 
** There's no technical reason for this limitation, and we're encouraging Zenith stuff because of the coming Onslaught
 
 
 
* Quickstarts are sorted alphabetically again, instead of when the quickstart was created
 
** Thanks to ArnaudB for the bug report
 
 
 
* Add some defensive code to the Dyson Sphere
 
** Thanks to GreatYng for reporting.
 
 
 
* Fixed a cross-threading nullref exception that could happen during unit unselection (probably due to it dying).
 
** Thanks to GreatYng for reporting.
 
 
 
=== Imperial Fleet Summoning Changes ===
 
 
 
* The AI now generates some weaker bonus exos against miscellaneous player targets (energy producers, MDCs, GCAs, etc), just to keep things exciting.
 
* Fix a bug where Exos were trickling into their targets instead of moving as groups.
 
* Start the Exos the moment you finish the hack, instead of some random time < 30 seconds from when the transceiver finishes.
 
** Blame MasterGeese for these changes
 
 
 
=== Multiplayer And General Lobby Work ===
 
 
 
* The "partial map generation" code for giving a preview in the lobby now does even less work, bringing our mapgen times down to 200ms or so on average.
 
** Because of this, we've also moved the mapgen code during partial-map-generation onto the main thread, to keep things as fast as possible.  The full map generation still happens on a dedicated background thread.
 
 
 
* During the lobby, the way that we handle the execution frame loops is now entirely new, and basically skips over a lot of things that were artificially introducing lag.
 
** This makes the lobby perform far better in general, and also makes the map generation times absolutely flyyyy compared to what they were before, on single or multiple player maps.
 
 
 
* This is leading to a number of substantial bugs in the lobby, temporarily, but will make the lobby performance far superior in both singleplayer and multiplayer as we get those resolved.
 
 
 
* The silent "generate partial map" or "generate full map" complete messages now tells you how long it took.
 
 
 
* The way that mapgen works, it now has a couple of different contexts that it passes in, so that each one has its own random number generator that is not dependent on the others.
 
** This lets us ensure that there is consistency between runs of the same code on different machines, and on the detailed version (for play) and the non-detailed version (for viewing in the lobby).
 
** This is largely solving the issue that we just have started having in this latest round of internal builds with a difference in the final map and the original map.
 
 
 
* Renamed the Generate() method on map generators to GenerateMapStructureOnly() to be more clear, and also make our code more eaily searchable.
 
 
 
* Adding a planet to a galaxy no longer requires passing in a context object at all.  It now generates its own internal random number generator for its initial variables based on the galaxy map seed, its index, and its original position.
 
** One of the side effects of this is that now when you change which planet you want to be your starting planet, it will keep the name the same instead of shuffling them around.
 
** This sort of name-stability has actually never been in this game before, and always was mildly annoying.  But in multiplayer lobbies it was going to be even more annoying. "I'll take Adam." "Okay, sure."  "Well, I clicked it and now it is called Brian, but that's the one I meant."  "Wait, what?"
 
 
 
* When you are loading a savegame or a quick start as a template into the lobby, it now immediately regenerates the map rather than using the old map, because it's highly likely that the new structure will be different in some fashion.
 
** This then also solves the problem of clients being different from the host on first connect, probably; that was kind of a compound problem in general.
 
 
 
* Fixed an order of operations issue that could lead to the occasional "No human players found to seed homeworlds for!" error in the lobby in general, but more recently in multiplayer more frequently.
 
 
 
* Possibly fixed the issue with later player accounts in multiplayer being renamed incorrectly to "player 2" and such.
 
** There is still a fair bit of duplicate data happening between data structures, and some lobby/startup code that is blatantly single-player-specific that we need to get sorted out.
 
 
 
* Dramatically cut down the time it takes to generate planet random seeds, but still with keeping them consistent as you click around the galaxy, by pre-generating the random seeds as the first 300 calls to the "broad random" for the galaxy.  Any seeds needed after that will be generated the slow-but-unique way.  This means mainly things like nomad planets or other things that are late additions.  When just adding a planet or two, it's not so slow as to be a problem.
 
 
 
* Until now, if you loaded an existing savegame it would automatically put you in control of the first player account, even if your profile name did not match.
 
** It now continues to do that when you are loading as a single player game, which is enormously helpful for testing and just in general, really.  But in multiplayer, it now tells you a list of what the available profiles are,
 
** In general, if you are loading something as a template, it now clears all the old player account data and loads in your own current name as the new first player account (and further players are already added properly as they connect).
 
 
 
* Fixed up the way that planets are shown as colored in the lobby galaxy map, so that it will work well with multiplayer and also with the new faster single-player-generated stuff.
 
 
 
* Improved the logic for it properly setting you to be viewing the new planet you've selected after you make a selection in the lobby.  Another thing that did work, but with the revised logic had to be made to work all over again.
 
** This concludes the fixes to all the known bugs that we are aware of that we've introduced into the lobby today.
 
 
 
* Fixed another nullref that was happening only on the multiplayer custom games after today's changes.
 
 
 
== Version 2.113 Dyson Growth ==
 
(Released August 3rd, 2020)
 
 
 
* Fix a null reference exception if the game wants to spawn a Relic but you own basically every explored planet
 
** Thanks to Lord of Nothing for reporting
 
 
 
* Fix a bug with Dyson Sphere units not marking up
 
** Thanks to GreatYng for reporting
 
 
 
* Fix a typo in a Battlestation description
 
** Thanks to ovalcircle for reporting
 
 
 
=== Multiplayer Work ===
 
 
 
* Fixed one oversight that was causing the factions tab chat to not show its chat text properly, unlike map and options in the lobby.
 
 
 
* As text messages come in inside the lobby, it now scrolls to the bottom of the chat window, as you would expect.
 
 
 
* The maximum length of chat messages in the lobby is now 1000 characters.
 
 
 
* GetLocalPlayerFaction() is now GetLocalPlayerFactionOrNull(), to support spectator players.
 
** Additionally GetFirstPlayerFactionOrNull() has been added, and GetIsFriendlyToLocalFaction() and GetIsHostileToLocalFaction() have been updated to work based on that in order to extend support for spectators even further.
 
 
 
* Planet visibility is no longer determined from your local faction (since for spectators that might be null, and for all humans it is identical anyhow).  It now just uses GetFirstPlayerFactionOrNull(), since that's slightly more effient and supports spectators.
 
 
 
* Huge areas of the AI have been updated to allow for spectators, generally giving them information that mirrors that of what the first player is seeing (objectives-wise and so on).
 
** In other areas, it simply updates things to not erorr out when you hit hotkeys, etc.
 
** Spectators also can't run "cmd" messages from chat; it will just show the text as if it were not a command.
 
 
 
* GetLocalPlayerFaction() on the planet object has been removed, as that did some risky caching for multiplayer in general, and also was not really compatible with spectators.
 
 
 
* Fixed a couple of errors where non-sim-but-background-fation-AI code was referring to the local player faction.  It now refers to the first player faction.
 
** Probably this would not have made much difference, unless the game switched hosts partway through or something like that.
 
  
* The chat controls in the lobby now work, though there are some bugs in them still.
+
* One can no longer manually click on a ship with active repair-delay and get your engineers to repair it
 +
** Thanks to Arides for reporting
  
* The correct name for each player faction now shows up for even for players who are in spectator mode.
+
* Exos that are being sync'ed with Wormhole Invasions or CPAs now always have a notification
  
* Player factions in spectator mode now see in the lobby chat area that they are in spectator mode.
+
* Slightly improve the nanobot center hovertext
  
* Both the lobby chat and main game chat now support more characters in their text -- basically anything that our "condensed" ascii format is allowed to display.
+
* The Esc menu now shows the "Display Name" of the map type instead of the "Internal Name"
  
== Version 2.112 Steam Networking Complete ==
+
* Slight buffs to the AI on intensity 10. The goal is a bit more raw power.
(Released July 31st, 2020)
 
  
* The description of the Ensnarer Battlestation now explicitly mentions that it can use AI Great-Turrets
+
* Fixed a bunch of cases of "address" being spelled with three Ds.
** A number of people have reported this as a bug over the years, so hopefully that won't happen anymore
+
** Thanks to Ovalcircle for reporting.
  
* All of the Fallen Spire ships, including those in the Spire Railgun Shop optional mod, have had their health and shields doubled, but their firepower halved.
+
CPAs are now a bit smarter at detecting when they planet they were going to is no longer relevant. CPAs for higher difficulties (AI difficulty >= 8) are now better at focusing their forces.
** This should make battles with other mega-units last longer, which feels more appropriate, but keep their "damage over time" the same.  
 
** When these were going toe to toe with the AI Exogalactic War Front units, they seemed to disappear too quickly, making them feel weak.  This should keep their effectiveness the same as before, but make the battles take about twice as long with those large ships, so that it doesn't feel like instant evaporation at least.
 
** The one unit not adjusted is the Spire SuperDreadnought from the Spire Railgun Shop mod.  That was already maxed out as a "kills everything and is basically invincible" sort of ship.
 
** Thanks to a variety of players for weighing in on the feel of these units, and Badger for suggesting this adjustment.
 
  
* Rather than having a slider for the number of planets in the galaxy map view, there is now a dropdown.
+
* Add a new Game Lobby setting to prevent Beacons from spawning in the game
** This prevents the intense "regenerate map spam" and lag that was inherent in using a slider, along with making it easier to choose a certain number of planets.
+
** Intended for people trying for Pure 10 runs, and for anyone who hates beacons
** We have made it so that it only gives you multiples of 2 below 60, multiples of 5 below 100, and multiples of 10 above that.  This makes it easier to quickly peruse the range.
 
** Each entry has some commentary on what it will mean to the feel of the map if you are hovering over it in the dropdown with the number of planets expanded.
 
** Actually, it wasn't even regenerating the map after you changed the number of planets, which was really confusing!  You had to hit regenerate map.  Now there is no confusion.
 
** All of this is easier to use as a player in general, on top of being something that is easier to deal with in multiplayer for sync purposes, too.
 
  
* Fixed a longstanding bug where dropdown selections that were open could persist when leaving the lobby or changing tabs within the lobby.
+
* Add a setting for 'Hide Undiscovered Factions from Esc menu'.
** Thanks to MaverickPenkenn for reporting.
+
** This is mostly for people who like surprises and have a poor memory of what was going on in their games
  
=== Milestone: Steam Networking Integration Complete ===
+
* If some piece of UI doesn't load properly, the main menu should no longer freak out and throw endless errors.
  
* Fixed an issue where multiplayer clients disconnecting from a host would try and fail to save the last settings from the lobby.  Now it does not save the lobby settings from a session you are just a client of.
+
* If you are adding a new faction in the game lobby and that faction has the same FactionCenterColour as an existing faction, the new faction gets a random colour
  
* All of the networking frameworks have had their "send to anyone here and myself" code consolidated into the network authority, so when an interface is partially implemented it won't wind up stalling out waiting on the host.
+
=== Astro Train Changes ===
** Less code duplication is also always good, but it wasn't clear that this was a complete commonality until we got partway into the Steam framework implementation.
 
  
* A new ArcenSteamClientConnection wrapper has been created to keep track of the Steam connection on servers.
+
* Astro Trains now count as 'Large Ships' for the 'planet in combat' notification hovertext
** This now properly is registered while the steam connection is alive, and all of the "waiting for player to connect" and "player disconnection" events now happen properly.
 
** For some reason, we are not getting the "host has accepted you" callbacks on the client end, but that doesn't really matter.  As we start actually having our challenge-response data sent via the higher-level networking code, that bit will become irrelevant as it establishes itself within part of one second anyway.  It's just a curiosity, or potentially something that is only meant to trigger host-side.  Frankly the documentation is sparse in points, both from the Facepunch C# wrapper and the Valve C++ baseline, so this might be working as intended.
 
  
* Substantial progress on the Steam network transmission of data. Still not quite seeing it register yet, but we're getting close.
+
* Astro Trains get fewer guards. Guards now attrition (quickly) if their train is dead, and they attrition slowly if their train is on a different planet
  
* The full suite of network logging has been integrated into our steam networking wrapper, now.
+
* Astro Trains are now better at heading to their Stations, and not getting distracted
  
* When a Steam host shuts down the connection, the steam client computers now definitely notice and react to that.  The inverse was already working from the start.
+
* This section thanks to feedback from GreatYng
  
* Figured out the missing information on how to get data from the facepunch steamworks wrapper (call Recieve() to trigger the other events), and are sticking with the derived classes methods rather than the interface method, since for relay connections it seems like the interface method is not fully implemented.
+
=== Refinements To Main Menu ===
** With this in place, we're now getting messages on the client machine, and they are properly decoded!  The host for some reason still doesn't get messages back, but this is progress.
 
  
* Fixed a bug in our connection status window code that was causing it to stop showing a timer on connection stages after the earliest ones.
+
* The reflection probe on the main menu is now located more to the side, so that it is not in the path of ships that go flying through out.
** With LiteNetLib, that all flashes past so fast we could not tell that was even happening.  With Steam currently stalling out with the host not getting messages, it became apparent.
+
** This makes it so that the reflection of the ships is shown, but there is not a giant flash on the entire screen as a ship exits the view.
  
* Previously it was possible for our socket mode to be off, and silently ignoring messages we were sending.
+
* The AI War 2 and Arcen Games logos are now subtly on the wall in 3D in the background on the main menu.
** This was initially done to make it so that any lingering messages that would try to be sent after a disconnect would not cause visible errors, but in this case we've wound up with the socket state being off on the steam networking, despite it being active, and this thus resulting in client messages being composed but not actually sent.  That was not obvious because of the lack of error messages.
 
  
* Figured out a stupid mistake in our own code, indeed a single line of code, which was preventing the client from sending data properly back to the host.
+
* The old ship that was being used for the main menu animation in yesterday's build is no longer used at all.  That was a junky dark ship that was never actually used in the game.
** Steam networking is now fully functional in terms of sending data back and forth. There is some sort of issue with the world data not getting across properly, but we have to now verify whether that's limited to Steam or also happens on LiteNetLib.
+
** Now we are using spiders, bombers, raiders, and MLRS corvettes.
 +
** There are two different animations for each one leaving the hangar, and the quality of the animation is now higher, as well.
 +
** The overall idea here is to give a lot more of a sense of life and personality to the scene, and make it clear that these are multiple ships launching instead of just one repetitive animation on loop.
 +
** There are also now point lights on these ships, which helps give even more of a dramatic bit of motion that interacts with the rest of the scene as they exit the hangar.
  
* Added in a substantial amount of extra error tracking in our univeral and game-specific network message handlers.
+
* Added a new ArcenFramerateTracker that now let's us track the framerate of the game at any time. We've previously been tracking sim performance, but not the actual framerate.
** This helps us to find out where errors actually are.
 
** In the case of steam, right now we are getting some exceptions when the host tries to tell the client what their player profile number is.
 
  
* Fixed a simple typo that was having us send a junk message via both frameworks to the client when they first connected.
+
* Also added a new ArcenCutscenePerformanceManager class that lets us react to poor framerates during a cutscene by reducing the reflection probe load.
** In both cases, this led to the galaxy map not showing up properly on the very first world connect.  But in the case of Steam networking, it also led to an exception because the byte array was too small.
 
** This extra smallness is actually more accurate, and basically it was only not erroring with LiteNetLib because the buffer array was larger than needed because they are pooled.
 
** This is an interesting difference between these two networking frameworks, but neither one is particularly "wrong.  But it does make Steam slightly more sensitive to certain errors in a way that is useful, because it's an error in both cases that manifests in other places.
 
** Anyhow, this seems to argue for us to internally use Steam as our main testing framework, additionally because that means we are round-tripping out through the internet and Valve's servers and back rather than having the speed of a LAN.
 
** This also means that the Steam networking library is fully completely integrated, which is a very major milestone!  Now it's all game logic, regardless of what is going on with the two networks.
 
** Also worth noting that it's under 3 seconds to connect a client to the lobby in our test case, using the Steam relay servers, etc.  On the LAN it is under one second, so that's pretty killer.
 
  
=== More Multiplayer Work For All Frameworks ===
+
* On the main menu, next to where it shows the amount of time it has taken to load the game, it now also shows the FPS of the game on the main menu.
  
* "Planet GalaxyMapVisuals in CenterGalaxyViewOnPlanet null!" will no longer happen.  It was a thing relating to trying to center on a planet slightly too early, and the population of the galaxy map still having failed.
+
=== UI Reskinning Part 2 ===
** We are now bypassing that and using the raw internal transform offsets to calculate the correct camera position.
 
  
* In response to the initial challenge from the host, the client no longer just sends their profile name.  They now also send their list of installed and enabled expansions and mods.
+
* Fixed an unsightly bit of extra partially-transparent white pixels in the corner of the rounded menu backgrounds.
** The host then compares that list to its own installed and enabled expansions and mods.  If there are differences, then it rejects the client connection and does a popup on the client and a chat message on the host side explaining why.
 
** It also notes in there that both parties can enable or disable expansions or mods in the Game tab of the Settings menu to get things to match.
 
** Please note that, yes, in some cases there will be mods that are enabled but which "wouldn't do any harm" because their functionality won't be triggered in the campaign in question.  We don't have any way of knowing that, so we have to err on the side of caution.
 
** When it comes to expansions, there are none that "wouldn't do any harm," because all of them add some ships and features to the game in general that all players need to have.  For instance, the first expansion adds a bunch of new turret options that are available to choose from in any game you play with that expansion on.
 
** At any rate, we've gone out of our way to make it easy for people to disable expansions and mods so that they can play with friends who don't have those same expansions or mods.  The last thing we want is for the only solution to this sort of thing to be someone reaching for their wallet or having to faff about in the filesystem.
 
  
* Low-level chat messages that are sent to everyone from the host are also now sent to the host themselvesPreviously, they could not see messages of this sort, turns out.
+
* The textbox used throughout the game has been updated to look much more attractive than it has in the last few beta versions.
 +
** Actually, then we updated it yet again to make its construction vastly more complicated, but to show the halftone pattern undistorted, the borders cleanly, the interior drop shadow properly, and all that at a variety of sizes as needWhoof, that took forever.
  
== Version 2.111 Initial Steam Connection ==
+
* Updated fonts on the tutorial screen, and the background to help differentiate it more from the other similar screens.
(Released July 30th, 2020)
+
** And gave the same treatment to the load quickstart window, but with a different background that is more golden and different shapes to help tell this one apart from others.
 +
** And also the load game menu, where it looks like a bunch of microprocessors and similar.
  
* Fix a null reference exception in my new spire relic code
+
* The following windows have had their fonts updated, but no special backgrounds as they are not used all that frequently and don't need differentiating:
** Thanks to Chuito12 for reporting
+
** Controls window.
 +
** Credits window (also updated it so that the names on the right-hand screen are not cut off).
 +
** Kickstarter backer credits window.
 +
** Background story window (this also has been updated to have a more readable and better-sized font for the central story).
 +
** Add/edit profile window.
 +
** Color picker (team and border based).
 +
** MP client connect by IP and List windows.
 +
** MP client connection status window.
 +
** Same for the two general "popup list option" window components.
  
* Nanocaust: Make the AI wait a bit longer before unleashing Exogalactic units on it. Remove some deprecated code
+
* The chat/log window has been updated like the others, but also with a dark blue background in there to set itself apart a bit more.
** Also the exogalactic units won't hang around to kill the entire nanocaust, so there's a chance it can recover.
+
** The factions window has also been updated and has a new different background, but it's a very subtle one.
 +
*** The sectional factions and galaxy options tabs in the main menu has been updated to match a combination of this and the chat window, since it incorporates elements from both.  This really helps to make them stand apart.
 +
**** The standalone chat on the right in the map tab in the lobby in multiplayer then matches the chat colors and such from THAT.
 +
** The personal settings window now has different visuals, slightly, from the galaxy-wide settings menu.  Again to help with people knowing where they are at a glance.
 +
*** The tips window also now has its own variant off the personal settings.
 +
** The settings sidebar popout has also now been updated (this is mainly used for fleets, but can be for other things also).
  
=== Milestone: Initial Steam Networking Connection Between Client and Host ===
+
* The notifications images have been updated a bit to have a slight bit of extra detail in their background.
 +
** These also now have different background images that we can swap in for minor, medium, major, OMG, informational, and hacking events.
 +
** Right now all the notifications are just set to medium, but we will hook them up to use different backgrounds later.
 +
** Thanks to Badger, zeus, Tzarro, Ovalcircle, and NR SirLimbo for helping figure these out.
  
* The Steam versions of the game now initialize relay access on startup, to make it so that the first connection using Valve's relay network will be extra fast.
+
* Updated the visuals for tabs, and the top bar in general in the lobby.
** If you wind up not playing any multiplayer, this is absolutely harmlessIf suddenly it is flagging your firewall on game start on the Steam versions of the game, though, that might be why.
+
** Also updated the tabs on the left of the main screen to match this new style, including slightly different spacing for the tabs themselves.
 +
** Updated the build sidebar's fonts slightly, and in general its backgrounds and so on.
 +
** Same for the fleets tab.
 +
** Same for the hacking tab, except for the header part that has the hacking icon.  That bit will be updated later.  The button color here has also become green.
 +
** Same for the journal tab.
 +
** And outguard tab.
 +
** And intel tab.
 +
** And science tabHere again the header icon has not yet been updated.
 +
** And the planet tab.  Later there will be many updates here, but those will have to wait.
  
* The basic connection through Steam's newer networking sockets connection is now in place, using their relay servers as recommended.  This is the approach that absolutely bypasses NAT traversal and anything else of that sort, and in fact hides your IP address from anyone you are playing with.  The claim is that their backbone is faster in most cases than the general internet one.
+
* The selected ships window has been updated except for its icons, which are going to be replaced and improved.
** If need be, we can make a "Steam over IP" version that allows for their networking sockets stuff to run more directly over UDP, and only fall back to their relay servers if there is a problem.  This would be a lot like LiteNetLib, except with much better NAT punchthrough making use of ICE and STUN and all those things.
+
** Same for the main header resource bar in the game.
** For now we are sticking with Valve's recommended practices.
+
** These will get some more work done on them tomorrow.
** Beyond just getting the initial connection up, we don't have anything there yet, but on the server we can see the Steam username of the client who requested to connect and who forged the connection.
 
  
== Version 2.110 AI Exogalactic War Front ==
+
== Beta 2.621 Gorgeousification ==
(Released July 29th, 2020)
+
(Released October 24th, 2020)
  
* Spire Relics now have additional text in their descriptions explaining either A. whether the relic is on route to a particular planet , or B. that this relic must build on this planet
+
* It is now possible to set up material swaps on a list of images related to a given button, which in turn lets us make the glows more intense or even different colors.
** Thanks to Lord of Nothing for suggesting
+
** We're now using this for the buttons in the lower left corner of the main view, so that as you hover over them it's super clear what you are hovering over.  This feels far more interactive, and has a lot more in common with what we are doing with other buttons elsewhere in the game.
  
* All of the units that were previously named "Galactic War [name]" are now just named "[name]"
+
* Added a new "pre-canvas LDR camera" that makes sure to do a no-algorithm tonemapping from the HDR range to the LDR range.
** However, in the tooltips for them, their faction should now say "AI Exogalactic War Front" in whatever the hunter fleet's color is, rather than saying the AI Hunter Fleet.
+
** This essentially does add an extra compositing step, but makes it so that anything that might peek into the HDR range from things like hovering over certain faction icons can't possibly interact with the new bloom effect that is used for buttons.
** This lets us keep the shorter name, while making their sub-group and source a lot more clear.
+
** Because we have a number of special extra cameras for things like the effects where we have not scouted or don't have current intel, this was the cleanest way to make sure that nothing else goes wrong.
** This does need testing, so please let us know if it doesn't show up correctly somewhere.  This is using a new xml feature called "override_faction_name", which lets us use a different faction name for some units in a faction, but without actually creating a new faction.
+
** Thanks to NR SirLimbo and Puffin for reporting.
** Thanks to Ovalcircle for leading the discussion that led to this.
 
  
* Spending a ton of science will now increase a player faction's Overall Power Level very slightly.
+
* The asteroid belt ring that goes around the playing area on planets has been updated so that it has full lighting effects on it, with a dark side and a light side that also matches the direction of the sunlight hitting the planet.
 +
** On dark starfield backgrounds, you'll mostly just see the brighter side of these asteroids, but you'll still finally be able to see them.
 +
** On light starfield backgrounds (lots of nebulas), you'll mostly see the shadowed side, which then looks a lot like before.
 +
** On areas of transition and contrast, you still have something to visually pick out in either situation.
 +
** Thanks to a lot of folks for reporting this over the years.  I tried this a while ago and couldn't get it to look acceptable, but this time it worked out.
  
* Remove some inaccurate description text for the Rorqual Hejira
+
* The timer text in the bottom left corner of the main view is now a bit smaller so that it can hopefully always fit its contents in there.
** Thanks to GreatYng for reporting
+
** Thanks to NR SirLimbo for reporting.
  
=== UI for Steam Networking ===
+
* The new background image behind the right window in the escape menu was actually too far forward, and was also set as a raycast targetConsequently, it looked slightly wrong and also caused the scrollbar to not be clickable.
 
 
* Added the new ArcenNetworkConnectionOption class, which we are using as a basis for things like lists of your Steam friends that you can connect to.
 
** On the network authority, there is a new PotentialServerOptions, which is used to list out such things.  This can be used for anything that we need to list a variety of to connect to, not just friends in Steam and GOG.  This is in contrast to the "type in an IP" method that we use with LiteNetLib.
 
 
 
* Started building out the Steam networking framework layer, currently based on the ISteamNetworking implementation that most games use.
 
** We MAY opt to also start supporting the newer ISteamNetworkingSockets framework that Valve has rolled out more recently, but that would be an alternative networking framework in AI War 2 that you could choose between.
 
** The fundamental premise of those two Steam networking setups is really different, and while the newer one would in some ways be easier for us to implement, it seems a lot less familiar to the average Steam player, involves IP addresses potentially, and is maybe less battle-tested, but who are we to say.
 
 
 
* Previously it was still possible to have some exceptions happen silently in the Engine_Universal main loop, and they would log to disk but not show up in your face.  Fixed.
 
** It was also possible to get some silent errors when clicking buttons and other UI elements, turns outThis made the application just seem not to respond to the click, but now it properly shows the error if there was one.
 
** Also it was possible for certain errors in the UI call stack to prevent the display of the error window.
 
 
 
* When you try to connect to an IP address, or you change your active networking framework, the game settings now get saved immediately so that that is remembered even if you shut down the program right away.
 
 
 
* There is now a screen that will be used for Steam and GOG connections, from the client side, and in Steam it now:
 
** Shows a list of all your Steam friends, with ones that are in AI War 2 at the top, then ones that are online, and then the rest below that.
 
** Lets you sort to just ones that are in AI War 2 or online.
 
** Lets you refresh the list to check for updated statuses.
 
** There is a connect button for each friend, but that is not functional yet.  Just haven't gotten to that part yet.
 
 
 
== Version 2.108 Galactic War Units And The Exostrike ==
 
(Released July 28th, 2020)
 
 
 
*  Completely rework the way Exogalactic strikeforce leaders work, to allow per-AI-Type customization. No functional change right now, but intended to support some new AI types for DLC2
 
 
 
* HandleHelperJournals() has been split out into a bunch of sub-methods, since they can error in rare cases and it would be nice to know where the error generally is.
 
 
 
* Fixed an issue where we were not letting negative risk analyzer data be saved properly.  Turns out that has a good reason to be negative at times.
 
 
** Thanks to Badger for reporting.
 
** Thanks to Badger for reporting.
  
* Added a new UI feature that is a throwback to some of the functionality we had in various past games: the "center screen message"
+
=== Revised Key Scenes ===
** This is basically a message that can show up near the top center of the screen, and stay there for a bit or for as long as needed.
 
** It won't block the mouse, and it is over everything except modal popups and tooltips.
 
** This isn't something we would want to use all THAT often, but for cases of things like "hey the server isn't responding, why is MP stalled," this is exactly the sort of UI functionality we need.
 
 
 
* Fixed a harmless bug where, for the last few months since we've been doing multithreaded loading of camera xml files, the "PrivateVisExtensions" assembly would sometimes have annoying but unimportant errors appear on startup.
 
** Essentially, it turns out that loading classes from a custom dll is not entirely threadsafe.  Go figure.  The fix for that is simple, and it doesn't slow things down, but now we know.
 
** Thanks to GreatYng for the first report of this we'd had outside of ourselves running into it.
 
 
 
* Fix a bug where macrophage achievements weren't triggering if you killed all the Telia
 
** Thanks to GreatYng for reporting and StarKelp for the fix.
 
 
 
* The in-game credits have been updated to include two more individuals who are key DLC2 testers.
 
 
 
* Added new GetWasWorldStartedOnGameVersionOlderThan() and GetWasWorldStartedOnGameVersionAtLeastThisVersionOrNewer() to world, which let's people find out in a really efficient way if a world was started before some certain point.
 
** We can't be accurate past a month or so ago, because we were not tracking the original savegame version back then.  But it's useful for looking at saves older than the more recent ones and altering them if need be.
 
** This is now used specifically to fix this macrophage disabled stuff only on older savegames than 2.108.
 
 
 
* Fix a mispelling in the Mesopotamian planet names
 
** Thanks to Lord of Nothing for reporting
 
 
 
* Fix a typo, "reciever" to "receiver"
 
** Thanks to Apthorpe for reporting
 
 
 
=== UI Changes ===
 
 
 
* In the Load Menu, campaigns are now sorted by 'most recent save game in that campaign' rather than alphabetically
 
** Thanks to Puppet Master for the suggestion.
 
 
 
* The default sort for the load menu is now by date.
 
  
* Rename 'Exogalactic Strikeforce' to 'Exostrike' and 'Extragalactic War Units' to 'Galactic War Units' in UI. Having "ExoGalactic" and "ExtraGalactic" was a perennial source of confusion
+
* The victory screen has been completely overhauled in terms of the visual background style, and the fonts used, and the composition of where text is, etc.
** Note that internally the code uses the old names for the moment
+
** The overall color scheme and the visuals are based on what the main menu has been for the last few years, except it's more dramatic than before in the sky and the lighting.
** Thanks to a discord conversation involving relmz32, Oryutzen and NRSirLimbo
+
** We were fond of that old main menu screen, and so wanted to keep it around in some fashion, but also to make it more dramatic in a way that is fitting for a victory screen.
 +
** We were NOT fond of the old victory screen visuals, so those are just tossed out.
  
=== Dyson Sphere Buffs ===
+
* Fixed a typo in the victory text.
 +
** Thanks to Venger for reporting.
  
* The Dyson Sphere's ships should now really level up after the hack
+
* The loss screen has been pretty cool for a while, and it was based on an even older version of the main menu (go figure), but it still needed some work.
** Thanks to GreatYng and zeusalmighty for the bug reports
+
** First of all, the armada in the background has been repositioned and also doubled in size, to better fit with the composition of where the AI overlord is located and not distract from certain other elements of the image.
 +
** Secondly, the background visuals are far more vicious and red and angry, and have even more visual interest, in terms of how and where they are positioned.
 +
** Thirdly, the blue planet now has an even stronger glow off its atmosphere, but more pale and more in the background.
 +
** Fourth, the lens flare and glare has been turned off of the bloom effect being used here, to keep things more consistent with the rest of the game.
 +
** Lastly, the text has been moved around a fair bit, and the fonts changed and button repositioned, etc.  It's more similar to the loss screen, but not the same.
 +
** This screen is not the super most legible text, just by nature, but it's at least attractive now and it definitely is readable.  But if any screen is going to cause a bit of eye strain while reading, it's this one.  We figure that's okay, as you don't really need to read the parts that would be at all that way, anyhow.
  
* Dyson Sphere hack descriptions now say "This hack will make the Dyson Sphere very unhappy with you for a while" to clarify the behaviour.
+
* The main menu scene is now completely overhauled, and shows a scene from inside the hangar of one of your fleet leaders.
** Thanks to Apthorpe for suggesting
+
** This ship is moving around in such a way that the starfields outside are spinning past, and you can see the reflections of these, and the planet that goes by, affect the dark metals of the large ship you find yourself inside.
 +
** Through the floor, ship after ship is raised up from the bowels of the structure and accelerated out into space.  Those who have been playing the game for a really long time will recognize this ship from being the "mascot ship" on the main menu 2-3 years ago.  It had the game logo and company logo in 3D on the side of itself back then, but no longer does.
 +
** As part of this change, now that this scene is so much darker than the old main menu, the buttons fit in better in general.  We are no longer tilting those backwards in order to make them fancier.  It has always introduced aliasing issues around the edges of those buttons.
 +
** To make the ship move and accelerate properly, we have now integrated Slate Cinematic Sequencer by Paradox Notion.  We've had that for years, but never had anything worth integrating it for in this project.  We're aware that Unity Timeline exists, but this was a quick and familiar thing.
 +
** This overall scene is pretty heavy, so if it's causing lag on the main menu, please let us know.
 +
*** On an i7 from 2016, and with a GTX 1070, at the moment we seem to only be getting around 40fps, which is a surprise.  In earlier testing with this scene we were getting 130fps or so.
 +
*** We're not sure if this is related to the Slate cutscene stuff, which was the most-recent-added, or if it's something else that we're not clear on.  At any rate, the realtime reflection probe at a really high quality doesn't help matters, but boy is it gorgeous.
 +
** At the moment, the main menu scene (after the loading scene, which is the same as it has been for a really long time) does not include the AI War 2 logo or any other logos.
 +
*** Later it would be nice to include the main logo and expansion logos, but perhaps integrated into the scene in some fashion.
 +
** Overall this, plus the changes to the other two scenes, are requiring about 300MB more disk space, and something along those lines in terms of RAM.  It doesn't have any effect on the speed of loading the game.
  
* The Dyson Sphere now gets additional income (ie it can build ships faster) that scales with AIP. As AIP goes up the Dyson and Antagonized Dyson get stronger
+
== Beta 2.620 Hotfixes ==
 +
(Released October 24th, 2020)
  
=== Multiplayer Work ===
+
* Fixed an error in the most recent beta where the lobby was broken if you didn't have DLC2.
 +
** Thanks to cml and UFO for reporting, and Puffin for pointing us to where the issue was.
  
* SendMessageToAllClients() has been split into two methods: SendMessageToAllClientsWhoAreFullyConnected() and SendMessageToAllClientsRegardlessOfConnectionStatus().
+
* Fixed a known issue from the last beta where the settings and chat visible buttons in the lower left corner of the main screen were not working.
** We really don't need heartbeats and frame auths and so on going to clients who are still connecting in.
 
  
* Also added a GetCountOfClientsWhoAreFullyConnected() that lets us know if there are any clients who actually have gotten all the way in (and thus we should send world data)/
+
== Beta 2.619 Quality Of Life And Polish ==
** And added GetCountOfClientsNeedingWorldData() that lets us know we should make everybody wait for a bit until those people connect in.  Otherwise everyone won't be on the same page.
+
(Released October 23rd, 2020)
  
* Added a OnServer_IsAtPausedSpotWhereGameWorldCanBeSent() that lets us wait for a break in things happening (usually only 400ms or so at most) to then have a clean slate to send a world state to a connecting client without that state changing between them being sent the state and them getting it.
+
'''Since there are many visual changes in progress, to save confusion this is only on the beta branch on steam and gog right now.'''
** Along with this, if GetCountOfClientsNeedingWorldData() is more than zero, then it now pauses authorizing more simulation frames until the world is fully taken in by the new clients who are joining.
 
  
* When a multiplayer game is stalled out for some reason, it now uses that central screen message to let you know what is happening, and if possible, why it is happening.
+
* Marauder Outposts now have more health
** The game itself will have stopped having any action at this point, though you can still scroll around and look at things and give orders.  But nothing is proceeding on the enemy side, so you don't have to worry about it being in your way.
 
** When a client is first connecting into the lobby, it also uses this, to basically get the host and any other existing players to wait a moment before making more changes, etc.
 
** On the host, this is already set up to give some context about the exchange under the hood that is happening with the new client.
 
  
=== Multiplayer Transition To LiteNetLib ===
+
* The faction list of the Esc menu is improved. It is now sorted for easier reading, and the 'allegiance' section of the Esc menu is color coded and simplified.
  
* Okay then... we are switching network libraries when it comes to our non-Steam/non-GOG transport layer.  Instead of FORGE Remastered, we'll be using LiteNetLib.
+
* Updated the galaxy map camera view to now use a 4-camera stack instead of a 3-camera stackThe new camera on the stack is just for rendering the space background, and it now uses a field of view of 60 rather than 40 so that it has the proper perspective and scale on those background starfields and nebulas versus seeming super zoomed-inThe field of view of the map parts itself remains at 40, to avoid distortion on them.
** FORGE has grown a lot over the years, but the version we were using was from 2018...ishWe looked into updating our version of the code, but were not thrilled with how complicated it was going to be.  Since we had working AI War 2 multiplayer on FORGE at least as recently as 2017 (in an alpha state), staying with the existing code made a certain amount of sense.
+
** Thanks to Puffin Emeritus for suggesting.
** However, we started running into really long delays with something as simple as sending 10 bytes to say what our profile name was.  This was taking upwards of 14-18 seconds between two machines sitting three inches apart and both within five feet of a powerful wifi router.  We verified that the polling was happening hundreds of times per second, and that massive amounts of data was being sent via sockets.  But in the internals of the old version of FORGE we have, it was taking it quite a very long time to assemble that into a full message, despite all the churn of hundreds and hundreds of data reads that were apparently all just empty headers and then noise. 
 
** Time for a new approach.  It's worth noting that the current version of FORGE still lists all the most internal classes as "in development and lots of dire warnings," so that was another reason for switching up frameworks.
 
** We chose LiteNetLib at this point, and within 40 minutes of dropping that in, we had the first successful connection between the machines on using this framework for the game.  It was just a simple "hello client" message in basic unicode, but it arrived extremely instantly, as expected.
 
** Next steps are going to be doing some cybernetic implants on LiteNetLib, rather like what we did on FORGE, to make sure that it integrates with AI War 2 properly and our network authority, and that it communicates as directly as possible with our own pre-formatted bitstreamsMost of that should be part of one day of work, at this point.  We shall see.  Then it's back to the actual larger "build out the multiplayer part of the game" work, but minus the lag that was tripping us up the last day or two.
 
** It's also worth noting that, with this switch, we had to unfortunately also lose the awesome NAT punchthrough work that Doug Fields did for us with the FORGE interface back in 2018, but LiteNetLib has some of that of its own.  And hopefully most people use Steam or GOG if they are behind firewalls of any complexity (since relay servers then become required, and that's where the free relay servers are).
 
  
* NetPeer in LiteNet now inherits from ArcenNetworkClientConnection.
+
* Harmonic turrets must be fully constructed in order to apply their "Strengthen other harmonic turrets" buff. Turrets under construction no longer count, and neither do remains
** For now, we are using our own methods to generate the ConnectionIndex, rather than using the existing peer.Id. There may be some numeric conflicts, otherwise, but we can also change this later.
+
** Reported by ArnaudB
** We also are initializing everything on the Arcen-integration side, keeping our own clientsOfServer list for quick access, and then calling the game-layer RespondToNewConnectionAcceptedByTransportLayer() that will kick things off.
 
  
* PrepareMessageForSending() has become WriteLogOfSend().
+
* Updated Harmonic mechanic to be able to increase per Mark. Harmonic turrets gain 10% of the original value per Mark.
  
* Added a new SendToSpecificPeer() method onto LiteNet's NetManager. Not sure why that variant didn't seem to exist.
+
* Vengeance Generators now prioritize other VGs close to deploying ships when sharing energy. The goal is to get multiple battles going at once. Also improve the hovertext for VGs with some colour
 +
** Thanks for GreatYng for prompting
  
* Wiring back up our LitNetSocket wrapper class:
+
* Astro Trains guards now spawn pre-stacked if appropriate
** SendMessageToHost_Inner() done.
 
** SendMessageToAllClientsRegardlessOfConnectionStatus_Inner() done.
 
** SendMessageToAllClientsWhoAreFullyConnected_Inner() done, using the new SendToSpecificPeer() method.
 
** SendMessageToSpecificClient_Inner() done, using our own ConnectionIndices for now.
 
  
* Booyah!  Exclamatory phrases are not the norm in our patch notes, but this is an exciting moment.  LitNetLib is sending messages, and doing so with speed and accuracy and a minimum of fuss.  The username travels three inches in well under a second, as should be expected.
+
* Add a new setting to not show the Dotted Lines between player planets and AI planets without wormholes. I like being able to see the colour gradient better.
** At first, I was getting some very strange data sent across, and I figured that this was going to be an endianness problem, but actually all of the .NET/Mono data is the same endianness from the look of things.  Which makes sense, given that otherwise savegames would not work from computer to computer.
+
** Off by default
** After spending the night with that rattling around in my brain, this morning I decided to definitely do some profiling of the data before I started messing with the #ifdefs.
 
** First thing I noticed was that I'd chosen to use the RawData byte array, and immediately next thought was "I better check there's not a network header in there."  Turns out, yes, there's a UserDataOffset.  The first four bytes are not my data, and so of course it would give gibberish as if the endianness was wrong.  Just starting my reads from the proper offset makes everything work instantly.
 
** All of this is from a Mac to a Windows machine at the moment, but my I'll be testing three-way with my linux machine as well.  Right now laptop is sitting closed under the Mac.
 
  
* LiteNet logging now gets funneled to our own main logging pipeline.
+
=== Journal Tweaks ===
  
=== Continued Multiplayer Work ===
+
* The game now does a better job of telling you when journal entries appear through their Chat text
  
* A fair bit of work has been done to make intentional disconnections from the client or server tell the other side more quickly.
+
* When there are new journal entries to read the "Journal" tab on the sidebar now changes colour to make it easier to notice
** This should help to avoid some disconnect-and-reconnect issues that are otherwise inevitable, and it just makes things feel more responsive.
 
  
* Additionally, when you use the in-game controls to exit the program as a while, it now takes one extra half second to lets Steamworks and GOG actually do their exit logic properly, rather than rushing out the door.
+
* Add a few journal entries for the astro trains
** This should hopefully help with any cases of the game still being thought to be running on Steam in particular after it closed.
 
  
* When you exit the game, while it is doing its brief exiting stuff it now throws up a center-screen "exiting.." message.
+
=== UI Reskinning Part 1 ===
  
* Got rid of OnServer_WaitingOnConnectionIndices, as this was basically a duplicate of something we are doing better and more cleanly a new way, now.
+
* Textboxes throughout the game now go to an ellipsis if there is not enough room for their contents, rather than looping to a second line in a strange way.  This rarely came up because of character limits.
  
* UpdateDebugText() and all of its related variables have been removed.
+
* When you go from hovering over a textbox to then clicking it, it no longer flashes a different color for a moment.
** This was the sort of thing that, in all of our prior games before Raptor and moving to 3D, you could hit F3 and get output information from.  But it has never really been used in AI War 2 properly.
 
  
* Got rid of WorldTransmissionMessageType, as it was needlessly complicated.
+
* Designed some new UI shaders that allow for us to use HDR blooms on icons.
** This was essentially us breaking the world transmission data into multiple parts and then sending those in partsHistorically there were two reasons for this:
+
** Added a post-processing stack bloom item on the GUI-layer camera that is specifically for anything that is still in the HDR range when it is post-processing there.   
*** Back in AI War 1, we were using the Lidgren network library, and even though it was trying to work around the MTU (typicaly 1200 bytes) of various networks players might be on (or passing data through indirectly), it was often having bottlenecks and slowdowns with how it sent fragmented messages through the network card.  Our theory at the time was that it was flooding the buffers of the NIC, rather than giving it data at a more reasonable pace.  Network cards have grown enormously in the last 11 years, as have the OSes that control them, so that's not really a concern now.  All of the newer network libraries that we would be using to send data should be able to handle 1MB of data without incident.
+
** This should not apply to anything except the UI itself, since everything else should have been mapped back down to the LDR range by the tonemapping prior to now.
*** Secondarily, for AI War 1 and for the A Valley Without Wind games, we were sending enough world data that you could see a noticeable wait time, and by handling this above the network transmission layer we could give you visual feedback on transmission progress (even though the whole act of that actually slowed it down).  Eleven years later, we have networks that are vastly faster basically everywhere in the world, and the world savegames for AI War 2 are much more efficiently packed than AI War 1 was.  So sending a file like this really is like a midsize image on any website you visit, now.  Not really a progress bar sort of situation, especially if the progress bar itself causes slowdown.
+
** At any rate, this then lets us use, very selectively and carefully, some glows on icons and similar in the UI and have that behave properly and give a much better sci-fi effect.
  
* ConnectionStage has moved from being just a UI-only element to being ClientConnectionStage as part of the ArcenNetworkAuthority, so that clients can better keep track of their connection statusUsually this is less than a second or so, anyhow, but we still need to keep track of it in case something goes wrong in particular.
+
*