input() and other new b42 macro functions

Doc requests, organization, and submissions

Moderators: Azhrei, dorpond, trevor

h3lrav3n
Kobold
Posts: 12
Joined: Thu Sep 28, 2006 1:03 am

Post by h3lrav3n »

PyroMancer2k wrote:
h3lrav3n wrote:Sorry... my last post above is in regards to b45.


P was renamed to R in b45. So in this section

Code: Select all

[h,p,c(NumProps,""): 


It should be

Code: Select all

[h,r,c(NumProps,""): 


Made the change. Like before, it edits the weapon properties, but now I get "Could not execute the command: null" in the chat window.
Thanks once again for your help and patience.

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

Post by knizia.fan »

b44 made some incompatible changes that will require tweaks to these macros. I'm holding off a rewrite until some other changes I'm making get applied to MapTool.

For now, the big problem is probably the roll.count change. If you go through the macros and replace every instance of

roll.count

with

(roll.count+1)

then it should be ok.

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

Post by lmarkus001 »

D&D3.5 has zillions of skills (the PHB alone has 42 NOT including Craft and Profession). Initially I used the basic input() example for skills provided in this thread, but that blows up quickly (or at least extends FAR below the bottom of my screen). So I have come up with this approach to the problem.

Note that this is a B45 solution, in future revs we are likely to have a looping structure which will make this even more flexible and extensible...


Edit Skills

Code: Select all

[H: tcnt = listCount(Skills, ";") - 1]
[H: td1 = ""]
[H, C(15): td1 = td1 + listGet(Skills, roll.count, ";") + " ; "]
[H: td2 = ""]
[H, C(15): td2 = td2 + listGet(Skills, roll.count + 15, ";") + " ; "]
[H: td3 = ""]
[H, C(15): td3 = td3 + listGet(Skills, roll.count + 30, ";") + " ; "]
[H: success = input(
  "tacp | " + ArmorCheckPenalty + "| Armor Check Penalty | TEXT | WIDTH=4",
  "foo | Don't add bonuses from abilities or level here. | Note | LABEL",
  "td1 | " + td1 + " | Set skill bonuses | PROPS"
)]
[H: abort(success)]
[H: success = input(
  "foo | Don't add bonuses from abilities or level here. | Note | LABEL",
  "td2 | " + td2 + " | Set skill bonuses | PROPS"
)]
[H: abort(success)]
[H: success = input(
  "foo | Don't add bonuses from abilities or level here. | Note | LABEL",
  "td3 | " + td3 + " | Set skill bonuses | PROPS"
)]
[H: abort(success)]
[H: ArmorCheckPenalty = if(tacp > 0, 0 - tacp, tacp)]
[Skills = td1 + " " + td2 + " " + td3]


Basically this breaks the list into 15 skill sublists, then chains up the dialogs to get the user input.

User avatar
Pyroman
Cave Troll
Posts: 68
Joined: Wed Dec 26, 2007 12:42 pm
Location: Tampa, FL

Post by Pyroman »

harchunk wrote:I tried to use this macro and the first part isnt operating correctly this is what i get "Could not execute the command: Index: 0, Size: 0"


If you are running this as a campaign macro (as I do) and not a token macro, you will need to be sure that "apply to selected tokens" is checked in the macro editor (or, right-click and choose "Run for each selected").

h3lrav3n
Kobold
Posts: 12
Joined: Thu Sep 28, 2006 1:03 am

Post by h3lrav3n »

knizia.fan wrote:b44 made some incompatible changes that will require tweaks to these macros. I'm holding off a rewrite until some other changes I'm making get applied to MapTool.

For now, the big problem is probably the roll.count change. If you go through the macros and replace every instance of

roll.count

with

(roll.count+1)

then it should be ok.


I hadn't realized that I didn't raise a couple of rollcount values one higher on the edit weapon macro. Made the correction and changed the value "p" to "r". It works now. :)

<!-- Build the list of weapon names. --> [h: WpnList = ""] [h, c(9,""): WpnList = WpnList + getStrProp(eval("Weapon" + (roll.count+1)), "Name") + ","]
<!-- Ask the user to select one of the weapons. --> [h: fail = input("WpnNum | " + WpnList + " | Select weapon to edit | LIST")] [h: abort(fail)]
<!-- Obtain the property string for the selected weapon. --> [h: WpnNum = WpnNum + 1] [h: WpnName = "Weapon" + WpnNum] [h: WpnProps = eval(WpnName)]
<!-- Error checking -- make sure the property string has been set up already. --> [h: NumProps = countStrProp(eval(WpnName))] [h: abort(NumProps)]
<!-- Put up a dialog with all the properties in the property string. -- Note that the new property string is automatically assigned back to the -- token property that holds the weapon's property string. --> [h: fail = input("blah | " + WpnNum + " | Weapon number | LABEL", WpnName + " | " + WpnProps + " | Weapon properties | PROPS | setvars=true")] [h: abort(fail)]
<!-- Print the new values to the chat window for verification. --> New properties for weapon #{WpnNum}: <table border=0> [h: NumProps = countStrProp(eval(WpnName))] [h,r,c(NumProps,""): "<tr><td style='padding:0px 5px'><b>" + indexKeyStrProp(WpnProps,roll.count) + "</b></td><td>" + eval(indexKeyStrProp(WpnProps,roll.count)) + "</td></tr>" ] </table>

Thanks to you all! :)

User avatar
Full Bleed
Demigod
Posts: 4444
Joined: Sun Feb 25, 2007 11:53 am
Location: MD
Contact:

Post by Full Bleed »

Knizia, any way we can get access to the title of the input window and change that name? Right now it always says, "Input Values for Token Name" regardless of the macro called.

