Custom Character Sheet Saving, but not loading

Hey team, I'm working on a custom character sheet for a robot game, and I've added the name="attr_blah" attribute in the input field. So when I make a change and blur the input, the value gets saved to the character's attributes. All good. But then if I or my player closes the character sheet and re-opens it, the value is displayed in the attributes tab, but not on the character sheet. What's going on? AV off, using Firefox 78.0.2 64-bit cache cleared.

Code example: <div class="mech-class artemis-div"> <div class="mech-class-header"> <h3> Artemis Mech </h3> <p>The Artemis is an adaptable standard. Great for first-time pilots.</p> </div> <div class="class-sheet-row"> <fieldset class="fieldset stats-panel"> <legend class="legend"> Mech Stats </legend> <label for="max-health">Health</label> <input type="text" name="attr_health" class="stat-box">/<input type="text" name="attr_health_max" id="max-health" class="stat-box"> <label for="shields">Shields</label> <input type="text" name="attr_shields" id="shields" class="stat-box">/<input type="text" name="attr_shields_max" class="stat-box"> <label for="move-speed">Move Speed</label> <input type="text" name="attr_move-speed" id="move-speed" class="stat-box"> <label for="max-ammo">Ammo</label> <input type="text" name="attr_ammo" id="max-ammo" class="stat-box">/<input type="text" name="attr_ammo_max" id="max-ammo" class="stat-box"> <small>All mechs start every round with full health, full sheilds, and full ammo.</small> </fieldset> ... div terminates after more code

If you haven't checked out the wiki page (and related pages) for character sheet construction, you might want to do so.&nbsp; The first entry in restrictions is that you can't use ID attributes. <a href="https://wiki.roll20.net/Building_Character_Sheets#Restrictions" rel="nofollow">https://wiki.roll20.net/Building_Character_Sheets#Restrictions</a>

I've read it through a couple of times and saw that. I figured it was outdated, since inspecting the character sheet in play with firefox's developer tools shows that the ID is persisted as written, and I need the ID attribute for the label to bind to the input. But If you think that might be tripping up the javascript that loads the value back, let's yank 'em out and see what happens... please stand by.

Hi&nbsp;Bleehu, +1 to Krynic's advice(the wiki link should answer most questions about sheet basics), Also fieldsets must include a class that start with "repeating_..." Names should be lowercase and cannot include underscores.&nbsp; <a href="https://wiki.roll20.net/Building_Character_Sheets#Repeating_Sections" rel="nofollow">https://wiki.roll20.net/Building_Character_Sheets#Repeating_Sections</a>

Thank you both for such rapid answers! The fieldsets in this case should not be repeating; since each has a unique name and I know ahead of time how many of them there are. :)

I "believe" that all fieldsets are repeating on roll20.&nbsp; ;-)&nbsp; Well at least I haven't used it or seen it used in any other way on sheets.&nbsp; &nbsp;If you don't need a repeating section, perhaps you can simply wrap the section within a div?

Removing the ID tag attribute from all of my HTML, saving, uploading, re-dumping the cache and Ctrl+shift+r reloading didn't solve the problem. But, removing the IDs didn't mangle the label-input layout like I had feared that it would. So small victory.Data pictured below is from making a couple of changes, closing the sheet, reloading the app, and re-opening the character sheet.

Bleehu said: I've read it through a couple of times and saw that. I figured it was outdated, since inspecting the character sheet in play with firefox's developer tools shows that the ID is persisted as written, and I need the ID attribute for the label to bind to the input. But If you think that might be tripping up the javascript that loads the value back, let's yank 'em out and see what happens... please stand by. That page is not out of date, it is among the most update and well maintained on the community wiki, and is in fact a better resource than the equivalent on Roll20's helpdesk. Vince said: I "believe" that all fieldsets are repeating on roll20.&nbsp; ;-)&nbsp; Well at least I haven't used it or seen it used in any other way on sheets. This is the established understand among sheet developers, but if you manage to use it without it turning repeating, let us know and it can be documented.

Looking at your pictures, I see you've probably missed that you can simplyfy health &amp; max health into a single stat, with "_max" as a suffix to the name, i.e. "attr_health" &amp; "attr_health_max" And to follow up on using #ID on sheets, it will cause troubles between character sheets and sync things between them, so you probably didn't notice any problems with testing only one sheet. It's more likely you encounter some undocumented quirk in how things work rather than finding something incorrect or outdated on the wiki regarding character sheet creation.

Looks like Vince is on the right track; If I use &lt;p&gt;Health&lt;/p&gt;&lt;input type="text" name="attr_health"&gt; Then stats load just fine. But as soon as I add this &lt;fieldset&gt; &lt;p&gt;Health&lt;/p&gt;&lt;input type="text" name="attr_health"&gt; &lt;/fieldset&gt; Then the bug reproduces. I guess the easy thing would be to scrap my aspirations to group form data with the tag that was designed to do so, eschew the label and just use divs and h1s like I'd only ever learned five tags. It can't really be that every fieldset is assumed to be a repeating section can it? That wouldn't make any sense, since that's not an assumption that the fieldset tag implies ; so it would be deliriously bad API design to add that assumption, especially since we've already got a pattern for adding that kind of implied behavior as an underscore-delineated classname. The hard thing to do would be to actually check the parser and see if it's searching on all fieldset tags for the repeating_ pattern and see if I could beat it somehow. Probably a waste of time.

