Accessing current trigger/topic or calling object macro in conditional

[davidchriqui]

Is there a way to access current trigger and current topic values in a conditional test ?
What about calling an object macros in a conditional?

[davidchriqui]

I actually look for a way to do the following :

> topic topic1

+ trigger1
% previous
- reply1

+ trigger2
% reply1
- reply2

+ quit
- ok{topic=random}

< topic

I want the user to be able to "quit" the current topic to the random one, no matter what previous bot reply is. With the previous example, the user would trigger "trigger1" then if he triggers "quit", he is redirected to the random topic instead of being replied with "reply2".

[davidchriqui]

Is it there a way to perform the following :

+ *
* <call>checkMacro <star> == true => blablabla
* <call>checkMacro <star> == false => blablablablabla

[kirsle]

That should work but you're missing the </call> tag.

+ *
* <call>checkMacro <star></call> == true => blablabla
* <call>checkMacro <star></call> == false => blablablablabla

You can do <get topic> to get the user's current topic. From an object macro you could use rs.lastMatch(rs.currentUser()) to get the current user's last matched trigger.

[davidchriqui]

I can't get object macro calls to work with conditionals (WITH the closing tag :) )

+ my email is *
* <call>checkEmailFormat <star></call> == false => Wrong format
- right format

checkEmailFormat is never called and RS always replies with "right format" (I double checked the "checkEmailFormat" function and it works properly)

[kirsle]

I verified the issue. This used to work, when <call> tags were executed inside the processTags() function with all the other tag processing, but in PR #78 support for asynchronous object macros was added which made this a two-pass approach:

processTags() just mangles the <call> tag to look like {__call__}name {__call_arg__}arg1{/__call_arg__}{/__call__} and that's where the condition was left when it came time to compare the result (which obviously fails the comparison 😜 ), and then processCallTags() was the one that actually ran the code.

So I have PR #111 open to fix this, but need to make sure it doesn't cause any other bugs (asynchronous object macros most likely won't work in conditions, because RiveScript needs the answer "now" to see if the condition is true or not).