Stellaris Dev Diary #232 - 3.2 Balance Changes and Performance Improvements

Hello everyone, today we would like to tease you with some of the upcoming changes coming with the 3.2 "Herbert" patch, named after Sci-Fi author Frank Herbert, which we will release along with the Aquatic Species Pack.

For Balance Changes, we have the following changes in store for you.
  • Functional Architecture and Constructobot: Reduced the free building slots granted from 2 to 1.
  • Agrarian Idyll empires now get one planet building slot per four Agricultural districts built.
  • Reduced the ship upkeep cost modifier for clone army admirals to 5/10/20% based on their decisions.
  • Ruins of Shallash arc site no longer has a chance of giving quite as much unity as defeating an endgame crisis.
  • You can no longer use planet killer weapons on primitives inside your borders if you lack the appropriate primitive interference policies.
  • Pops working the Livestock job now have 10% less political power.
  • A lot of anomalies were rewarding 3 Society Research deposits, there is now more variety.
  • Made Awakened Fallen Empires use Traditions (but not Ascension Perks).
  • Several productivity-improving technologies are now no longer of dubious benefit, as their upkeep (and production) effects now only apply to jobs actually primarily producing resources.
  • Nerve Stapled Hivemind pops can no longer perform complex drone jobs.
  • Reduced the amount of jobs added by Leisure Arcology Districts to bring them into line with other Ecumenopolis districts.
  • Ion cannons are no longer free to maintain, and have an upkeep cost of 8 energy.
  • Necro-Hives:
    • Cut Necrophage pop assembly penalty to 50% from 75%
    • Made pop output modifiers (positive and negative) no longer apply to hive minds.
    • Made the -50% organic upkeep also apply to energy, for photosynthesis.
    • Devouring Swarm Necrophages now spawn with extra infrastructure to account for the lack of chambers of elevation.
Of note here is the Functional Architecture change, we are aware that the extra building slot was the main draw of the civic but it was also way over-represented even after the initial release-hype

While not a pre-planned balance pass like we did for the Lem patch, we still found a few places to tweak and adjust and we will continue to do that in future patches.

...and now, handing over to Caligula Caesar for a look at some performance improvements and moddability topic.

A Look at Script Performance
Hi! You are probably used to me writing lengthy prose about new moddability and scripting language features. This time, we only have a few things to show off in that regard, but there are nevertheless some cool, technical things I can speak about.

Knowing the script language pretty well, I always found the performance impacts of our scripts to be a big unknown to me. Was what I was adding going to mess with performance? Well, I could do plenty of guessing as to how to script most efficiently, and general concepts of programming such as early outs do apply. But how big was the difference? And how much can we save by identifying inefficient scripts and improving them?

Moah had made some progress on porting the EU4 script profiler over to Stellaris as a pet project some time ago. The only problem was, its information was quite incomplete (since it needs a lot of tags added in many places of the code, basically everywhere where an effect or trigger is called). It was also pretty hard to read the information presented. But now, with the Custodians initiative, the time had come to see what we could do with this.

After a bit of (very tedious) work to make the information all-encompassing, systematic and readable, I let the game run on a Huge galaxy with a few extra boosts to the AI - 0.75 research costs, 1.25 habitable planets - and ran it a year with the script profiler enabled. Then, issues could be found. I’ve attached two versions of this output: one as it was in one of the early runs - so before coverage was comprehensive (notably, triggered modifiers and economic tables are missing), but also before any optimisation work was done - and one as it is now, in the 3.2 beta. (Note that the figures for how long it spent on each object is massively inflated by my having run the game in unoptimised debug mode with the profiler turned on)

Now, I must state in advance that we aren’t able to release the script profiler to the public with the 3.2 update for technical reasons: running the game with it makes the game about 50% slower, so we need to work out a way to be able to turn it - and its full performance impact - on and off at will. (At the moment, it is hidden behind compiler flags that are not available to the public). But we definitely hope that we’ll be able to release it to modders in the future.

Early Gains
The first big finding was that the game is repeatedly recalculating certain game rules a large number of times per pop each day, which was having a disproportionate impact on performance. The biggest culprit was “can_vote_in_democratic_election”, which it turned out was checked on every pop in the country every day for each pop faction while they were calculating their support value. Yes, you are reading this right: the imperialist faction would check whether each pop in the entire country was allowed to vote, then the prosperity faction would do the same, and the imperialist one, and so on… These cases were fixed by making use of daily caching: the pops will now calculate the result once per day (or, in the case of species_has_happiness, once per species in a country each day), and other places in the code can simply refer back to that result. Furthermore, pop factions’ support calculations were optimised so that the total by which they were dividing their support could be calculated once per country, rather than once per faction.

On the script side, by parsing various of the top hits, we noticed a few easily-optimised bits of script. First off, graygoo.555 was trying to fire a surprising number of times for an event that should come into play only when the Gray Goo are active (which they weren’t). It turns out that this was because it was missing “is_triggered_only”, so it was trying to fire on all planets every day! Similarly, a number of test events were scripted in a similar way, but with “always = no” as their trigger so they’d never fire. They made a small but nevertheless noticeable impact on performance, so they had to go.