It would be nice to be able to change the name of the box to "Input Values for Initiative" or something.

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

Post by knizia.fan »

Full Bleed wrote:Knizia, any way we can get access to the title of the input window and change that name? Right now it always says, "Input Values for Token Name" regardless of the macro called.

It would be nice to be able to change the name of the box to "Input Values for Initiative" or something.


I was copying the behavior of the original variable popups in MapTool. There isn't a clean way for me to do something like this, because input() takes a variable number of parameters and all of them are used to define variables. I'll think about it, though.

However, with an upcoming patch, you can use a label control with the new SPAN=TRUE option as a summary/title/description for the stuff below it. This method also works if your dialog has multiple parts you'd like to separate and label. Hopefully the new build will arrive today or tomorrow.

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

Post by lmarkus001 »

I have discovered a weakness/error in the listGet() routine. The optional list delimiter (default is ",") is restricted. I have found it to work for comma, semicolon, hyphen. But it does not work for any character defined.

For example, if I have a property with the value: 2d6, I would like to use listGet to separate out the 2 and the 6 using the d as the delimiter.



Test cases:

Input: listGet( prop, 0, "d")
aaadccc
2d6

Output:

aaadccc
<null>

Input: listGet( prop, 0, "-")
aaa-ccc
2-6

Output:

aaa
2


P.S. - The delimiter is also limited to a single character. While this is not erroneous functionality, it would be a nice added capability to be able to define any number of characters as the delimiter.

Mithrus
Cave Troll
Posts: 30
Joined: Fri Sep 12, 2008 11:52 pm

PROPS and multi-word keys

Post by Mithrus »

I'm using b43, so this may have been fixed. I have a StrProp property that includes an entry which has two words for the key (i.e. it contains a space). It seems input() ignores the first word when processing a PROPS entry, and only shows the last word for the key. Also, the key is then updated to only contain the last word.

For example, I am making a custom WoD-based token, and one of the skills added is "Hearth Wisdom". I am using a StrProps to store the different skill groups (Mental, Physical, Social), so for Mental, the value of the prop would look something like this:

Code: Select all

Academics=1 ; Crafts=1 ; Hearth Wisdom=2 ; Investigation=0 ; Medicine=2 ; Occult=4 ; Politics=0 ; Technology=1 ;

On the input() form, the line for "Hearth Wisdom" only displays "Wisdom", and if I accept any changes, that key is then changed to "Wisdom".

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

Post by knizia.fan »

lmarkus001 wrote:I have discovered a weakness/error in the listGet() routine. The optional list delimiter (default is ",") is restricted. I have found it to work for comma, semicolon, hyphen. But it does not work for any character defined.

<snip>

P.S. - The delimiter is also limited to a single character. While this is not erroneous functionality, it would be a nice added capability to be able to define any number of characters as the delimiter.


I've mentioned a few times here that the non-default delimiters were buggy in the initial release. Trevor already has a patch from me which fixes your examples, and happens to also add multi-character support.

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

Re: PROPS and multi-word keys

Post by knizia.fan »

Mithrus wrote:I'm using b43, so this may have been fixed. I have a StrProp property that includes an entry which has two words for the key (i.e. it contains a space). It seems input() ignores the first word when processing a PROPS entry, and only shows the last word for the key. Also, the key is then updated to only contain the last word.

For example, I am making a custom WoD-based token, and one of the skills added is "Hearth Wisdom". I am using a StrProps to store the different skill groups (Mental, Physical, Social), so for Mental, the value of the prop would look something like this:

Code: Select all

Academics=1 ; Crafts=1 ; Hearth Wisdom=2 ; Investigation=0 ; Medicine=2 ; Occult=4 ; Politics=0 ; Technology=1 ;

On the input() form, the line for "Hearth Wisdom" only displays "Wisdom", and if I accept any changes, that key is then changed to "Wisdom".


I'll have to think about this. The property names can be used as variable names by some functions, so they originally were restricted to single words. Changing this would require some kind of error or peculiar behavior when those other functions are used. Maybe I can come up with a clean solution for you with more thought.

For now, of course, you can use "HearthWisdom" or "Hearth_Wisdom" as a workaround.

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've mentioned a few times here that the non-default delimiters were buggy in the initial release. Trevor already has a patch from me which fixes your examples, and happens to also add multi-character support.


Woo hoo, thank you for your excellent additions to MapTool, and to all your hard work!!!

Mithrus
Cave Troll
Posts: 30
Joined: Fri Sep 12, 2008 11:52 pm

Re: PROPS and multi-word keys

Post by Mithrus »

knizia.fan wrote:
Mithrus wrote:I'm using b43, so this may have been fixed. I have a StrProp property that includes an entry which has two words for the key (i.e. it contains a space). It seems input() ignores the first word when processing a PROPS entry, and only shows the last word for the key. Also, the key is then updated to only contain the last word.


I'll have to think about this. The property names can be used as variable names by some functions, so they originally were restricted to single words. Changing this would require some kind of error or peculiar behavior when those other functions are used. Maybe I can come up with a clean solution for you with more thought.
For varsFromStrProp(), I'd recommend converting all spaces in the key to underscores. This would make it predictable (and thus minimize any accidental conflicts).

Syne
Kobold
Posts: 17
Joined: Fri Sep 19, 2008 9:15 am

Post by Syne »

Hell, I think it would just be better to make the varsFromStrProp() use the last word in the key name to build the variables, but explicitly mention this in the documentation. After all, some functionality is better than none at all, and it caused me some problems before. Sometimes, you will want the macro to search for a string the user inputs; and that string is bound to have spaces.

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

Post by demonnic »

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 =)

Post Reply

Return to “Documentation Requests/Discussion”