Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

[Macro] Question about reading a roll result

December 15 (2 years ago)

Edited December 15 (2 years ago)

Hi, I'd need a looting macro that goes through a lot of "if" conditions to end with a text result, but I'd need my macro to read the past rolls result for that, for example :

/roll 1d100

if it's between 51-90 → /roll 1d2 → if it's 2 then /w gm "The player didn't find anything"
                                                     → if it's 1, return to normal line but "Rarity" = Common

if it's 10 or lower → /roll 1d6


if it's any other result → /roll 1d5 → if it's 1, then "Drop = Item"
                                                      → if it's 2, then "Drop = Book"

                                                      → etc..

/w gm "Player found a [Rarity] [Drop]"

Which would become "Player found a Common Book"

Is it possible ?


December 15 (2 years ago)
David M.
Pro
API Scripter

You may want to check out the Scriptcards mod. It can handle that type of conditional logic pretty easily.

December 16 (2 years ago)
timmaugh
Pro
API Scripter

Metascript option you're free to not use...

You weren't complete in your branching examples, so I adapted what you were doing to a way that could show how metascripts could help. The idea here is that you roll 1d100. Depending on what you roll, you could get a more/less rare item of different value.

Create mules of variables on a character. I'll use the character MuleBoy and create mules (abilities) named:

LoodD100
LootRarity
LootGoodStuff
LootBadStuff
LootStandardStuff

I'll fill them with the appropriate values:

LootRarity

<=1=Unremarkable
2=Common
3=Uncommon
4=Rare
5=Very Rare
>=6=Unique

LootGoodStuff

<=1=Vintage wine
2=Jeweled totem
3=Oxford Orcish to Elvish Translation Dictionary
4=2lbs Yak Hair, Blessed
5=Weaponizable Infernal Contract
>=6=Bowl of Unspoilable Pudding

LootBadStuff

<=1=Nothing
2=Collected notes from the magical academy's worst-ever student
3=Chatty halfing
4=Muck-rake
5=Beard-hair sword
>=6=Note reading, "Sorry I took the thing you were looking for"

LootStandardStuff

<=1=Book
2=Radio
3="So you find yourself in a fantasy adventure, let me explain radios" instruction manual
4=Food
5=Costume jewelry
>=6=Pottery

Then the LootD100 mule, which is where the magic happens:

<=10=get.MuleBoy.LootRarity.[[1d5+1]].value/get get.MuleBoy.LootGoodStuff.[[1d6]].value/get
11-50=get.MuleBoy.LootRarity.[[1d2+1]].value/get get.MuleBoy.LootStandardStuff.[[1d6]].value/get
51-90=get.MuleBoy.LootRarity.[[1d2]].value/get get.MuleBoy.LootStandardStuff.[[1d6]].value/get
>91=get.MuleBoy.LootRarity.[[1d3+2]].value/get get.MuleBoy.LootBadStuff.[[1d6]].value/get

What's Happening

So when you roll a 1d100 against the LootD100 mule, it reads your result and makes a secondary roll against the LootRarity mule and one of the item mules. You can structure this as you see fit, including whatever options and ranges match your needs.

Usage

In isolation, the usage could look like this:

!\w gm @{selected|token_name} found get.MuleBoy.LootD100.[[1d100]].value/get{&simple}

Or, if you wanted to use this in a roll template, you could so something like:

!\w gm &{template:default} {{name=@{selected|token_name} Is Looting}}{{Item 1=get.MuleBoy.LootD100.[[1d100]].value/get}}{{Item 2=get.MuleBoy.LootD100.[[1d100]].value/get}}{&simple}


SCRIPTS REQUIRED:

ZeroFrame, Muler (Beta)

December 16 (2 years ago)

I really like the Mule idea !


However, how can I put a condition inside another condition ?

For example, on the line :

51-90=get.MuleBoy.LootRarity.[[1d2]].value/get get.MuleBoy.LootStandardStuff.[[1d6]].value/get


