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

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

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

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

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.

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

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

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