Dialog Help: Line attempted over and over (1 Viewer)

[WeeWillie]

I'm working on a dialog, and I use a lot of checks to control the dialog flow. I'm seeing an issue in the logs were a line such as cum_in_mouth or cum_on_face is being attempted over and over, but is failing due to my conditional scripting. The fail is by design, but since that line type is being tried over and over, she just shuts up. No other generic line, head grabbed, other cum line, etc will fire, so she just goes completely silent.

Does anyone have any suggestions to make a line fail but not be attempted over and over again?

 

[f93]

This is actually one of the reasons why I try to avoid having conditional checks like {"held":"true"} or even {"mood":"Normal"} - it can randomly pick a line, see that line's condition isn't met, then randomly pick the same line, over and over.

My own way of getting around this is to use variables, and just link the default linetypes to ones with the possible values for the variable after it. It needs a bit more work to set up, but it avoids this issue.
So you'd have something like:

dialogue_name:"example"
initial_settings:{"played":"false"}
CUSTOM:
intro:"[intro*played*]"
introfalse:"The dialogue has begun! Grab me![HOLD]"{"set":{"played":"true"}}
introtrue:"You have grabbed me, and I will repeat this line forever!"

So introfalse can only be reached once, and introtrue will play forever instead afterwards.

You can do this with other variables, so you can have a grabbed variable that's usually 0 but set to 1 whenever she is grabbed, and general:"[general*grabbed*]" to link you to general0 and general1 line types without any checks actually failing.

Edit: Replaced introset with played for consistency (and to make it actually work).

 

[WeeWillie]

Thank you for the advice! Goodness, I have a TON of recoding to do, *sigh*.

 

[WeeWillie]

I do see one potential issue with the approach that maybe you have thoughts about.

The base line that always fires would need to be {"style":"thought"} so that it will fire even with her mouth full. For example:

intro:"[intro*played*]"{"style":"thought"}

However, some lines should only play when she can speak. For example:

introfalse:"I'll only say this with my mouth available"{"style":"speak","set":{"introset":"true"}}
introtrue:"I'll think this forever."{"style":"thought"}

So if this runs for the first line, but her mouth is preoccupied, then you'll get an empty dialog bubble for the master intro: line, followed by nothing. This feels like a bug.

Would separating master lines by type work? For example:

intro:[introspeak*played*]{"style":"speak"}
intro:[intronospeak*played*]{"style":"thought"}
introspeakfalse:"I'll only say this with my mouth available"{"set":{"introset":"true"}}
introspeaktrue:"I'll say this forever."
intronospeakfalse:"I'll think this anytime"{"set":{"introset":"true"}}
intronospeaktrue:"I'll think this forever."

Would this get rid of the empty dialog box, or would it just bring back this issue of a line being attempted over and over but failing? It also has the side effect that when speaking is available, it'll be random which group, speak or think, that she'll say, so there could potentially be lots of lines to cover all situations.

 

[f93]

That is indeed a problem that shows up with dialogues done that way. Thought and Him lines will show up a lot more frequently, so those tend to make up more of the lines in complex dialogues (to avoid repetition). There are a lot of approaches to dialogues depending on what you're trying to do, really.

I'm pretty sure you can't use {"style":"speak"} - any line without a style is her speaking (except finish1, finish2, etc, which inherit the style of whatever had *FINISHES*), and I don't think there's actually a proper way to specify that it's a speaking line for her.

Oh, whoops, just realised I forgot to changed "introset" to "played" in all parts of my example when I was chopping it out of a dialogue. I'll edit that in.

 

[Pim_gd]

defining {"style":"speak"} is just being verbose; SDT adds it automatically internally anyway.
When SDT reads a dialogue line from the file, and there is no style defined, SDT assumes style speak.