AI.War.2.Update.v1.309-PLAZA - Kommentare

Sprache wählen
Board RSS API Hilfe Kontakt
Sprachen (nur Bildschirmtext):
Matrixxneo User
24. Jan 2020, 10:08 Uhr

[Spoiler: Zum Lesen hier klicken!]
Update v1.309:
The counterattack notifier hovertext now tells you how many guard posts you have to kill to disable the counterattack
Fix a bug where the Devourer wasn't shooting the zenith trader
Thanks to Ovalcircle for reporting
When the game tries to create notifications up at the top part of the screen for the human player, if it runs into an error it now is much more informative about what the error was, although it's still not exact in every case.
Thanks to DefeatedByTheCat for the report that triggered us to add this.
Fixed a variety of places where if the AI did not have a "most annoying faction" at a location, it would error instead of simply waiting because it was not annoyed.
In "send a wave if alerted after X seconds" (raid engine).
In the human notification checks for raid engines.
And that's it, from a thorough code review. Everything else actually already checks properly for the most annoying faction index being -1, or the resulting faction object being null, as relevant.
Though it is worth noting that if there is mysterious threat showing up because of minor faction aggro against the AI, it's possibly because the AI got a -1 from this at some point.
Thanks to DefeatedByTheCat for the report that led us to finding this. This isn't actually a new bug at all, just a rare one apparently.
Lone Wolf Flagships can no longer have ship lines swapped to them. This is a very longstanding bug.
Thanks to a bunch of people for reporting, including Chthon, Iocaine and deo
Fixed the "Called AI Sentinels_execCont_607 pathfinder from two different contexts! First was executionContext, new one is specialFactionContext_22_AI" error, and probably all related errors.
The correct pathfinder to use for a faction is now centrally calculated from a method called GetPathfindersOfRelevanceFromContext, and there are now many more pathfinder instances possible to have on a faction instance to avoid the potential case where factions need to pathfind out of cases we were expecting.
If pathfinding is done by Faction.FindPath in a generalized sense from certain types of threads (anything other than the main, execution context, or background faction planning threads), then honestly it will probably wind up with an exception and the programmer in question needs to instantiate their own custom pathfinder instance for whatever it is they have in mind.
As it stands, it's now lazy-instantiating all these new possible pathfinding contexts per thread type per faction, since a lot of factions do next to no pathfinding and all of them only use some of the thread cases.
This helps to avoid memory over-usage (even though that would still be minor in the grand scheme), and makes instantiating faction external data slightly faster than it was in the past and would have become in the future.
Thanks to zeusalmighty for reporting.
Also put in a count of pathfinders created in total, and discovered that we were creating and discarding a pathfinder or two every second or so. This was a minor performance drain and is now fixed.
You will notice that the number of pathfinders goes up over time early in a new game because of the lazy-creation of them as factions need them, and that's normal (even some getting added hours after starting is normal, if a faction enters a new mode for the first time). Exiting one game and creating another will also cause more to get created. But there shouldn't be a runaway growth of them indefinitely.
Fixed a cross-threading bug that could cause GetWormholeToOtherPlanetOrNull to have a nullref inside it.
Thanks to Binary Blitz for reporting.
CPAs no longer allow you to C-click them, and the slight information that was actually useful inside a c-click of one is now just in the direct tooltip, which no longer asks you to c-click them. This is all just a lot more clean and clear.
Thanks to Badger for suggesting.
Change Instigator Base spawning rules to hopefully make them a bit less frustrating
Previously once you hit 300 AIP the Instigator base could spawn anywhere
Now between 300 and 600 AIP the instigator base must spawn between 4 and 7 hops from one of your planet, and it's only unlimited after 600 AIP