How can I say, "if it's between 51-90, then roll 1d2, if it's 2 then "/w gm Player found nothing, else Rarity = Common" ?

December 16 (2 years ago)
timmaugh
Pro
API Scripter

If you look at the line you quoted, there, it is already doing it... when it does this:

get.MuleBoy.LootRarity.[[1d2]].value/get

it's rolling a 1d2 and retrieving the value from the LootRarity mule. I ended up putting more things in my LootRarity mule than just two options (finding nothing vs finding something common), but the overall structure is up to you. Maybe you have one mule that handles rarity for most everything (LootRarity), except for when you roll 51-90, in which case your 2 choices are finding nothing or finding something common.

What you have to think about is what the overall command line looks like when this is done... in other words you have to think about every branch of the logic producing a meaningful message.

Will they all whisper to the gm? If so, put that at the start of the line.

Will they all use a roll template? If so, that can go at the start, too.

However, if the answer to either of those questions is "not all of them will do that", then you have to build your branches as fuller statements. Those that will whisper will need the "/w gm" at the beginning.

Similarly, will they all require output to the chat? If so, we can put the {&simple} in the main message string. If only some of them will need to output to the chat (and others might not output anything, or might go on to a separate script), then we'll have to be more granular when we use the {&simple} syntax to output something.

I'm mentioning all of that because to my sensibility you wouldn't want the "/w gm" in the "Player found nothing"... you would always be whispering to the GM and only changing *what* you're whispering.

But if this doesn't make sense or doesn't answer your question, post back with more of the outcomes of the various branches (if 51-90 followed by a 1d2=2 should whisper to the GM  that the player/character found nothing, then are there branches where nothing would be whispered?) and I'll try to show how to  accommodate all of it.

December 17 (2 years ago)

Edited December 17 (2 years ago)

May I ask how do I set a variable inside a line ?


For example, how can I say:

If it's 10 or lower, then Rarity = Legendary, then roll 1d5

In the same line ?

Would it be like this ?

<=10=Legendary get.MuleBoy.LootDrop.[[1d5]].value/get


And then LootDrop does this :

<=1=Weapon
2=Item
3=Science
4=Food
>=5=Material
December 18 (2 years ago)
timmaugh
Pro
API Scripter

Yes, exactly!

So anywhere you have the get.Char.Mule.var/get, that space will be filled with what you retrieve. Here, you might get "science", so this would become "Legendary science". Then that result gets returned to the get statement that caused the d100 roll in the first place.

December 18 (2 years ago)

Edited December 18 (2 years ago)
Sadly, it doesn't seem to work, did I do anything wrong ?



Here are my mules inside the character MuleBoy :

LootD100

<=10=Legendary get.MuleBoy.LootDropCrit.[[1d6]].value/get
11-20=Epic get.MuleBoy.LootDrop.[[1d5]].value/get
21-50=Rare get.MuleBoy.LootDrop.[[1d5]].value/get
51-90=Common get.MuleBoy.LootCommun.[[1d2]].value/get
>=90=Mediocre get.MuleBoy.LootDrop.[[1d5]].value/get


LootCommun

<=1=Common get.MuleBoy.LootDrop.[[1d5]].value/get
>=2=Nothing


LootDrop

<=1=Weapon
2=Item
3=Science
4=Food
>=5=Material


LootDropCrit

<=1=Weapon
2=Item
3=Science
4=Food
5=Material
>=6=Gun


December 19 (2 years ago)
timmaugh
Pro
API Scripter

You have to start as a bangsy message (with an exclamation point)... Then the {&simple} is what tells it, once all of the metascripting is done, to output the current line to chat (instead of continuing to your script stack). Otherwise that all looks right.

December 19 (2 years ago)

It works ! Thank you so much !! Your script is absolutely amazing and so easy to use, I'm stunned!

December 19 (2 years ago)

Edited December 19 (2 years ago)

May I ask, how can I show the d100 result for the players ?

