Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account
This post has been closed. You can still view previous posts, but you can't post any new replies.

Maths in character attributes

February 23 (11 years ago)

Hello guys!

I did't found a topic for that. If I overlooked a Thread, sorry for that.

I would appreciate the possibility of doing maths in abbility fields within the character sheets. For example, if I note attribute A with a value of 5 and attribute B with a value of 4, it would be great if i could calculate automatically Attribut C, which is dependent to A and B.

Input field of Attribute C ==> (@{attributeA}+@attributeB})*5

I am creating a Shadows of Esteren campaign at the moment, and it would be a help and it would save some time. Do you see the possibility implementing such a function? Or is there a possibility right now, which I missed? Thank you in advance.

Greeting, Tom
February 23 (11 years ago)
Tom
Plus
Sheet Author
You can't do this already? Pretty sure you can. I know I have a macro that uses a multiple of an attribute to calculate the number of dice rolled.

/roll [[(?{Number of Minions|1}*@{Threat Rating})+@{Melee}]]d10!10>7sd Damage vs @{target|Avoidance} [Avoidance]

Try adding a closing parentheses.
February 23 (11 years ago)

Edited February 23 (11 years ago)
Hello Tom!

Tank you for your answer. I didn't mean macros. What I want, is to calculate dependent attributes out of others in a char sheet, in the attribut section. In some systems for example, the attack value depends for example on strength and dexterity. When i create a new character, I want the system to take the imput values from the strength and the dexterity field and in the created attack field, i would like to to some math (e.g. (STR+DEX)*2). Not in the abilities area.

This would save much time, when I operate with many NSCs. I only have to fill in the two values and the system calculates the dependent ones (attack, parade,...). I hope i can express my needs properly. Sometimes writing english isn't that easy.

EDIT: I guess, this is only possible with the API. Another reason for me, to understand API as soon as possible.
February 28 (11 years ago)
I'd second this request. Pathfinder and other d20 systems have dependent abilities such as Str mods which appear in many ability formulas... writing "floor((@{STR}-10)/2)" everywhere it needs to be gets old almost as fast as seeing it in "floor" in the /r output. Currently I do a "backward" STR score where STR is actually the modifier and the real score goes in the "Max" column, but PF has ability score damage and such that are hard to track with that system. Basically players have to keep a separate sheet with "real" maxes that way (which obviously they'll have one anyway, but I'd like to not have to refer to it during play).

I would like instead to have a STRMOD attribute which is the modifier without requiring effort on my part, allowing the current/max columns to be used for their intended purpose.

TL;DR...+1?
March 01 (11 years ago)
Gauss
Forum Champion
Just a note regarding Ability Score Damage, it does not actually change the ability score. It is counted upwards from zero rather than reducing the existing stat and for every 2 points of damage you suffer a -1 penalty to various things. Source: CRB p555
March 04 (11 years ago)

Edited March 04 (11 years ago)
Roger A.
Sheet Author
I use math in my attributes right now with no problem.... When you call an attribute it pulls the value of anything it can recognize in the box you told it to pull from, and goes several levels deep as far as i can tell. It doesn't work for things where you need the number without the ability to do math(like any box that will be linked to a bubble(it shows the full text instead of doing the math and giving the result)) but i have the max listed for all my attributes, then calculate the stat on the fly from the max version. I even include references to a gm only character sheet for things like rage effects on strength. You just have to use the @{character name|Attribute} syntax instead of the @{attribute} syntax you would in an ability.

Also, you have to be really careful with your parenthesis and brackets not to break things, or screw up the math.

I am pretty sure this isn't actually a real feature, just an accident based on the way the dice roller works, but it does exactly what i want it to do....Please don't fix this bug!!!!!
March 04 (11 years ago)
Gauss
Forum Champion
Roger, Im not sure what you are 'unintended feature' you are referencing. Could you explain?
March 04 (11 years ago)

Edited March 04 (11 years ago)
Roger A.
Sheet Author
Every time i have seen someone ask about using multiple attributes in a formula inside another attribute, for instance @attack=@strength+@BAB
they have been told, "no, that doesnt work". like in this thread. If you use
@attack= @character name|strength + @character name|BAB
whenever you call @attack in a roll, it will pull the text, then pull the values, and do the math. Anything you can use in the dice roller can be put in the boxes for the attribute values as long as you are careful about your parenthesis, brackets, and anything else that might cause unintended errors. I am currently using @strength= ((@{character name|strength max}/2)-5) for my strength attributes, and similar for my other attributes. I even have a formula referencing a boolean value on a gm adjustment sheet on the Strength max box of my barbarian.
The values dont work in the token bubbles or auras or anywhere else that the input doesnt get put through the dice roller, but if the stat is being called by the dice roller you can do a lot of stuff that it seems like was not intended in the design of the character sheets.
Also, abilities that call an attribute using a formula from the attribute max, dont seem to work while the character sheet is open in the edit mode, but saving the edits(and thus exiting edit mode) lets the abilities work.
March 04 (11 years ago)