The opinion modifier triggered_opinion_galactic_community_in_breach was taking up more performance than any other opinion modifier, by a distance, which seemed a bit strange. It turned out this could be fixed by a slight change in order in the triggers: it was checking “is_in_breach_of_any” before verifying Galcom membership - which sounds like it wouldn’t be a big issue, but that trigger then checks the triggers for the breach conditions of all passed resolutions, so it is in effect a lot of triggers in one. Simply swapping the order had very positive results, here.

Finally, the event crime.1 (somehow the second most costly event in the early version) was a similar case, but a lot more complicated. The main problem here was the following piece of script:

Code:
OR = {
            AND = {
                count_owned_pop = {
                    limit = {
                        is_shackled_robot = no
                        is_unemployed = yes
                        NOR = {
                            has_living_standard = { type = living_standard_utopian }
                            has_living_standard = { type = living_standard_good }
                            has_living_standard = { type = living_standard_shared_burden }
                        }
                    }
                    count > 3
                }
                owner = { is_gestalt = no }
            }
            AND = {
                count_owned_pop = {
                    limit = {
                        is_unemployed = yes
                        NOT = { has_living_standard = { type = living_standard_organic_trophy } }
                    }
                    count > 10
                }
                owner = { is_gestalt = yes }
            }
        }
This is quite inefficient, and large benefits could be found in applying the principle of early outs. “Count_owned_pop” is a relatively expensive way of calculating anything, because a lot of efficiency is lost in converting script into code and working out the results of this, so on a planet with 80 pops, it is looping through each of those and checking a set of triggers on each of those. Unfortunately, because of the ordering, it would do this twice per day on each planet which did not have 3 unemployed pops on it:
  • The event is checking the triggers every day on each inhabited planet. Or at least often. 44,000 times in a year, to be exact.
  • It does not verify that there are unemployed pops on the planet before working out what kinds of unemployed pops there are. Which means that the OR will return false on both count_owned_pop sections, which consequently means it is checking both. Adding “num_unemployed > 3” near the start had big benefits
  • It would check the number of unemployed pops relevant to non-gestalts and only after that check the country was not gestalt. By swapping the gestalt check to the start, it means it will only ever be trying one of the count_owned_pop loops.
A new, more efficient version of the trigger was therefore this:

Code:
num_unemployed > 3 #early out before the expensive count_owned_pop to come
        OR = {
            AND = {
                owner = { is_gestalt = no }
                count_owned_pop = {
                    limit = {
                        is_unemployed = yes
                        is_shackled_robot = no
                        NOR = {
                            has_living_standard = { type = living_standard_utopian }
                            has_living_standard = { type = living_standard_good }
                            has_living_standard = { type = living_standard_shared_burden }
 
                        }
                    }
                    count > 3
                }
            }
            AND = {
                owner = { is_gestalt = yes }
                count_owned_pop = {
                    limit = {
                        is_unemployed = yes
                        NOT = { has_living_standard = { type = living_standard_organic_trophy } }
                    }
                    count > 10
                }
            }
        }

Gains from Further Analysis
This was some cool stuff to fix, but beyond this, simply looking at the list became a bit harder to yield significant savings. Enter spreadsheeting! We pasted the results into a spreadsheet and, a few formulas later, and a nice pivot table to give us some breakdowns along the lines of “what is the total impact of all jobs”, or “what is the impact of the potential trigger of pop factions”

script profiler 1.png

Picture shows values after performance improvements

This allowed us to pinpoint a few more things. Firstly, ai_resource_production was causing an absurdly high performance cost from a rather small number of hits. The culprit, here, turned out to be that the “planet_resource_compare” trigger (used mainly here) was incredibly expensive. The problem was that it was recalculating the resource output of all resources on the planet, basically (including by seeing what each pop was producing!). It turned out to be possible to mitigate this somewhat (to about 75%) by making it selectively recalculate the production of the relevant resource, but this was still quite expensive for a trigger, so we also cut down on its use a bit. I suggest modders not overuse it either.

Another thing we saw was that, not unexpectedly, jobs were quite expensive. Specifically their weights and their “possible” checks. We have some ideas to save time on the weights that we aren’t ready to speak about yet (they emerged too late in 3.2 development to be considered for the patch, because they are relatively likely to need some iteration), but we found a way of making the “possible” triggers cheaper. Basically, every seven days, a pop would recalculate its job cache, at which point it will check whether it is allowed to work each job, and if so, calculate its weight. But most jobs have fairly standard “possible” triggers that check the first part - specifically, there is a shared set of triggers between, respectively, worker, specialist, ruler and drone jobs. It turned out that very significant improvements (to the degree of almost two thirds) were possible by having the pop calculate these four triggers first, then loop through the jobs and simply match the result to the right job.