For example, the macro whispers to me what the player gets and everything, but it sends in the chat only the result of the D100 (like 74, 32, 99, etc..)



Oh, and, how can I do a query inside of it too ? For example asking "Is the area popular ?" and from the different answers change the Mule you call

December 19 (2 years ago)
timmaugh
Pro
API Scripter

Thanks, Kinji!

To include a query, you just have to use the normal query syntax. However, one limitation is that the query has to be at the top level of the whole chain. Queries are going to resolve before the message reaches the metascripts, so once we're into the mules, you won't get another chance for a secondary query.

A couple of options...

If you know you're going to want the answer to the question for every message, you can ask it at the top level. In that case, if you need to refer to the answer in a mule return, you can't use the normal query syntax again. If you answer the query in the outer message and then want to reference the answer in something you get from a mule, the rollquery syntax won't resolve... Instead you'll have to set a variable in a mule that you can then read again.

The other option would be if you can structure things correctly, you can return a button to chat that can give you another chance for a query (by building the right command line). The trick there would be stashing anything from the first message you need to keep for later messages. That, again, would be using muler set statements and reading them in later, button-driven messages.

December 19 (2 years ago)
timmaugh
Pro
API Scripter

Oh, and to show something to the players, you have a couple of options. When you send a message through chat, it is either whispered or it isn't. One message, one output option.

To do what you want, you can use Plugger (another metascript) to initiate a second message from within the original. Effectively, you whisper a new message to your player with some info while you continue to add more information that will get whispered to you.

