▶
Stellaris Dev Diary #204: Scripting Language and Moddability Improvements
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 = }. It turned out that there were quite significant variations as to what 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.
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, Ive 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:
Inhouse, we made the UI by assigning a function to buttons in the source code. But theres 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!
[ 2021-03-11 14:15:13 CET ] [ Original post ]
"Hi all! Im Caligula, our resident scripting language magician. As someone who works with our scripting language - both using it and improving it - on a daily basis, Im 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. Ill 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.
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 =
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, Ive 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 variables 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
- 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 youd 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 hasnt been set.
- 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.
Button Effects
Inhouse, we made the UI by assigning a function to buttons in the source code. But theres 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 =
and win = yes now exist. Im 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 wasnt 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
- Its 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
- Theres quite a lot of new on_actions, and you can make your own ones with fire_on_action effect
- And a lot more.
[ 2021-03-11 14:15:13 CET ] [ Original post ]
Stellaris
Paradox Development Studio
Developer
Paradox Interactive
Publisher
2016-05-09
Release
GameBillet:
10.50 €
Game News Posts:
542
🎹🖱️Keyboard + Mouse
Very Positive
(119848 reviews)
The Game includes VR Support
Public Linux Depots:
- Linux [153.28 M]
Available DLCs:
- Stellaris: Infinite Frontiers eBook
- Stellaris: Plantoids Species Pack
- Stellaris: Leviathans Story Pack
- Stellaris: Utopia
- Stellaris: Nova Edition Upgrade Pack
- Stellaris: Galaxy Edition Upgrade Pack
- Stellaris: Anniversary Portraits
- Stellaris: Synthetic Dawn
- Stellaris: Apocalypse
- Stellaris: Humanoids Species Pack
- Stellaris: Distant Stars Story Pack
- Stellaris: MegaCorp
- Stellaris: Ancient Relics Story Pack
- Stellaris: Lithoids Species Pack
- Stellaris: Federations
- Stellaris: Necroids Species Pack
- Stellaris: Nemesis
- Stellaris: Aquatics Species Pack
- Stellaris: Overlord
- Stellaris: Toxoids Species Pack
- Stellaris: First Contact Story Pack
- Stellaris: Galactic Paragons
- Stellaris: Astral Planes
- Stellaris: Expansion Subscription
- Stellaris: The Machine Age
- Stellaris: Cosmic Storms
- Stellaris: Grand Archive
- Stellaris: Rick the Cube Species Portrait
Explore a vast galaxy full of wonder! Paradox Development Studio, makers of the Crusader Kings and Europa Universalis series presents Stellaris, an evolution of the grand strategy genre with space exploration at its core.
Featuring deep strategic gameplay, a rich and enormously diverse selection of alien races and emergent storytelling, Stellaris has engaging challenging gameplay that rewards interstellar exploration as you traverse, discover, interact and learn more about the multitude of species you will encounter during your travels.
Etch your name across the cosmos by forging a galactic empire; colonizing remote planets and integrating alien civilizations. Will you expand through war alone or walk the path of diplomacy to achieve your goals?
Main Feature
Featuring deep strategic gameplay, a rich and enormously diverse selection of alien races and emergent storytelling, Stellaris has engaging challenging gameplay that rewards interstellar exploration as you traverse, discover, interact and learn more about the multitude of species you will encounter during your travels.
Etch your name across the cosmos by forging a galactic empire; colonizing remote planets and integrating alien civilizations. Will you expand through war alone or walk the path of diplomacy to achieve your goals?
Main Feature
- Deep & Varied Exploration.
- Enormous procedural galaxies, containing thousands of planets.
- Explore Anomalies with your heroic Scientist leaders.
- Infinitely varied races through customization and procedural generation.
- Advanced Diplomacy system worthy of a Grand Strategy Game.
- Ship Designer based on a vast array of technologies.
- Stunning space visuals.
MINIMAL SETUP
- OS: Ubuntu 20.04 x64
- Processor: Intel iCore i3-530 or AMD FX-6350Memory: 4 GB RAM
- Memory: 4 GB RAM
- Graphics: Nvidia GeForce GTX 460 or AMD ATI Radeon HD 5870 (1GB VRAM). or AMD Radeon RX Vega 11 or Intel HD Graphics 4600Network: Broadband Internet connection
- Storage: 12 GB available space
- OS: Ubuntu 20.04 x64
- Processor: Intel iCore i5-3570K or AMD Ryzen 5 2400GMemory: 4 GB RAM
- Memory: 4 GB RAM
- Graphics: Nvidia GeForce GTX 560 Ti (1GB VRAM) or AMD Radeon R7 370 (2 GB VRAM)Network: Broadband Internet connection
- Storage: 12 GB available space
GAMEBILLET
[ 6085 ]
GAMERSGATE
[ 3241 ]
FANATICAL BUNDLES
HUMBLE BUNDLES
by buying games/dlcs from affiliate links you are supporting tuxDB