(Note to modders: the format looks a bit different now. If you used the scripted triggers worker/specialist/complex_specialist/ruler/drone_job_check_trigger, you will now need to define e.g. “possible_precalc = can_fill_ruler_job”. And if you changed them, you will need to change the new versions of them in game_rules)

Finally, although the game rules optimisations had already fixed several performance issues with pop factions, there were a few more spots where they could be improved. The first was whether a faction should exist at all: it turned out that both the script and the code was checking whether there were 5 pops that could join the faction, just that the code wasn’t checking this anymore after the faction was formed. Obviously, this wasn’t ideal, so the script check (being the slower) was removed, and the code check amended to account for shrinking pop factions becoming invalid.

The second was deciding whether a pop should belong to a faction: even though almost all factions only allow pops matching their ethos, the filter by ethos is quite late. By putting it much earlier - in code, before the script is even checked at all (with an override in case this isn’t desired, e.g. for technologist robots) - this massively cut down the costs of this particular calculation.

Finally, a number of their demands - checked each day per faction - were quite exorbitant. By changing the ordering and using equivalent but cheaper checks (e.g. any_owned_species instead of any_owned_pop). This, too, had a significant impact, so that the script footprint of pop factions (excluding game rules they use) was reduced by about two thirds.

Further Performance Topics
It is my hope that this work will be felt in the form of a bit less late game slowdown. My tests would indicate that this was a success, though it’s very hard to quantify by how much. It was however work that was solely focused on the script performance footprint, so there’s plenty of other things for us to look at! The job is never over, when it comes to performance, and hopefully we’ll have time to make further improvements for 3.3.

For example, I have heard a few complaints about UI lag in the late game, which might be improved slightly in a few interfaces as a result of the performance work, but this work didn’t focus on UIs. It is certainly true that some of them are not as fast as we would like them to be. Particular ones in this regard are the planet view, the species view and the colonisation selection menu, and we are looking at options to speed them up. (And, indeed, if anyone can think of any others, it would be useful for you to point them out!)

Moddability Improvements
I can’t really do a dev diary without talking about a few moddability improvements, so here they are. As I said, we don’t have that much this time, but there’s a few things that people might enjoy trying out:
  • There’s now a create_nebula effect. Although it’s best used during galaxy generation, since the visual effects on the galaxy map won’t refresh during the game.
  • Decisions can now have on_queued and on_unqueued effects.
  • Terraforming now uses the Megacorp economy system. Meaning, the costs are configurable resource tables, and you can make economic_unit modifiers to apply to them.
  • There’s a species_gender trigger that checks what gender the species’ leaders can be
  • You can now define custom tooltips for systems that you see when you mouse over them on the galactic map
  • There’s now on_actions for on_capital_changed and on_planet_class_changed
  • For Traditions, the “possible” trigger of its adopt tradition will now show in the tooltip for adopting it if it fails. I’m told that you can also now make the tradition categories have a container where you add a gridbox.

There’s also a couple of things that modders will have to update (aside from the terraforming, as mentioned):
  • any/count/every/random_planet_army now refers to all armies on the planet, not just all owned by the owner of the planet
  • Set_starbase_building/module and the remove variants are now consistent in starting at slot 1, rather than “set” starting at 0 and “remove” at 1.
  • In component_templates, valid_for_country is now a trigger rather than a weights field
  • Fire_on_action had some issues where you defined scopes with “prev” and “from”, those no longer exist.
As a final moddability note, for anyone who misses the meaty dev diaries with far-reaching moddability changes, not to worry! Anyone that has played around with the script of our newer games will know that there’s a lot more potential in our scripting language. There’s some cool stuff in the works, though I can’t at this stage say what exactly or in which patch it’ll be.

I am also, as last time, attaching the script docs to the dev diary, so that you can see any changes I forgot to mention. Also, any modders who are interested in early access to the 3.2 Update, for the purposes of getting your mods updated, you can sign up here: https://pdxint.at/3bZbVJN
 

Attachments

  • profiling_summary after.log
    695,8 KB · Views: 0
  • profiling_summary before.log
    465,4 KB · Views: 0
  • effects.log
    181 KB · Views: 0
  • localizations.log
    4,4 KB · Views: 0
  • modifiers.log
    332,5 KB · Views: 0
  • scopes.log
    8,1 KB · Views: 0
  • triggers.log
    128,8 KB · Views: 0
Last edited by a moderator:
  • 95Like
  • 25Love
  • 25
  • 4
  • 2
Reactions:

Critical Ethics

