RPTools.net

Discussion and Support

Skip to content

It is currently Fri Jan 19, 2018 2:39 pm 






Reply to topic  [ 191 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 13  Next

Previous topic | Next topic 

  Print view

Author Message
User avatar  Offline
Great Wyrm
 
Joined: Sat Sep 06, 2008 6:54 pm
Posts: 1391
 Post subject:
PostPosted: Wed Sep 17, 2008 1:21 am 
knizia.fan wrote:
"Edit weapons" macro
So, we've stored various bits of information about each weapon in a single token property that looks like this:
Token property for weapons wrote:
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.


Top
 Profile  
 
 Offline
Giant
 
Joined: Wed Jul 30, 2008 2:43 pm
Posts: 199
 Post subject:
PostPosted: Wed Sep 17, 2008 1:46 am 
palmer wrote:
knizia.fan wrote:
"Edit weapons" macro
So, we've stored various bits of information about each weapon in a single token property that looks like this:
Token property for weapons wrote:
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:
[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().


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Sat Sep 06, 2008 6:54 pm
Posts: 1391
 Post subject:
PostPosted: Wed Sep 17, 2008 4:03 am 
knizia.fan wrote:
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


Top
 Profile  
 
User avatar  Offline
Dragon
 
Joined: Sat May 31, 2008 11:06 pm
Posts: 610
Location: THe City of Roses
 Post subject:
PostPosted: Wed Sep 17, 2008 5:59 am 
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.


Top
 Profile  
 
 Offline
Giant
 
Joined: Wed Jul 30, 2008 2:43 pm
Posts: 199
 Post subject:
PostPosted: Wed Sep 17, 2008 3:49 pm 
hennebeck wrote:
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:
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.


Top
 Profile  
 
 Offline
Giant
 
Joined: Wed Jul 30, 2008 2:43 pm
Posts: 199
 Post subject:
PostPosted: Wed Sep 17, 2008 6:02 pm 
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.


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Fri Mar 28, 2008 11:30 pm
Posts: 1870
Location: Layfayette Hill, PA
 Post subject:
PostPosted: Wed Sep 17, 2008 8:04 pm 
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...

Image


Top
 Profile  
 
User avatar  Offline
Dragon
 
Joined: Mon Jul 28, 2008 11:23 am
Posts: 558
Location: Oshkosh, WI
 Post subject:
PostPosted: Wed Sep 17, 2008 8:09 pm 
lmarkus001 wrote:
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...

Image

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

_________________
--O

I am a small and fragile flower.
http://maptool.rocks.andyousuck.com


Top
 Profile  
 
 Offline
Giant
 
Joined: Wed Jul 30, 2008 2:43 pm
Posts: 199
 Post subject:
PostPosted: Wed Sep 17, 2008 8:15 pm 
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.


Top
 Profile  
 
 Offline
Cave Troll
 
Joined: Fri Sep 12, 2008 10:52 pm
Posts: 30
 Post subject:
PostPosted: Wed Sep 17, 2008 9:25 pm 
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:
[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.


Top
 Profile  
 
 Offline
Giant
 
Joined: Wed Jul 30, 2008 2:43 pm
Posts: 199
 Post subject:
PostPosted: Wed Sep 17, 2008 10:39 pm 
Mithrus wrote:
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.

Mithrus wrote:
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.


Top
 Profile  
 
 Offline
Kobold
 
Joined: Thu Sep 28, 2006 12:03 am
Posts: 12
 Post subject:
PostPosted: Thu Sep 18, 2008 1:34 am 
Wonderful work, knizia.fan! I love what you did :D

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.


Top
 Profile  
 
 Offline
Giant
 
Joined: Wed Jul 30, 2008 2:43 pm
Posts: 199
 Post subject:
PostPosted: Thu Sep 18, 2008 5:42 am 
h3lrav3n wrote:
Wonderful work, knizia.fan! I love what you did :D

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


Top
 Profile  
 
 Offline
Cave Troll
 
Joined: Fri Sep 12, 2008 10:52 pm
Posts: 30
 Post subject:
PostPosted: Thu Sep 18, 2008 9:23 am 
knizia.fan wrote:
Mithrus wrote:
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.


Top
 Profile  
 
 Offline
Cave Troll
 
Joined: Fri Sep 12, 2008 10:52 pm
Posts: 30
 Post subject:
PostPosted: Thu Sep 18, 2008 9:42 am 
BigO wrote:
lmarkus001 wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 191 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 13  Next

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 243 on Sun Nov 04, 2012 6:14 am

Users browsing this forum: No registered users and 1 guest





Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

Style based on Andreas08 by Andreas Viklund

Style by Elizabeth Shulman