• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Hi all! I’m Caligula, our resident scripting language magician. As someone who works with our scripting language - both using it and improving it - on a daily basis, I’m very happy to be able to show off some of the new stuff that modders (and us inhouse) will be able to use going forwards, once the upcoming patch hits.

I’ll begin with a rundown of the new features:
  • Espionage: modders can add new operations, much like arc sites
  • First Contact: script driven, so modders can change much of the system, but all first contact is now technically one long event chain, so overwriting could be an issue. Luckily we have a new effect, “fire_on_action”, which has been inserted into various places that should alleviate this
  • Become the Crisis: code features e.g. the interface are all activated by script. So in theory, one could overwrite the whole feature to be whatever sort of progression to a goal you happen to want to mod in.
  • Emperor/Custodian: feature designed by the most experienced Content Designer at PDS. Brought with it many collateral scripting improvements, such as far more flexibility with galcom resolutions and the ability to spawn federation / community fleets via script.

Now, it’ll be exciting to see what modders do with this, but there’s so much more that we’ve done since 2.8 hit, so...

General improvements and standardisations

It would be fair to say that the Stellaris scripting language has grown incrementally according to the game's needs. This is not unexpected - Stellaris itself has grown incrementally. But it has had the side effect that a lot of different people have contributed to it, and so inconsistencies between different implementations have arisen. On the user side, this would show itself in, for example, things which work in one place but do not work in other, equivalent places.

For the upcoming patch, we had time to take a holistic view of certain things and implement some general improvements and standardisations.

A quick win in this regard is what is known internally as "script lists". These are a code system which generates random/every/any/count_whatever_object from a single section of code - guaranteeing that the way that array is built is the same between them, i.e. any_owned_pop checks exactly the same pops as every_owned_pop would execute on. We have been using these for quite a while, but there were still some very old implementations for certain scopes that predated them. The result of this was in some cases confusion - for example, x_pop and x_planet did sometimes radically different things depending on whether you used every, random, any or count (e.g. working in different scopes, sometimes referring to all the objects in the game and sometimes all of those belonging to the current scope...). Disturbingly, it was found that any_ship referred to "any ship in the game" and was in fact used wrong 100% of the time in our scripts. Another result was that in some cases one of the versions (usually the "count" version) was simply missing.

With the next patch, nearly all of the pre-script list implementations have been removed and replaced with script lists. In some cases, the opportunity was taken to clarify what the script list did, e.g. the "planet" script list is now split between "galaxy_planet" and "system_planet". (This will break some mods, for which I am a bit sorry, but not very :D It was worth it, and the patch notes will give details on what changed. In most cases, a batch-replace will suffice. Also, because of script lists, a fair few count_x triggers have changed names to lose an "s" at the end, which is slightly regrettable from a grammatical point of view). Some have also had some functionalities expanded, e.g. owned_pop, owned_planet and system_within_border now all work in sector scope.

A further area singled out for improvement was references to scopes in effects and triggers, e.g. create_pop = { species = <whatever> }. It turned out that there were quite significant variations as to what <whatever> in that example could be, depending on the effect or trigger. In some cases, only the species was allowed; in others, perhaps species or leader or country or pop; in others, the same but not pops… In some cases, we even used something called “owner_main_species”, which worked in just those places (unlike “owner_species”, which was the same but worked everywhere…). Our solution was to go through each and every trigger and effect and enforce standardisation - with the same code functions used in each case - for any script call to a species, country, planet, leader, or solar system location. No more shall we be confused that something works in one place but not in another!

This also lets us make sure that errors are correctly (and usefully) logged each time a scripter gets one of these wrong. (N.B. for modders not in the know: the error log can be found in Documents/Paradox Interactive/Stellaris/logs/error.log). In a similar vein, error logging has generally been improved across the whole scripting language. A large number of error messages lacking essential information (e.g. file location) have been updated to include that - as guardian of our overnight testing error logs, I have gone on a personal crusade against useless error log messages. Furthermore, we have fixed a disturbing number of cases where something didn't work but didn't warn you - e.g. doing something wrong in a trigger so it is always false, or messing up an effect so it did nothing. I'm not going to promise that this will never happen anymore, but a concerted effort has been made to eliminate such cases. Modders should expect the error log to warn them of a lot more issues both during startup and during the campaign. This has also made us somewhat more effective in fixing script bugs, since many more are now caught in the aforementioned overnight tests.

