AI War 2:Finalizing Multiplayer

Known Issues

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

• Multiplayer is in public beta, as noted below. There is a detailed multiplayer guide that we are working on building up.

• Feel free to join discussions on discord!

What Does Multiplayer Beta Mean?

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

What's this phase all about?

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 term. So hence it still being in alpha status. But we greatly welcome folks to play, and hopefully give us reports on what is going wrong if something does go wrong.

We expect to be to a fully-polished non-beta status for multiplayer in May, if things continue as they have.

Our second expansion for the game, Zenith Onslaught, has a whole heck of a lot of it completed, but still needs more doing. Badger has done all of his parts for it, and has 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.

2.811

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

• Balance Changes
  • Fixed description of dire forcefieled guardian to say units protected by the shield do full damage (instead of only half)
  • Added a 2.2 strength multiplier to the Shredder Dire Guardian -- its strength value was wildly underestimating it because its drones weren't considered
  • Usurper metal cost 12,000 -> 100,000
  • Tier 1 exgalactic unit energy increase 15K -> 50K
  • Tier 2 exgalactic metal cost 2M ->5M; energy increase 15K -> 75K; armor thickness 180 mm -> 245mm
  • Tier 3 exgalactic metal cost 2M ->6M; energy increase 15K -> 100K; armor thickness 180 mm -> 350mm (except Jackalope); mass 8tx ->12tx
  • Tier 4 exgalactic metal cost 2M ->8M; energy increase 15K -> 250K; armor thickness 180 mm -> 350mm
  • Flenser metal cost 2M ->10M; energy increase 15K -> 1M

2.810 Hotfix for Death

(Released April 28th, 2021)

• Fixed a bug in the prior version where ghostbusting was being so thorough that it was actually preventing things from dying to remains, or being crippled, on hosts and single player machines. The "deep scrub ghosts" logic now only applies on multiplayer clients, and if it gets a bit overzealous and scrubs something too much, the host will be along to fix that very soon after.
  • It's possible that if this leads to brief visual artifacts on the client in an ongoing fashion (that remains to be seen), that we could make this specifically exclude things that die to remains or things that are crippled rather than dying, etc. We'll need more MP testing feedback to know if that's required or not.
  • Thanks to Democracy, donblas, bahrman, and psychophilosopher for reporting.

2.809 Self Optimization

(Released April 27th, 2021)

Balance

• Balance adjustment for Space Planes and Mirage strikecraft
  • Damage reduction value against distant foes reduced from 99% to 90%
  • Base health doubled from 1200 to 2400
  • The Mirage had its strength multiplier value raised to 2 from 1.6 to account for its shield ignoring damage which quickly disposes of most system defenses when deployed in large numbers.
  • The Mirage had its AI purchase price raised from 15 to 18 to match the price of the Space Plane the base variant. The more dangerous version being cheaper was leading to some gargantuan sized stacks in games with particularly bad RNG for the player.
  • Both ships should now be much closer in estimated strength value to their actual impact since a 99% damage reduction effect against fixed defenses that cannot close distance basically made even a simple mark one stack of ~60 ships have over seven million effective health. Now that same mark one stack would only have about a million and a half effective health. These ships are still quite dangerous if you don't have a nearby fleet or specific counters handy, but shouldn't chain wipe multiple systems on their own.
  • Thanks to CRCGamer for adjusting.

• Adjusted Expatriate Tech cost scaling
  • Previously was 2000, 2750, 5000, 7500, 10000 science cost.
  • New adjusted costs of 1000, 2500, 4000, 5500, 7000.
  • Makes grabbing a few ranks to improve HRF unlocks or Outguard easier to swallow while the final two ranks are still an expensive splurge.
  • Thanks to CRCGamer for adjusting.

Performance

• Updated the central DoForPlanets() type methods to now have a SingleThreaded and Parallel variant for each one.
  • The parallel versions are able to run on a ton of threads at once, and are way more efficient. However, there are very strict rules about how they are allowed to touch data. If you're a modder (or developer) for the game, and you don't fully understand what you're doing with this aspect of threading, then always just choose singlethreaded. It's slower but safer.
  • So far, we've used the parallel variants in a few places that should dramatically speed up a few areas of code that were previously bottlenecks in really large galaxies, or with lots of battles going on.
  • There are more places where we could use this, but those would take some refactoring to port over for various structural reasons, so we'll just handle those as they become pain points.

Bugfixes

• Fixed a couple of cross-threading exceptions that could happen in Base_StrengthData_PlanetFaction_Stance even in single-player on suitably multi-core machines.
  • Thanks to abuchris for reporting.

• Silenced a pointless "Null ArcenShot InstancedRenderer" error that could happen in ReactToShotHittingSquad() in certain cross-threading instances. Originally we had that code in place to make sure there were no problems, but now it's definitely pointless.
  • Thanks to abuchris for reporting.

• Fixed a few more cross-threading issues that could happen in GetEnergyUsage() and similar on units.
  • Thanks to abuchris and Bummeri for reporting.

• Fixed a pretty huge mistake in GetEnergyUsage() where if it could not find the fleet membership, it was using the shield amount of the unit rather than the energy cost of the unit.
  • It's likely that this was never really being hit, because the fleet membership should always be there except when something is in the middle of teardown anyhow, but still oof.

• Fixed some more cross-threading issues that could happen in DoEntitySecondLogic_FromSimBGThread().
  • Thanks to abuchris for reporting.

• Fixed a cross-threading exception that could happen in CalculateSpeed(), more likely in MP than SP, but possible in both. Also sped up this method for stationary units in general.
  • Thanks to abuchris and Bummeri for reporting.

• When the count to spawn on death is set to zero, it no longer throws an exception warning you of this when that type of unit dies. This makes it possible to override that field on copy_from children in the main game or in DLC or mods.

• If count_to_spawn_on_death is zero, then the "on death, will spawn" part of the tooltip won't show. This is very useful for when we are using copy_from and then forking a unit to not spawn something on death.
  • Thanks to Zeus for reporting.

• Fixed a number of rare cross-threading bugs that were possible inside of the shot visualizer.
  • Thanks to slake-moth for reporting.

• Fixed an exception that could happen in GetNumberOfTimesHacked() after a number of hacks were performed on various units.
  • Thanks to Therival for reporting.

• DoOnFail_CalledFromMainSimOnly() now has very granular exception handling, and will report problems that it has in a sub-area, as well as not actually breaking the entire flow if just part of it goes wrong.
  • Thanks to greyhoundgames for reporting.

