Suppress macro.return?

Discuss macro implementations, ask for macro help (to share your creations, see User Creations, probably either Campaign Frameworks or Drop-in Resources).

Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice

Post Reply
MikeKozar
Cave Troll
Posts: 73
Joined: Sat Sep 12, 2009 6:35 pm

Suppress macro.return?

Post by MikeKozar »

I'm using some of the debugging tricks, and I think I shot myself in the foot. I was using an eight-line troubleshooting block, which would (depending on debug mode settings on the library token) either do nothing, add a tooltipped "?" to the macro output, or pop up an Input window with current state information.

I kept revising this code block, but it was making me crazy to try and edit a dozen macros every time a new feature occurred to me. I wound up using the defineFunction() command to make myself a pretty little function called debug() that I could drop in wherever I might want a debug flag, usually reporting on things like macro.args and macro.return, so I can monitor what is being passed to the next step in the chain.

The problem I am having is that if I run [debug("Ending Dice Roller",macro.return)], it *eats* macro.return. When it terminates, it resets macro.return to its own output, a null. This made last night's game session kind of a nightmare.

I see a lot of options for variable scope documented on defineFunction(), but none of them seem to keep it from overwriting macro.return. I also can't find *any* documentation on the macro() function - is this missing from the wiki? Is there any way to keep a macro from returning data, if all you want is output?

User avatar
plothos
Great Wyrm
Posts: 1890
Joined: Sat Jun 21, 2008 1:07 am

Re: Suppress macro.return?

Post by plothos »

If I'm reading this right, it seems your issue is you have one macro in which you call a second macro, which sets a macro.return in the first macro, but then when you run a third macro you can't keep it from resetting macro.return?

If that's the issue, the solution would seem to be just setting a new variable with the first macro.return contents as soon as the called macro returns it. This is probably a good idea anyway, as it'll help mnemonically.

But maybe I'm missing a deeper problem here?
Drop-In Utilities:
My Spell Manager for D&D3.5 and PFRPG
My Inventory Manager for D&D and PFRPG, but more generally useable than that.
My Message Manager -- My Top-Down D&D Token Images
and my Custom Initiative & Status/Spell-Effect Tracker (work in progress, but functional).

User avatar
mfrizzell
Dragon
Posts: 762
Joined: Sat Feb 13, 2010 2:35 am
Location: California

Re: Suppress macro.return?

Post by mfrizzell »

MikeKozar wrote:I'm using some of the debugging tricks, and I think I shot myself in the foot. I was using an eight-line troubleshooting block, which would (depending on debug mode settings on the library token) either do nothing, add a tooltipped "?" to the macro output, or pop up an Input window with current state information.

I kept revising this code block, but it was making me crazy to try and edit a dozen macros every time a new feature occurred to me. I wound up using the defineFunction() command to make myself a pretty little function called debug() that I could drop in wherever I might want a debug flag, usually reporting on things like macro.args and macro.return, so I can monitor what is being passed to the next step in the chain.

The problem I am having is that if I run [debug("Ending Dice Roller",macro.return)], it *eats* macro.return. When it terminates, it resets macro.return to its own output, a null. This made last night's game session kind of a nightmare.

Why would you be running debug during a game? If you're macros are not ready for primetime don't run em. :D

MikeKozar wrote:I see a lot of options for variable scope documented on defineFunction(), but none of them seem to keep it from overwriting macro.return. I also can't find *any* documentation on the macro() function - is this missing from the wiki?

Nope it's under roll options.
http://www.lmwcs.com/rptools/wiki/macro_%28roll_option%29

MikeKozar wrote:Is there any way to keep a macro from returning data, if all you want is output?

Data is only returned through macro.return so if you don't want any return don't use macro.return.
DCI/RPGA# 7208328396 Skype ID mfrizzell77
Characters:
Strabor - Dwarf Avenger 5th Level
Tikkanan - Human Warlock 2nd Level
----------------------------------------------------
"People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs."

MikeKozar
Cave Troll
Posts: 73
Joined: Sat Sep 12, 2009 6:35 pm

Re: Suppress macro.return?

Post by MikeKozar »