Variables

Onto something a bit different. On Stellaris, inhouse scripters and modders alike have long looked with envy upon the capabilities of the newer PDS game engines, compared to our own ability to do maths in script. We did have variables, but their functionality has been a bit more limited than we may have desired. In fact, I’ve seen some of the ways that modders get around their limitations, which have been incredibly motivating to make such horrible scripts no longer be necessary!

In 2.8, the following was possible with variables:
  • You can check, set, add, subtract, divide or multiply variables against values, other variables on the same scope, or the same variable on other scopes
  • You can export various galaxy generation settings as variables
  • You can refer to variables in localisations, but if the variable’s value is 0, it will show as blank because the variable is cleared
  • Variables can be used as a parameter in a handful of places, such as the count in a “while” effect

Quite a lot of improvements have been made since then, and further ones are planned for the near future. In the upcoming patch:
  • You can also check, set, add, subtract, divide or multiply variables against different variables on other scopes
  • There are new effects to modulo (% operator), round up, round down and round to the closest full number
  • A new trigger check_variable_arithmetic checks the value of a variable if you’d perform some arithmetic to it in a certain way, e.g. multiply it by another value or variable (add, subtract, multiply, divide and modulo all work)
  • New effects to export various game values to variables have been added. These are: export_modifier_to_variable (check_modifier_value trigger also exists now), export_resource_stockpile_to_variable, export_resource_income_to_variable
  • add_modifier, add_resource, resource_stockpile_compare now have “mult” parameters where a variable is accepted. So you can scale resource costs and bonuses in effects by a variable now.
  • Variables are no longer cleared when they are 0, but instead when you use the clear_variable effect, so they can be reliably used in localisations.
  • Certain usages of variables now have error logging, in case you try and use one that hasn’t been set.

Additionally, we have started making it possible to use variables way more widely. The idea is that we want to change how simple numerical effects and triggers (i.e. ones which accept a number as the right hand side parameter and do not have any “{ }”) work:
  • Effects should allow you to use a variable, and should grab the number from that variable
  • Triggers should also let you use a variable, and should check themselves against the value of that variable
  • Triggers should by default also let you check them against another scope for which that trigger would work. So “num_pops > from” should check if the current object has more pops than “from” does
  • It should be possible to export the current value of a trigger to a variable via an effect, i.e. “export_trigger_value_to_variable = { trigger = num_pops variable = my_var }” => sets the my_var variable to the number of pops the current scope has.

Unfortunately, it only recently became possible for us to pursue these changes, and while the groundwork has been set for them, they are not yet fully implemented - finishing the Nemesis expansion and accompanying patch has rightly taken priority (the changes are not without danger: it’s a lot of lines of code that have to be modified for it). So consider this a preview for how it will look in the hopefully near future, and in the meantime, the fleet_power trigger already works in the way specified, and export_trigger_value_to_variable is in the patch, albeit working with only that trigger.

Button Effects

Inhouse, we made the UI by assigning a function to buttons in the source code. But there’s also support for interface buttons that you mod into the game. In previous versions, these did not take the scope of the object that they were attached to, so if you added a button to a planet, it would still execute the effect on your country rather than that planet. We have fixed that for a bunch of cases: they will now be able to deduce their interface's planet, fleet, ship, system, ambient object, megastructure, federation, archaeology site, first contact site, spy network or espionage operation. (Incidentally, debug console commands like “effect …” and “trigger …” now work in those same scopes)

Disclaimer: The way it works is a tad hacky and it may be possible to confuse it by opening multiple interfaces at once. I recommend checking “is_scope_type = planet/whatever” in the allow and/or effect sections of the button effect. But the signs are that it should work with no problem in most cases, which is better than none!

