Hi everyone!
This week, @Gruntsatwork will discuss the technical details of pop group scripting. This topic is likely to be of most interest to the modding community.
The systems we’re implementing now are just scratching the surface of where we want to go with them - we’re looking forward to some of the things we’ll be able to do with these tools over the next few years as well as seeing what you do with them.
As with all of these dev diaries, some of this is still subject to change during implementation and during the beta.
As Eladrin already mentioned in Dev Diary 370, we are changing the way we look at Pops by grouping them together into Pop Groups. These groups are defined by their species, traits, ethics, and factions but NOT their jobs. It is entirely possible and likely for a pop group to have pops working different jobs.
The goal is that for most purposes in the game, you will reference pop groups instead of pops, which should hopefully save us from iterating through every single pop in our empire whenever a modifier needs to be re-calculated.
This allows us to tone down or remove some of the most performance-intensive actions we used before and replace them with far more performance-friendly variations instead.
For example, that means that both “random_owned_pop” or “any_owned_pop” have been relegated to the dark corners of history and replaced with “random_owned_pop_group” and “any_owned_pop_group”.
The same holds true for many of the effects used on those pops, like create_pop or kill_pop, or move_pop. Going forward, we will now create, move and kill pop groups, either in their entirety or through percentages. And for the eagle-eyed among you, YES, that means you no longer have to loop through singular pops to do unspeakable things to them, you can nicely target their pop group and let it do the math for you.
Thanks to the tireless efforts of our programmers, who have given us some new functionality for scripted triggers like comparators, other old tools, like num_pops, will see a resurgence as a scripted trigger. We expect the modding folks to find a lot of use in that, even as we slightly dread what you will come up with.
As also mentioned by Eladrin, this means we no longer have a constant contact between pops and their job.
Instead, there is a single moment of assignment when the pop group briefly knows which job it is supplying and with how much workforce. From then on, the job only knows that it has been supplied with workforce and thus must produce the associated resource. As long as the assignment stands, we have no need to check on the pop again.
This brings us to one of our biggest changes: removing all production modifiers on species traits and replacing them with bonus workforce. Simply put, because the workforce assigned to a job does not know which species it came from during most checks, production bonuses from species (modifiers like +10% Research from Jobs from the Psionic trait) cannot be applied. Instead, species traits now provide modifiers like “+10% Bonus Workforce for Researcher Jobs”, which means 100 Psionic Pops working 100 Physicist jobs will have the job upkeep and output of 110 Physicist jobs. In other words, we only pay upkeep on 100 Pops, but we get the output of 110 Researchers! This also has the side effect of the modifiers for job output from species traits are now multiplicative with other modifiers.
As an example, in 3.14 if we had 1 Psionic (+10% Research from Jobs) Pop working a Researcher job in an empire with the Meritocracy civic (+10% Specialist Job Output) on a Relic world with a Central Spire (+15% Research from Jobs), the total output would be 3 × (1 + 0.1 + 0.1 + 0.15) = 3 × 1.35 = 4.05 of each type of research.
In 4.0 if we have 100 Psionic (+10% Bonus Workforce for Researcher Jobs) Pops working 100 Physics jobs in an empire with the Meritocracy civic (+10% Specialist Job Output) on a Relic world with a Central Spire (+15% Research from Jobs), the total output would be 3 × (1 + 0.1) × (1 + 0.1 + 0.15) = 3 × 1.1 × 1.25 = 4.125 physics research.
This brings us beautiful new script entries like this one from the Psionic trait:
It doesn’t have to be like this. But it can be. Grunts made his choice. - E
This is perfectly serviceable - G
I have hopes to refactor this - AS
As a side note, some checks can still query a pop’s job, but only indirectly, by scoping to a job and determining which pop group is filling it. This means we can still ensure functionality for Death Cults and similar targeted kill_pop effects.
In contrast, production bonuses on the planet or the empire are still available since they simply affect everyone.
So for species traits, we encourage the use of these new modifiers
pop_job_bonus_workforce_mult
To increase the bonus workforce a pop generates for a given job.
pop_job_workforce_mult
To increase the workforce a pop generates for a given job, this is not bonus workforce.
job_max_workforce_mult
To increase the maximum workforce a Job can accept
As a reminder, a job's workforce will fill to its maximum allowed but not beyond that. If a pop generates more workforce than usual, fewer pops will be required to fill the job to max, but it will not produce more than its maximum. If a pop generates a bonus workforce, it can go beyond the job's maximum and scale its production up.
In addition, we have also split quite a few of our economic categories that depended on triggered checks of species traits. This also includes the use of triggers to fake an inheritance of economic classes, which we have removed in many cases and only left in the ones we deemed the most reliant on them.
For inheritance, we recommend the normal parent-child structure of economic categories OR, to use static_modifiers to grant the modifiers of any combination of economic_categories.
Most, if not all, of these changes were made to improve performance: reducing calls, loops, and modifier cascades that would otherwise trigger recalculations across every planet and pop in your empire, just in case a deficit check was needed at that moment.
Looking ahead, we see great potential in workforce mechanics, both for us and the modding community. We've hinted at automation – workforce decoupled from pops – and some of you may have already considered new applications for Virtuality. Who knows what other, more extreme variations in the type and number of pops empires require might now be possible?
Simply put, we now have the workforce to power Stellaris for years to come. Pun very much intended.
Next week we’ll have some more updates on how things have been going.
This week, @Gruntsatwork will discuss the technical details of pop group scripting. This topic is likely to be of most interest to the modding community.
The systems we’re implementing now are just scratching the surface of where we want to go with them - we’re looking forward to some of the things we’ll be able to do with these tools over the next few years as well as seeing what you do with them.
As with all of these dev diaries, some of this is still subject to change during implementation and during the beta.
Pop Groups and Jobs
Hello everyone, @Gruntsatwork here! Let us talk about some of the script changes that are coming with 4.0 when it comes to pops and jobs…As Eladrin already mentioned in Dev Diary 370, we are changing the way we look at Pops by grouping them together into Pop Groups. These groups are defined by their species, traits, ethics, and factions but NOT their jobs. It is entirely possible and likely for a pop group to have pops working different jobs.
The goal is that for most purposes in the game, you will reference pop groups instead of pops, which should hopefully save us from iterating through every single pop in our empire whenever a modifier needs to be re-calculated.
This allows us to tone down or remove some of the most performance-intensive actions we used before and replace them with far more performance-friendly variations instead.
For example, that means that both “random_owned_pop” or “any_owned_pop” have been relegated to the dark corners of history and replaced with “random_owned_pop_group” and “any_owned_pop_group”.
The same holds true for many of the effects used on those pops, like create_pop or kill_pop, or move_pop. Going forward, we will now create, move and kill pop groups, either in their entirety or through percentages. And for the eagle-eyed among you, YES, that means you no longer have to loop through singular pops to do unspeakable things to them, you can nicely target their pop group and let it do the math for you.
Thanks to the tireless efforts of our programmers, who have given us some new functionality for scripted triggers like comparators, other old tools, like num_pops, will see a resurgence as a scripted trigger. We expect the modding folks to find a lot of use in that, even as we slightly dread what you will come up with.
As also mentioned by Eladrin, this means we no longer have a constant contact between pops and their job.
Instead, there is a single moment of assignment when the pop group briefly knows which job it is supplying and with how much workforce. From then on, the job only knows that it has been supplied with workforce and thus must produce the associated resource. As long as the assignment stands, we have no need to check on the pop again.
This brings us to one of our biggest changes: removing all production modifiers on species traits and replacing them with bonus workforce. Simply put, because the workforce assigned to a job does not know which species it came from during most checks, production bonuses from species (modifiers like +10% Research from Jobs from the Psionic trait) cannot be applied. Instead, species traits now provide modifiers like “+10% Bonus Workforce for Researcher Jobs”, which means 100 Psionic Pops working 100 Physicist jobs will have the job upkeep and output of 110 Physicist jobs. In other words, we only pay upkeep on 100 Pops, but we get the output of 110 Researchers! This also has the side effect of the modifiers for job output from species traits are now multiplicative with other modifiers.
As an example, in 3.14 if we had 1 Psionic (+10% Research from Jobs) Pop working a Researcher job in an empire with the Meritocracy civic (+10% Specialist Job Output) on a Relic world with a Central Spire (+15% Research from Jobs), the total output would be 3 × (1 + 0.1 + 0.1 + 0.15) = 3 × 1.35 = 4.05 of each type of research.
In 4.0 if we have 100 Psionic (+10% Bonus Workforce for Researcher Jobs) Pops working 100 Physics jobs in an empire with the Meritocracy civic (+10% Specialist Job Output) on a Relic world with a Central Spire (+15% Research from Jobs), the total output would be 3 × (1 + 0.1) × (1 + 0.1 + 0.15) = 3 × 1.1 × 1.25 = 4.125 physics research.
This brings us beautiful new script entries like this one from the Psionic trait:
It doesn’t have to be like this. But it can be. Grunts made his choice. - E
This is perfectly serviceable - G
I have hopes to refactor this - AS
As a side note, some checks can still query a pop’s job, but only indirectly, by scoping to a job and determining which pop group is filling it. This means we can still ensure functionality for Death Cults and similar targeted kill_pop effects.
In contrast, production bonuses on the planet or the empire are still available since they simply affect everyone.
So for species traits, we encourage the use of these new modifiers
pop_job_bonus_workforce_mult
To increase the bonus workforce a pop generates for a given job.
pop_job_workforce_mult
To increase the workforce a pop generates for a given job, this is not bonus workforce.
job_max_workforce_mult
To increase the maximum workforce a Job can accept
As a reminder, a job's workforce will fill to its maximum allowed but not beyond that. If a pop generates more workforce than usual, fewer pops will be required to fill the job to max, but it will not produce more than its maximum. If a pop generates a bonus workforce, it can go beyond the job's maximum and scale its production up.
In addition, we have also split quite a few of our economic categories that depended on triggered checks of species traits. This also includes the use of triggers to fake an inheritance of economic classes, which we have removed in many cases and only left in the ones we deemed the most reliant on them.
For inheritance, we recommend the normal parent-child structure of economic categories OR, to use static_modifiers to grant the modifiers of any combination of economic_categories.
Most, if not all, of these changes were made to improve performance: reducing calls, loops, and modifier cascades that would otherwise trigger recalculations across every planet and pop in your empire, just in case a deficit check was needed at that moment.
Looking ahead, we see great potential in workforce mechanics, both for us and the modding community. We've hinted at automation – workforce decoupled from pops – and some of you may have already considered new applications for Virtuality. Who knows what other, more extreme variations in the type and number of pops empires require might now be possible?
Simply put, we now have the workforce to power Stellaris for years to come. Pun very much intended.
What’s Next?
Our planned livestream is going to be delayed a bit, and will likely end up being alongside the Open Beta. Right now our primary focus is on implementation.Next week we’ll have some more updates on how things have been going.