First Lieutenant
34 Badges
Jun 3, 2017
284
964
  • Stellaris: Galaxy Edition
  • Sword of the Stars
  • Majesty 2 Collection
  • Stellaris: Synthetic Dawn
  • Sword of the Stars II
  • Magicka
  • Surviving Mars: First Colony Edition
  • Stellaris: Nemesis
  • Stellaris: Megacorp
  • Surviving Mars: First Colony Edition
  • Age of Wonders: Planetfall
  • Age of Wonders: Planetfall Deluxe edition
  • Age of Wonders: Planetfall Premium edition
  • Age of Wonders: Planetfall Season pass
  • Age of Wonders: Planetfall Sign Up
  • Stellaris: Lithoids
  • Stellaris: Federations
  • Stellaris: Necroids
  • Surviving Mars: Digital Deluxe Edition
  • Stellaris: Apocalypse
  • Stellaris: Humanoids Species Pack
  • Age of Wonders
  • Age of Wonders III
  • Surviving Mars
  • BATTLETECH
  • Stellaris - Path to Destruction bundle
  • Stellaris: Leviathans Story Pack
  • Stellaris: Digital Anniversary Edition
  • Stellaris: Galaxy Edition
  • Stellaris
  • Stellaris: Distant Stars
  • Stellaris: Ancient Relics
  • Age of Wonders: Planetfall - Revelations
  • Crusader Kings II
I've worked with reinforcements quite a bit for this patch with the help of a few other custodians.
The goal has been to not only fix the recent issues with it, but also to improve the feature overall to ensure that it simulates the process it automates well enough that players don't feel that constructing reinforcements manually is worth it.

That being said, there will still be cases where the ships are spawned at the shipyard, but they should be less common and when they do occurr, they should cause less frustration. The reason why we can't eliminate this completely is because there needs to be a safe path for the consutructed fleet to get to the one requesting reinforcements, or else it would be exploitable and it wouldn't simulate the manual reinforcement process. A lot can happen between the time when you order the reinforcement and the time when they finish construction and attempt to make their way to the target fleet and if it's no longer possible to get to that fleet safely, we will spawn the ship at the shipyard and leave the problem of getting the ship to the target fleet in the hands of the player.
The bigger issue for me than the spawning of the mini fleets is the cleanup afterwards. It would be great if there was an alternate reinforcement button that hoovered up "spare" ships before building new ones.
 
  • 4
  • 1Like
Reactions:

DrFranknfurter

Captain
26 Badges
May 8, 2017
413
1.181
  • Age of Wonders III
  • Stellaris: Nemesis
  • Stellaris: Necroids
  • Stellaris: Federations
  • Stellaris: Lithoids
  • Stellaris: Ancient Relics
  • Prison Architect
  • Stellaris: Megacorp
  • BATTLETECH: Flashpoint
  • Shadowrun: Dragonfall
  • Stellaris: Distant Stars
  • Stellaris: Apocalypse
  • Stellaris: Humanoids Species Pack
  • Surviving Mars
  • BATTLETECH
  • Stellaris - Path to Destruction bundle
  • Stellaris: Leviathans Story Pack
  • Stellaris: Digital Anniversary Edition
  • Stellaris
  • Pillars of Eternity
  • Cities: Skylines
  • Europa Universalis IV
  • Crusader Kings II
  • Stellaris: Synthetic Dawn
  • Sword of the Stars II
  • Sword of the Stars
