input() and other new b42 macro functions

Doc requests, organization, and submissions

Moderators: Azhrei, dorpond, trevor

knizia.fan
Giant
Posts: 197
Joined: Wed Jul 30, 2008 3:43 pm

Post by knizia.fan »

demonnic wrote:Not sure, but I may have found a bug in the input() function. I noticed today while editing my macros for skill usage that if the token name was "Grum" then it wouldn't read the token properties into the varFromStrProp() function, but if it was "Grum " (yeah, that's a space at the end) or Grum with anything after it, it would read it fine. The Grum here is unimportant, I tested with all my tokens =)


Could you explain this in more detail? I don't really understand what you're describing, so I'll need some help.
  1. Is the bug in input() or varsFromStrProp()? The two functions have almost nothing to do with each other.
  2. The varsFromStrProp() function doesn't read from token properties. Are you saying that it doesn't write to token properties?

Strange that MapTool will allow you to give your token a name that ends with a space. That should probably be changed.

If you can give a sequence of steps that reproduces the problem, beginning with starting up MapTool, that will be very useful. For example, I just tried this:
  1. Start b45
  2. Drag a token on the map
  3. Edit Token: Name it "Grum", and set its HP property to 20, AC property to 30.
  4. Impersonate the token
  5. Type [varsFromStrProp("HP=5; x=3;")]


Result: The token's HP property changes, as expected.

There is one issue that might be causing confusion. If you rename your token while impersonating it, the Impersonate panel does NOT refer to the newly-renamed token any more. You can even delete the token entirely, and the Impersonate panel will still happily tell you you're impersonating someone who doesn't exist, and even let you run macros from the deleted token! Note that the chat window also thinks you're still impersonating the old token.

So if you were playing around with renaming tokens, this might have been involved in what you were seeing.

demonnic
Cave Troll
Posts: 53
Joined: Sun Sep 07, 2008 10:03 pm

Post by demonnic »

Ok.
It's probably actually somewhere in the way either maptool in general, or varsFromStrProp() accesses token data, actually...


1. Open up maptool b45
2. With the name how it is (my maptool automagically adds a number to the end of the name) you can run the macro just fine.
3. Remove everything after the filename portion of the token (for example, it 'names' the token from filename.ext to Filename <two>, and you remove everything after Filename)
4. Now when you run the macro, it asks for a value for WisSkills, but if you look in the token the value is still in there. This is a global macro, with "Apply to selected tokens" and "Auto Execute" checked, with no hot key.
5. Now change the name of the token to something completely different, a new number, add a last name, whatever
6. The macro magically works again.

The macro code follows, the WisSkills property is currently set to:
"Listen=0 ; SenseMotive=0 ; Spot=0 ; Heal=2 ; Survival=0 ;" without the quotes

Code: Select all

[h: varsFromStrProp(WisSkills)]
[h: input("Skill | Listen, SenseMotive, Spot, Heal, Survival | Which skill do you want to roll for? | RADIO|value=string")]
[h: Ranks = eval(Skill)]
[h: Modifier = WisBonus + Ranks]
{token.name} makes a {Skill} check ( [1d20 + Ranks + WisBonus] ) , which includes {Ranks} ranks in the skill, and their Wisdom Bonus of {WisBonus}<br>



ETA: I just realized my edit up there was a bit muddled. It would seem that the only thing which the token -cannot- be named is the same thing as the filename. with aothaine.rptok as the example, I can name it anythign except for "Aothaine" and it works just fine. I've tried it with two different tokens so far, aothaine.rptok, grum.rptok.

demonnic
Cave Troll
Posts: 53
Joined: Sun Sep 07, 2008 10:03 pm

Post by demonnic »

Aaand in the further adventures, it would seem it only happens with .rptok files, and only if they are named something other than the filename to start. That is to say when I change the naming convention to 'increment' instead of random two digit and drag the token on for the first time, it works fine. Subsequent ones which have been renamed do not, if I erase it back to the filename portion only.

However, if I add an image file to the token layer, instead of a saved token, it doesn't seem to care, as long as I edit it to get the default properties to come in. I'm probably giving either too much or too little info here.

knizia.fan
Giant
Posts: 197
Joined: Wed Jul 30, 2008 3:43 pm