More nice things
  • In most places where you could previously use logical operators such as >, >=, =<, <, you can now use != for “is not equal” too.
  • Message types now have their own folder, so mods can add to them without overwriting the file (great for intermod compatibility, and also for modders being able to add QoL without overwriting each other)
  • Messages spawned by the create_message effect now support using loc commands such as [This.GetName] (where “This” is the specified target of the message).
  • Also, since we had to fix a large number of cases where there were references to the “Galactic Community” rather than the “Galactic Imperium”, [ ] locs now work in quite a variety of extra places.
  • The effects “add_victory_score = <number>” and “win = yes” now exist. I’m sure no one will misuse them.
  • Added new event types: leader_event, system_event, starbase_event, first_contact_event, and espionage_operation_event. Though mean time to happen does not work for any of them at the moment - fixing that wasn’t a priority, as it is generally better to avoid mean time to happen anyway.
  • Hardcoded juggernaut behaviour is now tied to a ship size being a starbase that is mobile, rather than the “juggernaut” key. I.e. mod-made juggernauts are now possible without crippling bugs
  • It’s now possible to hide a static modifier from the list of country modifiers
  • You can check the distance of objects within the same solar system now by adding “same_system = yes” to the distance trigger
  • There’s quite a lot of new on_actions, and you can make your own ones with fire_on_action effect
  • And a lot more.

Finally, I'll leave you with the new trigger docs (as of today), which are now found in their own file called trigger_docs.log, and which really speak for themselves. Also, don't forget Paradox Insider will premier this Saturday at 8 PM CET (7 PM UK, 2 PM ET, 11 AM PT) on http://twitch.tv/twitchgaming
 

Attachments

  • trigger_docs.log
    253,4 KB · Views: 0
Well the variable part seems promising but i am not quite sure what will he variables be able to affect, maybe i am just not reading properly but i get the idea that the variables still wont be usable for things like cost of buildings, output of buildings, cost of ships, colonization cost, tech cost, etc. And if this is correct is there a possibility of this becoming possible later on (for example 3.0) or is it completely out of the question ?
 
What we found, though, is that the single best way to improve performance is to drastically reduce the number of pops, to be honest.
Well, who'd've thunk. :D

All silliness aside though, there's a lot of cool new stuff here.



Some personal highlights:

With the next patch, nearly all of the pre-script list implementations have been removed and replaced with script lists.
Our solution was to go through each and every trigger and effect and enforce standardisation - with the same code functions used in each case - for any script call to a species, country, planet, leader, or solar system location. No more shall we be confused that something works in one place but not in another!
More consistency is always great.

On Stellaris, inhouse scripters and modders alike have long looked with envy upon the capabilities of the newer PDS game engines, compared to our own ability to do maths in script.
Indeed! Heck, variables often felt less useful than back in CK2.

Message types now have their own folder, so mods can add to them without overwriting the file (great for intermod compatibility, and also for modders being able to add QoL without overwriting each other)
It's always nice to need one less mega-compatibility patch.

you can make your own ones with fire_on_action effect
This might just be the biggest one though. Mods being able to call each others code without a complex patchwork of, uh, patches? Yes please!


Mod compatibility is something I'm always happy to see, so these are very nice. There's still quite a few headaches in other parts of the script, but this here is a nice, big step forward.
 
  • 3
Reactions:
Hi all! I’m Caligula, our resident scripting language magician. As someone who works with our scripting language - both using it and improving it - on a daily basis, I’m very happy to be able to show off some of the new stuff that modders (and us inhouse) will be able to use going forwards, once the upcoming patch hits.

