Dialogue questions I have (1 Viewer)

[edgelord 3000]

I figured I might as well just start a topic for the questions I have regarding dialogue technicalities.

1. Is there any way for me to check where her arms are before playing a line? Sort of like

generic:"My left hand is on your penis."{"check":{"left_arm":"handjob"}}
generic:"My hands are on my legs."{"check":"{arms":"legs"}}

I could probably write an attribute each time I change arms position, but the player is easily able to change hand positions on their own, and no attribute would be written when they do.

2. Can I trick the game into playing a Speak line even when her mouth is... otherwise occupied? I have in my head so many lines regarding her trying to talk with her mouth full but right now I can't use any of them because the game won't let me.

3. Which is better performance wise?

generic:"Line."{"check":{"value":"set"}}

or

generic:"[generic_*value*]"{"style":"Thought"}
generic_set:"Line."

The latter is the "cleanest", but with many attributes comes many extra lines, and I'm not sure if that has a noticeable impact on the game or not.

 

[Rudgar]

I figured I might as well just start a topic for the questions I have regarding dialogue technicalities.

1. Is there any way for me to check where her arms are before playing a line? Sort of like

generic:"My left hand is on your penis."{"check":{"left_arm":"handjob"}}
generic:"My hands are on my legs."{"check":"{arms":"legs"}}

I could probably write an attribute each time I change arms position, but the player is easily able to change hand positions on their own, and no attribute would be written when they do.

As far as I know: regretably no, not even with DiablogueActions mod

2. Can I trick the game into playing a Speak line even when her mouth is... otherwise occupied? I have in my head so many lines regarding her trying to talk with her mouth full but right now I can't use any of them because the game won't let me.

You can, but the lines must then be with "{"style":"thought"} or anything else but "speak"

3. Which is better performance wise?

generic:"Line."{"check":{"value":"set"}}

or

generic:"[generic_*value*]"{"style":"Thought"}
generic_set:"Line."

The latter is the "cleanest", but with many attributes comes many extra lines, and I'm not sure if that has a noticeable impact on the game or not.

second.
"check" consumes a LOT of performance - I personally refrain completely from it.

HTH

Respectfully,
Rudgar

 

[edgelord 3000]

You can, but the lines must then be with "{"style":"thought"} or anything else but "speak"

Oops, I forgot to specify that it had to at least look like one of her speak lines. It wouldn't make much sense to have her thoughts being garbled...

 

[Rudgar]

Oops, I forgot to specify that it had to at least look like one of her speak lines. It wouldn't make much sense to have her thoughts being garbled...

Oh, maybe you can use this mod to color one of the custom types just like the spoken lines.

HTH

Respectfully,
Rudgar

 

[edgelord 3000]

That seems to be the best option, especially since it seems SpeakAlt1 (and probably the others) completely ignore if her mouth is full or not, yet move her lips. Some might call this a bug, I call it the perfect feature. Now I just need to find a way to "copy" the colors from the default Speak style to SpeakAlt1, so I don't have to override people's preferences...

 

[edgelord 3000]

Hey, I already have a new question!

4. Let's say I have these triggers:

generic:"Line 1"
generic:"[generic_secondary]"
generic_secondary:"Line 2"
generic_secondary:"Line 3"
generic_secondary:"Line 4"

Will each of these triggers have an equal chance to play, aka. Line 1 -> Line 2 -> Line 3 -> Line 4, or will the game favor the "top" triggers over unplayed triggers, aka Line 1 -> Line 2 -> Line 1 -> Line 3 -> Line 1 -> Line 4?

 

[Rudgar]

Hey, I already have a new question!

Oh, what a surprise

4. Let's say I have these triggers:

generic:"Line 1"
generic:"[generic_secondary]"
generic_secondary:"Line 2"
generic_secondary:"Line 3"
generic_secondary:"Line 4"

Will each of these triggers have an equal chance to play,

No.
First, the game will give the first two lines a 50:50 (meaning 1/2 each = 50%) chance.
If the second line is the lucky one, each of the secondary lines has a chance of 1/3 (= 33,33%).

So in total:

generic:"Line 1" = 1/2 = 50%
generic:"[generic_secondary]" = 1/2 = 50%
generic_secondary:"Line 2" = 1/3 of 1/2 = 33,33% of 50% = 16,667%
generic_secondary:"Line 3" = 1/3 of 1/2 = 33,33% of 50% = 16,667%
generic_secondary:"Line 4" = 1/3 of 1/2 = 33,33% of 50% = 16,667%

Understandable?

HTH

Respectfully,
Rudgar

 

[Wolf357]

"check" consumes a LOT of performance - I personally refrain completely from it.

HTH

