Can we add the special character list that was in the previous guide?
%22 = "
%2A = *
%3A = :
%0A = Text continues on a new line (equivalent to hitting 'Enter' in word processing).
Here you can see, that you can trigger the *FINISHES* variable just like any other variable, the only difference? You do not set it via {"set":{... . Instead you set them by writing finish*number*:"Value". This enables linear progression without checks. This can be used in the current audiologue modding template!
Some more info: You set the "Value" of the *FINISHES* variable by writing finishes0:"Value", "Value" can be a number or a word! Now after every cumshot *FINISHES* steps up to the next value you pre-defined. you could define a string like {0,1,two,chewingum,...} and a trigger [reply*FINISHES*] would be answered by {reply0,reply1,replytwo,replychewingum}. You cannot reset the variable by triggering a finish*number* line.
Now this is where I'm having trouble:
intro:"[ANGRY_MOOD]Tell me your feelings.[reply*mood*]"{"style":"Him"}
intro:"[NORMAL_MOOD]Tell me your feelings.[reply*mood*]"{"style":"Him"}
intro:"[HAPPY_MOOD]Tell me your feelings.[reply*mood*]"{"style":"Him"}
intro:"[AHEGAO_MOOD]Tell me your feelings.[reply*mood*]"{"style":"Him"}
replyAngry:"I am furious."
replyNormal:"I am ok."
replyHappy:"I like you."
replyAhegao:"MORE"
general:"[ANGRY_MOOD]Tell me your feelings.You're supposed to be *Mood*.[reply*mood*]"{"style":"Him"}
general:"[NORMAL_MOOD]Tell me your feelings.You're supposed to be *MOOD*.[reply*mood*]"{"style":"Him"}
general:"[HAPPY_MOOD]Tell me your feelings.You're supposed to be *mood*.[reply*mood*]"{"style":"Him"}
general:"[AHEGAO_MOOD]Tell me your feelings.You're supposed to be *mood*.[reply*mood*]"{"style":"Him"}
Here I'm trying to use the *mood* variable, but these lines fail, as I'm apparently using the wrong name for the variable, which is odd, as you can check for moods via
line:"This is a line."{"mood":"Normal"}
This line would only be displayed when she is in the normal mood. That's why I thought the variable for moods would be *mood* but those lines fail. Any idea how I can trigger that variable?
I'm not sure that you can use the hardcoded mood set by the [xxxx_MOOD] command as a variable.. But why not just use the "set" command? You don't need to "check" for it, to achieve what You want..
//testing variables
DEFAULT:
all:"CLEAR"
dialogue_name:"mood test"
intro:"[ANGRY_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply*mood*]" {"style":"Him","set":{"mood":"Angry"}}
intro:"[NORMAL_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply*mood*]" {"style":"Him","set":{"mood":"Normal"}}
intro:"[HAPPY_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply*mood*]" {"style":"Him","set":{"mood":"Happy"}}
intro:"[AHEGAO_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply*mood*]" {"style":"Him","set":{"mood":"Ahegao"}}
replyAngry:"I am furious."
replyNormal:"I am ok."
replyHappy:"I like you."
replyAhegao:"MORE"
//testing variables
DEFAULT:
all:"CLEAR"
dialogue_name:"mood test"
intro:"[ANGRY_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply]" {"style":"Him","set":{"mood":"angry"}}
intro:"[NORMAL_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply]" {"style":"Him","set":{"mood":"normal"}}
intro:"[HAPPY_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply]" {"style":"Him","set":{"mood":"happy"}}
intro:"[AHEGAO_MOOD]Tell me your feelings. You're supposed to be *mood*.[reply]" {"style":"Him","set":{"mood":"ahegao"}}
reply:"I am furious." {"mood":"Angry"}
reply:"I am ok." {"mood":"Normal"}
reply:"I like you." {"mood":"Happy"}
reply:"MORE" {"mood":"Ahegao"}
Both dialogues result in the same display of lines. So in the end it's just a matter of personal preference which of them you want to use..
And as the variable keeps it's value until it is set to a new value, You can use it for quite a lot of different lines.
The thing is, I'm searching for ways to implement variables into audiologues. But the audiologue modding template does not contain anything in {} brackets. So, no thought lines, no him lines, no custom variable setting/checking. That's why I'm looking for hard coded internal variables I could call up :-\
I thought if I set the mood to angry by [ANGRY_MOOD] I could then trigger lines with [line*mood*] but I can't find the internal mood variable... I thought it would be *mood* since that's what the mood checking looks like.
@Slinger - not sure if there's anything below You might want to add to the #1 post in the thread...
I've been trying to transfer one of my dialogues into an automated version and faced several problems, of which not the least is my current lack of dedication timewise...
.... but in preparation for this automated dialogue I did a little test. Using the script given in the Spoiler I started a total of 12 sessions with a girl set to 75% general and throat resistance, then with 50/50% and again with 1/1%. Each setting was tested with each of the four available auto modes - self, soft, normal and hard. Due to lack of time each session/ mode combination was tested for five minutes only, before I copied the log and sorted it for the number of times a line was displayed.. yes, that's only a small sample, but maybe it's enough to see some trends evolving.
head_grabbed:"Head grabbed *headgc*" {"style":"Him", "set":{"headgc":"+1"}}
pulled_up:"Pulled up *pupc*" {"style":"Him", "set":{"pupc":"+1"}}
pulled_down:"Pulled down *pdc*" {"style":"Him", "set":{"pdc":"+1"}}
The #1 in mass of displayed lines was "pull_off" with 88 of 330. Most often, when "she" had been deepthroated and was pressed down ballsdeep down on the cock. Which results in the most "pull_off" lines - 36 of 88 - being displayed in "hard" mode, as this was the only mode to achiece a deepthroat in short time (see below).
The lines that came up secondmost in this tests were the notorious "resistance" line. From a total of 330 "resistance" came up 63 times. BUT of these were only 11 displays done while in "auto hard" mode. The highest number of displayed resistance lines came in "self" and "soft" mode.
Then come the "first_throat" lines. 40 of them. Here it's interesting. Again "hard mode" gets the most line displays - 17 of 40 - with most of these of course being achieved when resistance is high..
Nextmost lines were "held" lines - 27 of 330 - and again "hard mode" was the leader here with 25 of those 27 displayed. Again the lack of deepthroating in the softer modes was the reason.
The "lick_penis" line showed 20 out of 330 times. Sometimes even when "she" was way down on the cock and gagging..
"Intro" lines were more often displayed - 15 of 330 - than "general" lines - 13 of 330. Nothing strange here, as intro lines showed when force was low and resistance high, while general lines were displayed when force was high and resistance low, leading to a faster deepthroat (or to any deepthroat at all...)
Nonetheless this might be good to remember when setting up a text. If "she" has low resistance you'll need more general than intro lines ^^
Here's a short overwiew of the other lines that showed:
pre_cum - 12 of 330; hard and some during normal mode restart - 10 of 330; nearly all during hard mode first_dt - 9 of 330; 6 during hard and normal mode, 3 in self and soft mode with low resistance vigorous - 9 of 330; all exept one during hard mode come_in_throat - 8 of 330; all but 1 in hard mode. The exception was 1 display in normal mode come_on_face - 6 of 330; often in combination with one of the other "come_on/in" lines.. head_grabbed - 4 of 330; when "he" grabbed "her" after she successfully pulled off come_in_mouth - 3 of 330 swallow - 3 of 330
Other observations:
- when attempting to write an automated dialogue the "self" and "soft" automatic modes take a terrible long time to reach a deepthroat. Of the three "first_dt"s achieved in "self/soft" mode two came up at 1% resistance and just shortly before the 5 minute test period ended. And only one of these lead to some sperm being ejaculated..
So if You plan your automated dialogue to lead to "her" getting a nice sperm shower within due time, don't use soft/self mode..
- on the opposite side there's "hard mode".. it goes through resistance faster than the other modes. But then it leads to many "held" lines and "her" getting gagged a lot, to the point of unconsciousness. And "he" will shoot his load a lot faster than with the other modes. At least twice as fast as in normal mode, I'd guess. So if You plan on an automated dialogue in which "He" does the talking and "she" is busy swallowing or getting bathed in cum, then "hard mode" should be your choice.
- the most dialogue for your money comes with "normal mode". Takes a while to get through her resistance, leading to quite a few pull_off / resistance lines, but after the first_dt all is well.. some hard action, even leading to "vigorous" lines, but also some pauses which would allow "Her" to say a few words, which would be near impossible in "hard mode"
more observations about certain lines
As can be seen above, "intro" lines, which are supposed to come up when nothing else fits before a first_dt is achieved, do not come up THAT often. A couple seconds of inactivity are needed or "she" must be doing something that doesn't trigger a "resistance" or "pull_off" line. So it's mostly those times, when "she"'s in "self / soft / normal" mode and just taking in the tip of "his" dick.. sucking lightly.. remember that for formulating what's supposed to be said or thought.
"Pull off" lines.. there seems to be no real indication when they will come up, other than that "she" has - or recently had - "his" cock in her mouth. I have seen them most often when "she" was deep down on "his" cock. Keep that in mind when formulating those lines.
"first_throat" lines... supposed to show, when "his" dick goes deeper in her mouth, until the deepthroat is reached. In reality it seems these lines show up whenever her resistance is overcome, not depending of going deeper than before, but just going deeper than he resistance would allow. Let's imagine those "resistance" lines show when "his" cock is about 20% inside of her mouth. Then it goes in to about 30%. The next moves go for 20% again and bring up "resistance" lines. When "his" cock goes in to the 30% mark a "first_throat" will show again...
So when You define those lines, remember that not every "first_throat" means the cock went deeper..
"Restart" Lines.... I hate them.. Way too often they don't show up. The problem with them seems to be, that they are triggered after an orgasm when his cock goes into her mouth again.. but not always. And that's where the problem is. You can't say if or if not it will display. So the best chance would be, to use some workaround like calling up a restart line from within a "come_in/on_etc" line.. BUT those may be triggered in pairs... after shooting some sperm in "her" mouth a bit might end up on her face, leading to both, a "come_in_mouth" and "come_on_face" line to be displayed... I don't have a solution for that, but can only advise to refrain from using any kind of counting in those restart lines... not even the built in *FINISHES*
"Lick_balls" lines do not only show, when "her" head is pushed down besides his cock to lick her balls... they also show up sometimes, when "she" is again balls deep on his cock and then sticks out her tongue so that it touches his balls.. remember that when formulating those lines..
That's all for now.. if anything else comes to my mind, there might be more...
Excellent work T0mcat! I think automation details are beyond the OP's scope, but your post sure makes this thread more comprehensive. Your data confirms my experience when writing my latest two semi and fully automated dialogues (SSSS p4 and SDT 2031). In the end, I used auto_hard exclusively since it had the best build in mechanics, and found useful workarounds for doing so:
1) If you [AUTO_HARD][RELEASE] her, she appears to be going solo, but with more gusto
2) If you want her to speak (and also not risk passing out), code him-style pull off and held lines that either break auto or switch to hand job. This frees her mouth and allows a back and forth dialogue to ensue, whereafter auto_hard can resume (a counter is increased, so that the next time held/poff is triggered, another mini-dialogue is displayed) This probably looks a lot better if one uses sby's invisible dialogue bubbles.
I also always use the same substitutions for resistance and first_throat lines since you can never be sure during automation which will appear - this essentially makes them the same category. I've found the various cum lines chaining up to be even more independable than restart, so I use pre_cum instead and ignore the cum lines. And I always make pre_cum dialogue him style (or thought) so that it always works. If I want her to say anything once he's done cumming, I'll not only use a restart line but EVERY possible line type (pull off, general, held) calls up that restart line so that it *will* be displayed. Pre_cum sets a variable so that it's the only thing that *can* be displayed, and once the restart line is triggered the value is increased so that it can only trigger once. That's the only reliable way I've found.
To make full automation work SOMEWHAT reliably from one playthrough to another, you really must make it completely linear with a progression variable so that event B cannot take place before event A. You really need to think every line through like a movie script, very precisely. That's my experience at least.
Yep.. but if I do that, I'll insert several "БББББББББББ" and put the [RELEASE] in a second line called up after them. So the sudden grabbing/releasing doesn't look so much like a slap to her head ::)
Slingerbult said:
2) If you want her to speak (and also not risk passing out), code him-style pull off and held lines that either break auto or switch to hand job. This frees her mouth and allows a back and forth dialogue to ensue, whereafter auto_hard can resume (a counter is increased, so that the next time held/poff is triggered, another mini-dialogue is displayed) This probably looks a lot better if one uses sby's invisible dialogue bubbles.
As I will ask people to make use of the Loader and Gollum's DialogueActions.swf with any automated Dialogue I'll make use of the [AUTO_OFF] trigger in such cases, although the change to a hand-job is another good option :)
Slingerbult said:
I also always use the same substitutions for resistance and first_throat lines since you can never be sure during automation which will appear - this essentially makes them the same category. I've found the various cum lines chaining up to be even more independable than restart, so I use pre_cum instead and ignore the cum lines. And I always make pre_cum dialogue him style (or thought) so that it always works. If I want her to say anything once he's done cumming, I'll not only use a restart line but EVERY possible line type (pull off, general, held) calls up that restart line so that it *will* be displayed. Pre_cum sets a variable so that it's the only thing that *can* be displayed, and once the restart line is triggered the value is increased so that it can only trigger once. That's the only reliable way I've found.
Well, as I wrote - seems "resistance" triggers when "his" cock doesn't go deeper than her resistance threshold, and "first_throat" triggers when it does ;)
So it's like... when "his" cock goes in for about 20% of it's length it triggers "resistance" lines. But when it goes in for 30% it triggers "first_throat". And when "first_throat" has been triggered a few times the new threshold is set to 30% for resistance and for "first_throat" to - maybe - 40% cocklength...
This is just an uneducated guess based on how I would handle the distinction between those two lines.. Guess only someone able to look deep into the code could tell us how it's handled for real...
pre_cum is a nice emergency brake, but especially with "auto_hard" it's sometimes too late to keep "him" from cumming... it triggers at 96% arousal and from there it's quite a short trip to full 100% and a spermshower ;)
As my laptop get's clogged awfully when too many checks are used within a dialogue I'll try to avoid checks as much as possible.. but I guess I'll have a closer look at how You handled that "pre_cum" leading to "restart" stuff... sounds neat :)
Problem might be that I'm lousy at decoding someone elses code - and dialogues ARE a kind of code, if only a simple one ;)
Slingerbult said:
To make full automation work SOMEWHAT reliably from one playthrough to another, you really must make it completely linear with a progression variable so that event B cannot take place before event A. You really need to think every line through like a movie script, very precisely. That's my experience at least.
Yepp.. although you can build in a little randomness.. but it has to be carefully planned randomness ;D
Wouldn't it be nice to have some kind of library for "working" scripts done to achieve a certain effect?
So one doesn't have to sift through a complete dialogue to find the hidden pearls within.. ;D
Or a script like this (working with the Loader and Gollum's DialogueActions.swf only) which makes her start a handjob, speeding it up twice, than make her change to blowhob mode... and putting in a brake when he's close to cumming... (though sometimes counting to three will be too much and he won't be able to stop fast enough ;D )
intro:"Ok.. get started..[LEFT_ARM_HAND_JOB][AUTO_SELF][intro01]" {"style":"Him","check":{"chapter":"introduction"}}
intro01:"And do it right..." {"style":"Him","set":{"chapter":"main","modus":"hand"}}
hjs1:"I count to three... one.." {"style":"Him"}
hjs2:"... two ..." {"style":"Him"}
hjs3:"... three ..." {"style":"Him"}
hjs4:"And now change the speed..[speedchange]" {"style":"Him"}
speedchange:"Yes, I'll do it faster.. [AUTO_NORMAL]"
hjs5:"I count to three again... one.." {"style":"Him"}
hjs6:"... two ..." {"style":"Him"}
hjs7:"... three ..." {"style":"Him"}
hjs8:"Now change the speed again..[speedchange01]" {"style":"Him"}
speedchange01:"Yes, I'll do it even faster.. [AUTO_HARD]"
hjs9:"I count to three again... one.." {"style":"Him"}
hjs10:"... two ..." {"style":"Him"}
hjs11:"... three ..." {"style":"Him"}
hjs12:"Now take it in your mouth..[change01]" {"style":"Him"}
change01:"Yes, I'll do it with my mouth..[AUTO_OFF][ARMS_LEGS][AUTO_SELF]" {"set":{"modus":"oral"}}
pre_cum:"Ok... time to tell a story... [AUTO_OFF][story01]" {"style":"Him","check":{"modus":"hand"}}
Re: pre_cum: I don't use it as an emergency break for the reasons you state (too unreliable) - I use it as a cum dialogue substitute. In that situation, I think it's appropriate that he is the verbal one and the auto hard just "keeps on cummin'" while he does the same. No randomness with cum placement triggering various stuff and no need to code 5 different variants based on the assumption that a man about to cum is in a position to make precise comments as to spunk location. A really neat way for her to still make reference to where he came that just occured to me, would be to have an invisible him-style bubble set a variable in the different cum categories. Then, different restart lines are triggered based on where he came, once he's actually done cumming, auto mode is off and her mouth is available.
Since you revealed your little tech on using triggers as a part of a custom line name (as in [res*PROG*] for a resistance line to be displayed at a certain point in the progression of the story), I haven't used a single check line since. Even mood checks are redundant in full automation as you know exactly what mood she will be at a certain point in the story as you have set it yourself (though such checks are probably a good way to include "controlled randomness" as you suggest).
As for the library you refer to, that was my initial idea when introducing the concept of "features" in this guide. Unfortunately, not many seem to be using it, but if dia writers started to separate these things into a feature section (like I do now) and explaining briefly what it does - borrowing (and tweaking) features between dialogues would be easy and make for more interesting stuff and less time spent reinventing the wheel.
initial_settings:{"nameIsSet":"true","namechecked":"false"}
intro:"[nameset*ME*]" {"check":{"namechecked":"false"},"set":{"namechecked":"true"}}
intro:"[intro1]" {"check":{"namechecked":"true"}}
intro1:"Wow, *YOU*, that's a huge cock you've got there! How would you like* ME* to suck it?" {"check":{"nameIsSet":"true"}}
intro1:"Wow, *YOU*, that's a huge cock you've got there! How would you like me to suck it?" {"check":{"nameIsSet":"false"}}
nameset:"" {"set":{"nameIsSet":"false"}}
New solution:
Code:
initial_settings:{"nameSet":"true","namechecked":"false"}
intro:"[namecheck*namechecked*]"
namecheckfalse:"[nameset*ME*]" {"set":{"namechecked":"true"}}
nameset:"" {"set":{"nameSet":"false"}}
namechecktrue:"[realintro]"
realintro:"[intro1*nameSet*]"
intro1true:"Wow, *YOU*, that's a huge cock you've got there! How would you like* ME* to suck it?"
intro1false:"Wow, *YOU*, that's a huge cock you've got there! How would you like me to suck it?"
You don't even have to use "true" and "false" - The regular could even be blank, and with name be "WithName".
initial_settings:{"nameSet":"true","namechecked":"false"}
intro:"[namecheck*namechecked*]"
namecheckfalse:"[nameset*ME*]" {"set":{"namechecked":"true"}}
nameset:"[realintro]" {"set":{"nameSet":"false"}}
namechecktrue:"[realintro]"
realintro:"[intro1*nameSet*]"
intro1true:"Wow, *YOU*, that's a huge cock you've got there! How would you like* ME* to suck it?"
intro1false:"Wow, *YOU*, that's a huge cock you've got there! How would you like me to suck it?"
Now, when you don't have a name set, the dialogue will instantly play. That's the only issue right now... if you do have a name set, the dialogue will go silent on the next line. Then you have to wait for the intro line to re-trigger.
[Aug 26 08:29:14] Pim_gd:I present to you: "How to check if a name is set, no variables"
[Aug 26 08:30:21] Pim_gd:intro:"Hi![intro1]*[YOU][intro1Named]*" intro1Named:"Hey, I know you, you're *YOU*!" intro1:"Huh? Who are you?"
[Aug 26 08:31:01] Pim_gd:Only flaw: Names can't have spaces in them.
[Aug 26 08:31:13] Pim_gd:Or they'll get printed on screen.
Full Dialogue:
dialogue_name:"Nametriggers"
all:"CLEAR"
intro:"Alright, let's get started![intro1]*[ME][intro1Named]*"
intro1Named:"Wow, that's a huge cock you've got there! How would you like* ME* to suck it?[toIntro2]"
intro1:"Wow, that's a huge cock you've got there! How would you like me to suck it?[toIntro2]"
toIntro2:"[intro2]*[YOU][intro2Named]*"
intro2Named:"Come on,* YOU,* ram it in already!"
intro2:"Shall I lick it, or do you want me to put it in completely straight away?"
[Aug 26 08:29:14] Pim_gd:I present to you: "How to check if a name is set, no variables"
[Aug 26 08:30:21] Pim_gd:intro:"Hi![intro1]*[YOU][intro1Named]*" intro1Named:"Hey, I know you, you're *YOU*!" intro1:"Huh? Who are you?"
[Aug 26 08:31:01] Pim_gd:Only flaw: Names can't have spaces in them.
[Aug 26 08:31:13] Pim_gd:Or they'll get printed on screen.
Full Dialogue:
dialogue_name:"Nametriggers"
all:"CLEAR"
intro:"Alright, let's get started![intro1]*[ME][intro1Named]*"
intro1Named:"Wow, that's a huge cock you've got there! How would you like* ME* to suck it?[toIntro2]"
intro1:"Wow, that's a huge cock you've got there! How would you like me to suck it?[toIntro2]"
toIntro2:"[intro2]*[YOU][intro2Named]*"
intro2Named:"Come on,* YOU,* ram it in already!"
intro2:"Shall I lick it, or do you want me to put it in completely straight away?"
I don't get how that's supposed to work (though I'm sure it does). You have a trigger and a variable with two triggers in it. I assume intro1 isn't triggered somehow if ME is defined (why?). What happens when you put triggers in variables and why is *[ME][intro1Named]* silent when there is no ME and why does it go to intro1Named when ME is defined? Does intro spell out the name after started! if ME is defined? Confused!
Ah, in the rush of excitement I forgot to explain it!
The lines:
intro:"Hi![intro1]*[YOU][intro1Named]*"
intro1Named:"Hey, I know you, you're *YOU*!"
intro1:"Huh? Who are you?"
What are they, really?
Lets take the first one.
intro:"Hi![intro1]*[YOU][intro1Named]*"
In the event that we don't have a HIM name...
this line is
intro:"Hi![intro1]", which is displayed as "Hi!". Since [intro1] is the last trigger that acts as a linereference, we go to intro1.
In the event that we do have a HIM name... let's say, Bob...
this line, intro:"Hi![intro1]*[YOU][intro1Named]*"
becomes
intro:"Hi![intro1][Bob][intro1Named]"
Now, why does this work?
Triggers are ALWAYS removed from the dialogue, unless they contain spaces (at which point they stop being triggers).
So we have this...
intro:"Hi![intro1][Bob][intro1Named]"
and it basically acts like
print "Hi!"
set next line = intro1
set next line = Bob
set next line = intro1Named.
At the end of this, next line is intro1Named, so we go to intro1Named.
How did I come up with this (another perspective of how it works)?
intro:"Hi, *YOU*!" = "Hi, Bob!"
intro:"Hi*, YOU*!" = "Hi, Bob!" - characters can be inserted
intro:"Hi*, YOU*!" = "Hi!" - if no name is present, nothing is inserted
initial_settings:{"var":"A"}
intro:"[scenario*var*]" = intro:"[scenarioA]" - Triggers are resolved runtime
initial_settings:{"position":1,"callback":""}
general:"[shiftPosition]" {"set":{"callback":"[generalPositionSwitch]"}}
shiftPosition:"[shift*position*]"
shift1:"[FACE_FUCK_STYLE]*callback*" {"set":{"position":2}}
shift2:"[NORMAL_STYLE]*callback*" {"set":{"position":1}} - It's possible to insert triggers into dialogue via variables
Because you can insert triggers runtime, and if no name is present nothing is inserted, you can insert triggers based on whether a name is present or not.
The last bit that you need to pull this off is the last trigger that does not lead to an action determines the next line to be played.
And due to that, this
intro:"Hi![intro1]*[YOU][intro1Named]*"
translates to (Pseudo code - attempt to execute this in your head like you would a dialogue!)
on intro {
Print Hi!
Set next = intro1
if(getHimName() is not ""){ //that's empty string, right there.
Set next = getHimName()
Set next = intro1Named
}
}
Slingerbult said:
I don't get how that's supposed to work (though I'm sure it does). You have a trigger and a variable with two triggers in it. I assume intro1 isn't triggered somehow if ME is defined (why?). What happens when you put triggers in variables and why is *[ME][intro1Named]* silent when there is no ME and why does it go to intro1Named when ME is defined? Does intro spell out the name after started! if ME is defined? Confused!
- I assume intro1 isn't triggered somehow if ME is defined (why?).
Because if ME is defined in the example (see below), then [intro1Named] is added to the end of the line. The last trigger that does not correspond to an action in SDT determines the line triggered.
Code:
intro:"Alright, let's get started![intro1]*[ME][intro1Named]*"
- What happens when you put triggers in variables[?]
Order of execution in SDT when playing a line, based on my research:
Insert variables
Convert percent-encoding to normal characters
Print line
So, based on that, if you put triggers in variables, they'll work as usual.
- why is *[ME][intro1Named]* silent when there is no ME
Because *[ME][intro1Named]* is no different than *, ME* or *ME*.
- why does it go to intro1Named when ME is defined?
Relevant section: [intro1]*[ME][intro1Named]*
If ME is defined (as Alice), this resolves to: [intro1][Alice][intro1Named]
If ME is not defined, this resolves to: [intro1]
And, as I said before: the last trigger that is not an action determines the next line.
- Does intro spell out the name after started! if ME is defined?
Yes, it does! But not in the way you'd suspect.
Let's say you boot up that Dialogue with SD Chan
This:
intro:"Alright, let's get started![intro1]*[ME][intro1Named]*"
turns into this:
intro:"Alright, let's get started![intro1][SD Chan][intro1Named]"
And you get the following output:
"Alright, let's get started![SD Chan]"
Because spaces break triggers. The [intro1] and [intro1Named] triggers do not show, as they are validated (no spaces).
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.