I’ll begin with a rundown of the new features:
  • Espionage: modders can add new operations, much like arc sites
  • First Contact: script driven, so modders can change much of the system, but all first contact is now technically one long event chain, so overwriting could be an issue. Luckily we have a new effect, “fire_on_action”, which has been inserted into various places that should alleviate this
  • Become the Crisis: code features e.g. the interface are all activated by script. So in theory, one could overwrite the whole feature to be whatever sort of progression to a goal you happen to want to mod in.
  • Emperor/Custodian: feature designed by the most experienced Content Designer at PDS. Brought with it many collateral scripting improvements, such as far more flexibility with galcom resolutions and the ability to spawn federation / community fleets via script.

Now, it’ll be exciting to see what modders do with this, but there’s so much more that we’ve done since 2.8 hit, so...

General improvements and standardisations

It would be fair to say that the Stellaris scripting language has grown incrementally according to the game's needs. This is not unexpected - Stellaris itself has grown incrementally. But it has had the side effect that a lot of different people have contributed to it, and so inconsistencies between different implementations have arisen. On the user side, this would show itself in, for example, things which work in one place but do not work in other, equivalent places.

For the upcoming patch, we had time to take a holistic view of certain things and implement some general improvements and standardisations.

A quick win in this regard is what is known internally as "script lists". These are a code system which generates random/every/any/count_whatever_object from a single section of code - guaranteeing that the way that array is built is the same between them, i.e. any_owned_pop checks exactly the same pops as every_owned_pop would execute on. We have been using these for quite a while, but there were still some very old implementations for certain scopes that predated them. The result of this was in some cases confusion - for example, x_pop and x_planet did sometimes radically different things depending on whether you used every, random, any or count (e.g. working in different scopes, sometimes referring to all the objects in the game and sometimes all of those belonging to the current scope...). Disturbingly, it was found that any_ship referred to "any ship in the game" and was in fact used wrong 100% of the time in our scripts. Another result was that in some cases one of the versions (usually the "count" version) was simply missing.

With the next patch, nearly all of the pre-script list implementations have been removed and replaced with script lists. In some cases, the opportunity was taken to clarify what the script list did, e.g. the "planet" script list is now split between "galaxy_planet" and "system_planet". (This will break some mods, for which I am a bit sorry, but not very :D It was worth it, and the patch notes will give details on what changed. In most cases, a batch-replace will suffice. Also, because of script lists, a fair few count_x triggers have changed names to lose an "s" at the end, which is slightly regrettable from a grammatical point of view). Some have also had some functionalities expanded, e.g. owned_pop, owned_planet and system_within_border now all work in sector scope.

A further area singled out for improvement was references to scopes in effects and triggers, e.g. create_pop = { species = <whatever> }. It turned out that there were quite significant variations as to what <whatever> in that example could be, depending on the effect or trigger. In some cases, only the species was allowed; in others, perhaps species or leader or country or pop; in others, the same but not pops… In some cases, we even used something called “owner_main_species”, which worked in just those places (unlike “owner_species”, which was the same but worked everywhere…). Our solution was to go through each and every trigger and effect and enforce standardisation - with the same code functions used in each case - for any script call to a species, country, planet, leader, or solar system location. No more shall we be confused that something works in one place but not in another!

This also lets us make sure that errors are correctly (and usefully) logged each time a scripter gets one of these wrong. (N.B. for modders not in the know: the error log can be found in Documents/Paradox Interactive/Stellaris/logs/error.log). In a similar vein, error logging has generally been improved across the whole scripting language. A large number of error messages lacking essential information (e.g. file location) have been updated to include that - as guardian of our overnight testing error logs, I have gone on a personal crusade against useless error log messages. Furthermore, we have fixed a disturbing number of cases where something didn't work but didn't warn you - e.g. doing something wrong in a trigger so it is always false, or messing up an effect so it did nothing. I'm not going to promise that this will never happen anymore, but a concerted effort has been made to eliminate such cases. Modders should expect the error log to warn them of a lot more issues both during startup and during the campaign. This has also made us somewhat more effective in fixing script bugs, since many more are now caught in the aforementioned overnight tests.

Variables

Onto something a bit different. On Stellaris, inhouse scripters and modders alike have long looked with envy upon the capabilities of the newer PDS game engines, compared to our own ability to do maths in script. We did have variables, but their functionality has been a bit more limited than we may have desired. In fact, I’ve seen some of the ways that modders get around their limitations, which have been incredibly motivating to make such horrible scripts no longer be necessary!

