Muler Thread Note

This thread was created because the previous closed for lack of updates. Click here for the original thread with the usage instructions.

Version 1.0.8 Released

August 4, 2021

FIXED: Bug that would throw an error if set statements were run without designating a Mule.

Update Notes

Minor update for a rare case of user oversight.

Crosspost in the ScriptCards forum:

@timmaugh:

Been loving how much control I can achieve with your meta-scripts (provided I can structure them correctly to do what I want!)

I'm working on a Wildshape macro:

 !script {{
--#whisper|gm
--#sourcetoken|@(selected|token_id)
--#activepage|[*S:t-pageid]
--=Snap|[*P:snapping_increment]
--=Scale|[*P:scale_number] / 5
--=TokenScale|70 * [$Snap] * [$Scale]
--~Name|string;before; ;[*S:character_name]
--#title|[&Name]'s Wildshapes
--#leftsub|[*S:class_resource] Uses Left
--#reentrant|[&Name]WS
--?[*S:class_resource] -lt 1|NoWS
--:WSLookup|
--+Large Land Animals|[rbutton]Brown Bear::WildShape;Brown Bear[/rbutton] [rbutton]Giant Goat::WildShape;Giant Goat[/rbutton] [rbutton]Warhorse::WildShape;Warhorse[/rbutton]
--X|
--:WildShape|chosen form
--#hideTitleCard|1
--~Form|string;replace; ;;[&reentryval]
--@script|_#hideCard|1 _#title|SettingVars| _#debug|1 _&Side|get.[&Form] {& mule [&Name].WSMule} _=hp|@^([&Name]'s [&reentryval]|npc_hpformula) {& log}
--@token-mod|_set currentside|[&Side] height|[$TokenScale]*[&Size] width|[$TokenScale]*[&Size] represents|"[&Name]'s [&reentryval]" bar1_link|hp hp|[$hp] bar2_link|npc_ac bar3_link|passive_wisdom
--X|
--:NoWS|
--+No More Wildshapes!|Rest before using.
--X|
}}

I am independently able to use the mule outside this script in a simpler form, so I know it is set up correctly. Basically, each wildshape gets a line with a side #. The druid's PC is side 1, Brown Bear is side 2, etc., and the mule reflects that.

The end idea is to be able to call to the mule to get the currentside, and then call to the separate character sheet for the wildshape to reference the token size, and use both of those data in token-mod to change the token.

I've tried having the mule loaded within the base scriptcard, rather than within a subscript, but I ran into the same problem. Muler is trying to find a mule for [&Name].WSMule without knowing what [&Name] is

Hey, Colin! Glad the scripts are helping out!

What you have going is a case of operational order... Muler detects the {& mule text and immediately parses it, looking to load the mule. Since it runs before your outer ScriptCard call, you haven't filled your [&Name] variable... so that is the very text ([&Name]) that is fed to Muler as the name of the mule character, and it will never be found. To fix that, we need to defer the Mule detection until after SC has a chance to process the variable and supply it to the command line. Luckily for you, where you need it is in an API call within SC... meaning that you start another cycle of:

Roll20 parsing => MetaScript parsing => Recipient Script

Since you want the Mule available to the Recipient script, you want the mule to be found in this cycle, not in the initial cycle that processed already before handing off to ScriptCards.

Kurt built into SC a deferral character (hard-coded, so you can't change it) of a ^ for these outbound api script calls. In fact, it looks like you're already doing that for a Fetch call in that script outbound command! So, to prevent the Mule from being detected and the mule get statements from processing until the script call runs, for example, you'd do something like:

--@script|_#hideCard|1 _#title|SettingVars| _#debug|1 _&Side|get^.[&Form] {^& mule [&Name].WSMule} _=hp|@^([&Name]'s [&reentryval]|npc_hpformula) {& log}

An interesting side note is that your {&log} statement here will run at the top level of the ScriptCard (before the outbound call is sent). That's because ZeroFrame will detect that construction without respect to where it occurs in your command line, or what that position means to the way the script will process. Basically, if a metascript can see it, it's going to take care of it. By the time your outbound call is sent, then you've already gotten your log and that construct is removed from the line. If you want a downstream log (of the outbound call message), then you'd want to defer your log construct the same way:

{^& log}

In fact, you could actually have both:

{&log}{^& log}

The first one will run at the top level, logging the outer ScriptCard, and the second would run after SC removes the deferral character and dispatches the new command.

timmaugh said:

Kurt built into SC a deferral character (hard-coded, so you can't change it) of a ^ for these outbound api script calls. In fact, it looks like you're already doing that for a Fetch call in that script outbound command! So, to prevent the Mule from being detected and the mule get statements from processing until the script call runs, for example, you'd do something like:

I ended up adding a setting for the deferral character shortly after implementing it. You can use

--#deferralcharacter|%

for example to set the deferral character to %.

Perfect. Awesome... I'll make a note of that!

Not sure if I'm heading down the right track or not, but I would love to get a log after each game of each of the rolls our players rolled - we'd get a kick out of some basic statistical analysis of who rolled best/worst/etc. Would Muler be the easiest way to do this - write code to log each player's rolls for the current session, then at the end of the session save/export those results to do my own analysis?

Thanks for any info you can provide!

Muler can do this... with a little help to make it easier. =D

You'd either need to modify every roll command you would want to track (to include the Muler verbiage), or you would want to configure a Customizable Roll Listener to listen for your rolls and then track them as necessary. I'm not completely sure how to configure the CRL, but the idea would be that once it recognized something it needed to track, it would run a macro that would track the roll information in the appropriate Mule. I'll poke Scott and see if he can chime in on that idea.

For just running the Muler verbiage (whether in a single CRL-driven macro or for all the macros of the rolls you'd want to track), you'd want to understand what you were tracking, since I haven't given you an iterative key element (like a timecode) that could generate NEW variables for each roll. In other words, you wouldn't get a log of:

4:00:23pm=Bob the Hirsute, 23
4:01:30pm=Bob the Hirsute, 28
4:08:29pm=Bob the Inelegant, 24
4:09:39pm=Bob the Inelegant, 4

You'd get more of a log of:

Bob the Hirsute Best Roll=28
Bob the Hirsute Worst Roll=23
Bob the Inelegant Best Roll=24
Bob the Inelegant Worst Roll=17
Overall Best Roll=28, Bob the Hirsute
Overall Worst Roll=17, Bob the Inelegant

And to do it right, I'd use APILogic to run an if/else comparison:

IF (the value for this character's best roll in the mule) is less than the current roll, track this as the best roll for that character,
  ELSE
    IF (the value for this character's worst roll in the mule) is greater than the current roll, track this as the worst roll for that character

If that is acceptable, can you post the roll verbiage you'd output that you'd want to track... then I can try to help with the Muler verbiage and maybe Scott can help with the CRL verbiage/setup.

Hmm I'm wondering if at this point it would be easier to write a script to scrape our chat log and pull out the roll history that way... I'll look into that a little bit and return here - this is my first exposure to the Roll20 API while I at least have Python experience outside of D&D ;) Thanks for your quick response!