Post by knizia.fan »

demonnic wrote:Aaand in the further adventures, it would seem it only happens with .rptok files, and only if they are named something other than the filename to start. That is to say when I change the naming convention to 'increment' instead of random two digit and drag the token on for the first time, it works fine. Subsequent ones which have been renamed do not, if I erase it back to the filename portion only.

However, if I add an image file to the token layer, instead of a saved token, it doesn't seem to care, as long as I edit it to get the default properties to come in. I'm probably giving either too much or too little info here.


It sounds like you have another token with the same name floating around. In any case, now that we know it's not input() or varsFromStrProp(), you should start a new thread for this issue. The people who might have good advice for you probably aren't spending their time browsing the 10th page of this thread :)

demonnic
Cave Troll
Posts: 53
Joined: Sun Sep 07, 2008 10:03 pm

Post by demonnic »

Well, you nailed it. After reading that response, I went scrounging through the map explorer. Found culprits for the three it ended up happening with. Thanks

[/derail]

knizia.fan
Giant
Posts: 197
Joined: Wed Jul 30, 2008 3:43 pm

Post by knizia.fan »

I have updated the first 4 posts in this thread for the changes in b46.

* Be aware of the incompatible change to varsFromStrProp(), which now has a mandatory second argument. Sorry that this breaks your macros. When I submitted the change it had been a short time after the initial release of the feature, so not many people would be burned by it. Hardware demons delayed the build quite a bit, so more of you will have to make updates. To get the old behavior, add a second argument string with value "UNSUFFIXED". If you can make the small changes necessary, using the "SUFFIXED" option is a better choice.

* I added new examples at the beginning for tabbed dialogs and the skill check macro that I had posted in the middle of this thread.

User avatar
Crudeboy
Giant
Posts: 122
Joined: Wed Jul 02, 2008 9:12 pm
Location: Little Rock, Arkansas (CST)
Contact:

Post by Crudeboy »

Holy crow.

I missed the tab thing completely.

User avatar
lmarkus001
Great Wyrm
Posts: 1862
Joined: Sat Mar 29, 2008 12:30 am
Location: Layfayette Hill, PA

Post by lmarkus001 »

Thanks for your great additions!

---

In an earlier discussion
http://forums.rptools.net/viewtopic.php ... &start=127

you had mentioned the listGet() issues should be resolved in the next patch. But listGet() appears to be functioning the same as it used too.


---

Additionally, the issue of an listbox with images generating errors on first load is still there.

---

And finally, there was a good deal of discussion about adding a vertical scrollbar to the input() dialog window. I do not see that functionality in b47 (I do not know if this ever was actually addressed, but figure I should mention it in case you thought it had been.)

User avatar
lmarkus001
Great Wyrm
Posts: 1862
Joined: Sat Mar 29, 2008 12:30 am
Location: Layfayette Hill, PA

Post by lmarkus001 »

knizia.fan wrote:I have updated the first 4 posts in this thread for the changes in b46.

* Be aware of the incompatible change to varsFromStrProp(), which now has a mandatory second argument.
...


These do not appear to have made it in to the build. When I run a macro with the second argument for varsFromStrProp() I get this output:

Code: Select all

Could not execute the command: varsFromStrProp() requires 1 parameters


But it works fine if I only have the single argument.

Oh yeah, I am testing with b47.

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Post by PyroMancer2k »

Your line of code for the example of new listFormat() returns the following when I run it. I wanted to see what it looked like and got this message.

Code: Select all

Could not execute the command: Undefined function: listFormat


I'm also with Imarkus001 in that varsFromStrProp() doesn't seem to have changed. When I read that I thought oh great now I gotta do a bit of editing cause I use it a lot in my macros :). Oddly enough until about 5 mins ago I hadn't tested my macros to see if they "broke" with the update, been too busy. :P

Haven't really look at them all the other changes you made but it should prove interesting.

User avatar
PyroMancer2k
Dragon
Posts: 925
Joined: Thu Sep 11, 2008 2:04 pm

Post by PyroMancer2k »

I found a whole list of things that don't work.

TAB on input.
strPropFromVars() says Undefined function.
formatStrProp() says Undefined function.
varsFromStrProp(properties, nameStyle) say only takes 1 parameter.

