Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
This topic has been pinned, so it's probably important 
Discussions Rules and Guidelines
1 
Report this post
Hopefully we will see some high-quality scenarios using the new events lab soon. *looks at brothercake*
And a third one too ... something very special ;-)
Let's say you're making a WWII scenario and you've got a trait called "Invasion of Poland".
Create a new event, and start with the event settings: event counter threshold = 0, times event can trigger = 1, reset event counter when fired = NOT checked
Add a global condition with a Tech Trigger, and specify the name of the trait as the trigger (in this case "Invasion of Poland").
Add a country condition with the "Country name" variable, and set the name of the country it should apply to (in this case "Poland").
Add an outcome, then in the variable selection dialog you'll need to check "Show Advanced", and then find the "Additional infections" variable. Select that variable, and then give it a numerical value -- it must be at least 1, or you could use a random value like random(1, 100)
And that's all there is to it -- when the trait is evolved, the specified country will be infected :-)
Setup a repeating monthly event (event counter threshold = 28, times event can trigger = -1, reset event counter when fired = checked), then define the following outcomes:
1 - Custom global variable 1 = 1 - (0.5 * infected percentage)
2 - Custom global variable 1 += (random(0, 4) - 2) / 10
3 - Genetic drift multiplier = Custom global variable 1
Then play at Mega-Brutal -- and the cost of every trait will change every month :-)
For example, a trait that costs 20 points might be 14 a month later, then 27 the month after that, then 19 ... and so on, throughout the whole game.
It works by re-purposing genetic drift. The first equation cancels it out, then the second applies some randomisation to increase or decrease the result.
However it does have some biases, because genetic drift is a curve, whereas the outcome equation can only define a straight line. So costs will be generally lower towards the start and end of the game, but higher in the middle.
IMPORTANT NOTE: repeating events effectively lock-out the cycle, so if you use this event:
- any other repeating events with a lower counter threshold will stop this one from firing
- any other events with a higher counter threshold will never fire
So basically, avoid either of those things if you're using this event.
Also, can you make an example where 1 of 4 effects is randomly chosen at the beginning?
Now, let's say you've got a repeating event which fires every 7 days and resets the clock. As soon as the clock gets to 7, the event fires, and the clock goes back to 0. When it gets to 7 again, the event fires again, and the clock resets again, and so on.
So if you have a second event that fires after 14 days, that event will never fire, because the clock never gets higher than 7. All events are synchronised by the same clock, so every time any event resets it, it goes back to 0 again.
If you don't reset the clock, then it will carry on counting. But that means the synchronisation of repeating events will no longer be regular. If the event fires after 7 days and doesn't reset the clock, well 8 also qualifies as "after 7" so the event will immediately fire again, and again at 9, and every day until the clock is reset.
The general rule of thumb is -- don't have repeating events. But if you really need them, then make sure you understand their impact on the clock :-)
Alternatively, if you need events that fire at regular intervals without resetting the clock, you can synchronise them to "days since game start", however the down-side of that approach is that you'd need a separate event for each time it should fire (eg. an event that should fire every 28 days for 2 years would require 26 separate events).
Event A would have a 1 in 4 global condition -- "if random(1,4) = 1" -- and then three global event untrigger conditions -- "if untriggered(Event B), and untriggered(Event C), and untriggered(Event D)".
Then each of the others would be the same random chance, with corresponding untrigger conditions (eg. Event B fires if A, C and D haven't fired).
The relative probabilities of those events are not quite the same, but it's close enough for most practical purposes.
However there is a chance that none of them will fire on the first day. If none of them fire on the first day, then they'll all be evaluated again on the second day, and every day until one of them fires.
There are ways of evening or further-biasing the probabilities, and/or making sure at least one of them fires on the first day, but that's more complicated than it's worth :-)
In fact if you do that, but leave the base transmission amount higher than 0, then you'll have the option of bringing it back later.
When transmission is off, it gets turned on again whenever any traits adds to that transmission amount. But this is relative to the base transmission. So if you set (say) sea transmission to off and base sea transmission to 1 (or another value), then you can re-enable it simply by adding a trait that adds sea transmission.
Edit: Making an event that closes air and sea ports when the country is fully infected seems to do the trick.
I've used the method I'm describing for land transmission, and it's completely effective there, but I've never used it for sea or air without also closing the ports.
You could try setting transmission to a big negative number, like -99999, that might do the job. But if closing ports its okay, then that would be most reliable.