1. Stellaris
  2. News

Stellaris News

Stellaris megastructures - a quick guide

So, you want to know about Stellaris megastructures? These gargantuan feats of engineering were first introduced in the first Stellaris DLC - Utopia - and range from habitats and gateways, to more specialised structures such as Dyson Spheres, giant art galleries, and a device that can destroy the entire galaxy.


Some megastructures - like Ring Worlds - will spawn naturally even if you don't own any of the expansions, and you'll be able to repair them if you have the right tech. You won't be able to research and build any new ones though apart from gateways without some DLC. Quite a few were included in Utopia, for example, but MegaCorps, Federations, and Nemesis introduced new options as well.


Other expansions, such as Distant Stars and Synthetic Dawn, also interact with the megastructure mechanics in some way - the former introduced the L-Gate cluster, for example, while the latter will cause more natural Ring Worlds to spawn in a specific place. We've put together this quick guide to Stellaris megastructures, we hope you find it useful, although for a more thorough breakdown you can also refer to the official Paradox Wiki, which we've drawn a lot of information from.


Read the rest of the story...


RELATED LINKS:

Stellaris cheats - a guide to Stellaris console commands

The best Stellaris DLC - a complete guide

New Stellaris update will let you play a race of decadent Star Wars-style clone troopers

Stellaris Dev Diary #222 - Moddability Updates in Lem

by Caligula

Welcome to another Stellaris Modding Dev Diary! Today, I’ll be talking you through some of the new scripting language features in the upcoming 3.1 patch.

We have already mentioned that Traditions are considerably more moddable now with the new system, with far less heavy lifting needed in the gui and loc files. I can also confirm that you can, for instance, now script in tradition trees that only become available if you make certain decisions during the game. But today, the main focus will lie on variables.

[h3]Variables[/h3]

I mentioned last time that we have been looking to do more with variables. In the last patch, several more ways to save various bits of information in the game were added, but the biggest missing one was an easy way to get trigger values, like for example the number of pops on a planet. You also were still quite limited in where you could use variables, especially compared to PDS’ newer games like CK3. Also, the syntax for using them was not quite ideal, in many cases.

With 3.1, we have greatly increased the power of variables. First of all, the format: previously, when you wanted to get the value of a variable, you had to refer to… well, the variable itself, and that was all. Now, you can do a few more things:
    value = my_var                                 #gets the value of my_var variable set on the current scope

value = from.capital_scope.my_var #gets the value of the my_var variable set on from’s capital

value = trigger:num_pops #gets the number of pops in the current scope

value = from.capital_scope.trigger:num_pops #gets the number of pops in from’s capital

So you can do dot scoping, which saves a lot of ugliness, and is a big improvement as it is. And as you can see, you can also refer to triggers, with trigger:. This will support any trigger checking a number and just a number, with no { }.