That issue happens when the marauder fleet is already on their way, and suddenly there is no longer any valid path towards their target. Usually this happens if they are on their way when the target (or enough other empires the fleet needs to path through) when the FTL inhibitor tech is finished. Fleets that are sent out afterwards have no trouble.
Perhaps being unlucky explains it... but it seems like it would be extremely rare for starbase construction/FTL research to occur the day the fleet spawns in causing them to never leave their system. Either way if a fleet is unable to reach its target the fleet needs to calculate a new path/target rather than getting stuck forever. (I mentioned it because it's part of the broader issue of the game not gracefully handling unexpected pathfinding problems...)

At least if the marauder is asking you for money you can pay them to fix it, and if their fleet was en route you could kill the fleet... but I've had the fleet stuck in the marauder system where you can't reach them to kill them, can't pay them (a rival bought a raid) and then the marauders just cannot end the first raid and are stuck forever, never sending another raid for the rest of the game.

Back on the subject of reinforcements... last night I was playing a devouring swarm and hit the reinforcement button while my fleet was moving towards my border and had fleets go MIA for 5+ years, when it takes 1 year to travel from one edge of my empire to the other (lots of sublight speed buffs), so I could win the war, get the fleet back home and be sat in the shipyard for several months before the MIA reinforcing ships returned (It was only 1 month after I got home but still)... and much later in the same game I clicked the reinforcement button for 40 ships while sat at a shipyard with 6 shipyards, sat on a gateway connected to a 2 more shipyard systems, building menacing corvettes that take nearly 30 days to build ...and the reinforcements instead were ordered from a shipyard 14 jumps away, not connected to the gateway network that was currently also building 6 battleships and 6 cruisers.... that's just crazy levels of broken. I'm really looking forward to reinforcements working even a little bit better... I just hope that reinforcements really work this time.
 
  • 1Like
Reactions:

Inny

Second Lieutenant
52 Badges
Mar 31, 2013
104
151
  • Crusader Kings II
  • Stellaris: Synthetic Dawn
  • Tyranny - Tales from the Tiers
  • Sword of the Stars II
  • Majesty 2 Collection
  • Magicka
  • Leviathan: Warships
  • Knights of Pen and Paper +1 Edition
  • King Arthur II
  • Europa Universalis IV: Conquest of Paradise
  • A Game of Dwarves
  • Europa Universalis III
  • Dungeonland
  • Stellaris: Necroids
  • Stellaris: Humanoids Species Pack
  • Age of Wonders
  • Stellaris: Apocalypse
  • Surviving Mars: Digital Deluxe Edition
  • Shadowrun Returns
  • Shadowrun: Dragonfall
  • Shadowrun: Hong Kong
  • Surviving Mars: First Colony Edition
  • Stellaris: Megacorp
  • Surviving Mars: First Colony Edition
  • Age of Wonders: Planetfall
  • Age of Wonders: Planetfall Deluxe edition
  • Age of Wonders: Planetfall Premium edition
  • Age of Wonders: Planetfall Season pass
  • Stellaris: Lithoids
  • Stellaris: Nemesis
  • Stellaris: Federations
  • Stellaris: Galaxy Edition
  • Europa Universalis IV
  • The Showdown Effect
  • Warlock: Master of the Arcane
  • War of the Roses
  • Pillars of Eternity
  • Knights of Pen and Paper 2
  • Stellaris
  • Stellaris: Galaxy Edition
  • Age of Wonders III
  • Tyranny: Archon Edition
  • Tyranny: Archon Edition
  • Stellaris: Digital Anniversary Edition
  • Stellaris: Leviathans Story Pack
  • Stellaris - Path to Destruction bundle
  • Crusader Kings Complete
  • Surviving Mars
  • Tyranny - Bastards Wound
  • Stellaris: Ancient Relics
One of the other major problems with fleet reinforcements is the extreme duration of the MIA. Something's very wrong with it.
Also, please consider making it so that once jump drives are equiped, reinforcement path checks should be made easier (with considerations of the relevant game rules can_jum_drive and can_enter_system_by_jump) and the MIA shortened even more, depending on the drive capabilities.
 
  • 4
Reactions:

Kaganis

Corporal
23 Badges
Apr 10, 2018
41
18
  • Age of Wonders III
  • Stellaris: Nemesis
  • Stellaris: Necroids
  • Stellaris: Federations
  • Stellaris: Lithoids
  • Stellaris: Ancient Relics
  • Stellaris: Megacorp
  • Stellaris: Distant Stars
  • Surviving Mars: Digital Deluxe Edition
  • Stellaris: Apocalypse
  • Stellaris: Humanoids Species Pack
  • Surviving Mars
  • Stellaris - Path to Destruction bundle
  • Stellaris: Leviathans Story Pack
  • Stellaris: Digital Anniversary Edition
  • Stellaris: Galaxy Edition
  • Stellaris
  • Crusader Kings II: Horse Lords
  • Crusader Kings II
  • Stellaris: Synthetic Dawn
  • Stellaris: Distant Stars Pre-Order
  • Crusader Kings II: Sons of Abraham
  • Crusader Kings II: The Old Gods
We did consider this. It is indeed a balance between accuracy & fairness vs convenience.

We felt that just allowing the reinforcement process to cheat would be the "easy way out" here and we would rather first attempt to make it work as best as we can without cheating and if players still feel it's not good enough, we will again consider dropping the conditions of a safe path in favour of making reinforcements feel better for the player.

The specific case you describe should be handled by the changes in 3.2.
If you still feel that it doesn't work well enough, be sure to let us know after you've tried it out :)

I'll admit that I've not played since just after Nemesis came out, so forgive me if this has been fixed. But the biggest problem I had with fleet reinforcement dropping to manual mode was when the route was Unsafe only because of the enemy fleet I was currently in combat with. If you don't check for such hazards in the system the fleet being reinforced is currently in, that will fix a lot of happening for me at least.
 
  • 1
  • 1Like
Reactions:

BlackholePD

Second Lieutenant
23 Badges
Dec 12, 2018
104
79
  • Cities: Skylines
  • Stellaris: Nemesis
  • Stellaris: Necroids
  • Stellaris: Federations
  • Stellaris: Lithoids
  • Stellaris: Ancient Relics
  • Stellaris: Megacorp
  • Cities: Skylines Industries
  • Stellaris: Distant Stars
  • Cities: Skylines - Parklife
  • Stellaris: Apocalypse
  • Stellaris: Humanoids Species Pack
  • Cities: Skylines - Mass Transit
  • Stellaris - Path to Destruction bundle
  • Cities: Skylines - Natural Disasters
  • Stellaris: Leviathans Story Pack
  • Stellaris: Digital Anniversary Edition
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Stellaris
  • Cities: Skylines - After Dark
  • Stellaris: Synthetic Dawn
  • Magicka
I just want the ability to build in-system defence installations beside the starbase, similar to how I hear it worked in earlier versions.