Edited March 04 (11 years ago)
Gauss
Forum Champion
Hmmm, not sure where you saw people get told that attributes cannot be placed in an attribute but it might have been an outdated reference. I have been able to stick attributes in other attributes for, well, a long time. Perhaps you are remembering something similar? (Such as not being able to use Attributes in Queries?)
March 04 (11 years ago)
+1 I agree this would be very useful.
Gauss - I suspect rather than outdated references, the problem comes down to a combination of "there's no auto-fill for attributes within attributes" and "you have to magically know to use the character name." I myself had absolutely no idea this was possible, and suspect there are some old forum posts from me requesting it. Is there anywhere in the documentation that this is even mentioned as current behavior? See e.g. here where it mentions that Attributes can be used in macros and abilities, but doesn't list "other attributes."

As it stands, the *necessity* of putting the character name directly into the attribute, rather than defaulting to the current character like abilities do, makes it darned difficult to create a template character sheet that you can copy for each player and/or NPC. I hope this will be obviated by the Data Delve updates (ohpleaseohpleaseohplease) and we won't ever have this sort of confusion again.
March 25 (11 years ago)

Kikanaide said:

As it stands, the *necessity* of putting the character name directly into the attribute, rather than defaulting to the current character like abilities do, makes it darned difficult to create a template character sheet that you can copy for each player and/or NPC. I hope this will be obviated by the Data Delve updates (ohpleaseohpleaseohplease) and we won't ever have this sort of confusion again.
This can be done via tokens with the @{selected|}, for currently selected token, and @{target|} for tokens you are then asked to choose.

March 25 (11 years ago)

Edited March 25 (11 years ago)
Gauss
Forum Champion
Kikanaide, Im really not sure what you mean by needing to magically know the character name. You should know the name. However, if you are using a generic macro that you want to auto-fill the name then as Dave stated, you can use @{selected|....} and @{target|....} to target character attributes, supply the name, etc.

Example: /roll 1d20+@{selected|Dexterity}
This will roll a 1d20 and add the dexterity attribute of the character sheet that has been assigned to the selected token.
March 26 (11 years ago)
I personally use @{selected|...} for all my task check rolls and @{target|...} for all my attack based rolls. In the campaign I GM I use it to pull the stats of everyone, considering I made sure everyone is using the same attribute names, otherwise I only pull the token_name variable so as to not gain meta knowledge from the GM's tokens. token_name is the variable to call when you need to pull out a token's name.

Here's examples of an attack/damage macro abilities I set up for one of my monsters.

/emas "@{selected|token_name}" shoots a burst of water out of it's mouth at @{target|token_name}.
/roll 1d100
/w gm Goal: [[@{ACC}-@{target|EVA}]]

/emas "@{selected|token_name}" hits @{target|token_name} for [[2d8+(2*@{MAG})-@{target|M.ARM}]] Water elemental damage.
M.ARM already taken into account.

I set the macro's up this way only because I'm the GM, and by taking a player's M.ARM into account for damage I save time for group and keep them from having to constantly calculate damage adjustments, considering in this system Armor reduces damage taken, not prevent it.
March 26 (11 years ago)

Edited March 26 (11 years ago)

Gauss said:

Kikanaide, Im really not sure what you mean by needing to magically know the character name. You should know the name. However, if you are using a generic macro that you want to auto-fill the name then as Dave stated, you can use @{selected|....} and @{target|....} to target character attributes, supply the name, etc.

Example: /roll 1d20+@{selected|Dexterity}
This will roll a 1d20 and add the dexterity attribute of the character sheet that has been assigned to the selected token.

Your pardon, Gauss. I meant to say that I can't find anywhere in the documentation that you can put math into attributes. Further, I can't find in the documentation that *have* to scope them by character, even though you're on a character's sheet already. Contrast this with abilities, where you don't have to scope unless you want to use something from a different character (or want to use /emas, but that's a separate gripe).

