written by Obidobi, Caligula and Eladrin
Hello everyone!
I hope you are all excited to get your hands on our next expansion ‘Overlord’ next week! Expanding on the Subject/Ruler dynamic has been something that we know a lot of you (and us, internally) have been wanting for a very long time, so it’s really amazing to finally see it come to fruition!
So to hold you over until Overlord release, here is the usual Dev Diary containing the changelog for you to read!
But first, we have a few Community events to talk about:
Today at 1700 CEST (UTC + 2), join us on the Official Stellaris Discord for our Overlord Dev Q&A! Have a question about something in today’s patch notes? Stop by and ask!
As well, join us starting at 1400 CEST on May 7th and 8th, for our Content Creator Multiplayer Showcase. We’ll be streaming Overlord all weekend on Twitch and YouTube, with some of our favorite community content creators!
Click here to read the 3.4 "Cepheus" Patch Notes
Moddability Changes in 3.4 ‘Cepheus’
I’m going to keep this one fairly brief, by my standards. Recent updates have given modders plenty to get their teeth into, and 3.4 is no different. We already described the Situations system a few weeks back, which will doubtless see much use and abuse from modders, so I’ll focus on other scripting language changes.
The biggest improvement that springs to mind is in the field of modifiers. In triggered modifiers, you can now define a “mult” value, which lets you apply a modifier or script value to that triggered modifier:
triggered_pop_modifier = {
potential = {
NOT = { is_same_species = owner }
}
modifier = { pop_citizen_happiness = 1 }
mult = modifier:non_main_species_happiness_mult
}
As you can see, I’ve defined a modifier that we do not have in the game there. That is because we can now define our own ad hoc modifiers in script, for instance:
non_main_species_happiness_mult = {
icon = mod_planet_happiness_mult
percentage = yes
good = yes
category = pop
}
This modifier will of course only do something so long as it is applied somewhere, but nowadays there’s plenty of places where that is possible (everywhere that script values are valid). For instance, we have refactored species traits’ amenities and trade output from jobs to use this system, which cut down on the effort it takes to tweak their numbers (and let us track down a few bugs in that regard).
As a low-key but quite nice improvement, you will also no longer get load order errors where certain modifiers do not work in certain contexts (e.g. ethos modifiers in traits).
That’s not all we have done. Developing Overlord naturally provided some opportunities to rework old systems. For instance, thousands of lines were saved in the scripts for enclaves by using the new “event inheritance” system. With this, an event can be specified to inherit properties from another via “base = ”. Then, various properties can be overwritten via “desc_clear”, “option_clear”, “picture_clear” and “show_sound_clear”. Basically, this lets us inherit the behaviour of a given event while changing its flavour.
The list goes on. A new common/tradable_actions folder now lets you define custom actions that you can trade with other empires. For instance, subjects can pledge loyalty to their Overlords in return for other benefits. The folder is also extensively documented:
# trade_action_my_example_action = {
# # If this is set to 'yes', then the action will be fired and then removed from the trade deal.
# # If 'no', then the trade deal will be treated as a treaty that lasts for at least 10 years.
# fire_and_forget = no
#
# # Determines if the action will show up in the list in the trade deals view.
# # SCOPE: Country "giving" the action
# # FROM: Country "receiving" the action
# potential = {
# has_overlord = from
# is_specialist_subject_type = { TYPE = bulwark }
# }
#
#
# If this trigger returns 'no', then the trade deal will be cancelled. Checked on daily tick. Only relevant if fire_and_forget is 'no'.
# # SCOPE: Country "giving" the action
# # FROM: Country "receiving" the action
# active = {
# has_overlord = from
# is_specialist_subject_type = { TYPE = bulwark }
# }
#
# # Effect that fires when the trade deal is accepted.
# # SCOPE: Country "giving" the action
# # FROM: Country "receiving" the action
# on_traded_effect = {
# from = {
# set_galactic_custodian = yes
# }
# }
#
# # Effect that fires when the trade deal ends. Only relevant if fire_and_forget is 'no'.
# # SCOPE: Country "giving" the action
# # FROM: Country "receiving" the action. Not guaranteed to be valid, since a trade deal is cancelled if one of the countries dies.
# on_deal_ended_sender_effect = {
# }
#
# # Effect that fires when the trade deal ends. Only relevant if fire_and_forget is 'no'.
# # SCOPE: Country "receiving" the action
# # FROM: Country "giving" the action. Not guaranteed to be valid, since a trade deal is cancelled if one of the countries dies.
# on_deal_ended_recipient_effect = {
# set_galactic_custodian = no
# }
#
# # Used to determine how much the AI will value the action in a trade deal.
# ai_weight = {
# weight = 1
#
# modifier = {
# weight = 2
# from = {
# is_galactic_custodian = no
# }
# }
# }
# }
Speaking of the AI and diplomacy, diplomatic actions are now a little bit more controllable from script. While they (and AI logic surrounding them) are still handled to a significant degree in code, additional reasons for the AI to accept or decline the proposals can now be scripted in an “ai_acceptance” field, while a “should_ai_propose” field lets you block the AI from proposing it.
Finally, something that modders need to know about is our changes to synced localisation. Or rather, the fact that we have completely removed it. This means that, everywhere where it was used, we now use the normal localisation system instead. There are several advantages of this:
Multiplayer will now work, even if one player is playing in Chinese and one player in English (this does not currently work)
It is theoretically possible to translate all names into other languages now. (Unfortunately, however, I can’t promise that we’ll ever do that, because European languages all have complicated grammar rules, and we have yet to work out a reasonable way to deal with them. But still, the possibility is pretty cool).
Unfortunately, there are also some complications, which can be summed up as: we need to save a property as it is at the time something is named (i.e. the property may change later - but this should not affect what it localises as), and also make sure that it is localising correctly no matter which language you are playing in.
Basically, this means that if you want to use bracket commands in setting names, you need to register it in the place where you are setting the name, e.g.:
set_name = {
key = "NAME_Absorbed_Species"
variable_string = "[Root.GetSpeciesNamePlural]"
}
NAME_Absorbed_Species:0 "Absorbed [Root.GetSpeciesNamePlural]"
Empire names in the random_names directory have a new “lookups” line to serve this purpose:
# Imperial Spiritualist 2
empire_name_format = {
random_weight = {
factor = 0
modifier = {
add = 1
has_government = "gov_theocratic_monarchy"
is_pirate = no
is_primitive = no
NOT = { is_country_type = fallen_empire }
NOT = { is_country_type = awakened_fallen_empire }
}
}
lookups = " [This.Capital.GetName]"
format = format.imp_spi.2 # of [This.Capital.GetName]
noun = format.homeworld # [This.Capital.GetName]
prefix_format = format_prefix.imp_spi.2 # [This.Capital.GetName]
# Empire of Earth
}
In cases where names were defined inline in script, which is quite common in mods, it will likely continue to work as it used to (so long as no square bracket commands are used). I can’t entirely vouch for this, since we don’t use this functionality inhouse as it would break Chinese (and now also Korean and Japanese) translations, since they have always translated names. It may also cause issues if the name you are setting something to is a key that is localised, but which you did not intend to refer to… (N.B. name lists now also use localisation keys).
As a word of caution, each square bracket command we make available has to be defined to work in the C++ code. We have tried our best to cover all the cases which one could want to use, but there may be some we’ve missed (in this case, the error log will complain about invalid property “GetXPersistent”). If there are any particularly egregious cases we turn out to have missed, please file bug reports and we’ll see what we can do!
Progenitor Hive Origin
This week’s origin reveal from Nivarias is the Progenitor Hive!
In the beginning, the Progenitor was.
Life on your homeworld was harsh and competitive, yet still the mighty Progenitor expanded its territory. Running such a vast dominion soon grew untenable, so the Progenitor created the first Offspring. In time, it became apparent that the Offspring could not manage alone. In turn, they produced menial drones to assist in taming our home.
As you took your first tentative steps across the stars, the Progenitor sequestered itself into a specialized nest. Endowed with greater, streamlined control, you are now ready to spread the Progenitor's influence to all the stars of the galaxy - for the Progenitor was, is, and will be.
The Progenitor Hive origin is a new Hive Mind origin coming in Overlord, and as such it also requires Utopia to play.
The hive relies heavily on the presence of powerful Offspring. While they are near, the hive thrives and functions with great efficiency.
Offspring Vessels can be included in your fleets, providing an aura that cancels out the inherent penalties of your ships, providing a net small bonus. You are limited in the number of Offspring Vessels your empire can support at any given time, based on your overall naval capacity, similar to the Titan limit. The Offspring Vessels share a pool, with larger ships taking a greater portion of the pool.
There’s also a starbase building to protect your empire space, which provides greater benefits than the ships.
The Offspring Nest replaces the Spawning Pools of regular hives, providing additional bonuses. You’ll want one of these on each of your planets.
Make sure someone is working the Offspring Drone job, since otherwise the directionless menial drones on your colonies face difficulties.
All employed leaders within a Progenitor Hive, passively gain experience at a steady rate, gaining skill levels at a much faster rate than leaders of other empires. On average, with no experience boosts or other sources of experience, they will passively gain a level about every (1.5 * level they’re going to) years.
Unlike other hives, the Progenitor is able to release sectors as vassals, placing the fate of the sector in the tendrils of an Offspring which is promoted to Progenitor status and becomes the ruler of the new empire. Progenitor subjects released inherit the Progenitor Hive origin from your empire, with all the bonuses and penalties that it entails.
Should you have a subject that is not a Progenitor Hive, you can build an Offspring Nest on their world, providing some much needed oversight to their dro- er, workers. They’re basically the same thing, right?
There’s also one other (non-Progenitor Hive related) holding to reveal!
Overlords with the Environmentalist civic can build a Ranger Lodge, which reduces consumer goods usage on the subject planet but also creates a Nature Preserve blocker, which cannot be removed as long as the lodge exists.
The Ranger Lodge can only be built on natural planets that have districts available to block, and cannot be built on Ecumenopolies, Hive Worlds, Machine Worlds, or Relic Worlds.