In 2.8, the following was possible with variables:
  • You can check, set, add, subtract, divide or multiply variables against values, other variables on the same scope, or the same variable on other scopes
  • You can export various galaxy generation settings as variables
  • You can refer to variables in localisations, but if the variable’s value is 0, it will show as blank because the variable is cleared
  • Variables can be used as a parameter in a handful of places, such as the count in a “while” effect

Quite a lot of improvements have been made since then, and further ones are planned for the near future. In the upcoming patch:
  • You can also check, set, add, subtract, divide or multiply variables against different variables on other scopes
  • There are new effects to modulo (% operator), round up, round down and round to the closest full number
  • A new trigger check_variable_arithmetic checks the value of a variable if you’d perform some arithmetic to it in a certain way, e.g. multiply it by another value or variable (add, subtract, multiply, divide and modulo all work)
  • New effects to export various game values to variables have been added. These are: export_modifier_to_variable (check_modifier_value trigger also exists now), export_resource_stockpile_to_variable, export_resource_income_to_variable
  • add_modifier, add_resource, resource_stockpile_compare now have “mult” parameters where a variable is accepted. So you can scale resource costs and bonuses in effects by a variable now.
  • Variables are no longer cleared when they are 0, but instead when you use the clear_variable effect, so they can be reliably used in localisations.
  • Certain usages of variables now have error logging, in case you try and use one that hasn’t been set.

Additionally, we have started making it possible to use variables way more widely. The idea is that we want to change how simple numerical effects and triggers (i.e. ones which accept a number as the right hand side parameter and do not have any “{ }”) work:
  • Effects should allow you to use a variable, and should grab the number from that variable
  • Triggers should also let you use a variable, and should check themselves against the value of that variable
  • Triggers should by default also let you check them against another scope for which that trigger would work. So “num_pops > from” should check if the current object has more pops than “from” does
  • It should be possible to export the current value of a trigger to a variable via an effect, i.e. “export_trigger_value_to_variable = { trigger = num_pops variable = my_var }” => sets the my_var variable to the number of pops the current scope has.

Unfortunately, it only recently became possible for us to pursue these changes, and while the groundwork has been set for them, they are not yet fully implemented - finishing the Nemesis expansion and accompanying patch has rightly taken priority (the changes are not without danger: it’s a lot of lines of code that have to be modified for it). So consider this a preview for how it will look in the hopefully near future, and in the meantime, the fleet_power trigger already works in the way specified, and export_trigger_value_to_variable is in the patch, albeit working with only that trigger.

Button Effects

Inhouse, we made the UI by assigning a function to buttons in the source code. But there’s also support for interface buttons that you mod into the game. In previous versions, these did not take the scope of the object that they were attached to, so if you added a button to a planet, it would still execute the effect on your country rather than that planet. We have fixed that for a bunch of cases: they will now be able to deduce their interface's planet, fleet, ship, system, ambient object, megastructure, federation, archaeology site, first contact site, spy network or espionage operation. (Incidentally, debug console commands like “effect …” and “trigger …” now work in those same scopes)

Disclaimer: The way it works is a tad hacky and it may be possible to confuse it by opening multiple interfaces at once. I recommend checking “is_scope_type = planet/whatever” in the allow and/or effect sections of the button effect. But the signs are that it should work with no problem in most cases, which is better than none!