Another option would be to use DiscreteWhisper as the original message script handle, but differentiate the output by using asides that only you see. DiscreteWhisper basically is a way to send differentiated messages to multiple recipients where each person might get parts of the message, but not all... (Like revealing details A and B to the party, but also details C and D who rolled really well for their perception checks.

If any of that sounds like something you want to try, post back and we can figure it out.

December 19 (2 years ago)

Edited December 19 (2 years ago)

For the Query I think the first option seems better, but I'd need more details on where and how to set the Query and how to call and read the variable that will result from the roll on other Mules

As for the roll to show to the players, Plugger seems a good idea, may I have an example on how to show the d100 to the players without showing them the rest of the Mule functions ?

December 20 (2 years ago)
timmaugh
Pro
API Scripter

So, you know you can typically do something like this:

The value is ?{Pick|1|2|3}. That means the value is ?{Pick}.

Or with ZeroFrame, starting that as a bangsy message and using the {&simple} to output a chat message after any metascripts would have at the message (though, in this case, I'm not using a metascript -- just trying to keep the example clear):

!The value is ?{Pick|1|2|3}. That means the value is ?{Pick}.{&simple}

You're reusing the query handle later in the message, and whatever the player (or you) pick from the options (or input, if it isn't built as  dropdown query) the result is subbed in whenever the parser encounters the handle. That is happening on the Roll20 side before it gets to the metascripts.

If that message has a muler get statement:

!The value is ?{Pick|1|2|3}. That means the value is get.MuleBoy.LootExample.?{Pick}/get.{&simple}

That will still work, because the R20 parser will be able to retrieve the value of the query. The query syntax is still at the top level of the message, present when Roll20 parsers get a turn at the message.

If, on the other hand, the text that is in the mule (which will be returned) needs to reference the query value, it won't work directly:

!The value is ?{Pick|1|2|3}. That means the value is get.MuleBoy.LootExample.[[1d100]]/get.{&simple}

If you roll 50 and the line for 50 looks like this:

50=?{Pick} Legendary Artifact

Then that query reference won't resolve. That's when you have to set the query result to a variable with a set statement:

!The value is ?{Pick|1|2|3}. That means the value is get.MuleBoy.LootExample.[[1d100]]/get.{&simple}set.MuleBoy.LootLibrary.Pick=?{Pick}/set

The set statement gets parsed out of the finished command line, so it really doesn't matter where you put it. And as long as you include the fully qualified reference to the mule (character + ability name), you can do it like the above with no separate {&mule statement}.

Then your "50" line in your mule would reference the "Pick" variable you just filled instead of the query reference:

50=get.MuleBoy.LootLibrary.Pick/get Legendary Artifact

So you're setting it at the top level of the macro, and retrieving that variable in your mule return.

Using Plugger to Whisper to Another Player

Plugger basically issues new outbound commands in the middle of another message running. If the outbound script is set up to "plug in" to Plugger, then it can return a value to that position in the line (much the same as your muler get statements return a value). In your case, you don't need to return anything... you just want to pass on the information to the player. So that's simple enough: just build your statement between the eval blocks, and be sure to include a {&simple} for the secondary message (for your player), because everything Plugger sends will be a bangsy message to begin with.

Plugger's eval blocks look like this:

{&eval} ... {&/eval}

Just replace the "..." with what you want the message to be.

A simple example would be:

!/w gm this is the main message where I see [[1d10]] and [[2d20kh1]].{&eval}/w Igtharian This is to Igtharian, where he only sees $[[0]].value. {&simple}{&/eval}{&simple}

You can do templated output for each, if you want:

!/w gm &{template:default}{{name=Proof of Concept}}{{GM Output=This is the main message: [[1d10]] and [[2d20kh1]]}} {&eval}/w Igtharian &{template:default} {{name=Secondary Proof of Concept}}{{Character Output=This is to Igtharian: $[[0]].value }}{&simple}{&/eval}{&simple}

One thing to remember is that the rolls, like the query results, exist in the top level/original command line. If I had left off the .value in the above command line, then when the secondary command gets issued from Plugger and the Roll20 parsers go to look for the roll to build the hover information  (or just display the value), they won't find any information for the roll! That's why I did the .value at the top level command -- to render the die roll down to a value that can exist as part of the message.

All of this (the original muler get statements, the new muler set statement, and the new Plugger syntax) can exist in the same message. Hopefully this is enough info for you to see how, but post back if you need help.

December 20 (2 years ago)

Edited December 20 (2 years ago)

Thank you !!


Everything's done and good for Plugger, thank you again for helping me understand it !

However, I still need a little bit of help about the Query part :

Is there any way to make it so that Muler reads the "Pick" mule/variable and chooses a Mule category from it ?

As an example (and obviously wrong and not working), I'd need something like that :

<=10 && ?{Pick}=1=Legendary
<=10 && ?{Pick}=2=Epic
<=10 && ?{Pick}=3=Common

Is it possible in any way ?

Again, thank you so much for your help, I'd never have understood any of those without your clear and amazing explanations.

December 20 (2 years ago)

Edited December 20 (2 years ago)
timmaugh
Pro
API Scripter

Glad we're getting you sorted, Kinji!

For your question about multiple conditions, you have a couple of options for that.

1. You can do it with another Mule and embedded get statements. Using multiple mules is the same idea people will do with rollable tables sometimes, where you would have a "LootPick" mule for each of the different results Pick could generate (ie, a Pick for your 10 range, one for your 11-20 range, one for your 21-50 range, etc.). For instance, say you had a "LootPick10" mule, and you roll an 8 on the d100. You already know you're pulling from the <=10 line in your d100 Mule... so that line could reference the LootPick10 mule. This would require the ?{Pick} result to be set at the top level of the macro, so that it was there when we got to the mule line; I'll assume that would be named "PickResult", stored in the "LootResult" mule. If all of that is accurate, then we can embed a get statement in another get statement. The inner one will be detected and resolved first:

<=10=get.MuleBoy.LootPick10.get.MuleBoy.LootResult.PickResult/get/get ...
11-20=get.MuleBoy.LootPick20.get.MuleBoy.LootResult.PickResult/get/get ...
21-50=get.MuleBoy.LootPick50.get.MuleBoy.LootResult.PickResult/get/get ...
...etc...

Based on what I *think* you're trying to do, I don't think that's a particularly efficient method, but I'm including it in case I don't have a grasp on what you want to do and you might see that this method would work better than others.

2. You can use APILogic (another metascript) to introduce a conditional to your mule return. This would be more efficient than the above, but not the closest match to what you want (I think -- see below for what might be the closest match). This approach is, however, extremely powerful.

<=10={&if get.MuleBoy.LootResult.PickResult/get = 1}Legendary{&elseif get.MuleBoy.LootResult.PickResult/get = 2}Rare{&else}Common{&end} ...

That will work by default (with ZeroFrame installed) because Muler runs at a higher priority than APILogic, so the get statements will resolve before the logical conditions are evaluated. (If you want to see the priority of the metascripts you have installed, run !0 from the chat -- this order can be rearranged as a configuration to ZeroFrame, or it can be altered for a given loop within a given message).

One added benefit of using APILogic is that you wouldn't have to commit your ?{Pick} result to a mule. APILogic lets you define terms and definitions as text replacement operations in the command line. ZeroFrame processes the message on a loop, and with every loop, each metascript gets a chance to detect any work it has to do. One of the things APIL has to do is replace defined terms with their definitions... so when the mule returns a defined term, APILogic will get a chance to replace it. So if in the top level of the macro you define "thepick" to be the result of the ?{Pick} query:

{&define ([thepick]?{Pick|1|2|3}) }

...that means that the above example of using APILogic in a mule return can be rendered simply:

<=10={&if thepick = 1}Legendary{&elseif thepick = 2}Rare{&else}Common{&end} ...

Your top level macro would lose the set statement.

3. What I think you're actually trying to do is to give yourself the ability to choose an option instead of roll one... while reserving the ability to roll if you actually want to do that. If that's what you're looking to do, then you can put your the roll in the query:

?{Pick|Random,[[1d6]]|Legendary,[[1]]|Rare,[[2]]|Common[[3]]}

Then, since that is going to return a roll, regardless, you can use the ZeroFrame .value statement to get the value, and assign it either to a mule variable or to a definition:

{&define ([thepick]?{Pick|Random,[[1d6]]|Legendary,[[1]]|Rare,[[2]]|Common[[3]]}.value) }

Now you've either selected an option from the query manually, or let it roll one for you. Elsewhere when you use "thepick", it will be replaced with what has been selected. If you wanted to use that to pull from a Mule of some special rarity (call it "LootSpecialRarity"), then your "10" line from your d100 mule can become:

<=10=get\.MuleBoy.LootSpecialRarity.thepick/get ...

Note I used the ZeroFrame deferral character (a backslash) between the get and the dot (.). This is because, like I said, by default Muler runs before APILogic... so before you go get something from your mule using a definition, you need to replace that definition with the value you've assigned to it. So we slow down this muler construction by one cycle (using one backslash), so that APILogic has a chance to work, first. If, instead of a definition you used a muler set statement at the top level of your macro, then you would simply do this with a nested get, as I showed before:

<=10=get.MuleBoy.LootSpecialRarity.get.MuleBoy.LootResult.PickResult/get/get ...

December 21 (2 years ago)

Edited December 21 (2 years ago)

The second one with APILogic did it for me, thank you a lot !


About showing the d100 result to the players tho, even though I made it work, I tried to make it a bit fancy for my players with a Power Card, but I can't get it to send one PC to the GM with everything and one to the players with only the result, do you have any idea about that ?


Here is how I tried it :

!power {{
--whisper|gm
--txcolor| black
--titlefontsize|2rem
--border|2px solid#000
--bgcolor|#980000
--name|Looting

--!loottext | ~C@{target|token_name} found: get.MuleBoy.LootD100.[[1d100]].value/get~C

}}


!power {{
--txcolor| black
--titlefontsize|2rem
--border|2px solid#000
--bgcolor|#980000
--name|Looting of @{target|token_name}

--!loottext2 | ~C{&eval} $[[0]].value{&simple}{&/eval}{&simple}~C


}}
December 21 (2 years ago)
timmaugh
Pro
API Scripter

Whatever you want to send using plugger needs to be between the EVAL blocks... and if you want to reference a roll by a roll marker (ie, $[[0]] ) that roll has to be in the same message as what you're currently sending. Two PowerCard command lines means two messages, and the roll data won't stick around from one to the next (roll queries do, oddly enough, but not rolls themselves).

Both of those things get solved by enclosing one powercard message in the EVAL blocks... I don't know the PowerCards  syntax well enough to critique that, so I'll just take what you provided. The "loottext" and "loottext2" look like maybe they are issuing an outbound command themselves already, in which case you might not need Plugger, but again I don't know the PC syntax. For now, I'm going to remove the bang at the beginning and the "~C" bounding the value side of the pipe. I trust you to know better what your trying to do with PowerCards, and I'm just trying to show how to frame one message in another using Plugger. That would look something like:

!power {{
{&eval}!power --whisper|gm --txcolor| black --titlefontsize|2rem --border|2px solid#000 --bgcolor|#980000 --name|Looting --loottext| @{target|token_name} found: get.MuleBoy.LootD100.[[1d100]].value/get{&/eval}
--txcolor| black
--titlefontsize|2rem
--border|2px solid#000
--bgcolor|#980000
--name|Looting of @{target|token_name}
--loottext2 |$[[0]].value
}}

In this case, you don't need any of the {&simple} tags, because those just make sure that what started out as a bangsy message should output to chat... this could be for shaping normal text with mule-gets or logical IF/ELSEs. It's also good for templated messages (like &{template:default} ) Once you have that, {&simple} bypasses the rest of your scripts and outputs the command line to chat. In your case, you want the message to continue to the scripts because you ultimately want PowerCards to shape the output that hits the chat. Your meta-operations are just shaping the PowerCards syntax to be the right shape for the output you want. Even when you use Plugger to output one message inside the other... that second/outbound message needs to also hit PowerCards, so no {&simple} required.

When Plugger runs, it will parse out everything between (and including) the {&eval}/{&/eval} blocks, so the one PowerCard's syntax and options won't interfere with the other. They just won't be there when the outer/housing PowerCard is evaluated by the PC script.

December 23 (2 years ago)

Hi again !


I'm running on my very last wall, it seems :

All of my Mules and mules inside other mules where all using one exact same condition on the variable "thepick"

However, it seems that only the first Mule can read the variable. After that they all end up as false.

Any idea ? Am I doing something wrong ?


Here is how I set the variable :

!{&define ([thepick]?{Which ?|1|2|3|4})} /w gm &{template:default}{{name=@{target|token_name} found}} get.MuleBoy.LootD100.[[1d100]].value/get {&simple} {&eval} &{template:wod} {{name=@{target|token_name}}} {{result=$[[0]].value}}{&simple}{&/eval}
December 23 (2 years ago)
timmaugh
Pro
API Scripter

I would need to get a fuller look at your setup, Kinji. Here's what I can tell you I've mocked up in my environment to test, and it's working fine... (also, I can tell you something in what you just posted that is jumping out at me as incorrect, so maybe that's the problem?)...

