Roll output expanded when it shouldn't be

[khabalox]

Code: Select all

[h: WpnMod = arg(0)]
[h: STRMod = getAbilMod("Strength")]
[h: SizeMod = getSizeMod()]
[h: AttRoll = 1d20]

[getName()] attacks:<br>

<!-- Check for Crit Success/Failure-->
 [switch(AttRoll),code:
    case 1: {<b>Critical Failure</b><br>};
    case 20: { 
	<b>Threat</b><br>
 	Critical Success Roll is: [1d20+STRMod+BAB+SizeMod+WpnMod]<br>
	Normal Damage is [if(getSize()=="Medium") : 1d8+STRmod+WpnMod]
	     [if(getSize()=="Large") : 2d6 +STRmod+WpnMod]
	};
    default: {
	AC: [AttRoll+STRMod+BAB+SizeMod+WpnMod]<br>
	Dam: [if(getSize()=="Medium") : 1d8+STRmod+WpnMod]
            	   [if(getSize()=="Large") : 2d6 +STRmod+WpnMod]
}]

This UDF (named 'Attack') is on the Lib:token 'Lib:Functions'. getAbilMod() and getSizeMod() are other UDFs which I've tested and they run with no problems. Attack() runs fine, except for the output of 'getName() attacks' line. When I call if from another token

Code: Select all

[Attack(1)]

What I get is this:
getName() = getName()Dannix«  attacks:
AC: 23
Dam: 6 »
There are tooltips for the 23 and 6 (as expected and desired).

I figured if I changed:

Code: Select all

[getName()] attacks:<br>

to

Code: Select all

[r:getName()] attacks:<br>

it would work, but then I get this:
Dannix attacks:
AC: AttRoll+STRMod+BAB+SizeMod+WpnMod = 11 + 1 + 9 + 0 + 1*22« 
Dam: 9  »
There is a little ASCII box where the * is above. The same thing happens when I run it from a different token, and the same expansion happens when the Threat switch is executed. Changing the AC line to [r:...] fixes it, but suppresses the tool tips, which I don't like. Any ideas?

And on an unrelated note: Is there anyway to store global variables (that exist after a macro is done executing) other than using Token Properties? I'm looking for a way to keep track of which spells are active, among other things.

[Brigand]

I've been getting the [ ] on the output in some cases too, but I've switched to using the same variable scope and it solved my problem.

[Mathemagician]

Code: Select all

[h: WpnMod = arg(0)]
[h: STRMod = getAbilMod("Strength")]
[h: SizeMod = getSizeMod()]
[h: AttRoll = 1d20]

[getName()] attacks:<br>

<!-- Check for Crit Success/Failure-->
 [switch(AttRoll),code:
    case 1: {<b>Critical Failure</b><br>};
    case 20: { 
	<b>Threat</b><br>
 	Critical Success Roll is: [1d20+STRMod+BAB+SizeMod+WpnMod]<br>
	Normal Damage is [if(getSize()=="Medium") : 1d8+STRmod+WpnMod]
	     [if(getSize()=="Large") : 2d6 +STRmod+WpnMod]
	};
    default: {
	AC: [AttRoll+STRMod+BAB+SizeMod+WpnMod]<br>
	Dam: [if(getSize()=="Medium") : 1d8+STRmod+WpnMod]
            	   [if(getSize()=="Large") : 2d6 +STRmod+WpnMod]
}]

This UDF (named 'Attack') is on the Lib:token 'Lib:Functions'. getAbilMod() and getSizeMod() are other UDFs which I've tested and they run with no problems. Attack() runs fine, except for the output of 'getName() attacks' line. When I call if from another token

Code: Select all

[Attack(1)]

What I get is this:
getName() = getName()Dannix«  attacks:
AC: 23
Dam: 6 »
There are tooltips for the 23 and 6 (as expected and desired).

I figured if I changed:

Code: Select all

[getName()] attacks:<br>

to

Code: Select all

[r:getName()] attacks:<br>

it would work, but then I get this:
Dannix attacks:
AC: AttRoll+STRMod+BAB+SizeMod+WpnMod = 11 + 1 + 9 + 0 + 1*22« 
Dam: 9  »
There is a little ASCII box where the * is above. The same thing happens when I run it from a different token, and the same expansion happens when the Threat switch is executed. Changing the AC line to [r:...] fixes it, but suppresses the tool tips, which I don't like. Any ideas?

And on an unrelated note: Is there anyway to store global variables (that exist after a macro is done executing) other than using Token Properties? I'm looking for a way to keep track of which spells are active, among other things.

Don't have time right now to track down the bug you're having with your macro, but global variables can also be stored in the token properties of a Library Token.

[khabalox]

Don't have time right now to track down the bug you're having with your macro, but global variables can also be stored in the token properties of a Library Token.

Hmm... I think I see what you mean. I'll play around with that. I'm not sure I totally understand the difference between Library Tokens and regular Tokens yet. I've only been using MT for a week or two.

Regarding the specific macro problem, let me add this. The macro was originally on a regular token where it ran fine. The original macro did not have the getName() function, and WpnMod was a "constant" I defined at the beginning of the macro.