(Note: the previous, ugly format for copying variables across different scopes has been removed. The one where you'd specify "value = { scope = x variable = y }")

3.0 already had an effect, export_trigger_to_variable, but it only worked with fleet_power. That was the prototype; the functionality has been expanded to all such triggers. Importantly, that effect lets you get values from triggers that are a bit more complex, with { }, that are still comparing a single number:
    export_trigger_value_to_variable = {
trigger = num_assigned_jobs
parameters = {
job = miner
}
variable = num_miner_jobs
}

3.0 also, to mention it again, added a bunch more ways to get game values such as modifier numbers and resource stockpiles to variables. It also added a few more places where you could use them: multipliers in add_resource and add_modifier, for instance. With 3.1, we have added a lot more things that you can use a variable for:

  • As values in triggers checking single numbers, e.g. "num_pops > my_variable", "intel = { who = from value < trigger:num_pops }"
  • As values in effects using a single number, e.g. "add_experience = my_variable".
  • As a multiplier parameter in triggered resource tables (e.g. in a building):
     resources = {
category = planet_buildings
cost = {
trigger = { }
minerals = 100
}
multiplier = my_var/owner.trigger:num_pops
}
  • In MTTH/AI Chance modifiers:
     ai_chance = {
factor = 1
modifier = {
add/factor = my_var/trigger:num_pops
is_variable_set = my_var
}
}
  • add_modifier now has a time_multiplier as well as a multiplier parameter, you can use it there. E.g. for death cults, this is used to apply a modifier for 10 years X edict_length_mult
  • In ordered_script_lists: a feature yoinked from our newer games. I’ll let the trigger docs entry explain:
ordered_owned_fleet - Iterate through each fleet owned by the country - executes the enclosed effects on one of them for which the limit triggers return true. Picks the specific object according to the order specified (position 0, order_by = trigger:num_pops would run the effects on the X with the most pops)

ordered_owned_fleet = {
limit = { }
position =
order_by = /trigger:
inverse = yes/no (default: no - if yes, then 0 is lowest rather than highest)

}

Supported Scopes: country

If your variable is too exact a number, you can now use round_variable_to_nearest to round its value to e.g. the nearest multiple of 10.

A summary of these functionalities have been added to an information file in the events folder (and attached to this post). Also, I could well imagine further expanding on these usages of variables, so it’s quite possible there will be even more coming along these lines in future. The changes have already proven extremely useful to us, e.g.:

  • Improving Death Cult rewards: cut about 1000 lines of script and still ended up with the new version taking more factors into account to determine the adequate reward for you!
  • Fixing Golden Rule cash payouts: the previous solution was to fudge the numbers and give you an amount with a rather tenuous connection to the actual pay-in. This is no longer necessary.
  • Improving Federation Science Leadership Challenge: adding the actual number of techs and repeatable techs you have researched as a factor
  • And more.


[h3]Sprite Sheet Changes[/h3]

That was already quite a lot, but there’s a few more things that I’d like to highlight. Firstly, certain older elements of the game used sprite sheets for their icons - a system where a list of icons would all be in a row on one image file, and we’d specify that we’d want to use, say, the 5th icon on the list. We had a few issues with these inhouse (the colony automation button currently accidentally being a robotic cow springs to mind), and modders have pointed out that they are a pretty bad overwriting bottleneck, since only one mod can overwrite the sprite sheet at a time, and therefore only one can add extra types of that object that add new graphics at a time.

We figured out a way to change index references to icons in sprite sheets into normal key references, which meant that we could convert these elements of the game to use string references to sprites (with no need for new icons to be inside a sprite sheet). This got rolled out to the likes of army types, colony automation types, bombardment stances, and (with great difficulty!) ship sizes.

An example:
    spriteType = {
name = "GFX_ship_size_military_1"
sprite_sheet_sprite_type = "GFX_ship_sizes"
default_frame = 2
}

In the case of ship sizes, it was a bit tricky, since the icon_frame index number then specified which icon it would use on multiple sprite sheets. In the end, we left that system in place for starbases (since very few tend to add a new type of starbase) and made the line “icon = ship_size_military_1” tell the game to refer to several sprite keys: GFX_text_ship_size_military_1, GFX_ship_size_military_1, GFX_ship_size_military_1_top, GFX_ship_size_military_1_top_damaged

This will need some updating for mods which change the affected objects, since the old format no longer works, but in the long term it will hopefully solve a lot of compatibility headaches!

[h3]Randomness[/h3]

Some have noticed that, in certain cases, the randomness of script functions such as random_list is not very random. Specifically, events fired from on_game_start had this issue (and various other on_actions, but that was the one that hurt the most). This was pretty unfortunate, since this effectively meant that certain things that were meant to be different each game... simply were not. Relatedly, we also revisited some more longstanding issues like where if you used while loops or every_x loops, each time the effect happened within that loop, the random result would be the same. (As in 25x random_list resulting in 25x the same result rather than 25x a random result).

We fixed this quite exhaustively:
  • The lack of randomness in on_actions like on_game_start is fixed. If we in future make the mistake that caused this to happen again, the game will warn us, so hopefully it is banished for good.
  • While loops and every_x loops have improved randomness
  • For good measure, we added a reroll_random effect


[h3]Other Cool Stuff[/h3]

On another note, we can now add triggered pop modifiers to traits, so for instance, you can add a trait that gives a bonus on one planet class and a penalty on another. The potential that this unlocks is quite considerable - for instance, it allowed us to stop using the somewhat unintuitive (and eminently cheeseable) stopgap solution of giving Void Dwellers two traits, and instead giving them one that applies differently depending on what sort of planet they are on.

As some have noticed, the Clone Army origin does several cool, new things that we haven’t really explored in the game before. A lot of what we added for it could have further cool uses in the future, for instance:

  • You can now gender-lock species
  • You can set an empire limit on how many instances of a building you can build. (And alter it during the game).
  • A game rule, “should_force_decline_species”, has been added. It will make a species for which it returns true decline on a planet, triggering an alert based on whatever tooltip is specified in the game rule. It is also hooked up to stop pops from migrating/being resettled/etc to a place where they would immediately start declining.


Finally, we added a bunch of new effects, triggers and modifiers, as usual. A couple to highlight are:

  • set_visited = - reveals a system to you, without you having surveyed it
  • set_saved_date - lets you save a specific date (can be in the future) so that you can use it in locs, similar to variables: [This.my_saved_date].
  • Technically, the last effect is actually adding a _flag, so the standard flag effects and triggers have been ported over to all scopes
  • You can now use [loc] commands in button effects, which apparently will be very useful for dynamic modded UIs
  • You can define descriptions for districts, buildings, jobs and special projects through desc = { text = X trigger = { Y } } now. They also now take loc commands.
  • We deleted has_non_swapped_tradition and has_tradition_swap, and consolidated them into has_active_tradition. Modders: do a search-replace!
  • Every scope that lacked script flags (e.g. country_flag) now has them. Also, variables work in all scopes now too.
  • Note for updating mods: count_diplo_ties is now count_relation, count_armies is count_owned_army or count_planet_army (depending on the case). any/every/random_mining_station/research_station have also been removed, because they were nonsense. Use simply mining_station/research_station/orbital_station scope change instead. Also, observation_outpost no longer takes a "limit", but you can say "exists = observation_outpost" as compensation.

Adding all these new functionalities has been a boon for us in the Custodian team, and we are gradually rolling them out to older parts of the game which can benefit from them. It’s something I look forward to doing more of in future, and equally, I am excited (and, I’ll admit, a tiny bit afraid) to see what modders will do with them!

One last thing: the old trigger_docs.log has now been deprecated, and instead we now have a more wieldy and more comprehensive script_documentation folder, the contents of which are attached to this post.

And as some of you are probably aware, we did some early access for Modders for the Nemesis update. We had ~10 mods update on release day, servicing around 1.6 million subscribers, overall we were very happy with the results and the community reaction, and if this continues to go well we’re looking to gradually expand this experiment to more of the Modding Community. For Lem, we’re looking to add another 10-ish Modders to the early-access experiment. If you’re interested you can fill out the Modder Early Access Request form.

DD#221 - Balance and Quality of Life Changes

Hey folks,

I’m Alfray Stryke, a member of the QA team for Stellaris. As part of the Custodians’ work on the 3.1 “Lem” patch, as mentioned in Dev Diary #215, the team has done a balance and Quality of Life pass on various features throughout the game and we’d like to highlight some of the more harder hitting changes. This is not a complete list of all changes, and may contain some not-final numbers. As a reminder, the changes to the Necroids Species Pack were covered in Dev Diary #216, and all of these changes will also be included in the Lem update.

[h3]Void Dwellers[/h3]

We’ve been aware that the implementation of Void Dwellers of having two separate traits, one positive and one negative resulted in behaviour that we weren’t happy with - in particular being able to gene-mod the negative aspects of the trait out of existence. To solve this we’ve made some changes to how the traits work:

There is now only a single Void Dweller trait, so it can’t be exploited via genetic modification of your species.
The modifiers on the trait itself have changed, previously it gave:
  • +15% Resources from Worker and Specialist jobs & -10% growth speed (for the positive version)
  • -60% growth speed (for the negative version)

The new version of the trait is now:
  • +15% Pop Resource Output on Habitats.
  • -15% Pop Resource Output on Non-Artificial Worlds.
  • -10% Growth Speed
  • -30% Happiness on Non-Artificial Worlds.
The new, improved, Void Dweller trait with its modifiers.

What this means is your Void Dwellers pops are most productive and happiest on habitats, have their bonuses removed on ringworlds and have production and happiness penalties if they settle on planets (best to leave those for immigrants or robots!)

[h3]Shattered Ring[/h3]

So before you grab your plasma-pitchforks (yes, plasma-pitchforks are canon now), rebalancing the Shattered Ring origin is something the team has been discussing for a while. We’ve gone through various iterations on decreasing the initial power of the origin, while keeping the player fantasy that it provides in mind and eventually settled on having the progression of the Shattered Ring resemble that of the Remnants origin.

The Voor Technocracy, showing off the Shattered Ringworld Segment as a homeworld.

The shattered ring itself supports the following district types:
  • City, Hive & Nexus - housing depending on your empire type.
  • Industrial - where valuable consumer goods and alloys can be manufactured.
  • Trade - where clerks turn a tidy profit and artisans run their workshops.
  • Generator (not pictured) - where hive-minds and machine intelligence power their infrastructure. Note that Generator and Trade districts swap depending on the owner of the Shattered Ring, much like Commercial and Generator Segments on a ringworld.
  • Agricultural - where food is grown for those that eat it.
  • Mining - more on that in a moment...

Once all the rubble has been cleared out, there’s space for 25 of these districts.

So you might be wondering, “Are those mining districts on my ringworld? What am I mining?”

Well dear reader, the answer is the ring itself!

Mining districts, aka tunnels filled with valuable minerals and alloys.

As a civilization that has only known life on the ring prior to achieving spaceflight, the only resources available to you were those that made up the ringworld itself. Luckily ruined ringworlds are massive and can spare some missing broken materials without falling into their local sun.

As such your mining district on the shattered ring replaces the regular miner jobs with scrap miner jobs with a base job output of 2 minerals and 1 alloy per month.

Of course, as was alluded to above, we wanted the progression for the shattered ring to resemble that of the relic world from the Remnants origin. So once you’ve cleared all the debris from the shattered ring and researched the appropriate technology you can repair it into a fully functioning ringworld segment.

Of course, sometimes a bit of home repair work needs to be done.

Upon completion of this monumental task, the districts on the shattered ring are upgraded into their respective ringworld districts at a 5:1 ratio - so 5 agricultural districts become 1 agricultural segment. Since fixing up the ring means you’ll no longer be clearing out material, the mining districts are removed and the ability to construct research segments is added.

[h3]Ecumenopolis QoL Changes[/h3]

Something we’ve received a lot of feedback on is that when a world is transformed into an Ecumenopolis is the assignment of industrial districts.

Prior to 3.1, all of the industrial districts were assumed to be devoted to alloy production and thus converted into foundry arcologies. No more, in 3.1 industrial districts will convert based off of the planetary designation:
  • With the “Foundry World” designation, industrial districts will convert into foundry arcologies, at a 2:1 ratio
  • With the “Factory World” designation, industrial districts will convert into factory arcologies, at a 2:1 ratio.
  • With any other designation, including the “Industrial World” designation, industrial districts will convert into both foundry and factory arcologies, at a 4:1:1 ratio.
Earth, a bygone relic of a time long past, ready to be restored anew.

Earth, restored anew! Note that the local governing algorithm did not assume all industrial capabilities should be focused on supporting the Custodianship Navy.

Another change we’ve implemented is the Arcology Project ascension perk and decision to restore relic worlds into ecumenopolises is now accessible to Rogue Servitors. In addition, the leisure arcologies that would normally be present have been repurposed for housing bio-trophies in luxurious towering arcologies.

Pampering will be provided at Floor 314, Room 15 at 9:26 am.

[h3]Assorted QoL Changes[/h3]

As mentioned above, the planetary designation for consumer goods has been renamed to Factory World, because we’ve added an Industrial World designation.

Multiple planetary designations for your various needs

The new Industrial World designation is ideal for planets where you don’t want to focus the Industrial districts on a single job type, instead providing a minor upkeep discount to both Artisan and Metallurgist jobs.

Industrial World Designation

Subversive Cults (MegaCorps with both Gospel of the Masses and Criminal Syndicate) no longer have access to the Temple of Prosperity. Instead, they can now establish a Subversive Shrine in their branch offices - increasing both Spiritualist ethics attraction and crime on the planet.

Subvert expectations with deals so good they’re criminal!

With that I’ll pass things over to Gruntsatwork to discuss some of the changes we’ve made to civics!

----

Hello everyone.

I am one of Game Designers currently working on Stellaris and on the Custodian Team. While we have been busy with radical changes here and there, new civics and origins, we also wanted to have some more tame but no less important balance changes for our already existing civics, specifically for our outliers and those we felt under- or especially over-utilized.

The following lists all the civics we felt needed a substantial lift up

[h3]Regular Empires[/h3]
  • Beacon of Liberty: Gave +15% produced Unity -> Now ALSO also gives -15% Empire Sprawl from Pops
  • Imperial Cult: Gave +1 Edict cap -> Now gives +2 Edict cap
  • Idealistic Foundation: Gave +5% Happiness -> Now gives +10% Happiness
  • Environmentalist: Gave -10% Consumer Goods Upkeep -> Now gives -20% Consumer Goods Upkeep
  • Parliamentary System: Gave +25% Faction Influence -> Now gives +40% Faction Influence
  • Efficient Bureaucracy: Gave +10% Admin Cap -> Now gives +20% Admin Cap
  • Nationalistic Zeal: Gave -10% War Exhaustion Gain and -10% Claim Cost -> Now gives -20% War Exhaustion Gain and -15% Claim Cost
  • Functional Architecture: Gave -10% Building and District Cost, -10% Building and District Upkeep and +1 Building Slot -> Now gives -15% Building and District Cost, +2 Building Slots, Upkeep reduction removed


[h3]Hive-Minds[/h3]
  • Subspace Ephase: Gave +15% Naval Capacity -> Now gives +20% Ship Speed and ALSO gives +15% Naval Capacity
  • Divided Attention: Gave +10% Admin Cap -> Now gives +20% Admin Cap


[h3]Machine Intelligences[/h3]
  • Constructobot: Gave -10% Building and District Cost, -10% Building and District Upkeep and +1 Building Slot -> Now gives -15% Building and District Cost, +2 Building Slots, Upkeep reduction removed


We hope those changes, while strictly number tweaks, will give those civics a breath of fresh air and increase their appeal to the wider player-base because, “oh, shiny new numbers” is one hell of a drug.

Now sadly, only strengthening the civics we felt undervalued or under-used doesn’t solve all issues, so we also introduced some slight nerfs to the 2(3) biggest offenders in terms of being “must have” civics.
  • Slaver Guilds : Reduced enslaved population from 40% to 35%
  • Indentured Assets: Reduced enslaved population from 40% to 35% (Megacorp civic)
  • Technocracy: Added 1 Consumer Goods upkeep to Scientist Jobs that create unity because of Technocracy

As you can tell, for the slaver guild civics, this change is relatively minor, compared to the Technocracy nerf. The goal here is to make those 3 civics slightly less good. We have no intention of nerfing them into the ground. Our goal here is to move them from “the best pick, every time” to “could be best pick, depending on circumstances”.

We will be following your feedback here and over all other platforms very closely as well as our own telemetry and we will keep adjusting and tweaking the civics as we go on.

As an extra note, we know that there are several other civics that definitely need a pick me up, we will be looking into them as well, but not for the Lem update.

That’s everything from us this week! Thanks for reading and we’ll be back next week diving into more changes in the Lem Update.

New Stellaris update will let you play a race of decadent Star Wars-style clone troopers

Grand strategy game Stellaris is gearing up for another free update next month, which will include new content for past Stellaris DLC in addition to the usual round of fixes and improvements. Last week we saw some new content coming to the Plantoids Species pack, and this week's dev diary explores new content for the Humanoids Species pack.


The new content will span two new civic options, and one new origin and the latter will let you play as a cast-off army of clone soldiers. Abandoned by their creators, clone soldiers can't breed - instead, they can only replenish their numbers via a new building called an 'ancient clone vat'. As a species, you'll be quite proficient at waging war, but your leaders will be short lived and you won't be able to genetically modify your species.


This new origin can combine with either - or both - of the new civics, Masterful Crafters and Pleasure Seekers. The former replaces the artisan job with a new artificer role, which along with creating consumer goods also gives trade value and engineering research. The latter turns your race into a bunch of decadent thrillseekers, and offers a big happiness boost at the expense of increased consumer goods upkeep.


Read the rest of the story...


RELATED LINKS:

Stellaris' 3.1 'Lem' patch drops next week

Stellaris megastructures - a quick guide

Stellaris cheats - a guide to Stellaris console commands

Nakama Infrastructure - Changes to Cross-Store PC Multiplayer

Hello everyone!

I’m here to announce a surprise update to the game. But before we get our expectations blown out of proportion, this update contains only a change to our Multiplayer Backend. We are rolling out the Nakama infrastructure to host cross-store PC multiplayer.

With this update we are completely removing our internally developed Multiplayer backend (PDXMP) that is currently used by all stores excluding Steam, which uses the built in Steam backend. The reason for this change is because we believe that Nakama, developed by an external partner, is more stable than our current in-house solution.

What this will mean for you as a player is hopefully nothing different from how you normally play the game. This update should not affect your single player experience whatsoever and if you have the game installed on Steam and don’t have friends on other platforms you won’t be affected by the Multiplayer change either.

The only people this will affect are those of you that play the game on Steam and want to play multiplayer with your friends that have bought Stellaris on other platforms (such as the Microsoft store). You might already know about the crossplay Steam Beta branch we have had in place prior to today, but from this update and forward you will now be able to launch the Crossplay version straight from the launcher!

All you have to do is go into “Game Settings” in the launcher and scroll down to “Cross Store Multiplayer” and click “Launch” as shown below:



If for some reason that doesn’t work, you can also add “-nakama” as a launch option in Steam. Do this by Right-Clicking Stellaris, Going to Properties, General Tab and adding “-nakama” to the Launch Options. This will force the game to switch from the Steam multiplayer backend to the new one for crossplay purposes!




#################################################################

######################### VERSION 3.0.4 ###########################

#################################################################


###################

# Performance and Stability

###################

* Replaced PDXMP multiplayer backend layer with Nakama.

#################################################################

Thank you for playing Stellaris, and if you experience any issues with Nakama Multiplayer please report them on the Bug Report forums!