In my LootD100 mule, I have the "10" line looking like this:

<=10={&if thepick = 1}Legendary{&elseif thepick = 2}Rare{&else}Common{&end} get.MuleBoy.LootGoodStuff.[[1d6]].value/get

Then, in the normal macro, I have:

!/w gm &{template:default}{&define ([thepick]?{Pick|1|2|3})}{{name=@{target|token_name} Looting Result}}{{Found=get.MuleBoy.LootD100.10/get}}{&simple}

I'm forcing the "10" line instead of rolling it, but the effect would be the same as rolling 10 on the d100. The definition is established at the top level, but the muled variable can still read it. If I pick "1", I get "Legendary", etc.

This works for me because the APILogic IF block runs without impacting the return of a mule variable. If the return of a mule variable was dependent on the return from the IF (as opposed to conditionally included based on the evaluation of the IF), then we might have to slow the get statement down so that APILogic can process first, followed by Muler.

This would be an example of a mule variable "conditionally included" based on the evaluation of the IF block:

{&if a = a}get.MuleBoy.LootD100.[[1d100]].value/get{&end}

The entire mule statement is within the IF condition. It will run, even if it runs before the IF block resolves (the only that would blow this arrangement up is if you are calling a variable that doesn't exist... even if muler returns a variable you don't ultimately need, it will be up to APILogic to drop that portion of the command line).

