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

[Pim_gd]

I have a question involving Variable Arithmetic. Currently I'm working on a dialogue, and my hopes and dreams for it is easily outclassing my skill (Which is good because it forces me to LEARN!), but anywho, I developed some algorithms to handle all my stat growth and decay, HOWEVER, I just realized that the "^" operator doesn't work.. ie... 5^2=25 I have very limited knowledge in how these mods actually interact with the main game and flash in general, so with that being said is it impossible to implement powers into Variable Arithmetic? I totally nutted my code so it would work but the lack of exponential growth and decay kinda makes me a little sad. :) I appreciate all the hard work you guys are doing to make the game so much more fun to tinker with! Thanks for reading!!

EDIT: Ok maybe I'm just math illiterate. NEW QUESTION! I'm trying to multiple with the [SETVAR..] trigger but getting weird results. Examples...
[SETVAR_stamina_-=*( 2 x 5 )*] returns a "not a number" error... so I tapped into 20 year old highschool math know how and did this..
[SETVAR_stamina_-=*( 2 ( 5 ) )*] where "stamina" originally was 100... and it returned 75. So for grins and also trying to find an explaination I tried ( 2 ( 3 ) ) and it returned 77...so somehow it seems its is ignoring the parentheses and LITERALLY subtracting 25 and 23... which means there is no way I can do multiplication, however when I look at other dialogues for examples they can clearly use "x" as an operator...
For not being a mathmatically inclined person, this just makes me face hurt lol. Can someone explain this to me please? And why does it seem the "x" operator isn't working? Using DialogueActions 4.06. Any help would be appreciated, this is very frustrating. Math is supposed to be logical not magical. :)

initial_settings:{"x":"*","var1":10,"var2":20}

start:"*var1 x var2*"

Result will be 200.

The "x" doesn't work, because, the X isn't used for multiplication. A special symbol is used, but people tend to write it as x. ... There's a tendency to use asterisks, but you can't do that because, well, * is already used for variable insertions for SDT. It's quite a pain.

 

[outlawtorn316]

Thanks DrZombi and Pim, THAT is the crucial part I missed. Some how with all the scripts I have been studying I missed the "x":"*" setting. That solves all the confusion. Thank you 10 fold!

 

[DrZombi]

Hi all,

I've just tried to use the mult and the da.random myself and I found this in the DialogueActions doc:

da.random {read only} - returns a random value between 0 and 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 9 + 1 \ 1*] - formula is ( random * ( max - min ) ) + min \ 1

I'm not a math guru so you can just tell me to get the fuck out if I'm wrong but from what I calculate myself, if you apply the above formula to get some number between 1 and 10, here is what you'll have:

da.random first gives you a floating number between 0 and 1, so it can be anything like 0.56698 for example.
Then you multiply by your (max - min), so here, (10 - 1 = 9) and your number can now be anything between 0x9 and 1x9 -> 0 - 9
Then you just add the minimum (+1) so nothing really changes, we just change our range to 1-10.
And finally we "floor-divide" by 1 just to convert the result to an integer and we have a range of integers from 1-10
BUT... If I'm not mistaken, to get a 10, you don't have much choice: you have to roll a perfect 1 at first because if you get a 0.99999, it will give you a x 9 = 8.99999, +1 = 9.99999, \1 = 9. And for this first 1 the chances are... small.
So you end up with something more like 1-9 with a small possibility of 10, which will result in a line of your dialogue (almost) never playing.

And as I told you, I'm not a Math Guru so with only flooring available, I can't find a way to have a uniform distribution of your random numbers.

If you add 0.9999 instead of 1, you still obtain a 1-10 range but this time, the 1 is unlikely to come out because you need to roll a perfect 0. Same cause, same consequences...

If you add 1.5, you also have a range 1-10 with far better chances to get the 1 and 10. But the 1 and 10 are still half the chances of any other number in the range. Not uniform.

So from this, and assuming that my maths are good, I see only 3 possibilities to use the da.random in your dialogue:

1) You don't give a fuck about the uniform distribution of your randomly generated range. Ok I shut up. But still your line 10 won't display much, and don't say I've not warned you

