Pim_gd's Mods - DialogueActions v4.08 (15 Jan 2017) (6 Viewers)

Pim_gd

Content Creator
Joined
Jan 25, 2013
December 18, 2016
Introducing v4.07 of DialogueActions!
- Fixed the use of checks (line-attribute check) so that they now work.
- Fixed a bug where sets would write to the dialogue variable scope even if a hook for that variable exists, which confused a lot of people
- Added [PUSSYDRIP_<durationInFrames>] trigger. This reproduces the effect you get when she cums from masturbation.
- Added support for targeting other character folders than the current one with filereferences through prefixing with a dollar sign. See "About filereferences.txt" for more details.
- Added da.dialogue.import {write only} variable which allows you to read a dialogue file and append its lines to the current dialogue.
- Added [CLEARLINES_<linetype>] trigger. This trigger clears all lines of the specified linetype.
- Added da.sdtoptions variables (see "Variables.txt" for a list). These allow you to modify all of the boolean options in the options menu.
Link in OP. Alternatively, get the latest version from the downloads page of the BitBucket repo.

There's lots of stuff in this release - pretty much all of it not supported yet by the DialogueChecker - I'll get to that later...
First, checks should be fixed, which is great!

Aside from checks, there's more support for doing things with multiple character folders. DrZombi DrZombi already added the ability to load different character folders (from what I hear). DA now allows you to target files in other character folders, making it easier for bundle creators to keep their assets in one place. Additionally, with the ability to import lines, you should be able to mix and match dialogues as well. I had some ideas to make that feature even better, but for now, this is the basic system. I still have to think about how I'm going to make the DialogueChecker deal with imported files - chances are I'll have the DialogueChecker run from the SDT folder and pretend its a loader loading files, but I'm not sure yet.

Another feature is the ability to manipulate the options menu. There's a bunch of stuff there that's pretty interesting - turning off breathing/gagging/coughing is helpful if it gets in the way of certain scenes. You can also turn off dialogue with this new feature, but if you do that... there won't be a way to turn it back on. The user will have to do that manually.
 

DrZombi

Content Creator
Joined
Jul 10, 2016
Wow ! A very violent update ! I love it :smile:
Concerning the DialogueChecker compatibility with the dialogue import feature, I'm not sure that this is something very important. The writer will check all of his dialogues anyway, so if one of them calls another, it should not change anything to the syntax errors inside.
You could just add something like this when you cross a da.dialogue.import:

Import of <filename> dialogue file detected. Don't forget to parse this dialogue file as well !
 

Pim_gd

Content Creator
Joined
Jan 25, 2013
I'm more concerned about the line usage checker - it's made to detect if you've made typos in your line reference triggers. Slingerbult Slingerbult is fond of this and he'll eventually run into a case where a line b911a5 isn't used and a trigger references to a nonexisting line b911a6. This gets lost when you have imported dialogues because you can literally declare a bunch of lines like slowBlowAnimation which uses, say, MoreTriggers to set up a neat animation - then put that line in a dialogue file, import it and then call it. Then you have an animations file, which, when checked, says there are multiple unused lines, and a regular dialogue file which, when checked, says there's multiple references to non-existing lines.

That's the annoying part.

And I can't handle it properly because there might be funny guys who do crap like [SETVAR_da.dialogue.import_dialogue*da.random x ( 10 - 1 + 1 ) \ 1 + 1*.txt]. Essentially I run into the halting problem.

So I'm not sure yet what I'll do with this. Possibly you'll just have to append any imported dialogues to the checked dialogue in the checker for now.
 

DrZombi

Content Creator
Joined
Jul 10, 2016
I'm more concerned about the line usage checker - it's made to detect if you've made typos in your line reference triggers. Slingerbult Slingerbult is fond of this and he'll eventually run into a case where a line b911a5 isn't used and a trigger references to a nonexisting line b911a6. This gets lost when you have imported dialogues because you can literally declare a bunch of lines like slowBlowAnimation which uses, say, MoreTriggers to set up a neat animation - then put that line in a dialogue file, import it and then call it. Then you have an animations file, which, when checked, says there are multiple unused lines, and a regular dialogue file which, when checked, says there's multiple references to non-existing lines.