Bleehu said: Looks like Vince is on the right track; Everyone who has responded to you in this thread has been 100% correct. It can't really be that every fieldset is assumed to be a repeating section can it?&nbsp; Indeed it can, and it is. You cannot use the fieldset tag on roll20 for anything except repeating sections. The only reason the tag exists on roll20 is to enable repeating section functionality. We only have access to a stripped down version of html on roll20. There's a lot of things that aren't available to us (like the aforementioned ids). The wiki is a vital resource - that's how you learn the specific limitations and requirements of coding on roll20.

You've got to be kidding. The primary code that runs the player view and UI boxes comes from <a href="https://app.roll20.net/assets/app.js?{cache-buster}" rel="nofollow">https://app.roll20.net/assets/app.js?{cache-buster}</a> From line 567 of the minified js; this._ignoreSheetSaves=!0; var e=this,t={}; this.$charsheet&amp;&amp;(this.$charsheet.find("fieldset").each(function(){ var i="&lt;div&gt;&lt;div class='repitem'&gt;&lt;div class='itemcontrol'&gt;&lt;button class='btn btn-danger pictos repcontrol_del'&gt;#&lt;/button&gt;&lt;a class='btn repcontrol_move'&gt;\u2261&lt;/a&gt;&lt;/div&gt;" +$(this).html() +"&lt;/div&gt;&lt;/div&gt;", n=$(this).next(".repcontainer"), o=n.attr("data-groupname"); if(n.length&lt;1||""===o) return!0; var r=o+"_",a={}; e.model.attribs.each(function(e){ if(e.get("name").toLowerCase().substring(0,r.length)===r.toLowerCase()) { e.get("name").toLowerCase().split("_"); var t=(e.get("name")+"").split("_")[2], i=e.get("name").substring(r.length+t.length+1,e.get("name").length); if(a[t]||(a[t]={}),a[t][i.toLowerCase()]!==undefined) return; a[t][i.toLowerCase()]={current:e.get("current"),max:e.get("max")} } }) //[end of each attrib] .... Here, the minifier has turned the keyword 'true' into '!0' to save a few characters. The jquery function `find("fieldset")` is getting all of the fieldset tags in the custom character sheet and creating a new div, with modal controls to delete the repeated attribute... crap, I think this is the wrong line. 'cause then it matches to each of the attribute like it's going to display it on the attributes tab ... gadzooks, you don't think they're parsing the character sheet in each player's browser each time its loaded!?!

Since app.js is served with the MIT license, I'm pretty sure I can legally test it. But honestly, at this point, I think that if I did find a way of using fieldsets with _ignoreSheetSaves=false and not having set classname += "repeating_whatever", it's likely not gonna be something you really want documented for community use. At the moment, I'm doing my free coding making character sheets, not hunting bugs. And unfortunately, it doesn't look like Roll20 is offering bounties .

Bleehu said: Since app.js is served with the MIT license, I'm pretty sure I can legally test it.&nbsp; I'm not sure what sort of legal considerations there are to testing client-side code, but not everything in app.js is under public license. It has many libraries concatenated in it, along with comments for the license of that library. The MIT License at the top of the file is referring to SockJS, which is for server-to-client communication. gadzooks, you don't think they're parsing the character sheet&nbsp; in each player's browser each time its loaded!?! I'm trying to figure out what concern you're implying. If it's that the parsing should all be done server-side to serve a parsed HTML, I disagree. Client-side applications are a thing, in which the DOM is dynamically modified. If anything, the industry is shifting to more client-side stuff over server-side (with search-engine-optimization as a competing concern). If it's security (since you linked to acknowledgements of White Hat contributors), I'm not sure what you're worried this client-side parser will expose. They've obviously taken measures to limit what community-contributed code can do - for example, document and jquery are not defined in the context used for worker scripts. I have my own considerations for how I wish character sheets on Roll20 would work, but that they're run client-side is not one of them.

At the moment, I'm doing my free coding making character sheets, not hunting bugs. Yeah, if you'd take our word on the fact that the Roll20 sheets is a limited playbook and some things just can't be done, you'd have it easier. But honestly, at this point, I think that if I did find a way of using fieldsets with _ignoreSheetSaves=false and not having set classname += "repeating_whatever", it's likely not gonna be something you really want documented for community use. Considering the JS available for us to use is very limited, how would you figure altering this things while limited to the "sheet worker" frame Roll20 have put together? If you manage to figure out new things that could be done, it would benefit everyone if you at least in passing mention things you found. Can I know your github name? If you end up hosting any of your code there, I'd be extremely interested in seeing the results. We all agree it would be great if it had more capabilities and all, but we're also understanding how it currently works, and aiming to create things with the existing tool-set is a better idea than trying to do things that (to our understanding) can't be done. You seem to be a great deal better at JS and these kind of things, so pretty sure you'd be able to implement whatever sheet or concepts easily with the known limitations of Roll20 sheets, and wouldn't be surprised if you figure out some novel things that haven't been thought of before. Just please don't bash your head against (farily well) established limitations when you could just create things with what's available with less headache.

There have been numerous posts that start with "My code works fine on &lt;insert your favorite js/html wysiwyg editor&gt; , but doesn't seem to work on roll20,..."&nbsp; +1 For expanding the access/implementation of js for roll20's character sheets.&nbsp; I assume the subset of js that we can use is due in part to security concerns (being a browser-based system) as well as an ever-evolving "WIP" spanning over the past 6+ years.