More nice things
  • In most places where you could previously use logical operators such as >, >=, =<, <, you can now use != for “is not equal” too.
  • Message types now have their own folder, so mods can add to them without overwriting the file (great for intermod compatibility, and also for modders being able to add QoL without overwriting each other)
  • Messages spawned by the create_message effect now support using loc commands such as [This.GetName] (where “This” is the specified target of the message).
  • Also, since we had to fix a large number of cases where there were references to the “Galactic Community” rather than the “Galactic Imperium”, [ ] locs now work in quite a variety of extra places.
  • The effects “add_victory_score = <number>” and “win = yes” now exist. I’m sure no one will misuse them.
  • Added new event types: leader_event, system_event, starbase_event, first_contact_event, and espionage_operation_event. Though mean time to happen does not work for any of them at the moment - fixing that wasn’t a priority, as it is generally better to avoid mean time to happen anyway.
  • Hardcoded juggernaut behaviour is now tied to a ship size being a starbase that is mobile, rather than the “juggernaut” key. I.e. mod-made juggernauts are now possible without crippling bugs
  • It’s now possible to hide a static modifier from the list of country modifiers
  • You can check the distance of objects within the same solar system now by adding “same_system = yes” to the distance trigger
  • There’s quite a lot of new on_actions, and you can make your own ones with fire_on_action effect
  • And a lot more.

Finally, I'll leave you with the new trigger docs (as of today), which are now found in their own file called trigger_docs.log, and which really speak for themselves. Also, don't forget Paradox Insider will premier this Saturday at 8 PM CET (7 PM UK, 2 PM ET, 11 AM PT) on http://twitch.tv/twitchgaming

Although this seems to be mostly of benefit to modders, its pretty obvious to me that it is a shift of the Stellaris team of getting ready to and may have already started, to fix the code base. I imagine the scripting stuff has been the first thing holding you guys back and not wanting to hurt the modding community? Thumbs up from me.

Will these changes affect the Enigmatic Fortress? It must be something your "well aware off" as a scripter - as it goes wrong in most play throughs!
 
  • 1Like
Reactions:
There is only one DD missing before the game can be released.
The achievement DD.

So my assumption, the will tell us tomorrow the release date and next week we will see the Achievement DD.
 
I will ask again:

Can we please have some more documentation? Chances are it's been laying around in your workstations for years.
It would be great if you could add some organization to it and release it as a unit - or create/update the relevant sections in the wiki.

(for the love, I know there was an attchament in the OP....)
You can generate documentation via console command and it will output it to log folder.
Or you can use online GitHub library https://github.com/OldEnt/stellaris-triggers-modifiers-effects-list (next patch docs in beta branch)


Do these mean that it would be possible to create a mod that would replace the

"galactic empire goes super evil, builds doomsday device of evil" plot with

a "galaxy unites under an emperor to face a greater threat that requires a massive device / effort to stop" plot?
Those two are the same thing. EU is canon.
 
EU4 meme.jpg
 
  • 15Haha
  • 1Like
Reactions:
Finally, I'll leave you with the new trigger docs (as of today), which are now found in their own file called trigger_docs.log, and which really speak for themselves.
Also, I just realized, this apparently managed to sneak through:
Code:
empire_sprawl - Checks the empire's sprawl
empire_size < 20
Supported Scopes: country
Wrong trigger in the example there.
 
  • 1Like
Reactions:
I would pay DLC money to have your internal documentation of the full list of function & effects and what they do.

Love seeing the non glamorous, under the hood work happening!
That is literally what the trigger docs are, that Caligula posted with the DD.
 
  • 1
Reactions:
I remember reading a while back that the titanic life modifier was meant to give three titans per planet with the modifier, but due to scripting limitations the player only got three total regardless of how many planets they had with it. Assuming that's true, do these changes mean those limits no longer apply?
 
  • 1Like
Reactions:
That is literally what the trigger docs are, that Caligula posted with the DD.
This is for the triggers, and I'm thrilled to have it! There are lots of modifiers and stuff that aren't in there though. I'm not even sure there is a public list of all of the working ones.
It's just the downside of using their own scripting language for this (as opposed to some public language) and a lot of things under the hood not being exposed to us.
 
  • 2
Reactions:
This is for the triggers, and I'm thrilled to have it! There are lots of modifiers and stuff that aren't in there though. I'm not even sure there is a public list of all of the working ones.
It's just the downside of using their own scripting language for this (as opposed to some public language) and a lot of things under the hood not being exposed to us.
Modifiers are available and generated into logs as well, you can always view them either on wiki or on GitHub library I already linked in this thread. https://github.com/OldEnt/stellaris-triggers-modifiers-effects-list/
 
  • 1
  • 1Like
