Triggers will slow down the game because they're code. SDT dialogues aren't compiled, so a bunch of empty triggers would still eat time.
That said, if you rig SDT's dialogue system as such that it doesn't wait for character printing and instead just executes triggers (which is what DA does if you append your linename with _INSTANT, or if your line consists of only one trigger and it's a trigger that neither the game nor any of the mods know AKA line-reference trigger, a trigger that will select the next line to be played)...
It will go pretty fast.
I recall I had a discussion with WeeWillie one day about a slow dialogue...
Basically, the Bazaar has to load clothing stuff into variables and it does so by looping through a buncha stuff. This used to take about a minute. A minute of staring at a black screen waiting for the dialogue to "load".
This was fixed by adding the feature to append _INSTANT to a line name and having it just "do all the triggers" without printing text.
The result was that loading did not take long at all - about half a second or so. And that's about 300-500 or more triggers all doing various expensive stuff like loading character codes or copying large amounts of variables and saving stuff etc.
So basically, use _INSTANT for lines that have just code in them.
First off, I had no idea I can set variables to play triggers like that.
See the technical details section of this dialogue guide:
Pim_gd's Advanced Dialogue Guide (v1.01 - updated 10 December 2013)
Specifically:
7) Play the random line that was picked by...
8) First applying the set and next line attributes.
9) Then converting percent encoded characters to real characters. This is why you might have to replace % for %25, if it's followed by two hexadecimal characters [REGEX: (%[A-F0-9]{2}) ]
10) Next up, inserting any variables and variable substitutions. When dealing with variable substitutions, they are replaced in this order: FINISHES, YOUR, YOU, ME, MY.
11) The line is played, character for character. When a trigger is found, it's checked for an action. If it doesn't have an action, the content of the trigger is set to be played as the next line. If it does have an action associated with it, that action is triggered and things will happen (Mood changes, coughing, looking up or down, etc...).
Set and next line attributes go first, then percent encoding, then variables, then the line plays. As the line plays, triggers happen.
Does this set the variable to nothing? Like a NULL value?
It sets the variable to empty string.
I guess sreact# is a trigger that reffers to the line in which I'll be adding dialogue?
See your own dialogue:
slap_s0:"[HOLD][RELEASE][SLAP]Б[HOLD][OW][WINCE][ADD_TEARS][sreact0]"
It has sreact0 at the end of slap_s0, sreact1 at the end of slap_s1... so if the line to be played is determined by "slap_s" + RSC, then we just make the slap line contain the shared content + "[sreact" + RSC + "]".
Lets say I have a trigger, we'll name it "
enddayEvent", and two other triggers "
normalEvent" and "
randomEvent" and then I use it it will go to this:
enddayEvent:"[normalEvent]"
enddayEvent:"[normalEvent]"
enddayEvent:"[randomEvent]"
enddayEvent:"[normalEvent]"
Does the
randomEvent have a 1/4 chances of happening? Are there any other things I have to keep in mind for this (Like if the ordering matters in some way)?
My idea was that, at the end of each day/night, there's a chance of, lets say 1/50 to get a random event. If no event happened in a while
then the probability for one to happen increases to 1/40, and so on until there's a 1/2 chance for one to happen
Again, see the advanced dialogue guide:
(It's possible that steps 1 and 2 are reversed in order, and it's possible the checks are run only once, and the played line filtering is done later. It's not really relevant. It just does those things and you can't interrupt them.)
1) First, define the linetype that will be played. This is done by checking for if a next line is defined, and else going through a set of checks for things like pulled_up, pulled_down...
2) After having defined the linetype, get all the lines that are related to that linetype, and haven't been played yet. Now filter them based on check, mood, held and style (Speak + mouth filled is a no go).
3) If no line is found, clear the list of played lines for the linetype, then repeat step 2.
4) If no line is found after THAT check, stop trying to display a line (it's not possible, there are no lines playable).
5) If lines are found, pick a random one. Add that to the played lines.
6) If the played lines amount is equal to the lines amount for that line type, clear played lines list.
7) Play the random line that was picked by...
What this means is:
It picks a linetype to play - "enddayEvent", because that's the next line to play. Then it takes the ones of those lines it hasn't played yet, and filters them based on the constraints you have supplied. In your case, the default style is "Speak", so if her mouth is full, all the lines will be filtered out. If it has no lines left (either because all the lines were already played or because they were all filtered out), it resets the lines played list (This means that if you have 50 enddayEvent lines of which only 1 is the lucky one and they have default style or Speak style and she can't speak, the "counter" will reset!). If the lines played list was reset, it tries again. If it finds lines to play, it plays one random line out of that bunch, else it just stops.
Basically, if you need a one in two chance, duplicating your line is fine. If you need a 1 in 3 or 1 in 4 or 1 in 6, sure, duplicate!
If you need 1 in 50, use variables and da.random. I don't think the dialogue will get very slow with lots of lines (but it might, a bit), but it's still not ideal to just have 50 copies of the same frickin line.
The documentation for dialogueactions mentions how to use da.random:
Pim_gd / SDTDialogueActions / source / Documentation / For Dialogue Writers / Variables.txt — Bitbucket
da.random {read only} - returns a random value between 0 and 1 (0 <= value < 1). Example usage to make it 1-10: (you'll have to define x as "*" in initial_settings to get access to multiplication operator) [VA_SET_VARIABLE_var1_*da.random x ( 10 - 1 + 1 ) \ 1 + 1*] - formula is ( random * ( max - min + 1 ) ) + min \ 1 + 1
Now, that's how to get a neatly rounded number. You don't care about neatly rounded numbers. Here's what you care about:
eventChance = 1 / ( difficulty - rollsMade )
success = randomRoll < eventChance
Where random roll is between 0 and 1. (Which is what da.random gives!)
Let's plug in some numbers (difficulty = 50)
1 / ( 50 - 0 ) = 1 / 50 = 0.02 (2%)
1 / ( 50 - 1 ) = 1 / 49 = 0.0204 (2%)
1 / ( 50 - 25 ) = 1 / 25 = 0.04 (4%)
1 / ( 50 - 49 ) = 1 / 1 = 1 (100%)
This is the same as SDT.
initial_settings:{"difficulty":50,"rollsMade":0}
start:"Rolling... [tryYourLuck*da.random < ( 1 / ( difficulty - rollsMade ) )*]"
tryYourLuck0:"Too bad... roll *rollsMade* failed.[start]" {"set":{"rollsMade":"+1"}}
tryYourLuck1:"Hurray!"
And if you want to, say, test your dialogue, you could temporarily change difficulty to 1. Or just increase the rollsMade from the start. That beats having to duplicate or delete lines just to set the difficulty.
Of course, SDT would, if given 49 "bad" lines and 1 "good" line, give you a proper random distribution containing 1 good line and 49 bad lines. The snippet I posted would give you, hmm, well, the bad line counter doesn't reset, and even then, the good line isn't taken out of the pool if it plays.
On the other hand, SDT will happily play all of the bad lines first before allowing you to play the good line again. So if you had the good line hit first, you'd be guaranteed 49 bad rolls in a row, because it filters for unplayed lines. Making use of variables allows you to have a more fine-tuned system with regards to randomization the lines that are played. SDT's system works best for simple randomization (1/3 chance, 1/4 chance) of non-repetitive events. SDT's system also works great for playing lines that the player hasn't seen yet (Basically, to prevent her from saying the same thing over and over and over again). It does NOT work well for randomization contraptions where it's important you have the correct chances to hit something.
Does having a lot of choices for a trigger to choose from slow down the game or the dialogue? If so is it a big slow-down?
Or does it just play the first one it scans?
I am not sure I completely understand your question.
Okay, so, the thing is... when you have the step where it checks for each line if the line is playable, you can see that duplicating lines for randomness causes slowdowns. As the amount of duplicated lines grows, so does the amount of lines that SDT needs to check. The finger that goes through the list has to move through all the entries one by one, so if the list is longer, it will take longer. (The real thing of interest might be the speed of the finger, though - if the finger moves at a rate of a million lines per second, you don't care. Computers are fast.)
But... look at this construct again.
start:"Rolling... [tryYourLuck*da.random < ( 1 / ( difficulty - rollsMade ) )*]"
tryYourLuck0:"Too bad... roll *rollsMade* failed.[start]" {"set":{"rollsMade":"+1"}}
tryYourLuck1:"Hurray!"
What really happens is this.
First, this line plays:
start:"Rolling... [tryYourLuck*da.random < ( 1 / ( difficulty - rollsMade ) )*]"
The variables are replaced...
*da.random < ( 1 / ( difficulty - rollsMade ) )* - DialogueActions first fills in the values...
*0.20456123 < ( 1 / ( 50 - 0 ) )* Then evaluates per subexpression...
*0.20456123 < ( 1 / 50 )* step
*0.20456123 < 0.02* by
*0* step.
Leaving you with this line:
start:"Rolling... [tryYourLuck0]"
Which is then played, printing "Rolling... " and then moving to the next line, "tryYourLuck0".
The thing is, there's only 1 line for "tryYourLuck0".
tryYourLuck0:"Too bad... roll *rollsMade* failed.[start]" {"set":{"rollsMade":"+1"}}
That one. And SDT thus only has to check 1 line to see if it can play.
Another way to look at this is that "slap_s" + RSC does not have to "look" and "decide" whether it should be "slap_s0", "slap_s1", "slap_s2" or some other string... it just concatenates (puts together) the two and the result is what line it will want to play.
SkyHeart
specified while writing the dialogue?
Pim_gd
which covers topics such as mod integration. DialogueActions is documented separately.
.