Starbase is cool and all, and make it cost a bunch of resources and upkeep if balance demands, but lemme bolster my Terminal Egress Starbase with a couple of defence stations around the planets habitat-style with a half-dozen defence platform slots if I really want to secure a system. I mean, technically I can just leave ships in the same place for the same effect, but it doesn't feel quite right, and then I'm building FTL drive vessels for nothing.
Just wanted to mention that I found a way to [[technically]] own a planet military station!!!

.....A space age primitive society built an early space station, and then I infiltrated them and brought them into my empire, keeping the early space station as a "military station" for my empire according to the map screen. It got hull bonuses and everything! lol

Just goes to show though, the code for player-owned military stations around system bodies is absolutely still in the game.
 
  • 3Like
Reactions:

grommile

Field Marshal
60 Badges
Jun 4, 2011
20.072
25.412
  • Crusader Kings III: Royal Edition
  • Europa Universalis IV
  • Hearts of Iron III Collection
  • Crusader Kings III
  • Hearts of Iron IV: Expansion Pass
  • Stellaris: Ancient Relics
  • Tyranny: Archon Edition
  • Stellaris
  • Hearts of Iron IV: Cadet
  • Shadowrun Returns
  • Teleglitch: Die More Edition
  • Victoria 2
  • 500k Club
  • March of the Eagles
  • Europa Universalis IV: Pre-order
  • Knights of Pen and Paper 2
  • Crusader Kings II
  • Europa Universalis III
This 1 mod seriously makes Starbases an iron curtain to deal with again. Combined with the new Unyielding tradition and techs and forget about it.
You have identified the exact reason why effective static defences are a serious game design problem with no good solutions.
 
  • 1
Reactions:

BlackholePD

Second Lieutenant
23 Badges
Dec 12, 2018
104
79
  • Cities: Skylines
  • Stellaris: Nemesis
  • Stellaris: Necroids
  • Stellaris: Federations
  • Stellaris: Lithoids
  • Stellaris: Ancient Relics
  • Stellaris: Megacorp
  • Cities: Skylines Industries
  • Stellaris: Distant Stars
  • Cities: Skylines - Parklife
  • Stellaris: Apocalypse
  • Stellaris: Humanoids Species Pack
  • Cities: Skylines - Mass Transit
  • Stellaris - Path to Destruction bundle
  • Cities: Skylines - Natural Disasters
  • Stellaris: Leviathans Story Pack
  • Stellaris: Digital Anniversary Edition
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Stellaris
  • Cities: Skylines - After Dark
  • Stellaris: Synthetic Dawn
  • Magicka
The biggest issue I have with reinforcements is when, after the manager "forgets" that reinforcements are en-route, it will add new ships that exceed my specified fleet loadout, throwing the entire fleet out of whack with too many ships of one class.

Even with the current issues, making specified fleet loadouts immutable, so that ships can't be added unless I specifically add new slots for them, would go a big way to solving the problem, even if the other issues remained. I'm tired of having to individually split out and remove excess ships.
 
  • 2
  • 1Like
Reactions:

MonzUn

Custodian Programmer
20 Badges
Oct 17, 2015
311
235
  • Prison Architect
  • Age of Wonders III
  • Stellaris Sign-up
  • Europa Universalis IV
  • Europa Universalis III Complete
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Europa Universalis III Complete
  • Warlock: Master of the Arcane
  • Stellaris: Galaxy Edition
  • Cities: Skylines
  • Pillars of Eternity
  • Stellaris
  • Warlock 2: The Exiled
  • A Game of Dwarves
  • Majesty 2 Collection
  • Magicka
  • Europa Universalis III Complete
  • Europa Universalis III
  • Cities in Motion 2
Would it be possible to use the naval cost (information inherent to the class of ships) of each ship with a modifier to determine whether any potentially intercepting fleet has enough "naval mass" to stop a reinforcing fleet?
It's technically possible, but it opens a can of worms.
When compared to manual reinforcements, you're no longer getting the same results in the case where it's deemed to be able to go through.
When doing it manually, the blocking fleet could potentially be destroyed by the reinforcing fleet and resolving that properly (and even determining what can block what properly, as loadouts matter) takes us towards the topic of combat simulation, which is quite complicated to get right, so I think we would rather allow the original exploit that attempt to simulate what can block what.

Your suggestion lies in between somewhere and unfortunately has the issue of being difficult to understand and predict from the perspective of the player.
I do appreciate you trying to keep it simple though! :)
 
  • 5
  • 1Like
Reactions:

MonzUn

Custodian Programmer
20 Badges
Oct 17, 2015
311
235
  • Prison Architect
  • Age of Wonders III
  • Stellaris Sign-up
  • Europa Universalis IV
  • Europa Universalis III Complete
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Europa Universalis III Complete
  • Warlock: Master of the Arcane
  • Stellaris: Galaxy Edition
  • Cities: Skylines
  • Pillars of Eternity
  • Stellaris
  • Warlock 2: The Exiled
  • A Game of Dwarves
  • Majesty 2 Collection
  • Magicka
  • Europa Universalis III Complete
  • Europa Universalis III
  • Cities in Motion 2