Looking at this with the clarity of the morning, I'm wondering if the problem is because getName is a function as opposed to a roll option (or vice versa) and/or I'm missing a colon.

[zEal]

The problem is 'layered' tooltip data. When you have a macro call [Attack()] it's giving that roll it's own tooltip/expanded output, and there are rolls inside Attack() that are creating their own tooltip/expanded output. Try using [r: Attack()] when you call it.

[khabalox]

Hmmm... I see what you're saying. When I add the r: option...

Code: Select all

[r:Attack(1)]

I get this:

Dannix attacks:
AC: AttRoll+STRMod+BAB+SizeMod+WpnMod = 19 + 2 + 9 + 3 + 134
Dam: 1d8+STRmod+WpnMod = 6 + 2 + 19 '' = ''

I've played around with [r:], [e:] and [t:] options, but couldn't get it to work the way I want. The really odd thing is that when I just use [Attack(1)] and [r:getName()], the Damage roll appears as wanted (i.e. just the total, with the tooltip available, while the To Hit roll (AC: line of output) show expanded.

I made some minor changes to the macro to make it a little easier for others to read, so here is the current state. I removed "BAB" which is a Token Property, and I change the various Mods to "magic numbers."

Code: Select all

[h: WpnMod = 1]
[h: STRMod = 2]
[h: SizeMod = 3]
[h: AttRoll = 1d20]

[r:getName()] attacks:<br>

<!-- Check for Crit Success/Failure-->
 [switch(AttRoll),code:
    case 1: {<b>Critical Failure</b><br>};
    case 20: { 
	         <b>Threat</b><br>
 	         Critical Success Roll is: [1d20+STRMod+SizeMod+WpnMod]<br>
	         Normal Damage is [if(getSize()=="Medium") : 1d8+STRmod+WpnMod]
	               [if(getSize()=="Large") : 2d6 +STRmod+WpnMod]
	};
    default: {
	         AC: [AttRoll+STRMod+SizeMod+WpnMod]<br>
	         Dam: [if(getSize()=="Medium") : 1d8+STRmod+WpnMod]
            	    [if(getSize()=="Large") : 2d6 +STRmod+WpnMod]
}]

This outputs:

Dannix attacks:
AC: AttRoll+STRMod+SizeMod+WpnMod = 3 + 2 + 3 + 19« 
Dam: 8  »

I think I will just give up on this. There is not a lot to be gained from making this a UDF, as each PC has different weapons (and hence damage) as well as other differences. My main goal was to abstract the attack roll (and crit checks) so that I could write a looping macro for Full Attack (playing 3.5e D&D, where every 5 points of Base Attack Bonus grants you an extra attack at -5).

I suppose it wouldn't be too hard to pass the Attack UDF all the necessary arguments from the PC token (e.g. [Attack(1, 1d8, 2d6)], but if I can't get the output readable, I'll have to go another route.

[zEal]

I just tried your updated code, and called it using [r: Attack()] and it worked exactly as it should. /shrug

[khabalox]

I've been getting the [ ] on the output in some cases too, but I've switched to using the same variable scope and it solved my problem.

Oops.. I missed this the first time. I'm assuming you mean the 4th argument to defineFunction(). Initially, my onCampaignLoad included this:

Code: Select all

[defineFunction("Attack","Attack@Lib:Functions")]

I switched it to this:

Code: Select all

[defineFunction("Attack","Attack@Lib:Functions",0,0)]

but I still get the same problem.

I just tried your updated code, and called it using [r: Attack()] and it worked exactly as it should. /shrug

Hmm... Well thanks for trying.

FWIW, I'm using 1.3b56; system specs are:
Dell Latitude E6500
Win XP SP3
4 GB RAM
Core 2 Duo T9600 @ 2.8GHz

Maybe I'll try starting a new campaign file from scratch. <shrug>

[Azhrei]

FWIW, I'm using 1.3b56; system specs are:
Dell Latitude E6500
Win XP SP3
4 GB RAM
Core 2 Duo T9600 @ 2.8GHz

Maybe I'll try starting a new campaign file from scratch. <shrug>

For something that is apparently software-related, it would also be helpful to know which version of Java you're running. You can get that from a command prompt by executing "java -version".

[Rumble]

I think the problem is that you don't have a "false" operation on your IF(): roll options. There's a bug that with an if option that doesn't have an r:, h:, or e: expansion, if you fail to put the "false" half of the statement in, it prints out a superfluous double quote.

Try changing your if options to something like:

Code: Select all

[if(getSize()=="Large") : 2d6 +STRmod+WpnMod;""]
 

When I did that, coupled with calling it as [r:attack(1)], I had tooltips where expected and no extraneous characters or expansion.

[khabalox]

I think the problem is that you don't have a "false" operation on your IF(): roll options. There's a bug that with an if option that doesn't have an r:, h:, or e: expansion, if you fail to put the "false" half of the statement in, it prints out a superfluous double quote.

I tried this and it worked. But then I noticed something. I have the Lib:token, and then two regular tokens which I'm using for testing. One of the tokens was calling Attack as a macro ([MACRO("Attack@Lib:Functions"):BAB]). The other token was calling it as a UDF ([Attack(BAB)]). Calling the macro works with or without the false conditions, and with or without the r option in [r:getName()]. Calling the function does not work either way.

This begs the question (for me anyway), what exactly is the difference between a UDF and a callable macro on a Lib:token? My first thought is that a UDF returns something (a value, JSON, etc.), while a macro only does something (i.e. outputs commands/text to the chat window which then get parsed). Is that the main/only difference? Other than "bugs" like this one, is there a reason to not make something a UDF as opposed to just a macro on a Lib:token?

For something that is apparently software-related, it would also be helpful to know which version of Java you're running. You can get that from a command prompt by executing "java -version".

Durr... of course. I guess it's a moot point, but here it is anyway.
Java version is 1.6.0_07
Java SE Runtime Environment (build 1.6.0_07-b06)

[Rumble]

This begs the question (for me anyway), what exactly is the difference between a UDF and a callable macro on a Lib:token? My first thought is that a UDF returns something (a value, JSON, etc.), while a macro only does something (i.e. outputs commands/text to the chat window which then get parsed). Is that the main/only difference? Other than "bugs" like this one, is there a reason to not make something a UDF as opposed to just a macro on a Lib:token?

AFAIK, there's not much difference, aside from utility. Advantages of UDFs include:

1. Makes a macro call into something that is not a roll option. Since Roll Options can only be nested with CODE braces, using UDFs can get you around the nesting limitations.
2. Lets you pass individual arguments which can be received on the other and, and don't require you to unwrap JSON objects or string property lists. For me, it's more intuitive to think "I need to send that macro the Attack Value, the Defense Value, and the damage dice" instead of "I need to put Attack Value, Defense Value, and Damage Dice into a JSON object and then send that whole object and then unwrap it on the other end and..."
3. Lets you write your own utility things, such as varsFromJSON(), which doesn't exists as a macro function but can be created as a UDF.

[Craig]

This begs the question (for me anyway), what exactly is the difference between a UDF and a callable macro on a Lib:token? My first thought is that a UDF returns something (a value, JSON, etc.), while a macro only does something (i.e. outputs commands/text to the chat window which then get parsed). Is that the main/only difference? Other than "bugs" like this one, is there a reason to not make something a UDF as opposed to just a macro on a Lib:token?

Its not a bug its an anti cheating feature.
If you have a user defined function it can not generate tool tips unless it is trusted (look on the wiki for trusted macros).
The reason for this is so players can not call it and then capture the output in a variable and modify the output. You will still need to do [r: ...]

[khabalox]

Its not a bug its an anti cheating feature.
If you have a user defined function it can not generate tool tips unless it is trusted (look on the wiki for trusted macros).
The reason for this is so players can not call it and then capture the output in a variable and modify the output. You will still need to do [r: ...]

Well I tried this, and couldn't get it to work either. My original UDFs and Lib:token macros were not trusted (editable by players was checked). I unchecked that box for all the macros but still got the same error.

Because I've tried so many permutations, I thought I should start from scratch. So a loaded a new campaign and added two tokens: "Elf" and "Lib:Dragon". These tokens are attached (should I upload the campaign file?). Below are the macros for each token:

Lib:Dragon
onCampaignLoad

Code: Select all

[defineFunction("Attack","Attack@this")]

Attack

Code: Select all

[h:varBAB = arg(0)]
[h:varWpnMod = arg(1)]
[h:AttRoll = 1d20]

[r:getName()] attacks:<br>

AC: [AttRoll+varBAB+varWpnMod]<br>
Dam: [1d8+varWpnMod] 

Elf
Attack - Std

Code: Select all

[Attack(5,1)]
<!-- Attack with BAB 5 and Wpn Mod 1 -->

When I as GM (I see my name, followed by (Gm) in the Connections window) click on "Attack - Std" on the token "Elf", I get the following in the Chat window.

Elf attacks:
AC: AttRoll+varBAB+varWpnMod = 16 + 5 + 122« 
Dam: 6 »

In the chat window there is an ASCII square between the 1 and 22 on the "AC:...." line. There is a tooltip for "Elf Attacks" which says:
"<<Attack(5, 1) = Attack (5, 1)>>"
There is a tool tip for the Damage roll which says:
"<<1d8 + varWpnMod = 5 + 1 >>

If I change the "Attack - Std" macro to:

Code: Select all

[r:Attack(5,1)]

I get

Elf attacks:
AC: AttRoll+varBAB+varWpnMod = 4 + 5 + 110
Dam: 1d8+varWpnMod = 4 + 15

There are no tool tips.

If I change the AC and Dam rolls in the Attack UDF to be [r:...], then I get this output.
Elf attacks:
AC: 7
Dam: 8
There is one tooltip for the entire output, which says:
"<<Attack(5, 1) = Attack (5, 1)>>
This is the output I want, but with tooltips showing the rolls and mods. Changing these two rolls in the Attack UDF to [e:...] will show the expansion, but I'd rather not show it unless the user hovers over it.

[Brigand]

This anti-cheat crap is stupid anyway. Player's can't create UDF's. So they're "trusted" to begin with.