That's the annoying part.

And I can't handle it properly because there might be funny guys who do crap like [SETVAR_da.dialogue.import_dialogue*da.random x ( 10 - 1 + 1 ) \ 1 + 1*.txt]. Essentially I run into the halting problem.

So I'm not sure yet what I'll do with this. Possibly you'll just have to append any imported dialogues to the checked dialogue in the checker for now.

You've opened a gate to HELL !!! You're doomed man, you're doomed :grin::grin:
 

Slingerbult

Content Creator
Joined
Sep 15, 2012
Actually Pim, I think I'll just use the checker for syntax and grammar in the future. Those are the important ones anyway that saves lots of time on troubleshooting. Also:

- Fixed a bug where sets would write to the dialogue variable scope even if a hook for that variable exists, which confused a lot of people

What does this even mean? Hook?!

Also, fantastic job man! The Options menu manipulation opens up a lot - good call!
 

Pim_gd

Content Creator
Joined
Jan 25, 2013
- Fixed a bug where sets would write to the dialogue variable scope even if a hook for that variable exists, which confused a lot of people
What does this even mean? Hook?!

I mean if a variable write handler exists for that variable (so any variable used by mods to accept input, like da.dialogue.load).

Basically what was going on is that the checks were broken. They couldn't read variable read handlers. Okay hang on....

You have local scope ("dialogue scope") variables. That's the stuff you put in your initial_settings. Think "introPlayed" or variables like that.

You also have mod scope ("mod variables") variables. That's the stuff from DA or MoreTriggers. Think "da.clothes.tops" or the new "da.sdtoptions.spit".

A "variable read handler" is a piece of code that describes how to handle a variable read action (such as inserting into a dialogue). For the da.clothes variables, such a piece of code would go and look at what clothes she's wearing, then return that as a result.

A "variable write handler" is a piece of code that describes how to handle a variable write action (such as [SETVAR_...] or the set line attribute). For da.background.load, such a piece of code would go and look for the file referenced by the written value, and then load it as background.

What was going on was that the checks (check line attribute) was broken. They couldn't make use of variable read handlers. So if you used a mod variable in your check, it didn't work. Inserting worked fine though, so if you used variable insertions (asterisks) to print mod variable values to screen, you would see the proper value.

If you performed a variable write action for a mod variable, the write action would ALSO write to the dialogue scope. What this means is that aside from telling the variable write handler (for da.clothes) "I want to change the clothing", the value was also stored in the local scope.

Checks could successfully read the local scope, so any values set in the local scope could be used to perform checks.

Thus it seemed that if you wrote to a mod variable once, it would start to work in checks again. But really what was happening was that you were checking against the old value that you had set once. Not against the real, live value. For instance, had you set the clothing to red panties, and then the user changed it to blue boxers, and you performed a check to see if it were still red panties, the check would have said yes. Since it checked against the old value.

DA v4.07 fixes the checks, so that they read from the variable read handlers if available. DA v4.07 also fixes the bug where, when writing to a mod variable, it accidentally copied the value into the local scope. The end result is that you will no longer have stale checks, because A) DA is no longer saving old values and B) DA is now capable of reading mod variable values for checks.
 

Slingerbult

Content Creator
Joined
Sep 15, 2012
A+ Pim, you explained that so even I could understand it :)
A) DA is no longer saving old values and B) DA is now capable of reading mod variable values for checks.
Great news! I suppose this still means we should avoid using any "mod scope" variables in dialogues? Like, if I decide to use my own variable to track positions, I'd better not call it atv_position.
 

Pim_gd

Content Creator
Joined
Jan 25, 2013
You should aim to avoid using such variables in your dialogue, yes, because the read/write handlers will (or at least should) override whatever semantic meaning you've attached to it. You can try storing your progress tracking in clothing colors if you want to, but if someone changes the clothing color then it's gone.