Update v1.308:
Most Notifications now work as follows. Clicking on them in the Galaxy view will center you on the planet. Clicking on them in the Planet view will take you to that planet.
Combat fleets now include their Strength in the tooltip in the Intel menu
Thanks to Admiral for suggesting
Even on the brief tooltips, the game now shows how many ships and what their strength is for AI reinforcement points. The medium tooltips show the types of ships in there and a bit more info. This is pretty important information at every tooltip level.
Add a setting for preventing instigator bases from spawning.
While canonically the AI gets instigator bases, some people find them frustrating or stressful to play against.
Requested by Admiral
Ghost, Ensnarer and Sniper AI Turrets now say their type, so the Ensnarer Battlestation having them doesn't seem so odd (as it now specifically says "Ensnarer Pike Great-Turret" for instance).
Mentioned by Ryulong and Venger.
Astro Train Buffs
Astro trains can now spawn multiple trains at once, based on the intensity of the faction.
Only for intensity >= 5. Chance for multi-spawn starts at 10% for intensity 5 up to 60% at intensity 10.
Lets see if this is enough to make them more exciting. From a discussion on Discord with Hyde, zeus and others
Fireteams drop out of 'bonus speed mode' once they are actually attacking the target. A fireteam only gets bonus move speed to make sure all the fireteams attacking arrive in a coordinated fashion
Thanks to Astillious for pointing this out
Fireteam-based Nanocausts now are constrained from attacking the player too early.
Killing a nanocaust hive now means nanocaust ships won't get any new orders (except 'fight on this planet')
Thanks to Astillious for the bug reports
Fixed a bug in the last couple of builds where it would always talk about your "best fleet" in the end of the game (win or lose) as "useless cowards" (which is just what it says when it can't find a fleet).
Thanks to Ovalcircle for reporting.
Fix a bug where factories weren't printing things they were rebuilding
Thanks to Mongoose on Steam for reporting.
Macrophages and Enraged Macrophages won't be counted as Threat anymore
Thanks to WolfWhiteFire for reminding me about this
Fix a bug where the Nanocaust invasion could trigger a bunch of threat against the player
Thanks to vodkasheep on steam for reporting
Fix a bug where Norris Effect ships were being blocked from going through wormholes by shields
Thanks to Flypaste for reporting
Put in even more of a fix to the fire teams having an INNER exception of thread abort that was being reported erroneously because it could happen during a sort operation.
This should solve some of the marauder debug code 1200 errors we were seeing that were not really a bug.
Units such as Hydra Heads and Mini Cluster Bombs will no longer show in the Double Shipline Cap option screen.
Thanks to Admiral, Daniexpert and NRSirLimbo for reporting.
Fixed an exception that could happen in rare cases on loading a savegame with a wave incoming, where it might say "Exception in ShipIconImageBase.RenderContents at stage 170"
Fixed Royal Tethuida and Shredder Guardians not having Drones.
Reported by Ryulong.
Hacks against the Dark Spire now correctly consume hacking points. Whoops
Thanks to NRSirLimbo for reporting
Unexplored planets will no longer show their mark level or the number of reinforcement points they had. Previously you could deduce way too much information about planets (including the location of AI Overlords)
Thanks to Fluffiest for reporting
Finally fixed a bunch of spurious errors that could happen when you exited out of the game and it was in the middle of shutting down background threads. They made it seem like things were happening such as clashes between pathfinding calls to the same pathfinder, and other things of that nature, but it was just the threads dying and not being as quiet about it as they should have been.
Fixed a couple of nullref exceptions that could happen during DoForEntities and a few related methods if the collection was changing during a cross-thread update clash.
Thanks to Ryulong for reporting.
Fixed a variety of quasi-invisible bugs where the wrong movement or decollision points could be given to the wrong entity if ships died in between when the command was issued and when they got it.
This could cause rare random things like a ship of your own suddenly moving without you telling it to, etc. It was likely pretty rare, although it got more common after we stopped pooling ships.
Thanks to NRSirLimbo and Badger for helping us accidentally find this.
Probably fixed a bug that could happen inside entity order creation for decollision. Whether we really fixed it or not will require more testing, as it was pretty rare in the first case. This was quasi-related to the above fix.
Thanks to NRSirLimbo and Badger for reporting.
Put in a lot of extra debugging stage code to help us know what is happening in the faction metal outflows code, so that when we get something like "ERROR In BuildingDronesInternally" we will know where the problem is. As it stands the code looks okay, but someone hit the error, so we'll need them to hit it again in the new code version before we can figure out what it is.
Thanks to NRSirLimbo for being our resident nullref exception sponge.
Put in a likely fix for a rare exception that could happen in GenerateMercenaryObjectives.
Thanks to NRSirLimbo for reporting.
Performance Hunting And Open-Sourcing
Reduce the number of FindPath calls made by Fireteams
Fix a bug where empty fireteams in some states were never being disbanded
The way that the game tracks commands that are actually queued versus those that are just requested but not actually sent is now much better, giving us insight into what the heck is going on and where we might be able to squeeze out some more performance in giant games in particular.
A large amount of code relating to simulation that happens at the planet level has been moved into the open-source dlls.
A whole bunch more of the world-step sim logic has been moved into the open-source (moddable) part of the code.
Fixed a minor performance drain where our "combine into stacks" code was pulling thousands more gamecommands from the pool in large savegames, then not using most of them because of whatever invalidities.
Put in a variety of fixes to the AI background thread where it could pull a "send wormhole" command prematurely and then realize that it had nothing to send, thus causing it to trigger some locks pointlessly and waste some background CPU cycles.
Put in some defensive code in dark spire, devourer, dyson sphere, instigators, and outguard that could cause it to issue blank wormhole move commands and calculate paths for no ships in potential rare circumstances.
Improved some of our utility methods to early-out a lot sooner when they don't have targets to chase, etc.
Improved the divide ships among planets code to definitely never send empty wormhole commands anymore.
Improved the auto pursuit mode for engineers to not request extra commands and then put them back, again improving performance slightly.
If null commands or null types on commands are sent, it now shows those in red in the escape menu.
For commands that have a different number of requests and actual queuings in the escape menu, it now shows those in red for easy identification.
When the game gets a request to shut down or quit to the main menu or other things of that sort, it is now absolutely brutal with the background threads, killing them all and exiting immediately. It was before trying to be polite and wait for them to tidy up and finish, but that was at the best case slow (now with fire teams in particular), and in the worst case would never exit (in the case of a stalled background thread).
Fixed an issue where if one of the background long term planning fields got stuck or was slow, it could cause others to be very slow to send their commands.
In general also made it so that long term faction threads now send their commands as they finish their individual work, which is far superior in terms of smooth performance when there are many factions.
If the game runs into a background thread that is taking more than 10 seconds (which means it is then blocking all other background threads, too), it now shows a message on the right hand side of the screen saying slow background threads and showing what the slow thread is.
In this way we can actually tell if something stalls out and then starts blocking the rest of the game, versus before it was pretty invisible.
Fixed some excessive requests for SetWaiting and SetBehavior_FromFaction_ThreatTimeToFight that were then never being queued for actual use.
Fixed some excessive requests to TransferEntitiesToFaction and ScrapUnits that would then not be queued.
Split the singular "SetWormholePath" into 17 distinct variants so we can see what is going on in terms of high volumes of those being sent in some savegames and thus causing a big slowdown.
The general idea is for us to be able to recognize hotspots at a glance, but all of these function the same so it doesn't matter which one a mod's code uses.
An interesting side effect of this is that it potentially cuts down on cross-threading contention since the pool has to be locked to take items out and put them back in.
The pool being locked and unlocked is one reason not requesting more commands than we need is a really good idea, too.
There is actually a measurable performance boost from these things alone.
Same thing with splitting CreateSpeedGroup into 4 variants.
FlushReinforcementPoints can now only be called on a planet once every 5 seconds at most.
This keeps certain factions from flooding the command queue with hundreds of such requests over the course of a second or two of game time.
Refinements to the pathfinding performance, round 1 (existing algorithm changes):
Starting performance:
3.30017 ms per call on average for marauders, over 25k calls in 84 seconds of processing for the marauders faction long term planning thread (stopped thread after this).
After making GetNeighborOfNodeByIndex much more direct and not involving a loop:
To start, 2.883 ms per call on average for marauders, over 16k calls in 48 seconds of processing for the marauders faction long term planning thread.
But then 3.212 ms per call on average for marauders, over 30k calls in 98 seconds of processing for the marauders faction long term planning thread (stopped thread after this)
It's worth noting that there's fuzz in all this data, from disk write speeds and application being in the foreground or background more, different routes being considered, etc. So it's only so precise.
Removed DoForNodesInFlood since it was never used anyway.
Then changed the pathfinding object itself to not instantiate a ton of stuff on the heap with every call, instead reusing objects and lists and dictionaries except for the final result dictionary.
As part of this, made it so that the FindPathInner method now also checks to see if it has simultaneous calls on the same object, to make it complain if it's used in a non-threadsafe manner. A single thread would only call these serially, after all.
After this, 2.642 ms per call on average for marauders, over 16k calls in 44 seconds of processing for the marauders faction long term planning thread (stopped thread after this)
It's observed that we're doing quite a few calls to these pathfinders on the main thread as well, but nothing at the sort of scale that the long term planning threads do. But some of the substantial performance degradation to the sim is probably this on the main thread also.
With the logging turned off, the long-running thread for marauders in the super-slow s6 save is now something that takes still north of 136 seconds, so this sort of low-hanging fruit is making very little difference in aggregate and could even simply be the result of instrumentation error (so to speak). The revisions definitely are performance improvements, but are apparently such a tiny portion of the load as to not be noteworthy.
Before we get into more extreme changes, the ArcenPathfinder class and its internals have been moved to the external public source code.
This makes things far quicker for us to change and then test the results with.
Added a new abstract Pathfindable class in the Arcen Core area, which is now required for use in the pathfinding code, and which Planet inherits from.
This lets us make a number of things more efficient, and not just in pathfinding.
PlanetIndex on the planet object is now just Index on Pathfindable.
LinkedPlanetIndices is now just LinkedIndices on Pathfindable.
Added a new LinkedPathfindables on Pathfindable which gets recalculated as needed and which can be manually recalculated via FillLinkedPathfindablesIfNeeded().
This actually should speed up calculations for a lot of things with adjacent planet checks, even outside of pathfinding.
The pathfinding code is now able to directly call a few things on Pathfindable, rather than having to indirectly get things via method calls.
This is another incremental improvement, but paves the way for a number of things, and in general makes the load on the call stack lower. Given how many paths are being calculated by fire teams, every little bit matters, even before we get into the larger changes.
Made some tweaks to fireteam code to reduce the number of FindPath calls.
This alone shifts the performance of the s6 savegame case to be able to finish the marauders long-running thread in 98 seconds now instead of it running somewhere north of 150 or 200 seconds.
The ArcenSimContext now has a non-sim incrementing loop counter in it that tells us when we need to refresh the pathfinding data and other things.
This is "non sim" in the sense that it doesn't matter what the loop counter number is, it just matters that it knows when the number is different. This is safe to use for multiplayer and on short and long term planning threads, main thread, etc.
To check if this is the same execution that it was the last time you were in a thread, you can now check a stored integer against NonsimLoopIndex on the context. If the numbers don't match, sim or not sim, then you should recalculate whatever you're intending to cache on a per-iteration-of-this-thread-whatever-that-is basis.
The pathfinding code now requires that an ArcenSimContext so that we can use that new stuff for lazy-load precalculations.
This lets us be sure that we're not wasting any CPU on precalculations that will never be used, but at the same time since these are per-thread we don't recalculate the same things over and over again. At least that's what will be the case.
The pathfinding code now also keeps track of what the first ArcenSimContext was to call into it, and if another context is ever used to call into it, it will complain.
Thus if we wind up with short term planning code calling long term planning code, we'll know, etc. So far the tests show no instances of this happening, but prior to now that would have been a silent problem if it was happening.
More tweaks to fireteam code to even further reduce the number of FindPath calls.
This shifts the performance of the s6 savegame case to be able to finish the marauders long-running thread in 77 seconds.
The background threads are now set to run not in background mode, and with a priority that is above normal. This shouldn't affect the front-end framerate except on extremely limited old-school single-core machines, which don't meet the minimum requirements anyhow.
This makes better use of your entire processor, and the more cores you have the better the improvement is. This may also be somewhat OS-dependent, as different OSes have different threading models and are better and worse at different things.
On Windows 10, simply switching from using the unity editor as our test environment to using a standalone build gets us from 40% sim speed to 50-70% sim speed in the s6 savegame, and it drops the background marauder thread from 80 seconds to 55 seconds to execute. On Linux, Badger reports 20 seconds or so for the same background thread, though.
After these changes to upping the priority, we get a much more solid 70-100% sim speed (those all are running on "background" threads as well, after all), and the background marauder thread drops from 55 seconds to 50.
We still have a ways to go with the pathfinding efficiency itself, and potentially with culling yet more cases where it's actually calling the pathing threads in a nested fashion, but some of this was based on our internal testing environment (who knew that unity's editor doesn't at all obey thread priorities?), and some of it is improved by giving the background threads in the actual standalone game more freedom to use your available processor space. If your CPU is half idle and the game is running at all slowly, that's just silly.
Made a variety of changes to improve pathfinding performance further.
We're precalculating node passability, which gets rid of the most frequent method call that we were seeing inside the pathfinding code. However, this only drops us from 55 seconds to 51 seconds (a 7.3% increase) for marauder path computations. We need to take it further! (Even though Badger has solved the problem another way that isn't checked in yet, we still want pathfinding to fly.)
Made further pathfinding changes to remove all uses of dictionaries and almost all use of lists, and definitely all uses of Contains.
This has basically linearized the node states into a series of arrays of fixed length 500, and if there are ever more than 500 planets in a galaxy the pathfinding will break unless it is recompiled to support higher numbers of planets. The overall game would burn performance at 500 planets and it would be unpleasant to play, anyway, so this does not seem like a problem to have.
With the changes to linearize things in this way, performance went down from 51 seconds on the marauder thread to... 7 seconds. So from the recent 55 seconds this is a full 87% improvement to pathfinding speed.
Badger figured out a way to also time-slice the fire team logic so that they only scan a certain number of planets (per faction) per check of fire teams.
This makes some of the fire teams a bit "slower to react" (this is VERY relative) in the super short term in saves with literally hundreds of fire teams on one faction and 200 planets, but it keeps everything running far faster.
A single fire team might need to evaluate hundreds of planets in order to find out what it needs to do after completing a major objective or just coming into an existence, and this was the case where the game could spike and have really long-running threads (north of 200 seconds prior to this release, now down to 7 seconds as of Chris's prior changes just above).
While Chris was doing his changes, Badger got in this throttling and managed to make the simulation run at full speed and take an average of 5 seconds instead of 55 even before the pathfinding was 87% more efficient. That was with 1000 planets being scanned at a time, max.
There is a new galaxy setting which lets you adjust the number of planets to scan, and its new default is now 2500 since between these changes, other fire team improvements, and the pathfinding improvements, what was once taking 200+ seconds now takes a second or two.
So the fire teams "reacting slower" as noted above means they might delay for a few seconds, maybe 10 at most, in the really huge savegames. But it's not something that will stall the game or performance anymore, and the prior amount of time we had to wait in prior builds for ANYTHING to happen was 200+ seconds. So... it's just plain faster.
Also, the name of the galaxy option to control this is "Max targets Fireteams can scan in one iteration" in the performance section.
Exo tweaks
Fix a bug where exos were losing their exo target between save/reload
If a unit had been in an exo but the target died, the ship drops out of the exo and joins the threat
Units in an exo stuck by a black hole machine should prioritize killing the black hole machine
This should make exos even more adept at chasing units across planets. Especially big, shard-shaped ones.
Thanks to Ovalcircle for the bug report
Cross Planet Attack (CPA) tweaks
AI homeworlds can no longer contribute to cross planet attacks (CPAs).
When pulling ships for a CPA, the AI now starts with the planets that are at or below its current mark level (whatever that is), minimum 2.
It then goes to planets 1 mark level above, then two, then random among everything else.
This makes it most likely, particularly in the early game, that most things will be relatively low-level.
To clarify, since many have been confused, while CPAs do have a budget, they do NOT create new ships.
As with the first AI War, they instead turn guards into threat. Aka, they set guards "free" to come attack you.
The budget of the CPA determines how many ships they can set free, but doesn't let them purchase anything new.
Specifically it only pulls from ships that are IN guard posts at the moment.
Previously, the mark level of ships in a CPA was downgraded (or upgraded) to whatever the mark level of the AI was in general at the time.
This was wildly unfair to the AI in a lot of cases, making high-mark ships into low-mark ones.
Now the AI gets whatever their actual mark of ships are freed, but it tries to free appropriate-or-lower mark ships first before launching harder stuff.
When it launches things that are lower-mark or higher-mark than its baseline, it pays less or more from its budget based on the strength differential. So the end strength should be the same in general.
When ships come out of guard posts for CPAs, previously it would grind some games to a halt because of them coming out unstacked and potentially huge in number.
Now it tries to stack them up to 99 ships at a time per stack, as it can.
Also previously, when the CPA launched you had no idea what you were in for. Now it tells you how many ships, what total strength, and how many of each mark level of ship were freed.
The idea is definitely to keep you from being surprised by higher-mark ships showing up, or in general by what is happening. Where the ships are and what specifically their composition is remains a mystery, though.
This also should immediately dispel any confusion about these being new ships versus freed guards, based on the wording of the notification.
The in-game Tip now explains these new mechanics
Balance Tweaks
Some buffs to the Macrophage, who are feeling pretty uninspiring. More buffs to come if they are still underperforming
Nanocausts and Marauders that were created before fireteams were an option now default to using fireteams
This includes Nanocausts and Marauders from quickstarts
Altered most of the Fleet Designs again, to fix some problems accidentally introduced previously, regarding Mono-Tech Fleets and the general chances of each Tech line being on paper fine, but in practice notably off.
Also added 15 new Designs, and removed 2 that were notable culprits.
Dark Spire Wraith and Phantoms can now be affected by the Strikecraft Coordinator, as well as have their lines doubled.
Mentioned by Ryulong.
Space Planes, Mirages and Apparitions have their damage resistance range reduced, to account for the recent 0.8x range modifier that does not affect this.
Also mentioned by Ryulong.
Added some more Guardian types to the Instigator Base spawns.
Requested by ArnaudB and Fluffiest.
Vanguard speed 400 -> 600, shots per salvo 1 -> 8, damage 360 -> 90, reload time 6s -> 8s.
Vanguard Hydra speed 600 -> 800, shots per salvo 1 -> 8, damage 180 -> 60, reload time 6s -> 8s.
Pulsar Tank speed 400 -> 500, main weapon range 4,200 -> 5,600, main weapon has the same damage bonus as the secondary.
Ablative Gatling speed 600 -> 800.
Ablative Troll speed 400 -> 600.
Pike Corvette and Porcupine speed 500 -> 600.
Grenade Launcher Corvette speed 400 -> 600.
Molotov speed 800 -> 1,000.
MLRS Corvette speed 400 -> 600.
Raptor damage bonus 4x -> 6x.
Ranger speed 800 -> 1,000, damage 225 -> 450, reload time 4s -> 8s, range infinite -> 10,100, now has a cloaking device.
Zenith Trader
Scrubbed Abberation and Abomination now do full Zombification rather than a form of Nanocaustation that would create normal zombies.
Led to a problem with the changes to Zombification to restrict what could be affected. Those did not affect Nanocaustation, so these units could still give the player zombie versions of Dire Guardians, for instance.
Now sells a Trader specific version of the Orbital Mass Driver, as to not interfere with the galaxy wide caps if you hack any.
All Zenith Trader goodies have a galaxy wide cap of 2.
Before you could armour up every planet you owned to a large amount with no other investment. Now you have to choose where these goodies go.
Zenith Forcefield is now Markless, but has improved stats over what it used to be.
Just clarity. It couldn't be upgraded anyhow.
All other Trader goodies are Markless.
Also for clarity, since most weren't affected anyhow, and the one that could (Tamed Macrophage) could have huge power spikes from planetary upgrades.
This might change in future.


24. Jan 2020, 07:25 Uhr
22 MB
Repack oder Proper:
Read NFO:
4,63 KB

Hast du das verstanden? Ja! | Nein!

Is that clear? Yes! | No!