Respectfully,
Rudgar

The biggest "pro" for check lines is when you don't have a clear-cut set, or are trying to test against several different variables, but don't necessarily have the variables be mutually exclusive (e.g. testing body scale as one var, and breast size range as another.) Sure, if you pre-define HER in the dialog, those are fixed values, but if you leave them as "any charcode", you couldn't have a pre-defined set.

Breast size alone would take 151 lines for a single line of printed text, if not using checks. You could break it down to two or three if you tested for "small", "large", and "medium" as a third: e.g.:

vigorous:"[vig_*da.her.body.breasts*]":{"style":"thought"} (line1)
vig_0:"Small" (line 2)
vig_1:"Small" (line 3)
...
vig_149:"Large" (line 151)

versus
vigorous:"Small"{"check":{"da.her.body.breasts":"<75"}
vigorous:"Large"{"check":{"da.her.body.breasts":">74"}

Adding in body scale, independent of breast size, would add an innumerable amount of lines, since it's a floating-point range. Using checks, you could test for <=1 and >1, and so on.

The performance hit is there, but there could be some utility there, as well.

 

[Rudgar]

"objection , Your Honor!"

The biggest "pro" for check lines is when you don't have a clear-cut set, or are trying to test against several different variables, but don't necessarily have the variables be mutually exclusive (e.g. testing body scale as one var, and breast size range as another.) Sure, if you pre-define HER in the dialog, those are fixed values, but if you leave them as "any charcode", you couldn't have a pre-defined set.

Breast size alone would take 151 lines for a single line of printed text, if not using checks. You could break it down to two or three if you tested for "small", "large", and "medium" as a third: e.g.:

vigorous:"[vig_*da.her.body.breasts*]":{"style":"thought"} (line1)
vig_0:"Small" (line 2)
vig_1:"Small" (line 3)
...
vig_149:"Large" (line 151)

versus
vigorous:"Small"{"check":{"da.her.body.breasts":"<75"}
vigorous:"Large"{"check":{"da.her.body.breasts":">74"}
Adding in body scale, independent of breast size, would add an innumerable amount of lines, since it's a floating-point range. Using checks, you could test for <=1 and >1, and so on.

The performance hit is there, but there could be some utility there, as well.

You don't have to react on each and every single value that might be possible.
You can work with conditions, too.
They result to 1 (true) or 0 (false):

vigorous:"[vigorous_*da.her.body.breasts > 75*_*da.body.scale < 1*]":{"style":"thought"}
vigorous_0_0:"Breasts are not greater than 75 and body scale is not smaller than 1"
vigorous_0_1:"Breasts are not greater than 75 and body scale is     smaller than 1"
vigorous_1_0:"Breasts are     greater than 75 and body scale is not smaller than 1"
vigorous_1_1:"Breasts are     greater than 75 and body scale is     smaller than 1"

For more information, check "operators.txt" in DialogueActions' documentation for Dialogue Writers.

Beside this, you can even do some stuff that you can't do with checks, like variable limits ...

vigorous:"[vigorous_*da.her.body.breasts > limit_breasts*_*da.body.scale < limit_body*]":{"set":{"limit_breasts":75, "limit_body":1}, "style":"thought"}
vigorous_0_0:"Breasts are not greater than *limit_breasts* and body scale is not smaller than *limit_body*"
vigorous_0_1:"Breasts are not greater than *limit_breasts* and body scale is     smaller than *limit_body*"
vigorous_1_0:"Breasts are     greater than *limit_breasts* and body scale is not smaller than *limit_body*"
vigorous_1_1:"Breasts are     greater than *limit_breasts* and body scale is     smaller than *limit_body*"

(works because the "set" will be performed BEFORE(!) the line content itself.)

... or even OR-Conditions:

vigorous:"[vigorous_*da.her.body.breasts > limit_breasts || da.body.scale < limit_body*]":{"style":"thought", "set":{"limit_breasts":75, "limit_body":1}}
vigorous_0:"neither breasts are greater than *limit_breasts* nor body scale is smaller than *limit_body*"
vigorous_1:" either breasts are greater than *limit_breasts*  or body scale is smaller than *limit_body*"

Final conclusion: checks reduce performance without having the least true advantage.
Sorry, W Wolf357

Respectfully, Rudgar

 

[Wolf357]

Eh, learn something every day. LOL That's why I haven't posted any dialogs; by the time I learn a new trick, I end up having to go back and "fix" all the previous efforts, get sick of the premise, start over on something else, learn another new trick, rinse, repeat, do not pass go, do not post dialogs... LOL

 

[Rudgar]

Eh, learn something every day. LOL That's why I haven't posted any dialogs; by the time I learn a new trick, I end up having to go back and "fix" all the previous efforts, get sick of the premise, start over on something else, learn another new trick, rinse, repeat, do not pass go, do not post dialogs... LOL

Don't you worry, same with me here. I remember all too well the day I tumbled over some really sophisticated lines of high dialogue writing art!

Respectfully, Rudgar

 

[Pim_gd]

Rudgar Use DA4.09dev9 for the snippet you linked instead... Pim_gd's Mods - DialogueActions v4.08 (15 Jan 2017) just need to check if it's not empty, can be done by [SPLITSTRINGBYNAEM_da.him.name_temp] and then either check or insert *temp.length > 0* to see if player name is set.

 

[edgelord 3000]

by the time I learn a new trick, I end up having to go back and "fix" all the previous efforts, get sick of the premise, start over on something else, learn another new trick, rinse, repeat, do not pass go, do not post dialogs... LOL

When you spend more time writing code for your dialogue than writing dialogue for your dialogue...

 

[Wolf357]

When you spend more time writing code for your dialogue than writing dialogue for your dialogue...

https://www.explainxkcd.com/wiki/images/a/a9/automation.png
Automation, refactoring, etc....

 

[edgelord 3000]

So, how do I use dialogueactions' _INSTANT when I'm using multiple triggers in a line? Let's say I have this code:

test:"[test1_INSTANT][test2_INSTANT]Test."
test1_INSTANT:"[COUGH]"
test2_INSTANT:"[HOLD]"

From what I thought, this would play out like if I had done

test:"[COUGH][HOLD]Test."

but it doesn't. Instead, she'll say "test", and he'll hold her. The cough trigger line doesn't play, and the hold trigger line plays after everything else.

 

[Deltavoid]

So, how do I use dialogueactions' _INSTANT when I'm using multiple triggers in a line? Let's say I have this code:

test:"[test1_INSTANT][test2_INSTANT]Test."
test1_INSTANT:"[COUGH]"
test2_INSTANT:"[HOLD]"

From what I thought, this would play out like if I had done

test:"[COUGH][HOLD]Test."

but it doesn't. Instead, she'll say "test", and he'll hold her. The cough trigger line doesn't play, and the hold trigger line plays after everything else.

This doesn't even seem possible. What's probably happening is it reads the first trigger and stores it like the "next" condition. then it reads the second trigger which overwrites the first one. I don't get how as I thought it would run the first trigger never reaching the second or the text after.
Also the _INSTANT tag just causes the line to process behind the scenes without displaying a box. its not like the wildcard lines (finish, cough, interrupt) where they play inside the line itself.

 

[edgelord 3000]

From what you say, the _INSTANT function seems redundant, as DA will hide trigger-only lines anyway. If I understand you correctly, that is.

Additionally, DialogueActions will instantly play lines that only contain a single trigger.
This means that if you have something like a callback or a branch decision, there will no longer be a lengthy period of blank box visible to the user.
Variables will still be set. If other mods relied on reading those lines, they can no longer do so - DialogueActions waits until is finished loading the variable values before forcing SDT to play the next line.
For larger lines with multiple triggers, you can add "_INSTANT" to the line name, like "intro4_INSTANT".
If a "_INSTANT" line contains something else than triggers, it won't be played instantly.

 

[Deltavoid]

From what you say, the _INSTANT function seems redundant, as DA will hide trigger-only lines anyway. If I understand you correctly, that is.

I never saw that in the documentation until now, which is odd because i have read each file. unless it was a newer addition to the about file, in which case I have not truly read that one since the last stable release. Its also possible I just plain forgot about that too. I have not seen anyone use "_INSTANT" like that. Weewillie does have several "_INSTANT" lines but I don't think he linked any. The only other possible ideas that comes to my mind is the obvious: check that coughing is on in Options [o] under the sounds column, check the log, and load up Monitordialog.

 

[edgelord 3000]

Monitordialog tells me what you already suspected, the "test1" line is never played. My reason for wanting to use several triggers in a line was that I wanted to check a variable using a trigger (like [test1_sick*issick == 1*]), which would then play or not play the test1 line with the single trigger, but unfortunately I guess I have to use a standard SDT check for that...

 

[Deltavoid]

Try these:

Operator Var1 Var2 Output
...
&& 1 0 0 - Represents a boolean AND. Returns 1 if (var1 + var2) equals 2. Otherwise, returns 0.
|| 1 0 1 - Represents a boolean OR. Returns 1 if (var1 + var2) equals or is more than 1. Otherwise, returns 0.
...

Example:

var1 = 1
var2 = 0
[test* var1 == 1 || var2 == 1 *] will run line test1
[test* var1 == 1 && var2 == 1 *] will run line test0