Such were the troubles by dialogues that didn't use variables at all - the hypnosis dialogue only uses the mood to determine what lines to play. As a result, it's pretty much incomprehensible.
 

Jaxx

Content Creator
Joined
Aug 15, 2016
if I decide to use my own variable to track positions, I'd better not call it atv_position
Seems quite ovbious, but I'm not sure I understand what you're trying to achieve. Knowing a position at some point ? Or checking it to ensure it's the one it's supposed to be ? Or something else ?
 

Slingerbult

Content Creator
Joined
Sep 15, 2012
Jaxx Jaxx It was just an example, I'm quite happy with the functionality of animtools' atv_position as it is :) I have used my own position tracking before though to recall the PREVIOUS position. For example to allow her to play one type of dialogue if you switch from oral to another oral position, and a very different type if you switch from anal to oral ;)
 

outlawtorn316

Avid Affiliate
Joined
Sep 4, 2016
Late to the party, but I'd like to cast a vote on Slingerbult's idea of a mouse off/on toggle. Great way for us to initiate a small cut scene without the use of animtools, which I could use for my project... a lot lol. Thanks for the great work!
 

DrZombi

Content Creator
Joined
Jul 10, 2016
Hi Pim,

My bundle won't load my dialogues anymore since I've replaced my dev version of DA with your new v4.07.
Here is the dialogue log, I don't know how you've integrated your new da.dialogue.import but it seems that it killed the regular da.dialogue.load I was using :frown::

Code:
492: Variable setter for da.mod.load registered.
493: Variable setter for da.bgm.volume registered.
494: Variable getter for da.blockingOrgasm registered.
495: Variable setter for da.blockingOrgasm registered.
496: Playing line "[MASTURBATE_OFF]"
497: Trigger called: MASTURBATE_OFF with 0 arguments ()
498: Variable getter for mt.cuminmouth registered.
499: Variable setter for mt.cuminmouth registered.
500: Variable getter for mt.vigour registered.
501: Variable setter for mt.vigour registered.
502: Playing line "I can't take any more than that!"
503: Loading custom dialogue.
------------------------------
504: Adding custom line: "[setup_INSTANT][INSTANT_FLASH_000000][KILL_PROGRESSBAR_ALL][KILL_OVERLAY][CLEAR_HAIR][BUTTONALL_CLEAR][BUTTONALL_OFF][AUTO_OFF]"
505: Adding custom line: "[intro][SETVAR_da.background.load_InvocationRoom.png]ББ"
506: Adding custom line: "[launch_dial][SETVAR_da.hair.load_DarkHood.png]ББ[LOAD_FULL_CHARCODE]ББ"
507: Adding custom line: ""
508: Done.
------------------------------
509: Playing line "[setup_INSTANT][INSTANT_FLASH_000000][KILL_PROGRESSBAR_ALL][KILL_OVERLAY][CLEAR_HAIR][BUTTONALL_CLEAR][BUTTONALL_OFF][AUTO_OFF]"
510: Trigger called: INSTANT_FLASH with 1 arguments (000000)
511: Trigger called: KILL_PROGRESSBAR with 1 arguments (ALL)
512: Trigger called: KILL_OVERLAY with 0 arguments ()
513: Trigger called: CLEAR_HAIR with 0 arguments ()
514: Trigger called: BUTTONALL_CLEAR with 0 arguments ()
515: Trigger called: BUTTONALL_OFF with 0 arguments ()
516: Trigger called: AUTO_OFF with 0 arguments ()
517: Playing line "[intro][SETVAR_da.background.load_InvocationRoom.png]ББ"
518: Trigger called: SETVAR with 2 arguments (da.background.load,InvocationRoom.png)
519: Playing line "[launch_dial][SETVAR_da.hair.load_DarkHood.png]ББ[LOAD_FULL_CHARCODE]ББ"
520: Trigger called: SETVAR with 2 arguments (da.hair.load,DarkHood.png)
521: Trigger called: LOAD_FULL_CHARCODE with 0 arguments ()
522: Playing line ""
523: Loading custom dialogue.
------------------------------
524: Done.
------------------------------
 