This piece of knowledge is what I referred to "magically" having to know. As you've said, you have the character name at hand - it's just not obvious that you need it. Admittedly, there is a helpful error message if you put syntactically correct reference to a non-scoped attribute (it at least lets you know it's looking for but not finding an attribute). But the lack of auto-fill as presented on the ability side both sends a message that you're doing something unintended and makes it less likely to arrive at a syntactically correct expression.

Dave W., the @selected workaround is decent, and is what I use in macros at present. Thank you for the suggestion, and it's likely what I'll use in attributes too. But like in macros and abilities, it can lead to remarkably strange behavior. @selected for an attribute creates an attribute that only works as intended when called through a token action. It could produce incredibly odd behavior when called from a macro written for the macro bar or intended to be called directly from the character sheet. I've stated before that we should seriously consider unifying the way those three types of macros should be written. I consider this further evidence.

Just pause for a moment - why, on a character sheet, am I writing @{selected|____} to refer to that character's own attributes? Particularly when @selected can point to anyone?
March 26 (11 years ago)
@{selected|...} is not necessary for abilities of a specific sheet. In abilities you don't need to reference the character itself. I only use it to pull token names cause for the monsters I will slightly adjust it's name when there are multiple of the same monster.

Also the reason there is no documentation for math in attribute fields is because it's not a current feature. And another note, if you try using @{selected|...} from the macro bar it work as intended. You will, however, get an error message if you do not already have a token selected. For this reason I recommend using @{target|..} for macros and @{selected|...} for abilities/token actions
Hi again Dave, thanks for the reply. So you stumbled into this discussion midway - see here where Gauss expressed surprise that not everyone knew that Attributes could be nested inside other Attributes. Note I said *attributes*.

This is in fact a surprising thing! You can do math inside of attributes! It won't compute at the time, and it's weird as heck (you *have* to do @{selected|attribute} or @{name|attribute} as opposed to just @{attribute}). But when you include that new, nested attribute in a macro/ability, it'll compute at runtime. It looks almost like there's just a string substitution that then gets evaluated when you run the macro. Regardless, you *can* do math in Attributes. You can do floor, ceil, etc too. It's possible, though I've never tried, that you could even do weird inline rolls.

Knowing that, I invite you to re-read my previous posts, noting carefully where I talk about attributes vs abilities. My beef is that you have to use either the explicit character name there (terrible for when you copy a character) or @selected, and @selected is terrifying to me, a bit, as the GM. For reasons I've described elsewhere, but repeated up above.
March 27 (11 years ago)

Kikanaide said:

Knowing that, I invite you to re-read my previous posts, noting carefully where I talk about attributes vs abilities. My beef is that you have to use either the explicit character name there (terrible for when you copy a character) or @selected, and @selected is terrifying to me, a bit, as the GM. For reasons I've described elsewhere, but repeated up above.

Yes but that was most likely unintended by the developers. I don't think they ever intended players to use the sheets in this manner. Personally I think you're better off doing the math in the macro, not nested into an attribute. The math will come out the same whether you have the formula in the macro itself, using the base stat, or if you try doing this method of nesting attributes, which probably never should of been done in the first place.
FWIW, I'm fairly certain that they did intend for abilities to support non-integer inputs. For two reasons:

1) They apparently represent abilities as strings, and that's harder than e.g. integers in most languages.

2) Several systems have "attributes" that are numbers and sizes of dice. For example, STR might be 2d4 but WIS might be 1d8. I don't think it's a coincidence that these systems are supported.

Unless Riley, etc. chime in and say it's unintended, I'm thinking it's intended but not fully supported (with things like auto-complete). Though I can see why you might think the other way. And I understand thinking that you're better off in the macro not the attribute, but what if you need the same math 30 times? And it can change when you level up? Re-use is a big, big factor in all coding, and macros are no exception.

Dave W. said:

@{selected|...} is not necessary for abilities of a specific sheet. In abilities you don't need to reference the character itself. I only use it to pull token names cause for the monsters I will slightly adjust it's name when there are multiple of the same monster.

Also the reason there is no documentation for math in attribute fields is because it's not a current feature. And another note, if you try using @{selected|...} from the macro bar it work as intended. You will, however, get an error message if you do not already have a token selected. For this reason I recommend using @{target|..} for macros and @{selected|...} for abilities/token actions

@{selected|...} from the macro bar is dangerous for GM's in particular, or for any players who have control of more than one token. That's not to say you can't use it correctly, or get it to work. It works great for abilities that every token has (like Initiative in most systems). That's what it's intended to do, and it works great for that.

Things get trickier if you're using @{selected|...} to mean "this character" inside of an ability. You can see the discussion thread here, where I wanted something to put after /emas so that I could have each of my monsters emote their attacks from their own "voice." Another alternative would have been to type every NPC name into every macro, but that seemed insane considering the amount of work. @{selected|character_name} works great for token actions, but can have unexpected effects if you promote one of those abilities to the macro bar (you can wind up saying things like "Gerbil swings his mighty great-axe with both hands"). Then you feel silly. Far more subtly, if you're *not* emoting but just using @{selected|attribute}, you can use the wrong NPCs attributes for an attack.

Really, this discussion belongs here. That thread is about creating a single, unified way to say "make this character do something using its own voice."
March 27 (11 years ago)
@{selected in the macro bar is what it was made for. Generic macros that work for any token.
March 27 (11 years ago)

Kikanaide said:

Unless Riley, etc. chime in and say it's unintended, I'm thinking it's intended but not fully supported (with things like auto-complete). Though I can see why you might think the other way. And I understand thinking that you're better off in the macro not the attribute, but what if you need the same math 30 times? And it can change when you level up? Re-use is a big, big factor in all coding, and macros are no exception.
Ever heard of nested Macros? Nolan himself said in an interview that he does this himself all the time. Also just because something is made to support a string does NOT mean it was ever intended to hold a formula for nesting other attributes. And actually you have it backwards. It's actually easier to make a field integer than it is string. Especially when you consider all strings are a series of characters and every character is represented by an integer, and all integers must then be converted into binary for the computer to understand.