





🌟 Special thanks to our amazing supporters:
✨ $10 Tier: [Geeks Love Detail]
🌈 $5 Tier: [Arch Toasty][Benedikt][David Martínez Martí]
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 its 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 todays 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. Well be streaming Overlord all weekend on Twitch and YouTube, with some of our favorite community content creators!
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, Ive 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 theres 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).
Thats 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 = # 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 cant promise that well 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 cant entirely vouch for this, since we dont 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 weve 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 well see what we can do!
[ 6075 ]
[ 1294 ]
[ 4061 ]