input() and other new b42 macro functions

[palmer]

"Edit weapons" macro
So, we've stored various bits of information about each weapon in a single token property that looks like this:

Weapon1 Name=Longsword +1 ; AttackBonus=1 ; Damage=1d8+1 ; MaxDamage=9 ; Crit=1d6 ; Keyword= ;

In the example campaign file, there is an "Edit weapons" macro:

b43 Bug?

When I use this macro to edit a weapon, it sets the Name=blah in the Weapon1 string.

But it also changes my completely separate and standalone "Name" property (where I put the character's name) into whatever the name of the last edited weapon is.

I discovered this after editing, and then mouseover statsheet told me his name was now Throwing Dagger.

Workaround: Don't use string props that duplicate existing properties. But still, that's not correct behaviour as far as I understand.

[knizia.fan]

"Edit weapons" macro
So, we've stored various bits of information about each weapon in a single token property that looks like this:

Weapon1 Name=Longsword +1 ; AttackBonus=1 ; Damage=1d8+1 ; MaxDamage=9 ; Crit=1d6 ; Keyword= ;

In the example campaign file, there is an "Edit weapons" macro:

b43 Bug?

When I use this macro to edit a weapon, it sets the Name=blah in the Weapon1 string.

But it also changes my completely separate and standalone "Name" property (where I put the character's name) into whatever the name of the last edited weapon is.

I discovered this after editing, and then mouseover statsheet told me his name was now Throwing Dagger.

Workaround: Don't use string props that duplicate existing properties. But still, that's not correct behaviour as far as I understand.

Nope, this is the way it works. Both token property names and temporary variable names are treated in the same way. The varsFromStrProp() function in the sample macro is effectively the same as writing:

Code: Select all

[Name = "Throwing Dagger"] 
[AttackBonus = 2]
[Damage = "1d4+2"]
[MaxDamage = 6]
[Crit = "2d6"]
[Keyword = "fire"]

After assigning values to these variables, the macro uses these variables to print the settings to the chat window. If I provided you with a macro containing those statements, it would overwrite your Name token property too.

But you raise a very good point. Using the varsFromStrProp() function, or the SETVARS=TRUE option on the PROPS inputType requires caution. It may have been better if my sample macro had used more distinctive names for the string properties, e.g. WpnName, WpnAttackBonus, etc. Such names would be less likely to conflict with token property names.

To be completely safe, you could modify the macro to use individual getStrProp() function calls instead of using varsFromStrProp().

[palmer]

Nope, this is the way it works. Both token property names and temporary variable names are treated in the same way. The varsFromStrProp() function in the sample macro is effectively the same as writing

But you raise a very good point. Using the varsFromStrProp() function, or the SETVARS=TRUE option on the PROPS inputType requires caution. It may have been better if my sample macro had used more distinctive names for the string properties, e.g. WpnName, WpnAttackBonus, etc. Such names would be less likely to conflict with token property names.

To be completely safe, you could modify the macro to use individual getStrProp() function calls instead of using varsFromStrProp().

This makes perfect sense now on the code side. It's just rather unexpected, and some kind of warning would have been quite appreciated.

I am appropriating much of your code from here verbatim, as my coding skills aren't that great, so I'm liable to run into such issues. I can usually correct them with little issue, but this was one I hadn't noticed for over an hour as it was silent and didn't affect anything I was paying attention to.

As I'm still trying to grok all the code could you show a way I could look through X numbered properties (Like Power1, Power2 etc), extract only those that match a criteria like having an "Area" variables, and present them in a dropdown while displaying some of those variables?

I'm thinking of a dropdown list (like the skill use macro) that also shows range and area for ranged powers.

Bonus points if it can exclude any where "Used = 1" so used powers don't show up

[hennebeck]

Knazia.fan, It's asking me for the value of "Private" each time I run that Skill macro.

I put in a skill twice and the macro runs, but it doesn't actual remember that skill. Nor do I think that's what hould be happening.

Other then that, these little tools are amazing.
I just wish I could think of things to do with this new code.

[knizia.fan]

Knazia.fan, It's asking me for the value of "Private" each time I run that Skill macro.

I put in a skill twice and the macro runs, but it doesn't actual remember that skill. Nor do I think that's what hould be happening.

Other then that, these little tools are amazing.
I just wish I could think of things to do with this new code.

Your campaign needs to define a token property called Private. If the property is missing, or if it is blank, you'll get this popup.

I suggest defining the property with a default value

Code: Select all

Private: " ; "

However, even if you do that, I think there's an issue where you have to open the Edit Token dialog once before the default value gets used by the token (not sure why that is).

As a test, impersonate the token and type [Private] in the chat window. If you get a popup, you know that there's a problem with the token property and the macro won't work. You can always just go into the Edit Token property and manually enter some text in the Private property -- it just needs to be non-blank.

[knizia.fan]

I've sent Trevor a patch for b44 with a few changes.

* Fix bug: indexValueStrProp() was always returning a string, even when it should return a number

* input() function new feature
All inputTypes have a SPAN=TRUE option, which hides the prompt label and allows the input control to span the whole dialog. (Mainly this is handy for the LABEL type.)

* input() function INCOMPATIBLE CHANGE
The SETVARS option for the PROPS inputType now works as follows:
SETVARS=NONE ==> (default) no individual variable assignments are made
SETVARS=SUFFIXED ==> individual assignments are made to variable names with an underscore appended
SETVARS=UNSUFFIXED ==> individual assignments are made to unmodified variable names
The SUFFIXED option is preferred over UNSUFFIXED except in special cases, so that you don't unexpectedly overwrite token properties or other variables. The b43 option SETVARS=TRUE corresponded to the new UNSUFFIXED setting, so macros will have to be modified.

* varsFromStrProp() function INCOMPATIBLE CHANGE
The function now takes an optional second argument, which can be "NONE", "SUFFIXED", or "UNSUFFIXED" as above. The default is "SUFFIXED". The b43 behavior corresponded to the new "UNSUFFIXED" setting, so macros will have to be modified.

I hope that the new SUFFIXED option will help users avoid clobbering variable names or token properties by accident.

[lmarkus001]

I would like to request a new option for the input() function.

I would like an option that wraps columns after x rows.

I am working on D&D3.5 skills which are FAR more vast than 4.0. For example, here is the list from the PHB minus the Craft and Profession skils. As you can see, an option to start another column after 15 or so is really needed. I can quickly blow out the height of a screen otherwise...

[BigO]

I would like to request a new option for the input() function.

I would like an option that wraps columns after x rows.

I am working on D&D3.5 skills which are FAR more vast than 4.0. For example, here is the list from the PHB minus the Craft and Profession skils. As you can see, an option to start another column after 15 or so is really needed. I can quickly blow out the height of a screen otherwise...

Or just a put it in a panel that has a scroll bar.

[knizia.fan]

Wrapping to a new column would require extensive changes. The current layout system is very simple.

I'll look into scrolling support.

For now, a workaround is to have a first dialog that lets you choose a subgroup of the skills (e.g. "a-j" "k-n" "o-z"), and a second that just shows you that subset. You may find that using the list-processing functions with the optional last argument set to ";" will be helpful in extracting subsets of your property string.

[Mithrus]

Just have to say THANK YOU SO MUCH! I love the new input function (although I had to recode all my macros ;)

Any chance the listAppend() could accept an number as a second parameter and automatically convert to string? Currently, I am using the function to store a bunch of rolls in a list, but i have to postpend a "" to force convert the value. See code below

Code: Select all

[h: NumDice=0][h: Reroll=10]
[h: fail = input(
  "NumDice|1|# of Dice|TEXT|",
  "Reroll|10|Reroll On|TEXT|"
)]
[h: abort(fail)]
[h: n = NumDice ][H: tn = 8 ][h: list=","]Reroll On:[P: Reroll]<br />Result:
[h, C(n): list=listAppend(list, roll(1,10)+"")]
[h: s = 0 ][h, C(n): s = sum(s,if(listGet(list, roll.count)==tn, 1, 0))]
[C(n+1): listGet(list, roll.count)]
<br/>Successes: [s]

I would love it if the PROPS input type could somehow support non-textbox input. For example, I have several forms that would be better shown as a radio/list. Maybe allow an option to specify input type (RADIO/LIST) and the accompanied list. The radio option could get a little dicey, as I could see support for horizontal and vertical.

[knizia.fan]

Just have to say THANK YOU SO MUCH! I love the new input function (although I had to recode all my macros

Any chance the listAppend() could accept an number as a second parameter and automatically convert to string?

Thanks for catching that. This was just an oversight I made in some of the list functions. I've prepared a patch so that listAppend, listInsert, etc will accept strings or numbers for the new list entry.

I would love it if the PROPS input type could somehow support non-textbox input. For example, I have several forms that would be better shown as a radio/list. Maybe allow an option to specify input type (RADIO/LIST) and the accompanied list. The radio option could get a little dicey, as I could see support for horizontal and vertical.

I don't see an easy way to do this, as the PROPS type accepts a bunch of variables. Currently it treats each variable as a TEXT type. Unless every single one of those variables in the property string is of the same type, the input() function would have to provide a place where the user can give a big list of inputTypes. That would be too messy.

If you're thinking of something different than what I just described, feel free to post an imaginary input() statement that does what you want and I'll take a look at it.

[h3lrav3n]

Wonderful work, knizia.fan! I love what you did

Hope this is the right place to post my query...
I took the states function and made it a global macro (I have a couple of different campaigns I use). I was wondering if there was a way to keep the target icon from showing in the chat window without completely disable the token image chat feature. Whenever a state is applied to or removed from a token, the token image shows up in the chat window after an extended refresh; it tends to spam up the chat window when applied to multiple targets. It does it as both a token property macro and global macro.

Once again, incredible work.

[knizia.fan]

Wonderful work, knizia.fan! I love what you did

Hope this is the right place to post my query...
I took the states function and made it a global macro (I have a couple of different campaigns I use). I was wondering if there was a way to keep the target icon from showing in the chat window without completely disable the token image chat feature. Whenever a state is applied to or removed from a token, the token image shows up in the chat window after an extended refresh; it tends to spam up the chat window when applied to multiple targets. It does it as both a token property macro and global macro.

Once again, incredible work.

Thanks, and if you make a macro you like, please share it in the thread posted in User Creations so that others can see what you've done and copy things. (Include some pictures!)

I haven't tested this, but I think there are two ways for you to prevent the chat spam.

1. Begin the macro with /self, so that only you see the results. As a GM, you may find it useful to have the macro print a brief confirmation message so you can see what has happened (e.g. printing out the state that was applied/removed). Your chat window will still get spammed, but your players won't see it.

2. End your macro with the following lines of code.

Code: Select all

<!-- This prevents the macro from displaying anything in chat. -->
  [h: abort(0)]

[Mithrus]

I would love it if the PROPS input type could somehow support non-textbox input. For example, I have several forms that would be better shown as a radio/list. Maybe allow an option to specify input type (RADIO/LIST) and the accompanied list. The radio option could get a little dicey, as I could see support for horizontal and vertical.

I don't see an easy way to do this, as the PROPS type accepts a bunch of variables. Currently it treats each variable as a TEXT type. Unless every single one of those variables in the property string is of the same type, the input() function would have to provide a place where the user can give a big list of inputTypes. That would be too messy.

If you're thinking of something different than what I just described, feel free to post an imaginary input() statement that does what you want and I'll take a look at it.

Yep, im thinking that all the properties would share the same options. I am not sure about other games, but WoD uses the 1-5 and 1-10 range ALOT, and having a radio button list for these values would look better IMO. As far as format, basically add an option as TYPE={RADIO|LIST} {RADIO|LIST options go here} VALUES={,-separated list, and this has to be the last option}

Example (current):
[h: fail = input(
"AttrCur|"+AttrCur+"|Current Attribs|PROPS|"
)]
[h: abort(fail)]

Example (i wish):
[h: fail = input(
"AttrCur|"+AttrCur+"|Current Attribs|PROPS|TYPE=RADIO ORIENT=H VALUES=1,2,3,4,5"
)]
[h: abort(fail)]

I'd like the SELECT to be automatically set to the current value for that property item.

[Mithrus]

I would like to request a new option for the input() function.

I would like an option that wraps columns after x rows.

I am working on D&D3.5 skills which are FAR more vast than 4.0. For example, here is the list from the PHB minus the Craft and Profession skils. As you can see, an option to start another column after 15 or so is really needed. I can quickly blow out the height of a screen otherwise...

Or just a put it in a panel that has a scroll bar.

In the meantime, you could break the skills up into the subclassed skills (Craft, Knowledge, Profession) and stand-alone skills (subclassed isnt quit the right descriptor, but you probably know want I mean). I'd say allow for 3-4 crafts and 2-3 professions, plus the knowledge skills and it should fit reasonably in a 800x600 screen (although most have 1024x768 anymore.