2) You multiply by (max - min + 1) instead, so that you have 1-11 with uniform distribution accross 1-10 and you manage the small possibility to get an 11 in the way that best suits you, probably by creating a line which redirects to the 10.

3) You're a Maths Nazi and you still thinks that this is not uniform because that gives a micro-much-more chance to get a 10 (Yes, you're a nazi for that, give me my Godwin point now please ). In that case I'd recommend you to make your range 1-11 and use the +1.5 solution, so that you have uniform distribution accross 2-10 and 1/2 chance to get 1 or 11 which you can both redirect to the same line (number 1 for example). And your range is now 1-10 with uniform distribution. Magic !


If anyone has a better solution, you're welcome

 

[Pim_gd]

I made a mistake.

This stackoverflow answer correctly explains how to do min and max with numbers (although it uses Java). I'll explain how to apply it for SDT's dialogues:

You can get 0 to 0.99999 (1 not included!) from da.random - because it's AS3's random ( AS3 Docs on Math.random).

*da.random x ( MAX - MIN + 1 ) \ STEP + MIN*

That's is the correct way to do things.

So if you want to get a number that is 1-10: you do this

*da.random x ( 10 - 1 + 1 ) \ 1 + 1*

If you want a binary value, you do this

*da.random x ( 1 - 0 + 1 ) \ 1 + 0*

I have updated the documentation. Thanks for notifying me.

 

[DrZombi]

It's been such a long time since I last had to mess with random() functions that I did not even think about checking the AS3 doc and just assumed it would generate between 0-1 which is in fact stupid when you think about it. But still, I'm happy that in my error I found something of interest anyway

Personally, I did use the formula written like this in my dialogue before you answer to my post:
*da.random x ( MAX - MIN + 1 ) + MIN \ STEP*
It gives the exact same result but I guess that adding the integer MIN to a Floored value like you propose it is mathematically & logically nicer. But if some people better understand the formula written like I did, I may not have 100% failed

P.S: In your modified doc, you changed only the formula, but you still states that the number is randomly generated between 0 - 1, which should be 0 - 0.999. I'd found it easier to understand this way, but that's only my opinion.

 

[desk87]

Hello everybody,

I'm having a problem with a dialogue I've written.

I would like to have the resistance, first_throat and first_dt lines played more than once, so at the moment I'm using the [RESET_RESIST] trigger to get the expected result, however the trigger also resets her resists (duh). Is there a similar trigger that simply allows those lines to be played again without resetting her resists?

 

[DrZombi]

Well, the thing is that each line has its particularity, and is meant to play at a specific time. resistance lines for examples, are meant to play when the girl's throat is loosing some of its resistance. So no, there won't be any way to make them trigger directly while the resistance is gone. In the same way, intro lines are meant to play only before the first_dt occurs. After that, you will trigger general lines.

Of course you can still use shortcuts like:
general:"[intro]"
vigorous:"[resistance]"

maybe with some variables to track when you don't want to read those lines anymore:
general:"[intro]" {"check":{"stillIntro":"true"}}
general:"blabla" {"check":{"stillIntro":"false"}}
vigorous:"[resistance]" {"check":{"stillIntro":"true"}}

If you tell me what you want to do exactly, and what you try to achieve, I may find better solutions.

 

[desk87]