Are you sure those things got into b47?

Also when you do change the varsFromStrProp() to have nameStyle option why can't you just leave the default option that it is now so we don't have to change our macros ;).

Lindharin
Dragon
Posts: 668
Joined: Sat Apr 21, 2007 4:51 pm

Post by Lindharin »

Okay, I finally started to play with the new macro functions from b41 on, and I have to say that I am LOVING it! :D :D :D

I have run into one snag with string properties and the new ability to call another macro from a library token, though. I've been finding string properties incredibly useful for passing multiple key/value pairs back and forth between the main macro and the library macro.

However, you cannot have either an equal sign (=) or semi-colon ( ; ) in the values in a string property. The lack of equal signs is a big problem, because it means you can't make use of tooltips in spans; we need to be able to have something like:

<span class="roll" title="1+3+4">8</span>

when we're building custom outputs for rolls. But that breaks if we try to add it to a string property and send it to/from a library macro, because the string property parser chokes on the equal signs in the span tag.

I went into eclipse and looked at the source, and I added a call to URLEncoder.encode() in the setStrProp function when it stores the value, and calls to URLDecoder.decode() in getStrProp, varsFromStrProp, and indexValueStrProp so that the stored value gets decoded before it is sent back to a macro.

This seems to work well, with one exception. If the string property gets stored in a token property and you look at the value in the token editor, you see the encoded string (this means all punctuation and special characters are converted into codes like %20, etc.)

How important is it for people to be able to see human-readable content in string properties stored in tokens?

jimb
Kobold
Posts: 22
Joined: Mon Sep 29, 2008 5:46 pm

Post by jimb »

Instead of string properties you could use a list. that would provide you with a position associative array rather than a keyword associative array and you could then choose the character to separate the parameters.

Lindharin
Dragon
Posts: 668
Joined: Sat Apr 21, 2007 4:51 pm

Post by Lindharin »

I think I have a compromise solution that helps string properties with no down-side that I can think of. Instead of encoding the values, I could just change the regular expression that parses it, which would solve the problem with equal signs.

At the moment, it chokes when it hits an equal or semi-colon in the value of property. There's nothing simple to fix the semi-colon, since that is the only separator. However, I can't think of any reason why it needs to stop processing a value at an equal sign; it isn't a delimiter of the string properties anyway.

So I could change the current regular-expression from:

Pattern entryParser = Pattern.compile("\\w+\\s*=\\s*[^;=]*");
Pattern keyValueParser = Pattern.compile("(\\w+)\\s*=\\s*([^;=]*)");

to:

Pattern entryParser = Pattern.compile("\\w+\\s*=\\s*[^;]*");
Pattern keyValueParser = Pattern.compile("(\\w+)\\s*=\\s*([^;]*)");

I've tested that and it fixes spans and formulas like "1+3=4".

k.fan, is there any reason not to do that?

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Post by Craig »

Lindharin wrote:I think I have a compromise solution that helps string properties with no down-side that I can think of. Instead of encoding the values, I could just change the regular expression that parses it, which would solve the problem with equal signs.

At the moment, it chokes when it hits an equal or semi-colon in the value of property. There's nothing simple to fix the semi-colon, since that is the only separator. However, I can't think of any reason why it needs to stop processing a value at an equal sign; it isn't a delimiter of the string properties anyway.

So I could change the current regular-expression from:

Pattern entryParser = Pattern.compile("\\w+\\s*=\\s*[^;=]*");
Pattern keyValueParser = Pattern.compile("(\\w+)\\s*=\\s*([^;=]*)");

to:

Pattern entryParser = Pattern.compile("\\w+\\s*=\\s*[^;]*");
Pattern keyValueParser = Pattern.compile("(\\w+)\\s*=\\s*([^;]*)");

I've tested that and it fixes spans and formulas like "1+3=4".

k.fan, is there any reason not to do that?


Also another thing you can look at adding is the ability to specify the delimiter from ';' to any character. That allows people to use characters that wont normally be used.

Of course what would really be nice is if the parser functions would treat any type they don't know about as a string, then you could create an internal representation of the property list how ever you want and there is no issues with what ends where, and at the end of the day if it gets passed to a non property list function you get exactly what you have now...

Post Reply

Return to “Documentation Requests/Discussion”