On the other hand, this is an example of a variable dependent on the IF result:

get.MuleBoy.{&if a = a}Legendary{&else}Rare{&end}.[[1d6]].value/get

In that case, you don't know what mule to pull from until the IF block resolves. In that case, you'd have to slow the get statement down:

get\.MuleBoy.{&if ...

About the mistake I see in what you shared... unless your LoodD100 mule has template parts (including the double opening & closing braces), you will never see it. It will be considered extraneous text (anything outside of a template part is not included in the message output).  You can see in my example, above, that I put the get statement as the "data" side of a template part:

{{Found=get.MuleBoy.LootD100.10/get}}

See if that helps you get to the bottom of what you have going on. If you still need help, shoot me an invite in a PM and I can take a look at your setup to get a fuller picture of what you're trying to do.

December 23 (2 years ago)

Edited December 23 (2 years ago)

I can easily show you my issue, I made 4 Test mules to demonstrate it :

If I have a macro that calls a Test mule like this, with the define included :

!{&define ([thepick]?{Which?|1|2|3|4})} /w gm get.MuleBoy.Test.[[1d100]].value/get {&simple}


And then the following Test mules :


Test

>=1={&if thepick = 1}Yes get.MuleBoy.Test2.[[1d100]].value/get{&else}No get.MuleBoy.Test2.[[1d100]].value/get{&end}


Test2

>=1={&if thepick = 1}Yes get.MuleBoy.Test3.[[1d100]].value/get{&else}No get.MuleBoy.Test3.[[1d100]].value/get{&end}


Test3

>=1={&if thepick = 1}Yes get.MuleBoy.Test4.[[1d100]].value/get{&else}No get.MuleBoy.Test4.[[1d100]].value/get{&end}


Test4

>=1={&if thepick = 1}Yes {&else}No {&end}


You will get the following result :


As you can see, only the first Mule can read the variable, after that it always returns false.. Any idea why ?

December 24 (2 years ago)
timmaugh
Pro
API Scripter

I do know what's going on!

...

And I do not like what is going on!

=D

The story goes like this:

Once upon a time, there was a metamancer who thought he would add to his APILogic script definable terms for text replacement. And all was good in the world.

But then that metamancer realized that when working with ZeroFrame loops, you might want to preserve your definitions from loop to loop. And so he abstracted the process to store those definitions with the message object, itself. That way the definitions would be there every time the loop looked for definitions. And all was good in the world.

Then,  one day, someone in the metamancer's lab -- it could have been the metamancer; it could have been his idiot helper (who totally exists... but you wouldn't know him... he's from Canada-sville-field-ton) -- decided to push out code that built off a previous version, dating to before the process was abstracted to survive the many loops. So the ability to have definitions preserved was lost.

*sigh*

Let me hunt back through my library of previous versions. I'll get an update pushed out asap, but with blizzard, sickness, xmas... might be a day or two.

December 25 (2 years ago)

Alright, thank you so much !!

December 25 (2 years ago)

Edited December 25 (2 years ago)
timmaugh
Pro
API Scripter

I pushed an update... you can get it from my repo until it gets merged into the one-click (not sure when that will happen this week, or at all until the following week... which is, of course, New Years week, so maybe not for a couple of weeks).

Here is my result of your test macros:


Thanks for spotting that bug and giving me the chance to fix the script!

December 25 (2 years ago)
With pleasure ! Everything's working fine now thank you very much !!