• Fixed some cross-threading issues that could happen with hacks that were in the middle of being failed throwing exceptions. (It's possible that these were things that also had a success but then were triggering a fail at the same time for some reason, but both should be fixed now).
  • Thanks to greyhoundgames for reporting.

• When a TSS or similar has too-few items to grant, that should now auto-repair itself just like the too-high case does. This is untested so far, so please let us know if that's not the case.
  • Thanks to Metrekec, ArnaudB, GreatYng, and others for reporting.

Multiplayer Improvements

• In the event that a given unit on a multiplayer client has not gotten any updates from the host for a full 60 seconds, have it just suicide itself.
  • This is a very long timeout, but we want to make sure that this does not kick in by accident if at all possible. Brief interruptions in network connectivity, or a particularly difficult load of ship syncs to cycle through shouldn't be able to accidentally trigger this, is the goal.
  • That said, in the context of 4-5 hour gaming session, or even a 20 minute gaming session, this should hopefully act as the ultimate end-stage "goalie" to catch any client ghosts that sneak through in any other fashion.
  • Thanks to abuchris and Bummeri and their playgroups for reporting.

• In general, added a two-fold new thing for deleting units that we want to have die.
  • On MP clients, it keeps a record of all the things that the host asked it to delete but that it could not find. If those units later do a ghost check, those units now also check that central list. If they find their name there, they kill themselves rather than going through infinite more ghost checks.
    • The amount of added processing caused by this on clients should be pretty low, and it should make some ship deaths more responsive.
  • In general, when ships die on one of many background sim threads, we now have them write their death into a central concurrent dictionary. The death cleanup process looks through this along with the usual stuff it looks through, and this thus prevents things that are not in the central registry properly from being immortal ghosts.
    • In theory this could have some singleplayer or host applications, but mostly this helps MP clients, at least at the moment. Here again, this should lead to rapid responsible ghost death, and hopefully avoiding hitting the 60-second goalie.
  • Thanks to abuchris and Bummeri and their playgroups for reporting.

• Added two new commands to the game:
  • cmd:stop sim: Stop the simulation. This halts the simulation on your machine until you enter the command a second time. This can be useful for artificially inflicting "very behind" status on an MP client and then seeing if it can catch up.
  • cmd:resync: Send a fresh copy of everything from the host to all clients. Previously, the only way to really do this was to disconnect and reconnect. This should prove to be a much quicker way of accomplishing the same thing.
  • Details: https://wiki.arcengames.com/index.php?title=AI_War_2:Cheats

• A variety of the long-term continuous threads are now explicitly barred on multiplayer clients. Something funky is going on where clients are getting some extra orders from somewhere (which is leading to a rubber band effect during battles), and this doesn't seem to be the answer, but it is at least ruling out some possibilities.
  • At the moment we have a test case multiplayer game that rubberbands constantly, and we seem to have reduced the severity of it a bit, but it's still pretty bad. We're still looking into the source of that.

• The scope of where random seeds are reinitialized for combat rounds has been narrowed down to specific planet factions at each planet. This makes it so that if there is a simulation divergence in one faction on a planet, it won't bleed over into ships of other factions on the same planet. This does help to keep the host and client more in sync in MP, but it isn't the root source of rubber-banding, it turns out.

• Added a new ArcenGameDebugLogger that allows us to log arbitrary data from the game simulation at various points in a thread-safe fashion (so it does work inside Parallel loops) so that we can do things like compare the output from a host and a client.
  • The rubber-banding issue during combat is something that we can reliably reproduce within seconds with one save in particular, and it really marrs the multiplayer experience, so we'd like to figure out where the heck the simulations are diverging and why.

• Added a huge amount of debug output options to MovementPlanning, since we were seeing divergences on the client and the host. We're now able to see what actually happens, and more or less why (when we turn the option on in code).

• Adjusted things so that the auto-kite settings are now properly set in an MP-friendly fashion for the warden and hunter kite-master variants.
  • There's now a centralized method for MP-safe setting kiting settings.

• The UnitsAutoKite variable on factions has been renamed to UnitsAutoKite_NeverSetDirectlyOrItBreaksEverything, since it seemed to be being set by some outside process.

• The way that partial-sync status is transferred has been condensed into one style, whereas before it had been split in two, because this makes things vastly more straightforward to make sure are correct.

Death Of Rubber-Banding

• Fixed an incredibly annoying bug where ships were seeming to rubber-band away to one direction and then back on MP clients. Not always, but if it was happening to you then it was constant.
  • This was the result of actually a much more serious bug that was introduced in the last week or so -- back when the bandwidth for the game was majorly improved, whatever release that was.
  • Normally we were inferring the position of factions in the central index, and taking their data in that way. If there are 18 factions and we send them all in order, then the first one is 0, and the last one is 17. Pretty easy. It doesn't save much data, but why not.
  • Well, I'll tell you why not. When I later had the clever idea to only send player faction data on the highest frequency, it started putting those at position 0 and 1 (0 typically being "natural objects"/nobody, and 1 typically being the first AI but not always) in a two-empire game. This meant that in a two-empire game, it was likely that if the second empire had ship kiting on (it is on by default), then it would turn kiting on for just the client on that first AI faction. This would cause the ships to behave wildly differently on the client compared to the host, leading to constant corrections from the host, aka the rubber-banding.
  • Mitigating this problem was the fact that every second or so, the data for all the factions would get fully copied back over, so player data was no looking entirely insane, and mostly this was being applied to just one AI faction or similar, anyway. But then a few hundred milliseconds after that, it would come back in and write the wrong data into the AI faction again.
  • Overall it's hard to guess how many strange bugs in the last week or so were caused by this, but apparently all of them were subtle enough that just the kiting was abundantly clear since it caused rubber-banding.
  • Thanks to abuchris and Bummeri for reporting the rubber-banding, and giving an idea of how to reproduce it.

Client/Host Collaborative Bandwidth Optimization

• The host and client now have more robust communications with one another about where exactly they are in the sim-processing pipeline. In the event that the client finds out it is more than 400ms behind, it will start showing a little notice in the upper right corner. In the event that the host becomes aware that a client is at least 1 second behind, then it will show a notice about that.
  • Using our new "cmd:stop sim" command to artificially stall out the client (as if the network connection were interrupted) and then restart it, we see the client doing a proper catchup without any incident at the moment.
  • There are some folks reporting some command lag, and if that is happening then we should start seeing these notices, at least. It may be that the command lag was an artifact of the wrong-faction data being passed in the prior build, or the rubber-band desync data. But in case it's not, now we'll have more information to work with.
  • It's possible that potentially the host is filling the client channel with too much sync data in some cases, causing it to fall behind in a way that this wouldn't replicate, so next we'll deal with that by essentially requiring acks for sync data on the client.
  • Thanks to abuchris and Bummeri for reporting.

• It's possible that the host was sending sync data at a rate that clients could not handle, in some cases, leading to a general backup of data until the connection is broken and reformed.
  • This isn't something that we can easily check for, but it logically stands to reason, because -- unlike the central game stuff -- we don't ask for any kind of acknowledgement of receipt on that data.
  • Now we do. On the host, underneath the Sync Cycles info in the escape menu, you can now see it counting up a bit more slowly, as it is waiting to hear back from all clients before proceeding.
    • Sometimes a client won't answer, though. Maybe the client just connected and it missed the message, or maybe the client disconnected but hasn't been pruned yet.
    • When this happens, then the host machine will start counting to 60 over sim frames, which might take around 6 seconds overall.
    • If that's happening, you'll see the "waiting for acks" count go above 0. When it hits 60, then it just says "okay, nevermind waiting on the clients, just move to the next."
    • The "Acks Skipped" count will then go up by one, and the most likely result is that all the clients start responding with acks properly after that. After initial connection, you're should be very unlikely to see any Acks skipped, but one or two acks skipped at the very start of a connection to the host is just fine.
      • Huh! Actually, after running for a while, we randomly saw an ack skip happen again, in our own testing. This might actually be some evidence of the network client being overwhelmed, and it gives all of the clients a chance to breathe a bit and catch up.
  • Overall this winds up reducing the bandwidth usage a bit, depending on how quickly the clients respond, anyhow. This does NOT pose any risk of actually slowing down the game simulation (actually, kind of the opposite).
  • This also does not slow down the sync data for the ships themselves, as that's on a separate process that we're not throttling via these acks.
    • There's a very outside chance that the ship data could stack up enough to where this is a problem, in which case we'd need to add acks for that as well. Right now in our testing, we're seeing 75% of the data sent from the host as ship sync checks and divergent ship fixes, so it's possible that now that has shuffled into the top spot as something that actually can become a runaway process.

• Okay, one last communication vector between the client and host now has acks involved. (The clients all having to say "I heard you and got the data" before the host says the next big chunk of data).
  • This overall is not a giant bandwidth reduction, and it is not too much of a slowdown in how quickly ship sync cycles are completed, but depending on the nature of your network connection between the host and the slowest client, this will cause the syncs to inherently adapt to their environment.
    • Put another way, in a semi-ideal case, the bandwidth is not really lowered. But if things get congested or there's a lot of packet loss, then this will inherently slow down the process rather than just flooding the client with sync info.
  • Overall even in a semi-ideal state, this does seem to be closer to 50% of the network traffic now rather than 75%, so we must have reduced the overall volume if that's the case. It's hard to be too precise between runs, but it does look like maybe a further 20% to 30% reduction in bandwidth usage.
  • Most importantly, these changes are adaptive to nonoptimal network environments of all sorts while not actually slowing down the gameplay, so it should yield better results in basically all situations.
  • The only data beyond this that we could really gate behind acks is all too central to the game running smoothly, and it's also a tiny minority of the data being sent (15% or so), so those will remain un-gated.

Mod Updates

• AMU:
  • Removed some leftovers from AJEA (Auto-Juggle Energy) debugging.
    • Thanks to Chris McElligott Park for noticing.
• Kaizers Marauders:
  • Nerfed the Raid Super Battleship's health, shield and damage by 40%, and it loses its boarding strike weapon. It was a ball of super-powered steamrolling nonsense.
    • Thanks to ArnaudB for the balancing feedback.
• Extended Ship Variants:
  • The Engineering Transport Flagship no longer shows that it's "claiming neutral units" but instead "assists claiming units", similar to engineers.
    • Thanks to Sorrydough for reporting most recently, but I think others reported it a while ago as well.

• AMU / Kaizers Marauders:
  • Updated to fit the most recent changes in the Vanilla codebase.

• AMU / Kaizers Marauders:
  • Made some fine-tuning for the DoForPlanets code to avoid cross-threading issues.
  • While doing so found a bug in the Fireteam Maintenance code where it was not moving units to planets of their fireteam if they had no orders at all but still were on a wrong planet. This may already have been caught by the Vanilla fireteam code, but it's good to have fixed.

2.808 MP Ghostbusting

(Released April 23rd, 2021)

• Add an additional beginner journal for after you've taken the nearby ARS and flagship.
  • This is very placeholder-y and needs to be rewritten by someone more skilled at the game

• The Hacking menu now shows an estimate strength response for many hacks.
  • This estimates are more what you call guidelines than actual rules. The goal is more to let you see "Oh, this will be something like 10-20 Str response; easy" vs "This is a 200 str response. I need to bring lots of forces"
  • Not every hack has an estimate

• Some improvements to the ARS section of the beginner journal pointing out that hacking an ARS three times is often risky

• Added a new "Hacker OS" planet name set by ZeroTheHero.

• "The Reprocessers" mod by CRZgatecrusher has been updated to have proper shortnames and work with the new sidebar styles better.

Balance Adjustments

• Make the AI less susceptible to being trapped by forcefields
  • If you have blocked some AI ships retreat path with forcefields over a wormhole, they are now allowed to find another wormhole to retreat to
  • This behaviour is only for AI difficulty >= 7

• Increased metal production of Zenith Metal Generator from 3000 to 5000 m/s.
  • With energy metal production and costs having been increased in the paradigm, it felt underwhelming for a structure you need to defend, and gave to little of a boost.
• Increased energy production of Zenith Energy Generator from 600k to 900k.
  • Same logic except it felt lacking compared to economical stations. This makes it great wihout being OP.
• Increased hull and shield of both Zenith Generators by 10x. This makes them roughly as resilient as a Forcefield mark III. So they don't instantly die the moment forcefields go down. They are very pricy to repair though.
  • Thanks to ArnaudB for adjusting.

• AI Risk analysers are now less significantly punishing than having Fallen Spire active.
  • Base ExoStrike budget reduced from 20k to 10k. This means the strikes have less strength but are launched faster. (for comparison, One spire city in Fallen Spire intensity 5 is 8k.)
  • Exo strike starts charging after 55min of 40min of gametime.
  • Income for Exostrikes from Risk Analysers changed: 15->50 budget for AI-held analysers, 50->30 for neutral analysers, 150->75 for player-held analysers. With 7+ Analysers, the income from each analyser in all three cases is lower.
  • This change makes using the faction compelling to players instead of an overwhelmingly bad deal. It was worse to hold the analysers than to kill them in every situation. Now, you want to actively hunt down the analysers an deal with them one way or another, because they provide much more income in the AI's hands. Exostrikes are also more common and less deadly, thus better able to take advantage of well-timed CPAs and Waves, instead of a doom tsunami when those happened to sync up.
  • Thanks to ArnaudB for adjusting.

• Hacking cost on ARSes has been reduced back from 16 to 12. There was a lot of discussion on this, and the boost a build or so back from 8 to 16 was more than had been intended by those originally proposing it. Apologies for misunderstanding, and thank you to everyone for the discussion!

Bugfixes

• Fix a bug with tutorials introduced in the last patch
  • Thanks to greyhoundgames for reporting

• Added wrappers to catch exceptions happening in UpdatePowerLevel, CheckIfPlayerHasSeenFaction, and UpdatePlanetInfluence in factions, and make it clear which factions had the error while also not blocking proper execution of other factions.
  • If a mod in particular has an exception in one of these methods, it will now have less of an impact on the rest of the game.
  • Thanks to various folks for reporting the errors in some mod factions here.

• Fixed a cross-threading issue that could occur in CalculateCurrentShieldRadius(), most commonly on MP clients.
  • Thanks to Bummeri for reporting.

• Recompiled Civilian Industries because of nonspecific report of them having some sort of exception. Everything seems okay at the moment, and we don't play the mod directly, so until we get a report with more details there's not a lot we can do.
  • There is currently a bug in the Kaizer's Marauders mod that is pending a fix from that mod author, so it may have been having downstream effects on other factions. The changes in this build overall should keep mod faction bugs from impacting other factions.

• Preemptively fixed a lot of potential rare cross-threading issues in the core unit logic. Preferable to picking these up randomly as they trickle in, largely through MP play.

• Adjusted a piece of onstart code that allows Kaizer's Marauders to work again.
  • Thanks to various folks for reporting, and NR SirLimbo for helping coordinate what his mods needed versus what the game was now doing, and why.

MP Ghost Busting

• Fixed another way in which multiplayer clients could have "ghosts" left behind after battles.
  • This is actually a two-pronged thing, with some ghosts that you could even hover over not being zapped before, and with others that disappeared when you hovered, but did not disappear until then because of something like the unit being set to be new to the planet continuously.
  • Both cases are now caught, but it's still possible to have some ghosts in some cases that last for up to 3 realtime seconds or until someone hovers over them. We can pretty much reliably reproduce that, but thankfully that's fairly fast self-correct even if it's not as fast as under a second like the bulk of cases.
  • Thanks to Bummeri for reporting.

• On MP clients, you can now see how long it has been since a ship has been updated by the server by hovering over it. If it has been more than 5 seconds (realtime, not game time), it will show up in red in general.

• Made some adjustments on MP servers to do more thorough sync checks in general, which leads to fewer ghosts!
  • This was a case of saving some data to be clever, but in the end causing far more data to be sent in the first place, sigh.
  • This new change has now dramatically cut down the amount of sync data that we send, while at the same time making the client correct faster, aka feel more responsive.
  • Ghosts still happen and get caught, but it's far fewer of them, and they do all seem to be caught by the above process now.

Steamworks Update

• Updated Facepunch.Steamworks to the newest version from their git repository, moving up from the prior version that was from July 6, 2020.
  • It's notable that under the hood they are now calling a newer version of some of Valve's networking APIs, which I didn't even notice was a thing that Valve did (they do it for backwards compatibility with old games). So hopefully that makes some positive differences.

• Updated our usage of the Steamworks API to version 1.51, which for OSX also includes shifting the usage from their .bundle file (older) to their new .dylib file.

2.807 Beginner Journals and MP Sync

(Released April 22nd, 2021)

• Blitzkrieg turret now fires 36 drones every 17s instead of 12 every 6s. This gives the AI more windows to close in before being assaulted by the next wave.
  • Thanks to ArnaudB for adjusting.

• Blitzkrieg: Reduced hull for Automated Drones from 2240 to 1200 hull and Mini Automated Drones 750 to 400 hull.
  • Death of an Automated Drone creates 4 drones instead of 3 on death.
  • Speed of both drones increased to 2200.
• Makeshift: Drone speed increased from 800 to 1600.
  • All of those changes make the drones rush in closer to the AI so they can be swatted by splash damage instead of arriving in an ever-stalling wave. The drones are gunbot-like health so they'll die like the chaff they're supposed to be. This makes both raid turrets more powerful on offense and hopefully weaker on defence.
  • Thanks to ArnaudB for adjusting.

• Base hacking point cost for FRS hacks has been increased from 10 to 22.
  • Cruisers are now 18 instead of 10, and destroyers now 16 instead of 12.
  • Regular ARS is now 16 instead of 8.
  • The hope is to overall have better balance by not giving players SO much power at such a low cost.
  • Thanks to Strategic Sage for the suggestions.

Beginner Journal Improvements

• Add some new beginner journals to give the player some early game direction. This kinda duplicates the same detail that is in the Intel Menu, but duplicating critical information is good design. I want a new player to feel like the game is actively poking them to make good choices.
  • After a minute of gameplay, the player gets a beginner journal journal entry chat saying "We think we've found a good target for you. See the Journal for more details".
    • The game has detected whether the closest ARS or flagship is the best target (the weaker of those two planets). The journal explains how an ARS or flagship works.
    • When the player has accomplished this first objective, they get a journal prompt about the second objective.

• Both of these journal entries suggest looking at the Intel menu for more ideas

Bugfixes

• When exceptions happen in trying to deserialize a table row by index, it now includes the field name properly. This will help fixing exceptions in those serialization areas.
  • Thanks to NR SirLimbo for the report that made it clear we had a gap here.

• Fixed a funky exception that could show up on at least a few linux machines in the prior version of the game, typically when entering the lobby.
  • Thanks to Badger for reporting.

• Added three more canaries that are network-only, these ones into hacking events, so that we can identify if there is a problem with them.
  • Thanks to NR SirLimbo for reporting an issue there.

• Added another canary around the active hacking event on entities, again only for multiplayer. Code review seemed fine, so narrowing it down even further seems needed.
  • Thanks to NR SirLimbo for reporting.

• Put in some extra paranoid canaries, for the network only, surrounding each kind of external data. That way if a specific mod or subfaction or whatever has a serialization issue, it will become apparent which one it was.
  • Thanks to NR SirLimbo for the report that inspired this change.

• Fixed a super longstanding MP issue that has become more prominent recently, but has been hiding in plain sight basically since the start, breaking ship sync intermittently and also causing some other issues.
  • Essentially, on MP clients it would not properly say "I finished my current hack" on ships that were hacking. This led to situations where it tried to deserialize nonexistent hacking event data on the hacker every time the host would send it new data, which would then lead to serialization failures and in general a long and continual divergence in the simulations.
  • However, this was something that would fix itself on disconnect or reconnect, or save and reload, so that made this super extra hard to find. Until recently, it was also not clear that this was related to hacking events, because without the new density of canaries we didn't find out things were wrong until long enough after a hack finished that they didn't seem correlated to anyone.
  • This was surely a cause for various other UI and behavior problems on clients, such as likely inability to do more hacks with that hacker, and other things of that sort.
  • We have verified the fix, and knock on wood let's hope this is the last of the mystery sync issues!
  • HUGE thanks to NR SirLimbo and ArnaudB for the multiplayer session and report that led to this finally being discovered and nailed.

• Fix a bug where ships in Exos weren't properly clearing their exo status if they were against something like a Spire City.
  • Thanks to kasnavada for reporting.

2.806 Correctness By Attrition

(Released April 21st, 2021)

• Put a flair on AI defensive structures built by the Zenith Trader to make it easy to tell if they cause AIP on death
  • Further work from a bug report by mahisev350

• Removed the dmg bonus for Nodorian as its main weapon damage did crazy damage.
  • Its attrition is also bugged, doing much less dmg than it should.
  • Thanks to ArnaudB for updating.

• Reduced RorqualHegira shield from 1.5m shield to 1.0m shield. Reduced shield hack cost from 40 to 20, can be done twice.
  • This basically put it where it was.
  • Thanks to ArnaudB for updating.

• Improve the hovertext for units that are warping in.

• Some minor buffs to instigators. The 'Strengthen Wormhole Invasion' instigator should no longer spawn if the AI can't actually send wormhole invasions.

• When a stacked unit takes attrition damage, it takes numStacks * baseDamage damage instead. This means that stacks are no longer a really effective counter to attrition damage.
  • Also a preemptive nerf to the nodorian totoroid.

• Fix a bug where battle Notifications could report incorrect enemy strength.

• Fixed an exception that could still happen in SetAllMembershipsUpFromDesignTemplates(), in MP or SP, largely during map generation.
  • Thanks to Bummeri for reporting.

Quite A Lot Of Multiplayer Improvements!

• Canaries in MP in the prior version greatly narrowed down the ship serialization issue. Thankfully it does not seem to be in external code. However, we still can't find it. We've introduced one possible fix that is cross-threading related, but for now inserted more MP-specific canaries to get a more detailed snapshot of where the issue might be.
  • Thanks to Bummeri for reporting.

• Our LiteNetLib implementation has been updated so that if a client disconnects but the host still has a few lingering messages for them, it won't throw any errors. If the client is supposed to be there or is in some other state, it also gives more information.
  • Thanks to Bummeri for reporting.

• Revised the network sync a bit so that it once again checks the faction and the type of the unit when it comes to correctness.
  • This normally should not be needed, but it is a thing that can happen where ships transform but keep their ID, or in particular when they are gifted between factions (especially subfactions of the AI).

• Also fixed a bug where when a ship sync happened and there was a faction mismatch, it was not properly changing the faction.
  • This was leading to things like "rubber band ships" on the clients where the AI "sentinels" ships would move in one direction on the client and then jolt back when sync caught them. This is because they were actually hunter ships, which would make different decision (aka sitting there) in this specific case.
  • Ironically, in the quest to save a bit of check data, this absolutely flooded the game with correction data since it couldn't correct things properly.

• Fixed several exceptions that could happen because of cross-threading on MP clients in particular.

• Fixed some more rare exceptions that could happen on MP clients when certain state was invalid and a ship tried to transform or similar.

• Another source of strange behavior on clients (rubber-banding units, or unkillable units) was "ghost" units that were somehow still thought to be alive on the client, but the host knows are dead. When a client mouses over these sorts of units, they destroy themselves, but until then they mess with the client simulation quite a lot. Why exactly these exist is hard to say, but the clients now do a sanity check for potential ghost units, and request full syncs from the server on any of them that are ghosts.
  • The ones that are updated in this way are stale for SOME reason, even if they're not a ghost unit, so this should solve sync issues that can be missed via the main process.
  • In the escape menu if you have detailed info turned on, the client now sees a "Ghost Suspect Syncs" stat. Hopefully it doesn't go too crazy, but it's measuring this.

• Whenever the game would normally do that "Memory Profile Debug Data On Game Exit" dump to your local log, if you were a multiplayer host or client it also now dumps how many messages and how many bytes were sent and received. For sends, it also has it broken down by channel.
  • This is one of those "hey, that's some useful trivia for us or end users and doesn't take much time or space" things.

• MASSIVE savings in terms of amount of network traffic. We're talking roughly 75% savings for network hosts and clients. It's based on these two advanced features that have been added under the networking tab:
  • Host: Number Of Skips In Rolling Sync
    • The larger the number, the more of a break the network host takes between giving bulk data about updated planets, factions, fleets, etc to clients. This can dramatically lower the bandwidth requirements of the game, but can also make it take longer for errors to self-correct.
    • This doesn't really have an effect on units themselves, which are synced in a parallel process, so the bulk of things will be fine. Default is 2, but you can push it a bit higher without many issues if your bandwidth is that high.
  • Host: Number Of Skips In Ultra-Frequent Sync
    • The larger the number, the more of a break the network host takes between giving every-sim-frame sync data about things like faction data. This can moderately lower the bandwidth requirements of the game, but can also make the client see a slightly delayed view of certain central numbers.
    • This doesn't really have an effect on units themselves, which are synced in a parallel process, so the bulk of things will be fine. Default is 2, and it's probably okay to go a bit higher if you must. When it 'skips' one of these cycles, it still sends the human-player faction info, so that critical part happens no matter what.
  • This should also make the Steam Tubes style of networking way more playable in general, as the congestion on the main channel will be much lower. This was kind of an "oh, hey, we can do that" sort of moment that came as a surprise.

2.805 Relentless On Several Levels

(Released April 20th, 2021)

• Fixed not being able to hack for a third Dark Spire design at the Vengeance Generator
  • Note: check if third hack blow up the VG.
  • Thanks to ArnaudB for fixing.

• Two new kinds of mark level scaling have been added.
  • MobileLoneWolfFleetFlagship now gets whatever is assigned to is_default_for_lonewolf="true" (if there is anything).
  • MobileOfficerCombatFleetFlagship now gets whatever is assigned to is_default_for_officers="true" (if there is anything).
  • Thanks to ArnaudB for requesting.

• It's not entirely clear what "Threat Waves" were in the current paradigm of the game, or if they were even working. At any rate, they were highly undesirable mechanically if they did work, and they were just an option in the lobby. They have now been removed.
  • Thanks to Democracy and Badger for suggesting.

• Fix a bug where structures that had died back to neutral could incorrectly be reclaimable during battles, which was a needless resource drain as the AI killed the things you were rebuilding.
  • We were always looking at the "time we were created (ie game start time)" instead of actually tracking the "time we last were killed and reset to neutral", so we would always think that it had been a really long time since the unit was reset to neutral.
  • This was not really a problem until Metal Generators were more expensive to reclaim and the game was trying to reclaim them during a battle

• Added a new GetDifficultyOrdinal_OrNegativeOneIfNotRelevant() that can be used on factions to get a difficulty or intensity for that faction if one is relevant. For most it just returns -1 right now, but for AI Sentinels it returns the AI difficulty.

Relentless Wave Intelligence Increase

• When the game swapped to the Relentless Wave faction, waves also got dumber; they would only go after your command station every time.
  • Relentless waves are now smarter; the goal is more interesting and varied (and hopefully smarter and more dangerous) waves. Note that these advanced behaviours are more likely on higher difficulties (and usually won't happen at all on low difficulties).
  • Here are the rules
    • If there's a wave on a planet adjacent to your homeworld, the wave is allowed to just go for the the throat. Note the wave will only do this if it thinks it can make a real run at your king
    • If the wave is outnumbered on the current planet but there's a weak adjacent planet, the wave is allowed to go after the weaker planet
    • The default wave behaviour on a planet is "just fight generically, don't go after anything in particular"
    • The wave is allowed to go straight for your command station on higher difficulties if it thinks that is a good idea
    • The wave is allowed to go after structures that would generate AIP on death
    • The wave is allowed to dispatch really fast ships or cloaked ships to bring down your metal generators

• Badger was thinking about Bellatrix's steam comment and that the waves could be much smarter. Then he remembered he had already written all that wave intelligence code, it just hadn't been ported over to the Relentless Wave faction yet.

Balance

• Balance adjustments following yet another difficulty 10 win with a heavy emphasis on Exotic tech.
  • Vampire Turret and Harmonic Turret swap techs.
  • Harmonic Turret reload reduced from 2s to 3s.
    • This is to make it harder to have a good mono-tech turret nest with only Exotic since Harmonic turrets are quite strong on their own with sufficient numbers to cap their gimmick.
  • Acid Turret debuff scaling nerfed from 65 +20/mark to 50 +5/mark
    • This is because the damage is treated as base damage and is multiplied out by things like special damage bonuses, military command percentage damage bonus, and FRS buff fleet damage bonus. And is incredibly powerful for things with high amounts of multi-shot or very high fire rates.
  • Vanguard acid debuff scaling dropped from 30 +10/mark to 20 +5/mark for same reasoning.
  • Parasitic starting fleet adjusted. Parasitic Pike line replaced with V-Wings to make the fleet have a way to catch targets more reliably and to make it not able to upgrade three out of four ships off a single tech.
  • Thanks to CRCGamer for adjusting.

• Changed military Command damage multiplier to +25% per mark as they were supposed to. The bonus is +0% at Mark I.
  • This was supposed to have gone through over a month ago, I don't know why this went back to 10%+15% mark
  • Thanks to ArnaudB for adjusting.

• Increased metal cost for Phase 1 and Phase 2 Overlord to 5million. Just so metabolism give a reward to the players, rather than 0 for killing each phase.
  • Thanks to ArnaudB for adjusting.

• To make the shifted Harmonic Turret fit subterfuge better it now does 2x damage versus targets requiring 2500 or more power.
  • Thanks to CRCGamer for adjusting.

• Minor balance tweak to the Vanguard drones used by both AI and player versions of Escort Carriers within More System Defenders so they aren't better than regular non-drone version that was just nerfed. Base damage amplification value 30 -> 15
  • Thanks to CRCGamer for adjusting.

• Changed Crusher so its magnetic Pull now hit 50 targets instead of being an AOE. It kept hitting the closest unit instead of trying to bring in more. That should solve it and make it much better.
  • Thanks to ArnaudB for adjusting.

• Metal Generators are much tankier but also more expensive to claim.
  • The goal is to make defending Metal Generators something you might actually think about. Previously Metal Generators were extremely cheap to claim but also very flimsy, so they basically were rebuilt as soon as your command station was built (and there were no enemies).

• AI Allied Scourge at intensity >= 6 now get a faster start

• Nerfs to the Dyson Sphere to make sure they don't spawn units every second

• Improve the game's ability to detect when Hunter ships are supposed to be warping out due to defeated enemies
  • Thanks to samnainocard for a save game where an immense number of hunter ships were spawn-camping the dyson

Overlords By Difficulty

• There is now a separate version of the AI Overlord (both phases 1 and 2) at each difficulty level. The prior version from the beta was really designed for difficulty 8, and so was game-endingly hard on difficulty 6 and similar, while being too easy on difficulty 10.
  • The general changes as compared to the base stats are:
    • Diff 1: 5% of health and attack power compared to normal. Phase 2 speed 150 (was 300 in prior builds). Known as the v0.001proto.
    • Diff 2: 10% of health and attack power compared to normal. Phase 2 speed 150. Known as the v0.002proto.
    • Diff 3: 15% of health and attack power compared to normal. Phase 2 speed 150. Known as the v0.003proto.
    • Diff 4: 20% of health and attack power compared to normal. Phase 2 speed 200. Known as the v0.44rc.
    • Diff 5: 25% of health and attack power compared to normal. Phase 2 speed 200. Known as the v5xrc.
    • Diff 6: 50% of health and attack power compared to normal. Phase 2 speed 200. Known as the x6kx.
    • Diff 7: 75% of health and attack power compared to normal. Phase 2 speed 250. Known as the t7000.
    • Diff 8: 100% of health and attack power compared to normal. Phase 2 speed 300. Known as the t80.
    • Diff 9: 120% of health and attack power compared to normal. Phase 2 speed 400. Known as the z90. That phase 2 speed is no joke.
    • Diff 10: This actually shows off our ability to have multiple overlord variants! Because why not.
      • Diff 10 A: 180% of health and 200% of attack power compared to normal. Phase 2 speed 500. Known as the x4000 Super. This whole thing is a death machine.
      • Diff 10 B: 180% of health and 150% of attack power compared to normal, plus 150% of normal attack range (ow). Phase 2 speed 500. Known as the PFFN. This is also a death machine.
      • Fun fact: I (Chris) have been using the nickname x-4000 online since the late-ish 90s, because it was the name of the villain in a novel I was writing at the time. Different clones from the same facility, or something like that (I was a high school writer, leaving a lot to be desired there). The hero was y-3003, but since I was originally using this online handle as a romhacker, I chose to use the villainous name and it stuck. Now it's actually finally in a work in an appropriate place.
  • Thanks to donblas for reporting what a crazy difficulty spike the Phase 2 overlord was in difficulty 6 games. Thanks to Badger for suggesting the PFFN variant, in honor of Puffin's contributions and long-time battle against diff 10 victors.

• When savegames are loaded, any older-style AI Overlords will be converted into their newer counterparts depending on the difficulty of each respective AI. So if you had a multi-AI game, you'll have multiple variants of AI Overlord if their difficulties varied.
  • This makes it so that lower-difficulty games-in-progress can avoid the shock super-hard ending difficulty spike.

Bugfixes

• Put in some new cross-threading protections for when entity order collections are altered in any way.
  • Rather than using a concurrent queue or something of that nature, we are using an old fashioned style of thread lock on the lists in question.
  • There is the very rare risk that this could cause a deadlock, but most likely this would be detected and it will kill the background thread. In the event that happens, we can adjust further. It's also possible that this was the cause of the freezing up that Strategic Sage saw over the weekend, although we're probably not that lucky.
  • Thanks to ptarth and Waladil for reporting.

• Fixed a regression that was a long-standing issue where if you tried to load a save that failed, and then clicked out of the load savegame window, you would wind up in a purgatory that was half crazed-main-game-ui and half main menu ui.

• Adjusted our entity order serialization code a bit so that EntityOrderType.Length can actually be serialized if need be.

• Improved the debug messages when entity systems fail to deserialize.

• The game now supports putting "canaries" into serialized savegames as well as on the network.
  • This is useful for quickly detecting when there is savegame corruption of some sort, which could be caused by a mistake on our part, or a bug in a mod that contains savegame-style data.
    • Because of the utility with mods, which are ever-changing, this is something we're putting in in a minimally-invasive fashion so that we can leave this in indefinitely rather than just having it when we know we have some sort of problem in our own code.

• There is some sort of ultra-rare serialization problem with entities that breaks certain savegames. This must be something that has a very strong temporal component, or is using a feature that very few ships use, or something of that nature.
  • Right now we are unable to identify where it is, although we know it is not mod-related. The new canaries are an attempt to locate this, given the rarity of the item in question.
  • We wish that we were able to to solve this directly in one go, but essentially we need a version of this where it is broken after saving with the canaries present in order for us to find it. We've tried reverse engineering it from existing broken saves, but did not find anything conclusive despite a few promising leads.
  • Thanks to ptarth for the one set of saves that had this problem.

• Put in some better clarity when Astro Trains run into trouble doing a depot event.]

• Fix a bug where player-allied Nanocaust might snipe player-allied scourge units when they spawn in
  • Thanks to Geeber51 for reporting

• Fixed a couple of bugs that could happen in DoMilitiaThreatReaction() in Civilian Industries, but in general just instrumented that code so that if it happens again we will know where and why it is happening.
  • Thanks to gigastar for the report.

• Improve the text of some settings related to player-allied factions
  • Thanks to mahisev350 for reporting.

• In a number of places in the game, we're updating counts from across multiple threads. It's generally for informational purposes, and originally was not too much under contention. But it has been lately, and we were getting wrong numbers.
  • We are now using System.Threading.Interlocked.Add() instead of just using variable++ as an operator. This performs better, and gives correct results.

• Rather than using finalizers and other not-so-efficient methods to track objects of which we are suspicious, we are now using a new ReferencerTracker class of our own design, which uses WeakReferences in a ConcurrentDictionary that is fed by the constructors of suspect objects, and which are parsed and pruned on background worker threads every 3 seconds or so.

Multiplayer Fixes

• Fixed some exceptions that could happen in DeployDroneContents_ONLYCallFromSimBGThread() on MP clients. This should not have been running on clients in general.
  • Thanks to Badger and Zegma for reporting.

• Put in some more canary code in Client_AcceptDivergenceDataFromHost, which seems to have been having some errors in MP at times.
  • Errors in this could cause various strange afflictions like units disappearing, so finding the root of this is important and this should be a good step on that path.
  • Thanks to Badger and Zegma for reporting.

• Fixed an exception that could happen during hacks on MP clients. In general this code is again now not run on MP clients. Ships involved are being immediately synced from the host to the clients anyhow.
  • In general, just to be on the safe side, but in extra instrumentation for this even on the host, and split it into its own method, however.
  • Thanks to Badger for reporting.

• Fixed a number of potential cross-threading issues in ActuallyFireSalvoAtTargetPriorityList(), most of which were mainly able to happen on MP clients, but technically which could likely happen under rare circumstances in SP as well.
  • Thanks to Badger and Zegma for reporting.

• Fixed some cross threading exceptions that could happen in WriteCityTooltipDetails, mainly in MP.
  • Thanks to Badger for reporting.

• Canary was hit for some faction's external data in MP, but not sure which one. We have improved the canary code to give us more information about what faction name and type is present.
  • Thanks to Badger for reporting.

• Whenever you quit the game to the main menu or the OS from an active game (or get booted in multiplayer from a lost connection) it now logs a little "Memory Profile Debug Data On Game Exit" table.\
  • This currently covers how many fleets, fleet memberships, orders, planetfactions, faction, other gameentities, shots, ships, speed groups, fireteams, pathfinders, gamecommands, and planets have been created, garbage collected, and are still active since last reloading the game.
  • There seems to be a memory leak in multiplayer on the clients, and comparing these numbers between client and host should give us some ideas on where that is. It's possible that these are in "external data" somewhere, in which case we will have to greatly expand our footprint reporting.
  • If you're curious, essentially if the number of active ones is super duper high on the client, that's the point of concern for a memory leak. That said, if the number of total ones created is very much higher on the client compared to the host, then that could be indicative of a performance problem (rather than a memory leak).
  • These numbers mean almost nothing in isolation (unless numbers are in the hundreds of thousands or up), so if you report your version of these, please pair the client(s) and the host versions of the report together.
  • If your game is getting laggy near the end of a long session, or clients are seeing strange behaviors, or whatever else, then please do send us these plus whatever other information you feel like is relevant!
  • Fleets or fleet memberships in particular are suspicious right now, as Badger had noted that sometimes on clients not all of the ships would be selected if you press the hotkey associated with that fleet. That could be a different form of code bug, but malformed/duplicate fleets or memberships is the highest likelihood. Paired with general command delays and slowdowns on clients in long sessions that reset when disconnecting and reconnecting, we know there is SOME sort of client memory leak in general.
  • In the absolute worst case, we can brute force fixing some of this (that may be needed in the event that mods are what contain a memory leak, for example, since we can't fix those sorts of things) by doing a complete rebuild on the client periodically, but this would lose some UI state and might be annoying. If we did do it, for the most part it would likely just feel like a "save interruption" in a game like Factorio. And if we did it, it would be an optional thing. For now we'd rather go hunting for the leak.

• Fixed a number of DoEntitySecondLogic_FromSimBGThread() errors that could happen on ships on MP clients.
  • Thanks to Zegma for reporting.

• Fixed a whole nest of more things that could go wrong in cross-threading on MP clients in wormhole traversal logic, AI orders reevaluation, etc.
  • Thanks to Zegma for reporting.

• The way that we were sometimes pre-generating PKIDs on the host and giving them to clients, and the way we were calling CreateNew_CallWithSpecificPKIDID_ClientOrHost(), has all been removed.
  • This almost never worked entirely properly, and tended to cause players to see the things they created exploding and then reforming exactly where they were. It also used more network data than is needed.
  • This was a clever idea before we came up with the concept of our "fast blast" network sync from the host, but now it's entirely unnecessary.
  • This also solves a cross-threading bug that could happen in that code, but that was honestly the lesser of the problems there.
  • Thanks to Zegma for reporting.

• Introduced more network canaries into the fast blast data, as some of it was not coming through properly for clients in some cases. In all cases, this seems to be ship data, so it's probably the same problem that we're seeing in some rare savegame cases for single player.
  • Thanks to Zegma for reporting.

• Stacks that are split are now done only on the host, and the data is sent quickly to clients. This avoids some errors that could otherwise happen on MP clients.
  • Thanks to Zegma for reporting.

• Fixed an exception that could happen in SwitchToFaction() on MP clients. This is now only done on MP hosts and then quickly synced to clients.
  • Thanks to Zegma for reporting.

• Fixed a couple of cross threading errors that could happen on MP clients in GetIsSelfConstructionBlocked().
  • Thanks to Zegma for reporting.

• Fixed an exception that could happen in DeployAIReinforcementContents() on MP clients. This is now only run on hosts, and clients hear about it quickly after.
  • Thanks to Zegma for reporting.

• Fixed up the way that we deserialize squad orders so that it is vastly more efficient for multiplayer clients.
  • This was at least a mild memory leak on MP clients, and possible quite a severe one.

• Also fixed a memory leak (probably a mild one) in the single-player game related to orders, in cases where the firing orders were invalid for some reason.
  • This was likely very very mild, if it even came up at all. But nice to have things fixed.

• Fixed an exception in SetAllMembershipsUpFromDesignTemplates() that could happen on MP clients when they were connecting in. That only needs to run on the host anyhow.

• Multiplayer clients are now a bit slower about deleting ships that were not in the prior sync cycle. They now wait two sync cycles to be sure, as well as not deleting something that is so new it has not been sync-processed at all yet.
  • This should reduce some network traffic, and some flickering of new units, and some issues with units that just moved between planets. This might have the side effect of a few dead entities sticking around for a few extra seconds on the client, but probably not (a different process should catch that).

• Multiplayer clients now split "catastrophic" ship mismatches (which should be just from a faction switch), and count missing ship mismatches as a separate category.

2.803 Multiplayer Option Overload

(Released April 16th, 2021)

• Updated the Fallen Spire journals
  • Thanks to Vinco for some excellent feedback

• Watched Fleets are now above Local fleets if both watched and local are above the ships in the planet tab
  • Thanks to Daw11 for the feedback

• Improve the text when you are hovering a fleet in the sidebar and ask for more detailed in formation
  • This was annoying Badger

• Added a new skip_all_waves="true" option for tutorials, which prevents any waves from spawning in them. This is set on for all of our tutorials, as we don't wish for any waves in these specific ones.
  • Thanks to Mr W and Strategic Sage for reporting.

• Fixed an issue where the GOG linux installer did not have the UnityPlayer.so file. This was missed because we upgraded to a new version of unity, and they moved that file there without us noticing it. Apologies!
  • This will be present in the new build of the game, which may take a few days for GOG to upload.
  • In the meantime, if you are missing that file, you can download it from here: https://drive.google.com/file/d/1TCj9xpZBGn_OAUJtLSy1tHnTxb7kUu0o/view?usp=sharing
  • Simply drop it right in your root AI War 2 folder, and you should be good to go.
  • Thanks to rudhek for reporting.

Way Too Many Networking Options, But Here We Are

• Holy explosion of Steam networking frameworks, Batman!
  • So... the networking options that we provided in the prior release did not work for everyone, and we're not sure why. To err on the side of caution, right now we're providing a stupidly high number of options. We'd love nothing more than to pare this back down, so feedback on what works and what does not would be very welcome.
  • There are now SIX variations of Steam networking, and soon that number may be eight, but we'll see.
    • These come in pairs, with Relay being ones that are sent through Valve's servers, and Direct being ones that just go across the general Internet (and sometimes require the host to share their public IP with the clients).
  • The first pair is called Steam Multi-Sockets.
    • These connect via four socket connections on four different ports (as with last release), and thus are way more efficient because of how they are able to avoid data traffic jams. These may not connect for all players, though, or if connectivity is rough, they be more prone to dropping client connections since there are four that must be maintained per client.
  • The second pair is called Steam Tubes:
    • This is the sort of networking we started out with in 2.800. It uses just a single socket connection, no channels or anything, and shoves all the data along it. It is VERY prone to traffic jams, because of this. This should only be used if Multi-Sockets is not working for you.
  • The third pair is called Steam P2P:
    • This uses a different (and slightly older) form of Steam networking called P2P. The underlying technology is completely different from the two forms of networking above. This works phenomenally well for some people, and is very fast for them. For others, it won't even connect. For a few others, for some reason the underlying network actually corrupts data from time to time.
  • In the game, we have ranked all of the various connection types from S tier down to C tier, with color-coding. This was the only real way we could think of to make this at least slightly less overwhelming, but it's still now awesome. Apologies for that.
  • Huge thanks to Fluffiest and bluastelo for helping us live-bugtest this.
    • They eventually got it to work with Steam P2P, but neither Multi-Sockets nor Tubes were working until they made the P2P connection. After the P2P connection was made, Tubes started working... so maybe that means that Multi-Sockets would then work? If so, they could move all the way back to Multi-Sockets, and have the most performant connection possible.

• Our integration with Steamworks no longer uses asynchronous callbacks. This was causing callbacks to be checked every 16ms, which in some cases is a bit too slow. We are now running callbacks every frame, directly on the main thread, because with those -- particularly the networking ones -- we want to be able to directly get the results asap and we need them on the main thread anyhow.
  • It's possible that the use of async callbacks was what was causing flaky networking via Steam for some folks, but it's hard to be sure just yet.

• Actually updated our callbacks-running to be even more explicitly checked right before network messages are checked. This should ensure absolutely the most timely possible reception of network messages via Steam.

• Fixed a random crash that could sometimes happen on clients of Steam Multi-Socket networking.
  • Thanks to Fluffiest and bluastelo for reporting.

2.802 Multiplayer Steams Onward

(Released April 16th, 2021)

• Adjusted several parts of the game to use EnumerateFiles() rather than GetFiles(), and the same for directories, because these things cause less of a delay when you have a huge number of savegames or campaigns.

• Updated several aspects of the quick start window and load savegame window to make them load much faster when you have hundreds of savegames on your machine.

• added_shots_per_salvo_per_mark can now take in non-integer numbers. The result at any given mark level will be rounded down to the nearest integer.
  • The math is [mark level above 1] * [added_amount], rounded down. So if you have a value of 0.6, then at mark 2 it would be just 0.6, round down to 0. At mark 3 it would be 1.2, round down to 1. At mark 4, 1.8, round down to 1. At mark 5, 2.4, round down to 2. Mark 6, exactly 3, and at 7 it will round down to 3 also.
  • If you want an added shot at marks 3 and 5 and 7, then a good number is 0.5. That would give you +1 at mark 3, and +1 at mark 5, and then +1 at mark 7 rather than mark 6.
  • Thanks to CRCGamer for requesting.

• Balance adjustment to Tritium Sniper Frigate: Now gains an extra shot per salvo at marks 4 and 6.
  • This should make it more competitive with its variant the Ramifier Frigate.
  • Thanks to CRCGamer for updating this.

• Add a setting to not place the Strike, Lone or Officer prefix before fleet names.
  • Thanks to Badger for adding.

Bugfixes

• Fixed a bug where electrotoxic effects were not working because we had intentionally disabled them when looking for a certain crash, and it accidentally got left off.
  • Thanks to CRCGamer for reporting.

• Fixed icon not working in Powerful Command Stations Mod by ArnaudB.

• Updated the game to allow parsing "false" as 0 when doing xml processing.
  • This solves the problem of potential exceptions when someone has AutoBuildAssaultFrigates in the old format rather than the newer style.
  • Thanks to KingSyphilis for reporting.

• Fixed a random cross-threading exception that could happen in FindProtectingForcefieldToHitInsteadOfTarget() if the stars aligned just wrong. This could affect multiplayer or singleplayer, and is not a new bug, but is just THAT rare.

• Fixed a fairly rare bug that was causing units to not serialize properly sometimes. It seemed to be related to the incomingshots list on units, which is something that really should only be sent in fully network syncs but should not be sent to disk or as part of smaller network syncs.
  • Essentially, because of the many improvements made to multiplayer efficiency, this unfortunately had created a miniature version of Russian Roulette (some sort of fantasy chain gun with 2000 slots but only one with a bullet in it), where if you got tagged with it, it would corrupt your save.
  • Thankfully, autosaves are a thing, and in the example save that had this issue, there was an autosave from literally 20 seconds earlier that did not have the problem. And with extensive testing on the same save, we couldn't get it to replicate.
  • That said, some of the persistent intermittent errors that folks were seeing in multiplayer were a lot less rare (because multiplayer takes a lot more tries at Russian Roulette, not because the actual odds changed), and this is probably an accidental discovery of what those were.
  • Thanks to deR Zaubererer and their MP partner for discovering this.

• Fixed an oversight where the "Intra Galactic Coordinators Permadeath" option was still in the advanced settings, even though IGCs themselves have been removed.
  • Thanks to Democracy for reporting.

• Fixed an exception that could happen when completing a spire relic hack if the spire relic was not on a nearby planet.
  • Thanks to vinco for reporting.

• Ships that regenerate in a certain amount of time based on seconds_to_fully_regenerate_hull now will still do it in that same amount of time even if their maximum hull health is increased by outside factors like a hack.
  • Thanks to CRCGamer and Democracy for reporting.

• Fixed an issue on the ODSS tooltips where it was still saying you could hack four times instead of twice.
  • Thanks to Zer0h1nder for reporting.

• Removed some old code that would complain about multiple PG factions if they were in the "wrong" order. It was annoying on startup of many savegames.
  • Thanks to Badger for the save demonstrating it.

• Dyson sphere: add some defensive code for a random crash Badger saw.
  • Thanks to Badger for adding.

• Fix a typo in the fleets swap line messages.
  • Thanks to Badger for fixing.

• Fix a very fun bug with ships aggrod by the dyson joining the hunter fleet.
  • This also was a memory leak, and has been around since October 2019. It happened more the more factions you had in general, and the more times you reloaded saves before closing the game.
  • Huge thanks to Badger for hunting this one down and fixing it!

Multiplayer Updates

• Put in some code with Steam P2P networking that should make it more likely to connect in general for more people.

• Steam networking has been split into four separate frameworks that you can choose from, rather than (recently) two or (previous to a few weeks ago) one.
  • This lets you choose between Steam P2P direct or relayed, or Steam Sockets (formerly Steam Connection-Oriented or C-O) Direct or Relayed.
  • The Steam P2P Direct method is new and doesn't require any special configuration. You just select a steam friend and hit connect like always. It may or may not work well, though.
  • The Steam Sockets Direct method is also new, and requires you to connect via IP address, which the host must provide to you. This works with both local and public IP addresses, and should be able to avoid NAT punchthrough -- but if that fails, you will still need to use Steam Sockets Relay to work around it.
    • This method is noticeably faster than any of the other Steam methods, but slightly less convenient because of the whole IP-sharing thing.

• On the networking tab, there is now enough room in the textboxes for you to read IPV6 addresses.

• The call to find your public IP address is now run asynchronously, so when you first click into the networking tab it no longer has a moment of lag while it contacts a server to find out what your IP is for you.

• When you are in the lobby as a multiplayer host, or in the escape menu as a multiplayer host once a game has started, it now specifies what your public and local IPs are if you are on the sort of networking framework that needs that.
  • In those places, it also specifies what networking framework you are using, in general.

• In the escape menu, if you are in single-player mode, it now will also show that. It looks like there were some ways for people to wind up no longer being a host without realizing it, and this will let people actually check. This is possibly what was leading to some (but definitely not all) connection issues for some folks.

• Fixed a bug where if you tried to load a savegame to host in multiplayer, but encountered an error, then it would switch you to single-player mode. That was going to be a problem if you were then expecting clients to be able to connect!

• Major networking improvement for the Steam Sockets networking style!
  • Steam sockets does not support multi-channel data, which is very limiting when it comes to sending main data quickly, but also having other large pieces of data that get there in a relatively-timely-but-not-so-urgent fashion.
  • To work around this, we basically followed Valve's suggestion and built in a multi-port solution, which uses the port you have chosen (for direct connection), or the virtual port 0 (for relayed connections), plus the next 3 numbered ports after that.
  • You can now see in your log as the client and host make and accept connections on each of those four channels/ports, and once all four are connected, then it starts sending data across them as needed.
  • If any of the four drop, then it will kill them all, but there's not really any reason to think that disconnects should be more frequent because of that. That was my original fear, but if that does happen I can potentially work around it a couple of ways. I have yet to see a disconnect, though, which is good.
  • Overall this takes the data sent from the host to clients, and makes something like 97% of it go on the secondary ports, which is a gigantic boost to the ability of the main port to send and receive timely information to keep the game going.

• The two Steam P2P network options have been commented-out for now, making them unavailable for use. The only advantage that they had over Steam Sockets was that they could send multi-channel data (and that was a huge advantage). But P2P has been very unreliable, and other game developers are recommending to avoid it. It's still there in the xml if someone needs to uncomment it and try it for some reason, but we're hoping to have fewer options to confuse people.
  • The need to have Steam Sockets Relay and Steam Sockets Direct as two separate options will pretty much always remain (because they work fundamentally differently and have very different pros and cons), but we'd definitely like to avoid having a silly amount of choices.

• Fixed up an issue where MP client machines could mess with the hack options of TSSes, ARSes, and similar. Now that is strictly handled by the host, and any changes that are made are sent to the clients post-haste. This was mostly already being caught and fixed on the client, but there was no good reason for the client to be doing this, and it just added inconsistencies to fix.

• Fixed a very funky exception that could happen in DoFactionStepLogic_Stage2 on random factions on MP clients in particular, but in MP in general.

• Fixed a variety of exceptions that could happen in HandleAutobuild() mainly in multiplayer, on the host or clients, due to cross-thread racing. Technically it could also happen in solo play, but we haven't seen any evidence of it actually doing so.
  • Thanks to Badger for reporting.

• The "BLARRRGH! Only authorized to execute through frame" error is now silenced. That... really wasn't actually a problem that was worth even complaining about. This was something that was showing up lately in at least a few multiplayer sessions, though something else seemed to be going on with them in general.
  • Thanks to Badger for reporting.

• Fixed a possible issue in multiplayer where out of order messages from the server might have potentially messed with the Network_AuthorizedToExecuteThroughFrameNumber.
  • There should not be out of order messages in the first place, but just in case.

• Fixed an issue in CheckForInternalShipDeployment_ReinforcementLocations() that could happen on MP clients, which really did not need to be running that logic anyhow.
  • Thanks to Badger for reporting.

• Fixed an exception that could happen in SpawnRaiders() on Marauders in multiplayer clients. Again not something they needed to ever do, it's left to just the host now.
  • Thanks to Badger for reporting.

• Fixed a number of possible cross-threading issues in CalculateShipsThatYouCanCapture(), which were vastly more likely to happen on MP clients.
  • Thanks to Badger for reporting.

• Fixed several more cross-threading bugs that could happen in WriteFleetTooltip(), again way more commonly on MP clients than anywhere else.
  • Thanks to Badger for reporting.

• Fixed another cross-threading bug that could happen in Hacking_GrantShipLine_DontDestroyTarget.GetCanBeHacked(), again mainly on MP clients. The obvious potential errors have been fixed, but then also it will now show in the ui an "error at debug stage x" message if it still runs into one. It will also silently log the error for us to look at more later, and to be able to further fix if need be.
  • Thanks to Badger for reporting.

• Fixed an exception in SetNextTargetForTradeStation() that could happen on multiplayer clients using the Civilian Industries mod.
  • Thanks to Zegma for reporting.

Prior Release Notes

AI War 2:The Paradigm Shift