The dialogue uses the AUTO triggers with the speed chosen randomly every know and then. What happens is that, once the resistance lines are played, if the random process picks a slow speed no dialogue line will be played (too slow to trigger vigorous, she is still moving so no general lines will be played and the pull_off lines don't play as often as I'd like to.

Using the [RESET_RESIST] trigger overcomes the problem (the dialogue won't get in a stuck state no matter what), but it has the flaw i described earlier. Maybe I could use that with a variable to manually lower her resistances. But probably the best solution would be to add a variation of the RESET_RESIST trigger.

I took a peek at the code, and probably it's not too hard to implement such trigger:

Spoiler: Code

public function resetResist(...args):void {

g.her.setIntroResistance(g.inGameMenu.costumeMenu.resistanceSlider.currentValue(100)); // Remove this for the new trigger
g.her.setThroatResistance(g.inGameMenu.costumeMenu.throatResistanceSlider.currentValue(100)); // Remove this for the new trigger
g.her.maxIntroDist = g.her.introStartDist; // Keep this (?)
g.her.firstDT = true; // Keep this
g.her.intro = true; // Remove this so that the general lines are played over the intro lines (?)
g.him.deepestPos = 0; // Remove this (?)

}

but I'm no expert of the SDT variables to know exactly what's happening there. Maybe Pim_gd can help me out there.

 

[DrZombi]

Can't you just stop using the slowest speed ?

[EDIT]: Sorry for that short response. I mean:

If you add some variable in your initial_settings:{"useSlowSpeed":"1"}
And then you add a {"check":{"useSlowSpeed":1}} at the end of each line where you have an [AUTO_SOFT] so you can be sure that the auto goes slow only when you want it to.

Then you add a {"set":{"useSlowSpeed":0}} at the end of your first_dt lines so that when resistance is gone, you're sure that you will have speed enough to trigger the vigorous lines.

Alternatively, if what you really want to do is create an automated dialogue, you may find a lot of useful triggers here: Colin's Loader Mods

 

[DrZombi]

Hi Pim_gd ,

I hope that I won't fall again in our old situation of "You already tried to tell me this but I did not understand it at the time". I've re-read carefull the previous discussion and I think that this is not the case but I'd like to come a little bit back to the post #347 of this thread.

I've been asked to add another variable in MoreTriggers (mt.vigour) alongside mt.cuminmouth, and while I was testing, I just found out that in fact, "check" actions just do not work AT ALL !! And it is not something linked to the fact of initiliazing the variable before checking or falling in an situation where the value is undefined. In fact, it acts exactly as if the "check" does not launch my get() function at all, and just checks the value of a mt.cuminmouth variable inside the dialogue instead of getting the actual value from the function which should be linked to the variable. I'll try to explain myself better, let's have a look at this example dialogue:

all:"CLEAR"

start:"[intro]mt.cuminmouth set to *mt.cuminmouth*..." {"style":"Thought","set":{"mt.cuminmouth":60}}

intro:"[intro]mt.cuminmouth now equals 0, cuminmouth%3A *mt.cuminmouth*" {"style":"Thought","check":{"mt.cuminmouth":0}}
intro:"[intro]mt.cuminmouth now below 30, cuminmouth%3A *mt.cuminmouth*" {"style":"Thought","check":{"mt.cuminmouth":"<30"}}
intro:"[intro]mt.cuminmouth now below 60, cuminmouth%3A *mt.cuminmouth*" {"style":"Thought","check":{"mt.cuminmouth":"<60"}}
intro:"[intro]mt.cuminmouth now equals 60, cuminmouth%3A *mt.cuminmouth*" {"style":"Thought","check":{"mt.cuminmouth":60}}
intro:"[intro]mt.cuminmouth now over 60, cuminmouth%3A *mt.cuminmouth*" {"style":"Thought","check":{"mt.cuminmouth":">60"}}

If you run this piece of dialogue you'll have the first line saying that mt.cuminmouth is set to 60 because the ** replacements do work perfectly and retrieve the exact value of the SDT variable by launching my get() function.

But then, you will fall in a loop on the 4th intro line with the girl thinking lines like this:

mt.cuminmouth now equals 60, cuminmouth: 60
mt.cuminmouth now equals 60, cuminmouth: 48
mt.cuminmouth now equals 60, cuminmouth: 37
mt.cuminmouth now equals 60, cuminmouth: 18
mt.cuminmouth now equals 60, cuminmouth: 0
mt.cuminmouth now equals 60, cuminmouth: 0

(The actual value decreases as the girl will automatically begin to swallow or drool when she has cum in mouth). The exact same effects will happen with mt.vigour but due to the very fast dropping speed of this variable, it is much more interesting to run the test with mt.cuminmouth.

So my guess is that the "set" works well, the ** works well, but the "check" does not check the value through the function that should be attached to the variable through the registerVariableReadHandler function that you provided me with. Instead, there seems to be a value attached directly to the mt.cuminmouth variable which is retrieved through DA by the "check". And this value is always equal to the last value actively set in the dialogue (60), not the value updated continuously by SDT and which I'd like to retrieve. And this totally explains my working examples of post #347. Since my examples were based on setting to 80 and then checking >75 only once or just checking the exact value after setting it...

So do you think that there is anything you could do about this ? I never had this kind of "check" problem with other DA variables.
I can still provide some kind of dirty workaround with the **, but that would really be better if the users of MoreTriggers could be able to really "check" those variables !

Many thanks anyway for having read this until here

 

[Pim_gd]

Hi Pim_gd ,

I hope that I won't fall again in our old situation of "You already tried to tell me this but I did not understand it at the time". I've re-read carefull the previous discussion and I think that this is not the case but I'd like to come a little bit back to the post #347 of this thread.

You're right!

See #346. DialogueActions does not support using the check line attribute for custom (mod defined) variables right now.

Pim_gd / SDTDialogueActions / source / Documentation / Known Bugs.txt — Bitbucket

I cannot fix this without breaking dialogpatch... so I dunno if I should.

 

[DrZombi]

You're right!

See #346. DialogueActions does not support using the check line attribute for custom (mod defined) variables right now.

Pim_gd / SDTDialogueActions / source / Documentation / Known Bugs.txt — Bitbucket

Yep, you told me that checks did not hook very well and that checking should not be done on variables which have not been set properly beforehand. This is not exactly the problem that I describe here so I was not sure that this was what you had in mind when writing #346.

I cannot fix this without breaking dialogpatch... so I dunno if I should.

So it seems that we're touching some deep questions which should be debated from the community benefit point of view.
Of course, breaking dialogpatch would not be very kind nor very logical since it adds some nice possibilities to the dialogue system too.
In the best world I can imagine, the solution would be to apply the needed correction AND integrate the dialogPatch code into DA !
Of course, this needs sby 's permission because you'd be basically "eating" his code. Even if I prefer to see this as an opportunity to participate to DA by offering some code.
I personnally love this solution because that would mean less mods to know and manage (with less interactions to anticipate) and this would be the best for the community of dialogue writers, which, I think, is what we all wanted when we decided to create mods which add possibilites to the dialogue system.

So what do you think of this ? Do you want me to ask him about this ? I love this idea of seeing 2 of the best modders here working together to achieve better solutions for everyone

 

[sby]

Yep, you told me that checks did not hook very well and that checking should not be done on variables which have not been set properly beforehand. This is not exactly the problem that I describe here so I was not sure that this was what you had in mind when writing #346.



So it seems that we're touching some deep questions which should be debated from the community benefit point of view.
Of course, breaking dialogpatch would not be very kind nor very logical since it adds some nice possibilities to the dialogue system too.
In the best world I can imagine, the solution would be to apply the needed correction AND integrate the dialogPatch code into DA !
Of course, this needs sby 's permission because you'd be basically "eating" his code. Even if I prefer to see this as an opportunity to participate to DA by offering some code.
I personnally love this solution because that would mean less mods to know and manage (with less interactions to anticipate) and this would be the best for the community of dialogue writers, which, I think, is what we all wanted when we decided to create mods which add possibilites to the dialogue system.

So what do you think of this ? Do you want me to ask him about this ? I love this idea of seeing 2 of the best modders here working together to achieve better solutions for everyone

if you want to absorb the code to build onto it further, go ahead. the tricky part is making sure people don't try to use conflcting mods, or you can try to add some code to essentially overwrite the patch.
never used it, but you can use this to undo the stuff the dialog patch does if someone happens to still load it first:
lp.restoreProxy(true);
where lp is the proxy to one of the functions that the patch applies.

ideally if you replace it, to keep the features it provides so it can act as a upgrade to the mod.

 

[DrZombi]

if you want to absorb the code to build onto it further, go ahead. the tricky part is making sure people don't try to use conflcting mods, or you can try to add some code to essentially overwrite the patch.
never used it, but you can use this to undo the stuff the dialog patch does if someone happens to still load it first:
lp.restoreProxy(true);
where lp is the proxy to one of the functions that the patch applies.

ideally if you replace it, to keep the features it provides so it can act as a upgrade to the mod.

Thank you sby !

Now Pim_gd , I'm sure that you totally don't need me to do whatever can be done but since I am involved in the process, don't hesitate if you need anything that I could provide to assist. I'd be glad to help if I can.

 

[Pim_gd]

I'd rather not integrate the code. It has its hooks in too many functionalities, and I don't fully understand how it works.

My proposed fix: ( sby DrZombi )

Dialogpatch changes the proxy for canPlay to use mycanplay.

        var canPlayProx:Object = lProxy.createProxy(g.dialogueControl.advancedController, "canPlay");
        canPlayProx.addPre(canPlay, persist==1);
        canPlayProx.hooked = false;

to

        var canPlayProx:Object = lProxy.createProxy(g.dialogueControl.advancedController, "canPlay");
        canPlayProx.addPre(mycanPlay, persist==1);
        canPlayProx.hooked = false;

Dialogpatch calls canPlay instead of mycanPlay for sayRandomPhrase.

            for each (_loc_5 in _loc_3)
            {
                if (mycanPlay(_loc_5))    //don't use object's canplay, use my custom one (which also calls my custom controller canplay)
                {
                    _loc_4.push(_loc_5);
                }
            }

to

            for each (_loc_5 in _loc_3)
            {
                if (g.dialogueControl.advancedController.canPlay(_loc_5))
                {
                    _loc_4.push(_loc_5);
                }
            }

These two changes make it so that there's only one execution flow for checking the eligibility of a line.

DialogueActions hooks canPlay after DialogPatch.

That is, g.dialogueControl.advancedController.canPlay_l calls DA.canPlay calls DP.mycanPlay calls DP.canPlay.

DialogueActions adds a post listener for canPlay.

In the hook for canPlay, DialogueActions fills any requested variables in the dict if not present.

In the post listener for canPlay, DialogueActions removes any variables it has filled in.

I have attached a build with check functional. If the changes I suggested are made, and the load order is Dialogpatch and after that DialogueActions, everything should work fine, from what I'm seeing.

Here's a commit to show what I changed:

Pim_gd / SDTDialogueActions / commit / c96f6fe59ccd — Bitbucket

Dialogues used for testing:

start:"checking to see if we can check *da.breathPercentage* [line]"

line:"breathpercentage 100![line]" {"check":{"da.breathPercentage":100}}
line:"no check used![line]"

start:"checking to see if we can check *da.breathPercentage* [line]"

line:"breathpercentage 100![line]" {"check":{"da.breathPercentag":100}}
line:"no check used![line]"

The first one spams both lines, the second one only spams one line.

 

[DrZombi]

Great ! Many thanks for this very fast answer !

I have attached a build with check functional. If the changes I suggested are made, and the load order is Dialogpatch and after that DialogueActions, everything should work fine, from what I'm seeing.

I personnally always load DA and my own mods at the end of my Mods.txt so it won't be a problem for me but we'll need to advertise this very clearly in the next releases of DA and DP if we don't want other people to fall in a trap !

My test dialogue uses DP for its < and > tests in checks so I'll have to wait for sby 's new DP and then I'll be able to tell you both if my 2 variables are now checkable with those 2 new mods working together (since you seem to confirm that it already works with DA variables and standard checks).

 

[Pim_gd]

< and > work just fine, it's != that dp adds

 

[DrZombi]

Mouarf ! I was sure that all those comparisons operators were added by DP !
Am I also wrong if I think that with != we can still only compare numerical values ? I seem to remember that something like "check":{"myStringVariable":"!=stringValue"} does not work. I'll maybe have to give this a retry ?

 

[Pim_gd]

uhhh

        public function canPlay(param1) : Boolean        //takes a dialog line, not string
        {
            //main.updateStatus("ran canplay");
            var _loc_2:* = null;
            var _loc_3:* = null;
            var _loc_4:* = null;
            var _loc_5:* = false;
            var _loc_6:* = "a";
            var _loc_7:* = null;
            var _loc_8:* = false;
            if (param1.settings["check"])
            {
                //debug
                //main.updateStatus("check ran");
                g.dialogueControl.advancedController.outputLog("Running checks for line: \"" + param1.phrase + "\"");
                _loc_2 = param1.settings["check"];
                for (_loc_3 in _loc_2)
                {
                
                    _loc_4 = _loc_2[_loc_3];
                    _loc_5 = _loc_4 is Number;
                    _loc_6 = Number(_loc_4.toString().replace(/[\>\<\=\!]?[\>\<\=\!]?/g, ""));
                    /*main.updateStatus("loc4:"+_loc_4);
                    main.updateStatus("loc5:"+_loc_5);
                    main.updateStatus("loc6:"+_loc_6);
                    main.updateStatus("loc6rep:"+_loc_4.toString().replace(/[\>\<\=\!]?[\>\<\=\!]?/g, ""));*/
                
                    if (!_loc_5 && _loc_4 is String)
                    {
                        _loc_5 = !isNaN(_loc_6);
                    }
                    _loc_7 = g.dialogueControl.advancedController._dialogueDataStore.hasOwnProperty(_loc_3) ? (g.dialogueControl.advancedController._dialogueDataStore[_loc_3]) : (_loc_5 ? (0) : (false));
                    if (_loc_7 is Number && _loc_4 is String && _loc_5)
                    {
                        _loc_8 = true;
                        if (_loc_4.charAt(0) == ">")
                        {
                            if (_loc_4.charAt(1) == "=")
                            {
                                _loc_8 = _loc_7 >= _loc_6;
                            }
                            else
                            {
                                _loc_8 = _loc_7 > _loc_6;
                            }
                        }
                        else if (_loc_4.charAt(0) == "<")
                        {
                            if (_loc_4.charAt(1) == "=")
                            {
                                _loc_8 = _loc_7 <= _loc_6;
                            }
                            else
                            {
                                _loc_8 = _loc_7 < _loc_6;
                            }
                        }
                        else if (_loc_4.charAt(0) == "!" && _loc_4.charAt(1) == "=")
                        {
                            _loc_8 = _loc_7 != _loc_6;
                        }
                        else
                        {
                            _loc_8 = _loc_7 == _loc_6;
                        }
                        if (!_loc_8)
                        {
                            g.dialogueControl.advancedController.outputLog("   Line will not play: \"" + _loc_3 + "\" needs to be " + _loc_4 + " but is currently set to " + g.dialogueControl.advancedController._dialogueDataStore[_loc_3]);
                            return false;
                        }
                    }
                    if (_loc_7 is Boolean && (_loc_4 == "true" || _loc_4 == "false"))
                    {
                        _loc_4 = _loc_4 == "true";
                    }
                    if (!(_loc_5 && _loc_4 is String) && _loc_7 != _loc_4)
                    {
                        g.dialogueControl.advancedController.outputLog("   Line will not play: \"" + _loc_3 + "\" needs to be " + _loc_4 + " but is currently set to " + g.dialogueControl.advancedController._dialogueDataStore[_loc_3]);
                        return false;
                    }
                }
                g.dialogueControl.advancedController.outputLog("   Okay.");
            }
            return true;
        }// end function

Relevant parts:

        _loc_7 = g.dialogueControl.advancedController._dialogueDataStore.hasOwnProperty(_loc_3) ? (g.dialogueControl.advancedController._dialogueDataStore[_loc_3]) : (_loc_5 ? (0) : (false));
        if (_loc_7 is Number && _loc_4 is String && _loc_5)
        {
            _loc_8 = true;
            if (_loc_4.charAt(0) == ">")
            {
               //...
            }
            else if (_loc_4.charAt(0) == "<")
            {
                //...
            }
            else if (_loc_4.charAt(0) == "!" && _loc_4.charAt(1) == "=")
            {
                _loc_8 = _loc_7 != _loc_6;
            }
            else
            {
                _loc_8 = _loc_7 == _loc_6;
            }
            if (!_loc_8)
            {
                g.dialogueControl.advancedController.outputLog("   Line will not play: \"" + _loc_3 + "\" needs to be " + _loc_4 + " but is currently set to " + g.dialogueControl.advancedController._dialogueDataStore[_loc_3]);
                return false;
            }

Looks like it's numbers only.

 

[DrZombi]

That's what I thought