Passing values to and returning values from functions in the API in a Macro?

If I want to use a function I create using the Javascript API, how do I then access that function from a macro? How do I pass a value to it from within the macro, and then return that function's result into the macro?

You must implement an API command: !tt param No text is displayed automatically as a result of commands that begin with ! Next you must catch that command in the API: on('chat:message',function(msg){ 'use strict'; if('api' !== msg.type) { return; } var args = msg.content.split(/\s+/); if('!tt' === args.shift() ) { sendChat('my API', 'received parameters: '+args.join(', ') ); } });

Note that nothing is ever actually returned to the macro. The macro executed, passing information to the API, then the API receives that information as an event, the the API issues a messages to the chat as a result.  There are many different events that can be registered for with the on() function. 

The on('chat:message',...) event receives ALL messages sent to chat, so the guard at the top checking the message type allows the handler function to stop processing the message early. It also prevents an infinite loop case where the handler is processing its own sendChat results and issuing more. :) You can process other types of messages as well, there are several scripts that process /roll messages and provide additional system specific details about a roll (pairs, runs, etc).

I see lots of API script, but I don't see you calling that function from a macro. Or did you forget that part?

!tt param Would be in the macro. I am using Aaron's state script to debug code.... I call it from a macro like this. In the next post in bold you can see where I act on it.

var handleInput = function (msg) { var message = _.clone(msg); if ( 'api' !== message.type || '!aoedrawer' !== message.content.split(/\s+/)[0] ) { return; } switch(message.content.split(/\s+/)[1]) { case 'menu': //do stuff break; case 'toggleMenu': //do stuff break; case 'toggleOnDefault': //do stuff break; case 'state': SotSA.CheckState(); break; default: //do stuff break; } },

Well yes, but you're only calling the one thing that way. I'm talking about passing a variable to the API and returning a result back to the macro so the macro can continue to parse. Would that work in the dead middle, or at the very end, of a dice roll macro?

I use something similar to Stephen S. where I have one API that is listening for API commands to come in through chat - anything that starts with the exclamation mark is earmarked as an API command. I then parse out what API command I am running and then parse out the message in the Switch case. If my macro contains the variables I need to pass my API/Function, then I parse those out of the message in my "Commands" API before calling the function.

Now, when you say "starts with", do you mean "the first character in the chat entry"? Because that would prohibit it being part of an existing macro, wouldn't it?

Tenacious Techhunter said: Well yes, but you're only calling the one thing that way. I'm talking about passing a variable to the API and returning a result back to the macro so the macro can continue to parse. Would that work in the dead middle, or at the very end, of a dice roll macro? What you're talking about is not possible. As Aaron said, the macro is executed, passing information to the API, which then processes the input and potentially generates output. However!  As is often the case , you might have latched onto what you think is a solution to your problem, and are asking how to implement the solution. It is often helpful for you to describe the problem you are trying to solve; the API cannot solve your problem in the way you describe, but it is entirely likely that the API can solve your problem in a different way.

Nice thought, but no. I have a YX problem. People keep thinking I want to do X, but I want to do Y. Because they have no experience with why doing Y would be a good idea, they cannot fathom why I would be asking how to do Y, so they tell me how to do X, in spite of the fact that I'm asking, "How do I do Y, if it is at all possible, which it might not be?". At which point, it is far more helpful for people to simply say, "No, sorry, Roll20 fails to support doing Y just now.", than to tell me how to do X, or Z, or whatever. Why I want to do Y: There didn't used to be a "floor" function; now there is . That's what I want to do; add functions to my diceroller (and maybe even override some that the Roll20 devs screwed the pooch on). Why? Because everyone has access to the diceroller. Not everyone has access to the APIs; it's way better to give your players the system support they need to come up with their own solutions than it is to can all the ones you can manage yourself exclusively through the API, or from some well-intentioned character sheet effort, that may not be enough for a specific use case. So unless you've got a way to use the API to add to the list of functions available to the macro engine, it's just not what I was asking for, which I went to considerable effort to clearly specify from the very beginning. Thank you for your effort, though.

Tenacious Techhunter said: Nice thought, but no. I have a YX problem. People keep thinking I want to do X, but I want to do Y. Because they have no experience with why doing Y would be a good idea, they cannot fathom why I would be asking how to do Y, so they tell me how to do X, in spite of the fact that I'm asking, "How do I do Y, if it is at all possible, which it might not be?". At which point, it is far more helpful for people to simply say, "No, sorry, Roll20 fails to support doing Y just now.", than to tell me how to do X, or Z, or whatever. Why I want to do Y: There didn't used to be a "floor" function; now there is . That's what I want to do; add functions to my diceroller (and maybe even override some that the Roll20 devs screwed the pooch on). Why? Because everyone has access to the diceroller. Not everyone has access to the APIs; it's way better to give your players the system support they need to come up with their own solutions than it is to can all the ones you can manage yourself exclusively through the API, or from some well-intentioned character sheet effort, that may not be enough for a specific use case. So unless you've got a way to use the API to add to the list of functions available to the macro engine, it's just not what I was asking for, which I went to considerable effort to clearly specify from the very beginning. Thank you for your effort, though. In short, no it's not possible to what you're requesting, but the heart of your logic is still possible, but not in the format you intended. Within the API you can send a chat message which means the dice roller can 're-process' it after the API has already processed it. Think of it as a preprocessor where you scan in the !command (args) which appears as a standard roll: !rr /roll 1d4+reduce(lambda(pi+sine(randnum))) Here in this case the functions lambda, sine, reduce and the variables randnum and pi are all extended by the API which can parse it out for preprocessing. After preprocessing you'd end up with. /roll 1d4+<result> After subsituting the calculated result and trimming the command name. This can be sent back through chat using the player's own player id (whom sent the command) to appear as if they sent it normally, but clearly there's been work done internally. You could also pad the message with constructs if you wanted to display the nested results, But again this is not the same as plugging in a function in-line with other dice roller functions. As a side note to the little side arguement: it's still helpful to express what you're gunning at tech. For myself it still wasn't clear in the OP what you wanted or the behavior you wanted to see was possible, especially compared to other API questions.

Ken L. said: As a side note to the little side arguement: it's still helpful to express what you're gunning at tech. For myself it still wasn't clear in the OP what you wanted or the behavior you wanted to see was possible, especially compared to other API questions. We'll have to agree to disagree on that; I don't think many could have done a more explicit job of stating what I was asking for.

Tenacious Techhunter said: Ken L. said: As a side note to the little side arguement: it's still helpful to express what you're gunning at tech. For myself it still wasn't clear in the OP what you wanted or the behavior you wanted to see was possible, especially compared to other API questions. We'll have to agree to disagree on that; I don't think many could have done a more explicit job of stating what I was asking for. You did a great job, the fault was entirely mine. Sorry.

The Aaron said: Note that nothing is ever actually returned to the macro.  Your floor() example is good, lead with that next time.  =D