plothos wrote:If I'm reading this right, it seems your issue is you have one macro in which you call a second macro, which sets a macro.return in the first macro, but then when you run a third macro you can't keep it from resetting macro.return?

If that's the issue, the solution would seem to be just setting a new variable with the first macro.return contents as soon as the called macro returns it. This is probably a good idea anyway, as it'll help mnemonically.

But maybe I'm missing a deeper problem here?


In my game system, modifiers are applied to the pool of dice you have to roll, and successes are all the 5s and 6s rolled with that many six-sided dice. For example, I have a macro for attacking that handles all the processing to determine what the attacker's pool of dice is, and a separate macro for rolling those dice and displaying the results. This second macro returns the number of successes rolled with that pool.

This basic idea (determine pool, roll pool) is the main link in most of my game's mechanics. I have macros that automatically handle attack, defense, damage, and death with four separate rolls on one click; each step logically follows the one prior modified by the number of successes at that stage. Was the attacker sufficiently accurate? Was the defender able to dodge? Did the defender's armor mitigate the damage? Is the damage enough to kill him?

As you can see, this is pretty complex. When something goes wrong and MapTools gives one of those errors that discard all output, it is very difficult to track down where in all those subroutines the bug has arisen. That's why I have a debug mode that pops up an Input() at each major step; I know that it has gotten to that point without an error.

The problem I'm having, specifically, is that if I try to send the final output of a macro to my debug command, that final output is changed to the debug command's output.

[debug("Successes",macro.return)]

...will display a popup that says [ Successes 5 ], but it will also overwrite macro.return with a null, defeating the purpose of the debug function entirely.

To get around this, I will need to build my macro.return twice; I get to the end of the macro, assign the output to macro.return, and assign the same output to a DebugInfo variable that I can pass to the debug() command. That extra line is bugging me (no pun intended) because in addition to it being extra work, it also means I might make a mistake and get innaccurate debug info; I'm not actually reading the macro.return at that point.

Come to think of it, that will still create the same issue; I will need to reassign macro.return *after* the debug runs for it to be any good to me.

The reason I bring it up is that the options for defineFunction allow you to do the exact opposite of what I want; discard all output and give a macro.return. What I want is the output to run normally, but the macro to discard all returns and not change macro.return.

I don't know if it's possible, or if there is another solution, but I thought I'd ask.

prestidigitator
Dragon
Posts: 317
Joined: Fri Apr 23, 2010 8:17 pm

Re: Suppress macro.return?

Post by prestidigitator »

My practice is to IMMEDIATELY assign macro.args (when it it used) to a local variable first thing in a macro, and to keep track of return value in a local variable until the last line of the macro, which looks something like "[h: macro.return = value]" (when it is used).
"He knows not how to know who knows not also how to un-know." --Sir Richard Burton

User avatar
aliasmask
Deity
Posts: 8609
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: Suppress macro.return?

Post by aliasmask »

I ran across an interesting thing where a function I made sometimes has a value returned, but it also calls other macros. I found macro.return to be global along the chain of execution where lets say udf1 calls udf2 which calls udf3. udf3 has a return value, udf2 sometimes has a return value and udf1 checks the return value. When udf2 doesn't assign a return value, then it gets the value returned by udf3. It was a no brainer just assigning macro.return = "" when it didn't have valid output, but still, I thought it was interesting.

prestidigitator
Dragon
Posts: 317
Joined: Fri Apr 23, 2010 8:17 pm

Re: Suppress macro.return?

Post by prestidigitator »

aliasmask wrote:I ran across an interesting thing where a function I made sometimes has a value returned, but it also calls other macros. I found macro.return to be global along the chain of execution where lets say udf1 calls udf2 which calls udf3. udf3 has a return value, udf2 sometimes has a return value and udf1 checks the return value. When udf2 doesn't assign a return value, then it gets the value returned by udf3. It was a no brainer just assigning macro.return = "" when it didn't have valid output, but still, I thought it was interesting.


Well, yeah. I mean, it would be pretty silly to put "[h: macro.return = macro.return]" at the end of any macro that returned the value returned by a called macro, wouldn't it? ;)
"He knows not how to know who knows not also how to un-know." --Sir Richard Burton

User avatar
biodude
Dragon
Posts: 444
Joined: Sun Jun 15, 2008 2:40 pm
Location: Montréal, QC

