[Sheet Workers- HELP] Unexpected NaN errors

...in a situation that makes very little sense. I know exactly where it's crashing- when it attempts to set the maximum weapon rank- but I have no idea why - yes, I'm setting the value to a string, but there's no reason why it shouldn't work, since that's perfectly valid under normal circumstances. It worked fine previously, but while I was attempting to get something else to work, this portion of the script stopped working entirely as well. Here is the relevant code. Please help!

Right, this code makes no sense. You're comparing some type of classType variable, but it's never set to anything, so it stays an empty string. Same for classIndex. Also, in line 19, you're setting  classType to 'pr' instead of comparing - probably missing an equal sign there (that's just what my hinter gave me). Okay, so I won't try to understand the code, since it's totally unreadable, but here's something I noticed: try <input type="hidden" name="attr_Daggerrank" value="E"> instead of  <input name="attr_Daggerrank" value = "E" hidden> Also you may want to move your non-constant declarations (let weps, let wepcaps, etc) into  the callback functions (but that should not affect this error).

Oh, I neglected to mention that this is only a portion of my code. I must have accidentally omitted portions I didn't mean to (such as the declaration of classType and classIndex). Would it help if you could see the entire thing? And yes, setting classType to "pr" is absolutely intentional. I'll give your suggestion a try and see how it goes. Edit: Nope, it still throws the exact same error. Here's a picture of the error message:

I don't know, when I just plugged in something like classIndex = 3, and classType= "pr" it just seemed to work without any error messages. But the best way to debug this is to just insert log(object) before doing setAttrs(object), and hopefully the console log will give you some hint about what's wrong. And yes, setting classType to "pr" is absolutely intentional. It's your code, and I don't get to tell you how to write it, but disguising an assignment as a comparison is pretty much deliberate code obfuscation! Why would anyone do that...

Well, when I log the value, everything seems perfectly fine, but I still get the same errors. I've also tried running my code through JSLint to see if there are any syntactical errors the Roll20 engine didn't catch, but there doesn't seem to be much there, either. Edit: Oh, actually, that's odd. When logging it on its lonesome, the value seems perfectly fine, but when logging the object of updated values, the rank is undefined. That explains the error, though I have no idea why. Here is my updated code. I have been able to successfully add the weapon rank values to the object of updated values, but it still returns the same errors.

The only real difference that I could find between the OGL character sheet and the provided is that the max values for the attributes have their own defined input on the character sheet whereas the provided code does not. I don't work with character sheets much, so my question is, "Would not having the max value of an attribute specified as it's own input, i.e <input type="hidden" name="attr_ATTR_max">, have an impact on being able to set this value through a sheet worker?"

@Kyle No.

This is an example of an object that has been logged to the console with my updated code : AnimaU: 0 AxeU: 0 BowU: 0 DaggerU: 0 DarkU: 0 GunU: 0 LanceU: 1 Lancerank_max: "B" LightU: 0 StaffU: 0 StoneU: 0 SwordU: 1 Swordrank_max: "B" Which seems perfectly valid, but I still get the exact same errors, which is odd. EDIT: I managed to make it work! I just needed to set default values for the _max fields. It still doesn't create any editable attributes on the Attributes tab, for some reason, but I don't get any error messages this time.

That's odd. It should totally create attributes.

Marth Lowell said: It still doesn't create any editable attributes on the Attributes tab, for some reason, but I don't get any error messages this time. Isn't that the purpose of declaring these fields as hidden?

Kyle G. said: Marth Lowell said: It still doesn't create any editable attributes on the Attributes tab, for some reason, but I don't get any error messages this time. Isn't that the purpose of declaring these fields as hidden? The purpose of hidden (non-autocalc) fields (apart from some CSS tricks) is to set default values for attributes so they don't come up as undefined before they've been set by a sheet worker. Actual attributes are only created when a field is changed from the default; just having hidden inputs on the sheet doesn't create any attributes at all. You can totally set attributes via sheet workers that do not correspond to any inputs and they should still show up on the attributes & abilities tab (except for repeating attributes).

It seems that the attributes are functionally there, but don't appear on the tab for some reason. It usually only does that when there's a runtime error with the script, but everything seems to be working perfectly, so I don't know what the problem is.

Are the attributes generated from within a repeating fieldset?  Repeating attributes do not show up on the attributes tab.

Nope. None of them are from repeating fieldsets.