Stellaris Dev Diary #240 - Scripting Improvements in 3.3

[Alfray Stryke]

Santa delivers again.

Take an orange juice shot every time a modder replies.

Praise Satan Santa?

 

[Enfield_PDX]

After I read, does this imply that the release of 3.3 has no DLC included?

Anyways it's great, appreciate your effort

Apart from the updates to already released DLC, no, no DLC with this release.

 

[Caligula Caesar]

I believe, based on previous observations, that additions are performed before multiplications, and then multiplications are performed additively, so I think example_cost here would evaluate to 2 + 2 * (4 + 4) = 32.

Script values evaluate strictly in the order they are written. So 3 + 5 * 5 + 1 = 41, which is a bit jarring when you write it that way, but since it's done with different lines, usually inside modifier = { }, it actually makes most sense this way.

 

[Alfray Stryke]

I noticed `country_admin_cap_add` (and mult) still exists as a modifier. Does this still function, aka so modders can make quirky ways to deviate from the default 100 sprawl cap in 3.3?

These should still generally work as they used to, but tooltips might not display all the information they previously did.

 

[Caligula Caesar]

This is really huge. Thanks so much.

Is it theoretically possible to have "district_farming_{housing/jobs_*/buildings}_add" type modifiers in the future? Many reasons to override districts in the first place would be taken away if such modifiers existed.

It's theoretically possible, but it'd be a can of worms on the code side, because you'd be generating A * B amount of modifiers where A is the number of districts, and B is the number of jobs. And then matching them together to make them actually do what they are meant to do would be an absolute nightmare.

Script values look very useful and convenient, but I'm concerned about performance for the large and complex repeated calculations they would be the most convenient for. Is there any precalculation or caching available? Or ideally, tracking what a value's inputs are and recalculating it only when an input's value has changed?

For some of the things I'm doing, it would also be very useful to be able to use some form of every_owned_planet and similar things in a script value. count_x is not sufficient because I want to do things like add the value of a particular variable or trigger from each planet.

There isn't any caching enabled, and it is true that there's potential performance downsides if they are used uncarefully. That's part of why I was so keen to make the scripting profiler work (see here). So, for instance, today and yesterday I was substituting pop job weights with script values using a smarter trigger I'd just devised. Ideally, this'd eliminate issues where we forget to give positive weights for pops with X trait to work Y job because it'd give more resources. Now, pop jobs can be a bit dangerous, and I wasn't entirely sure about this new trigger, so I checked it out on the script profiler, and it was a bit on the unperformant side. So I had to delve into the economic system's templates to find why this was happening. (For the record, I succeeded, so in 3.4 (not 3.3) job weights will hopefully be simplified - and there will be a lot fewer bugs in them).

That's not really helpful to modders, since we haven't enabled the script profiler for the public yet. Hopefully we'll get around to that soon. But what I can say is, using script values is less costly than some of the alternatives to still have dynamic effects. For instance, if you have four different triggered upkeeps depending on some factor or other, or you make one triggered upkeep and use a script value which modifies it, then the latter will probably be more performant - especially if you can find a way to modify it based on a single factor.

I also agree on the every_owned_planet thing. We only realised this gap recently, but hopefully we'll be able to rectify it for 3.4

So can script values be used in things like empire modifiers? For instance, could I set up an empire modifier with a scaling research speed bonus based on the number of pops that have x pop modifier?

The only way to do that at the moment is something like "add_modifier = { modifier = my_mod multiplier = value:my_script_value }"

Speaking of modding, are you planning on making modyfing name lists not change the checksum? I would love to get some custom name lists for my mp larp

It'd be nice to be able to do that, but it'd probably cause OOSes. Basically, say if you add 20 leader names to the Humanoid 1 name list and then play MP, when the game picks a random leader list, on the computer with the mod, it'll have 20 more names to pick. This means that it is very likely to pick a different name (e.g. one that's in the mod but not the Vanilla version) and the game will instantly OOS because the leaders are named differently.

So does this mean 3.3 releases on monday?

No. But you can already try out the beta, which has most of the changes.

Great stuff!

Is there any way the team could find some time to write up a more comprehensive documentation of Stellaris's scripting capabilities? The modding wiki is useful, of course, but as a beginner-intermediate modder I often find myself jumping around between pages trying to piece together how a general principle works based on isolated examples, changelogs, and parsing dev diaries in order of release to determine what changes were made to the language since launch and how those changes interact with each other. Even as someone with a fair background in scripting languages, and experience with what you might call "pre-Stellaris Paradox script", it's hard to determine exactly what capabilities are available to me and exactly how to use them because there have been so many incremental changes both to the language itself and how it interacts with the underlying C++.

CW Tools is a good tool to script with. I can also refer to the log files in Documents/Paradox Interactive/Stellaris/log/script_documentation.

Aside from that, the dev diary by BlackNinja on CK3 is an interesting read, and although the details are different, a lot of aspects of it are true for Stellaris too.

 

[Caligula Caesar]

Thank you for the tips, but an actual central document would help a lot of people get into modding and might well be helpful around the office, too. If that isn't in the cards then so be it - I understand that documentation is not any programmer's favorite task and is often a hard sell to management, too - but as anyone trying to learn any language could attest, an autogenerated variable/function list without annotations describing their purpose and examples of their use (as the script_documentation files are) is not half as useful as a reference document written by a person. The VS code extension is great for reminding you of what things do while you are coding, but less useful for taking stock of exactly which knobs you can turn and which you can't; aside from that, the CW Tools descriptions are written by users rather than the people creating the scripting language, which means they may be missing small nuances or edge cases.

In other words, it would be nice to have a document which describes how entire systems within the language work overall rather than piecing things together based on descriptions of individual variables and functions. The process of compiling it might even help spot and solve problems like the ones described in this dev diary.

Someone above linked the Modding Den discord, I can only second that. More tutorials would be nice, but at present we don't have any to share.

Overall a lot of good changes for modders, good job.

I have one question: any chance we can get ability to dynamically change modifiers/properties of objects, for example adding/removing/changing triggered_planet_modifier block on districts/building etc. without overriding entire entry. Like Civilization does with its xml/sql editing. It would be especially beneficial to mod compatibility.

It's complicated. Can't promise we'll be able to add that.

Stellaris Modding Den ticket, free of charge.


I can tell you that issues with AI weights were enough for me to not implement AI support for my modded features (AI would never use them).

Yeah there were a few more I didn't mention. For instance, in technologies, the base was 100 instead of 1, so if you wrote "weight = 10" then that meant you were setting it to 10% as likely not 10x as likely. And writing "factor = 1" as the basic number didn't always mean the same thing, which could be a bit problematic. I'm very glad we have a unified system now.

Is there going to be a DLC or expansion that comes with this update?

Also, as always, please add an expansion planner for Branch Offices.

No. A branch office expansion planner would be nice, though.