The biggest issue I have with reinforcements is when, after the manager "forgets" that reinforcements are en-route, it will add new ships that exceed my specified fleet loadout, throwing the entire fleet out of whack with too many ships of one class.
I think this one might be addressed in 3.2, but I'm not 100% sure as I wasn't the one who did bugfixing on the fleet manager itself.
 
  • 5
  • 1Like
Reactions:

MonzUn

Custodian Programmer
20 Badges
Oct 17, 2015
311
235
  • Prison Architect
  • Age of Wonders III
  • Stellaris Sign-up
  • Europa Universalis IV
  • Europa Universalis III Complete
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Europa Universalis III Complete
  • Warlock: Master of the Arcane
  • Stellaris: Galaxy Edition
  • Cities: Skylines
  • Pillars of Eternity
  • Stellaris
  • Warlock 2: The Exiled
  • A Game of Dwarves
  • Majesty 2 Collection
  • Magicka
  • Europa Universalis III Complete
  • Europa Universalis III
  • Cities in Motion 2
The bigger issue for me than the spawning of the mini fleets is the cleanup afterwards. It would be great if there was an alternate reinforcement button that hoovered up "spare" ships before building new ones.
We haven't gone for this exact solution, but there have been some work done to tackle the same underlying issue.
 
  • 4Like
  • 4
Reactions:

MonzUn

Custodian Programmer
20 Badges
Oct 17, 2015
311
235
  • Prison Architect
  • Age of Wonders III
  • Stellaris Sign-up
  • Europa Universalis IV
  • Europa Universalis III Complete
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Europa Universalis III Complete
  • Warlock: Master of the Arcane
  • Stellaris: Galaxy Edition
  • Cities: Skylines
  • Pillars of Eternity
  • Stellaris
  • Warlock 2: The Exiled
  • A Game of Dwarves
  • Majesty 2 Collection
  • Magicka
  • Europa Universalis III Complete
  • Europa Universalis III
  • Cities in Motion 2
I'll admit that I've not played since just after Nemesis came out, so forgive me if this has been fixed. But the biggest problem I had with fleet reinforcement dropping to manual mode was when the route was Unsafe only because of the enemy fleet I was currently in combat with. If you don't check for such hazards in the system the fleet being reinforced is currently in, that will fix a lot of happening for me at least.
This issue was both addressed and reintroduced again in 3.1 by yours truly :oops:
In 3.2, reinforcements should MIA to and merge with the requesting fleet even if it's in combat, or I'll have to eat my idiomatic hat!
 
  • 10Like
  • 3Haha
  • 3
  • 1Love
Reactions:

TheRevanchist25

Sergeant
58 Badges
Dec 18, 2018
75
298
  • Shadowrun: Hong Kong
  • Hearts of Iron IV: Death or Dishonor
  • Stellaris: Synthetic Dawn
  • Cities: Skylines - Green Cities
  • Crusader Kings II: Jade Dragon
  • Hearts of Iron IV: Expansion Pass
  • Stellaris: Humanoids Species Pack
  • Stellaris: Apocalypse
  • Surviving Mars: Digital Deluxe Edition
  • Cities: Skylines - Parklife
  • Stellaris: Distant Stars
  • Shadowrun Returns
  • Shadowrun: Dragonfall
  • Surviving Mars
  • Surviving Mars: First Colony Edition
  • Cities: Skylines Industries
  • BATTLETECH: Flashpoint
  • Stellaris: Megacorp
  • Crusader Kings II: Holy Fury
  • Prison Architect
  • Surviving Mars: First Colony Edition
  • Cities: Skylines - Campus
  • Stellaris: Ancient Relics
  • BATTLETECH: Season pass
  • Stellaris: Lithoids
  • BATTLETECH: Heavy Metal
  • Stellaris
  • Stellaris: Nemesis
  • Crusader Kings III: Royal Edition
  • Stellaris: Federations
  • Island Bound
  • Crusader Kings II: Sons of Abraham
  • Prison Architect: Psych Ward
  • Cities: Skylines
  • Crusader Kings II: Way of Life
  • Pillars of Eternity
  • Crusader Kings II: Horse Lords
  • Cities: Skylines - After Dark
  • Crusader Kings II: Conclave
  • Crusader Kings III
  • Hearts of Iron IV: Cadet
  • Hearts of Iron IV: Colonel
  • Crusader Kings II: Reapers Due
  • Tyranny: Archon Edition
  • Stellaris: Digital Anniversary Edition
  • Stellaris: Leviathans Story Pack
  • Cities: Skylines - Natural Disasters
  • Hearts of Iron IV: Together for Victory
  • Stellaris - Path to Destruction bundle
  • Cities: Skylines - Mass Transit
You have identified the exact reason why effective static defences are a serious game design problem with no good solutions.
That's not a problem dude, that's called working as intended. If static defenses aren't capable of stopping you then they serve no purpose. Zerging through 900 star systems without resistance is not entertaining and is very 1 dimensional. You want through the Great Wall? Break it down, or go around. That's not a problem, that is the purpose.
 
  • 5
