TUXDB - LINUX GAMING AGGREGATE
 NEWS TOP_PLAYED GAMES ITCH.IO CALENDAR CHAT WINE SteamDeck
 STREAMERS CREATORS CROWDFUNDING DEALS WEBSITES ABOUT
 PODCASTS REDDIT 

 

SUPPORT TUXDB ON KO-FI

MENU

ON SALE

New Twitch streamer aggregation implemented (#FuckTwitch) due to Twitch's API issues (more info on my Discord )


Name

 Stellaris 

 

Developer

 Paradox Development Studio 

 

Publisher

 Paradox Interactive 

 

Tags

 Strategy 

 

Simulation 

 

Singleplayer 

 

Multiplayer 

Release

 2016-05-09 

 

GameBillet

 33.97 /

 

 

Steam

 9,99€ 8,74£ 9,99$ / 75 % 

 

News

 504 

 

Controls

 Keyboard 

 

 Mouse 

 

Players online

 12062 

 

Steam Rating

 Very Positive 

Steam store

 https://store.steampowered.com/app/281990 

 

How long to Beat

Main Story

 18 Hours 

 

Main Story + Extras

 27 Hours 

 

Completionist

 40 Hours 

 

SteamSpy

Peak CCU Yesterday

  

Owners

 2,000,000 .. 5,000,000 +/-  

 

Players - Since release

  +/-  

Players - Last 2 weeks

  +/-  

Average playtime (forever)

 5376  

Average playtime (last 2 weeks)

 385 

Median playtime (forever)

 2822 

Median playtime (last 2 weeks)

 450 

Public Linux depots

 Linux [153.28 M] 


DLC

 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 




LINUX STREAMERS (55)
futureisopenbiffditlinuxlikeabossscork661
ozonedtwsplitshockvirusgamingonlinuxseiferfyu
beniwtvpipninafoxmuldzonlytworoads
gerasmuscanadianbluebeerhexdsldeadlinux
pnomolosmonochromagicdarwinsswaggersakuramboo
darkmavrikcorrgancypher0n3wyldphyr3
choub24linuxmindfreeman42xgjouersouslinux
jenshaesirsamsairobotmaster1nusuey
hamishtpbthebloodyironmonstannerdavidphysicscriminal
abyssusjgjm1976tatumkhamunlionheartv80
sagitario73from_gehenna_to_streamjaimejouercastsax850
Despotjoshdancing_ghostsiaspidemfuafoa
pip0uneoskudebananas369redstonelp2
jujut8disk1of5spookyzalost




Stellaris Dev Diary #182 : The Perils of Scripting and How to Avoid Them

"Hi everyone! I am Caligula, one of Stellaris Content Designers, which means that I do a variety of tasks based around narrative writing and scripting - scripting being our term for doing things that is somewhat similar to programming, but without changing the source code. In other words, I do what modders do (though I have the significant advantage of also being able to peek into the source code and change it around when needed). Every Content Designer has their niche, and mine is that when a particularly complicated system needs to be scripted in (or, more frequently, is giving some sort of trouble - the War in Heaven still gives me nightmares...), I step into the breach.

Now, we have a lot of exciting stuff to show off in the weeks and months to come, but for today, inspired by some questions that were asked after the last dev diary, Im going to be writing about the technical side of scripting for modders and aspiring modders, specifically with an eye on what can cause performance problems and how to avoid making bad scripts.

The Stellaris scripting language is a very powerful tool, and a lot can be done with it, but first of all, a note of caution: just because something is possible, does not mean it should be done. I cant really stress this enough, because (and I speak from experience here) this attitude will almost certainly end up causing both performance issues and unreadable scripts that you will not be able to disentangle six months later when you realise some part of it is broken. Though it should be borne in mind that doing something in code is, by definition, faster: in code, you can check a single function and be done with it, but if you want it to be accessible through script, theres a fair few necessary functions it has to go through before you get to checking your function (turning the line of script into a code command, checking whether its used in the right scope, etc etc) - hence why some things are hardcoded, and also why hacky solutions to problems can end up being quite bad. So, the first question to consider is, should I really be doing this?

But who am I kidding, Im speaking to modders here, so of course you will do it :D So without further ado...

[h2]What causes performance issues?[/h2]

Every time you run a check or execute an effect, this will take a very tiny amount of your computers processing power. With a few exceptions that should be used sparingly (Ill get to those later), this is totally fine and is needed to do anything at all. It is when the check is repeated often, over lots of objects, that problems happen. In practice, this usually means pops are the cause, though running something across all planets in the galaxy is also a pretty bad idea.

As a first step, when possible, it is a good idea to control when your script is run. The best way to do this is by setting where events are fired and using on_actions (or firing events from decisions and the like) wherever possible, instead of mean time to happen or, even worse, just setting an event to try and fire every day. If a degree of randomness is needed, one could also fire a hidden event via, say, a yearly pulse and then firing the actual event you want with a random delay (for an example, check out event action.220). "

If you wanna read the full post, have a read here!


[ 2020-09-03 11:39:36 CET ] [ Original post ]