Re: Suppress macro.return?

Post by biodude »

prestidigitator wrote:My practice is to IMMEDIATELY assign macro.args (when it it used) to a local variable first thing in a macro, and to keep track of return value in a local variable until the last line of the macro, which looks something like "[h: macro.return = value]" (when it is used).


Yeah, me too. Keep in mind that macro.args & macro.return are GLOBAL variables, which means they always keep their values as macro execution moves around from one macro to another.

I had similar problems trying to debug macro.args (calling a debug function in which you pass macro.args does not work the way you'd expect). Now, I always assign macro.args to a local variable (usually 'args') very early on in any macro. Then, I can more easily debug that value, which is less likely to be affected by a user-defined debugging macro.

Same thing for macro.return: it's always the last statement in my macros, where I assign it the value of some local variable I use to track/build returned values.

Note that a user-defined function can return output (if it is not supressed), rather than the value of macro.return. In this case, the value of macro.return can be different than the value returned by the function :shock: (this means you can essentially get 2 separate value from a function, or send function output as output, and get some other value(s) from macro.return)
"The trouble with communicating is believing you have achieved it"
[ d20 StatBlock Importer ] [ Batch Edit Macros ] [ Canned Speech UI ] [ Lib: Math ]

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: Suppress macro.return?

Post by Rumble »

biodude wrote:Note that a user-defined function can return output (if it is not supressed), rather than the value of macro.return. In this case, the value of macro.return can be different than the value returned by the function :shock: (this means you can essentially get 2 separate value from a function, or send function output as output, and get some other value(s) from macro.return)


Supremely useful trick, too. I use it in several macros.

User avatar
aliasmask
Deity
Posts: 8609
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: Suppress macro.return?

Post by aliasmask »

Yeah, I ran across that in some code I've seen... I'm not a fan because it's not obvious what you're returning. It works, but it feels more like a hack than structured code, IMO.

MikeKozar
Cave Troll
Posts: 73
Joined: Sat Sep 12, 2009 6:35 pm

Re: Suppress macro.return?

Post by MikeKozar »

Alright, I think I found a workaround. Just for the record, I couldn't find any way to access the global macro.return from within a called macro. However, since one of the main functions here is to peek at macro.return without changing it, I decided to go with a simple hack. The format of my command is [debug(first line of popup,second line of popup)], and I generally use the first line to indicate macroName and a brief text flag like Start, End, or Loop. The second line is usually macro.args or macro.return, unless there is a special variable in the middle of a macro I need to peek at. It hit me that if I am planning to send macro.return to the function anyway, I can just plan for that. This seems to work:

Code: Select all

[ macro("[email protected]:SR4"): "Pool="+Pool]

[debug("Testing.",macro.return)]

Second Macro Output = [r: macro.return]


Code: Select all

<!- Debug function
   Checks the Troubleshooting flag on the LIB:SR4 token; on 0 it ends quietly, on 1 it inserts a GM-visible tooltip with the information passed
   to the debug macro, on 2 it also pauses execution and pops up an input() box with the information passed. The macro.return will be a
   passthrough of the second argument, allowing for transparent inspection of macro.return within another macro scope.

   Mike Kozar, 07/11/2010
-->


[h: count=argCount()]
[h, IF(count>=1),CODE:{
   [title=arg(0)]
   };{
   [title=" "]
   }]
[h, IF(count>=2),CODE:{
   [troublecode=arg(1)]
   [macro.return=arg(1)]
   };{
   [troublecode=" "]
   }]

[IF(getLibProperty("Troubleshooting","Lib:SR4")), CODE:{
   [IF(getLibProperty("Troubleshooting","Lib:SR4")==2),CODE:{
      [h: input("Troubleshooting|"+title+"|Troubleshooting|LABEL|SPAN=TRUE",
      "Troubleshooting|"+troublecode+"|Troubleshooting|LABEL|SPAN=TRUE")]
      };{}]

   [h: Troubleshooting=concat(title," ",troublecode)]
   [g,t("?"):Troubleshooting]
   };{}]


Thank you for the help, guys. I'm really glad the solution did not wind up being 'give up on debug'. :D

Post Reply

Return to “Macros”