Reactions:

grommile

Field Marshal
60 Badges
Jun 4, 2011
20.072
25.412
  • Crusader Kings III: Royal Edition
  • Europa Universalis IV
  • Hearts of Iron III Collection
  • Crusader Kings III
  • Hearts of Iron IV: Expansion Pass
  • Stellaris: Ancient Relics
  • Tyranny: Archon Edition
  • Stellaris
  • Hearts of Iron IV: Cadet
  • Shadowrun Returns
  • Teleglitch: Die More Edition
  • Victoria 2
  • 500k Club
  • March of the Eagles
  • Europa Universalis IV: Pre-order
  • Knights of Pen and Paper 2
  • Crusader Kings II
  • Europa Universalis III
That's not a problem dude, that's called working as intended. If static defenses aren't capable of stopping you then they serve no purpose.
If static defences can stop you, then static defences + a fleet can't lose.
 
  • 6
  • 1Like
  • 1
Reactions:

Nebbie Zebbie

Captain
21 Badges
Nov 16, 2020
431
1.231
  • Stellaris - Path to Destruction bundle
  • Stellaris: Federations
  • Stellaris: Lithoids
  • Stellaris: Ancient Relics
  • Prison Architect
  • Stellaris: Megacorp
  • Shadowrun: Dragonfall
  • Stellaris: Distant Stars
  • Stellaris: Apocalypse
  • Stellaris: Humanoids Species Pack
  • Stellaris: Synthetic Dawn
  • Cities in Motion 2
  • Stellaris: Leviathans Story Pack
  • Stellaris: Digital Anniversary Edition
  • Hearts of Iron IV: Cadet
  • Stellaris
  • Cities: Skylines
  • Sword of the Stars II
  • Sword of the Stars
  • Magicka
  • Crusader Kings II
One of the other major problems with fleet reinforcements is the extreme duration of the MIA. Something's very wrong with it.
Also, please consider making it so that once jump drives are equiped, reinforcement path checks should be made easier (with considerations of the relevant game rules can_jum_drive and can_enter_system_by_jump) and the MIA shortened even more, depending on the drive capabilities.
I've heard there's some kind of bug in the current version that greatly increases MIA time because the pathfinding is broken.
 

Eled the Worm Tamer

Major
30 Badges
Aug 5, 2017
573
142
  • Stellaris: Humanoids Species Pack
  • Stellaris: Nemesis
  • Stellaris: Federations
  • Stellaris: Lithoids
  • Stellaris: Ancient Relics
  • Cities: Skylines - Campus
  • Surviving Mars: First Colony Edition
  • Stellaris: Megacorp
  • Cities: Skylines Industries
  • Shadowrun: Dragonfall
  • Shadowrun Returns
  • Stellaris: Distant Stars
  • Surviving Mars: Digital Deluxe Edition
  • Stellaris: Apocalypse
  • Cities: Skylines - Green Cities
  • Age of Wonders III
  • Surviving Mars
  • Cities: Skylines - Mass Transit
  • Stellaris - Path to Destruction bundle
  • Stellaris: Leviathans Story Pack
  • Stellaris: Digital Anniversary Edition
  • Cities: Skylines - Snowfall
  • Cities: Skylines - After Dark
  • Cities: Skylines
  • Crusader Kings II
  • Stellaris: Synthetic Dawn
  • Shadowrun: Hong Kong
  • Stellaris
  • Sword of the Stars
  • Magicka
If static defences can stop you, then static defences + a fleet can't lose.
Which is where the espionage system should have come in. I've seen whole novels and movies using the plot of 'temporarily subvert the defense station, so our guys can win' or 'sabotage a fleet, so we can win against the odds'.

You know, instead of what we got?
 
  • 3Like
  • 1
Reactions:

grommile

Field Marshal
60 Badges
Jun 4, 2011
20.072
25.412
  • Crusader Kings III: Royal Edition
  • Europa Universalis IV
  • Hearts of Iron III Collection
  • Crusader Kings III
  • Hearts of Iron IV: Expansion Pass
  • Stellaris: Ancient Relics
  • Tyranny: Archon Edition
  • Stellaris
  • Hearts of Iron IV: Cadet
  • Shadowrun Returns
  • Teleglitch: Die More Edition
  • Victoria 2
  • 500k Club
  • March of the Eagles
  • Europa Universalis IV: Pre-order
  • Knights of Pen and Paper 2
  • Crusader Kings II
  • Europa Universalis III
Which is where the espionage system should have come in.
My consistent experience of sabotage (rather than just espionage) systems, where they are not the entire reason the game exists in the first place, is that they exhibit one or other of the standard failure modes:
  • too weak for the player to bother using against the AI
  • so strong that the meta revolves around the sabotage mechanics even though it wasn't intended to
  • too annoying to allow the AI to use against the player
Paradox GSGs are no exception to this.
 
  • 8
Reactions: