Kl1 breaking on one character but not another??

Hello. To specify, this is Pathfinder I had simple dragged Burning hands into my character sheet. And for some reason, it is only roll 1 non-lethal with damage. I have even adjusted my casting level to 5 test to see if that would fix it, to only get the same result of 1 non-lethal. The default macro that comes with the Burning Hands spell. ([[[[{(1*@{caster1_level}),5}kl1]]d4]]) After deleting the kl1 portion, the spell works fine. I then went to an old character, dragged the Burning hands spell in, and it works perfectly fine. Another player in the same campaign also dragged Burning hands into his character sheet and is working as it should. Any ideas as to why this is the case for I am stumped

Could you elaborate which character sheet you are using? If you don't know the name of the sheet a screenshot would help us identify the sheet. 

Gauss said: Could you elaborate which character sheet you are using? If you don't know the name of the sheet a screenshot would help us identify the sheet.  Sure thing, Here is a screen shot of the character sheet and the the roll showing it is not working properly.

Ok, that is the Pathfinder by Roll20 sheet.  In my testing it worked correctly. I dragged and dropped from the compendium, then tested it.  Check your configuration tab, if your CL is 0 it will produce the result you got. 

That's the thing, you can even see on the spell page, My spell Casting level is 1. I have no idea why only my character sheet is doing this.

Ok, found out what it is, and it is dumb. So I have three copies of my character sheet do to how split my character is. Normal, Paladin, and Anti-Paladin.  I didn't update the Paladin character sheet from 0 CL to 1 CL. And now it works. That is the last thing I expected, was a one of the player sheets, to be effecting another the other ones.

Not sure why one sheet would be affecting the other ones. Are you using macros? 

I was using the base Burning Hands, Dragged from the Compendium into the character sheets.

If these 3 character sheets all have the same name that could cause a whole mess of trouble as it may end up referencing a different sheet than the one being used. Such usage can end up with a mishmash of correct and incorrect references and inconsistent behaviour.

RainbowEncoder brings up a valid point...are your character sheets all named the same thing? If so, you need to change the names slightly. Maybe add "1" "2" "3" after them.

I'm surprised the character name has any impact at all. I'd expect each sheet is identified by a hidden UUID (a secret ID that is certain to be unique). But it's worth changing the names to see if it makes a difference, and let us know if it does.

I believe each sheet does have a UUID but behind the scenes the parser changes unqualified (no name/keyword) attributes into name-qualified attributes (There is no id-based attribute referencing). It has to fully qualify the attributes since if you reference a different sheet it needs to be able to know to pull the attribute from that sheet and not the first sheet even after multiple levels down. I also reckon it does this qualifying upon retrieval of the attribute/ability since if you sneak in an unqualified attribute (such as via the prefix trick ) it will fail with the same error as trying to use an unqualified attribute in the chat box.

I have ran into a problem in the past when two characters were named the same thing. Any macro that pulls information from a character sheet based on the name, rather than an id number, can pull from the wrong sheet. I am guessing a similar problem is happening here, as RainbowEncoder stated.

Only reason all three are named the same. Are myself and the DM don't give away to much player knowledge away that could effect natural reactions from the other characters.  But I am willing to test anything you guys would like scene if we would like to travel down the path to figure out what and why for future players that may come across this issue.

Deadman said: Only reason all three are named the same. Are myself and the DM don't give away to much player knowledge away that could effect natural reactions from the other characters.  But I am willing to test anything you guys would like scene if we would like to travel down the path to figure out what and why for future players that may come across this issue. This isn't a bug, just a natural consequence of naming. Go into a room with three people named Robert, call out the name Robert. All three respond, that isn't a bug, just a natural consequence.  I would suggest changing the names and then not showing the players the second and third characters. There is probably no reason for them to see it. 

Deadman said: Only reason all three are named the same. Are myself and the DM don't give away to much player knowledge away that could effect natural reactions from the other characters.  But I am willing to test anything you guys would like scene if we would like to travel down the path to figure out what and why for future players that may come across this issue. One confusing way around this would be to have a space or two after the actual name. When displayed those extra spaces would generally get hidden as a result of how webpages display spaces. "Deadman", "Deadman ", and "Deadman  " would be considered three distinct names and can reference attributes separately such as @{Deadman|hp}, @{Deadman |hp}, and @{Deadman  |hp}. You just need to be careful with your spaces if you need to reference a particular version.

RainbowEncoder said: One confusing way around this would be to have a space or two after the actual name. When displayed those extra spaces would generally get hidden as a result of how webpages display spaces. "Deadman", "Deadman ", and "Deadman  " would be considered three distinct names and can reference attributes separately such as @{Deadman|hp}, @{Deadman |hp}, and @{Deadman  |hp}. You just need to be careful with your spaces if you need to reference a particular version. Ah, yes, the simple adding of a single and then double space has made the difference enough in name scheme to not effect the other two character sheets. Which will also something I will need to keep in mind and suggest to my DM just in case he ever pulls a multiple identical siblings situation. Gauss said: This isn't a bug, just a natural consequence of naming. Go into a room with three people named Robert, call out the name Robert. All three respond, that isn't a bug, just a natural consequence.  I would suggest changing the names and then not showing the players the second and third characters. There is probably no reason for them to see it.  Quite true, that would be very much the case in real life, and just wasn't expecting it with the programming. I would have thought all three would have unique identifiers to keep them separated My DM and I had already thought ahead and made the splinter character sheets hidden from the other players.  For anyone curious, I have a paladin that after a backstory event, has been split between paladin and Anti-paladin ways. With the main character sheet only having the basics from paladin/Anti-paladin, but not alignment/channeling specific abilities like lay on hands or Touch of Corruption until siding which way her alignment is leaning. Very homebrew but a fun one for obviously, the normal play would be staying in the specific alignment area at all times. 

Deadman said: Quite true, that would be very much the case in real life, and just wasn't expecting it with the programming. I would have thought all three would have unique identifiers to keep them separated Things can be addressed via unique identifiers, or the name...it depends on the method used. The method in this case appears to be the name. 

The name issue might be related to the age. When Roll20 was introduced, the API didnt exist and even character sheets didn't exist, so the need for a UUID probably wasnt necessary - or maybe wasn't considered. As other aspects of the system improved, some aspects of sheets might not have been updated to use UUIDs, like the character sheet name. I'm just speculating here, but there are other examples of newer introduced features using different code from earlier stuff.