Last edited:

Lokar

Potential Patron
Joined
Dec 25, 2016
Hi i know i'm late to the party but i think there is a bug with the buttons or i'm just an idiot. When i try to take the gag of with a button it fucks up all the buttons

I use this to put gag on-off
button7:"[Act_C*Action*]" {"style":"him"}
Act_C0:"[BUTTONALL_CLEAR][BUTTON10_ON][BUTTON9_ON][BUTTON8_ON][CHK2]"
CHK2:"" {"set":{"da.button9.name":"Earrings", "da.button8.name":"Chocolate", "Action":3}}

Act_C2:"[Gag_G*Gagged*]"
Gag_G0:"" {"set":{"da.clothes.gag":"Ring,0,0,0","Gagged":1}}
Gag_G1:"" {"set":{"da.clothes.gag":"None,0,0,0","Gagged":0}}

it does this only with the gag i can take anything elese off with no problem
 

Jaxx

Content Creator
Joined
Aug 15, 2016
Act_C0:"[BUTTONALL_CLEAR][BUTTON10_ON][BUTTON9_ON][BUTTON8_ON][CHK2]"
When you use [BUTTONALL_CLEAR], it removes any da.button#.name value, so if by "fucked up" you mean empty buttons, it's normal, you should use [BUTTONALL_OFF] instead, and merging lines Act_C0 and CHK2 won't be a problem anymore.
You could also put something like "da.button7.name":"Gag on" or "da.button7.name":"Gag off" on lines Gag_G0 and Gag_G1 in order to change your button label acording to what the next action will do.
You didn't define any style for lines Gag_G0 and Gag_G1, which means those are speaking lines that cannot be triggered if she's gagged, try with "style":"Thought", even if the text is empty.
 

Lokar

Potential Patron
Joined
Dec 25, 2016
sorry for my lack of detail on my comment what i mean by "fuck_up" is they don't work anymore the buttons have names and everything is working fine. i CAN gag har but when i try to un-gag her an empty dialogue box appears on the screen and then the buttons stop responding
I used "monitor dialogue" to try and see the problem, when i press the button again to take the gag of the buttons stop using the refference betwen the "[...]" and nothing works anymore (i've tried with "style":"thought" to no success)

and its rly frustrateing because if i use a downloaded dialogue from the forum that has the gag on/off feature it works and if i copy-paste it from there and then change the variables in initial_settings to match the line it still donsn't work

if you want i can give you the dialogue to take a look in the whole file
 

DrZombi

Content Creator
Joined
Jul 10, 2016
Like Jaxx Jaxx said, you should not mix [BUTTONALL_CLEAR] with other button related actions. I recommend to use it only at the start of a dialogue to actually clear everything button-related. If you want good working examples of menu-submenus dialogues, you can have a look at Weewillie's Slave Bazar, Fleack bundles, or my Dialogue Template that you'll find in my bundle -> Mods\Write-Utils\Char Helper. You'll also find in this folder a complete doc explaining how the template works, waht you can modify and how, etc...

[EDIT]: Also: you should have a look at Pim_gd's Dialogue Checker. It is very useful and it can leverage some issues that you made like [MOOD_ANGRY] which does not exist and should be [ANGRY_MOOD], and on line 64 you wrote tounge for tongue. I know that the problem is not there but these are still good to know :smile:
 
Last edited:

Lokar

Potential Patron
Joined
Dec 25, 2016
so i use [BUTTONALL_CLEAR] when i open a new menu is that ok or should i use [BUTTONALL_OFF] or close each one with [BUTTON#_OFF]?? also i solved the problem by changing "da.clothes.gag":"Ring,0,0,0" with "da.clothes.gag.type":"Ring" why did this work?

Thanks for the heads up with the tongue and the mood
 

Users who are viewing this thread

Top


Are you 18 or older?

This website requires you to be 18 years of age or older. Please verify your age to view the content, or click Exit to leave.