Reactions:
This is for the triggers, and I'm thrilled to have it! There are lots of modifiers and stuff that aren't in there though. I'm not even sure there is a public list of all of the working ones.
It's just the downside of using their own scripting language for this (as opposed to some public language) and a lot of things under the hood not being exposed to us.
The game generates all used modifiers into one of its log files when it starts. This includes any made by mods active during that session.
 
  • 2Like
Reactions:
This is for the triggers, and I'm thrilled to have it! There are lots of modifiers and stuff that aren't in there though. I'm not even sure there is a public list of all of the working ones.
It's just the downside of using their own scripting language for this (as opposed to some public language) and a lot of things under the hood not being exposed to us.
Upon starting the game, it generates setup.log in the logs folder under Documents, which contains all the modifiers.

Edit: I swear the two posts above weren't there before. :confused:
 
  • 5Haha
Reactions:
Modifiers are available and generated into logs as well, you can always view them either on wiki or on GitHub library I already linked in this thread. https://github.com/OldEnt/stellaris-triggers-modifiers-effects-list/

The game generates all used modifiers into one of its log files when it starts. This includes any made by mods active during that session.

Upon starting the game, it generates setup.log in the logs folder under Documents, which contains all the modifiers.

Edit: I swear the two posts above weren't there before. :confused:
I can't believe I never knew that modifiers are dumped at the bottom of the setup log.
And to think I've been poking around stellaris code for a year.

Brb, deleting account in shame now. I have become the Organic Agenda that XT-489 Eliminators swore to destroy
 
  • 3Haha
  • 1Like
Reactions:
Thank you for this exciting dev diary. I can't wait to try out all the new modding tools added with Nemesis!

Just for curiosity's sake, will there be a way to change the name_list, ruler_title and heir_title of a specific empire with an effect script similar to set_graphical_culture or will it still be impossible to do so?
 
I just tested this (but with a hard-coded value as a stand in until 2.9) by copy-pasting the empire_limit block (and then possible_construction block) from the Titan to the Battleship. [steamapps\common\Stellaris\common\ship_sizes\00_ship_sizes.txt]

View attachment 691254

I use 40 as battleships have a fleet cap usage of 8, so if I want to restrict the fleet to 20%, 140/(5*8) = 140/40 = 3.5 = 4 battleship-sized ships permitted. However the "empire_limit" block seems to be rigid, you cant stick it in an IF statement or within potential_construction = {} without getting script errors.

With 2.9 / the ability to manipulate variables, it should be possible to emulate the empire_limit block but with more flexibility via the potential_construction block. I've quickly written up the below example (which is inserted in to a battleship ship_size potential_construction field

View attachment 691279

This itself probably wont work, as I cant check 2.9 errors, but the final example will likely end up being some scripted variation on this (or one that calls a separate scripted_effect to calculate this), making #BBs allowed for construction vary with ethos [or whatever other limit one desires], assuming I have understood @Caligula Caesar 's new export variables.
I don't think I like the idea of caps on different ship classes because it restricts a lot of freedom for the player to come up with strategies. Maybe it would be better if there only was a requirement for total amount of ships that would then determine your trade and anti piracy efficiency. You need bigger numbers of ships to 'patrol' your trade routes and occasionally 'check' ships. If all your naval cap is all battleships you would get a penalty for trade effeciency. It all depends on balance but right now there is no reason to build smaller ships once you unlock bigger hulls. (Corvettes with torpedos can be built but they aren't cost effective because you just lose too many of them.)
 
New effects to export various game values to variables have been added. These are: export_modifier_to_variable (check_modifier_value trigger also exists now), export_resource_stockpile_to_variable, export_resource_income_to_variable
Is there an ETA for these features? I use the E in ETA loosely. Any ballpark guess will do. I promise not to hold you or anyone else to it. Please?