[5e Shaped] Version 8+

Pakki said: zerosius said: I can also report a few cases where some descriptive text was lost for my homebrew monsters, where i apparently added them into the wrong section. There seems to be a few cases where this is not fixed, as i made 100% sure to let every sheet complete its upgrade before closing or messing around within it. Not a big deal, but i can definitely also report this behaviour pointed out by a few people before. Same here. A lot of my monsters lost their descriptions, and all of their attack rolls failed to convert in their entirety. Any ones that do convert are converted to spell attack rolls. I'm seeing the same issues.  All of the NPCs I have imported from the SRD (afraid to open my custom monsters for fear of recreating them), have most of their Actions and Attacks fields defaulted to "Melee Spell Attack" with no governing attribute and no damage rolls (rolling 'd0' with no damage modifier).  I have let the sheets continue to process for minutes in hopes that it will recover itself, but alas, no help. The sheet output also doesnt seem to be using the same template that it was using last version.  That's weird, but not the end of the world

Matthew H. said: I'm seeing the same issues.  All of the NPCs I have imported from the SRD (afraid to open my custom monsters for fear of recreating them), have most of their Actions and Attacks fields defaulted to "Melee Spell Attack" with no governing attribute and no damage rolls (rolling 'd0' with no damage modifier).  I have let the sheets continue to process for minutes in hopes that it will recover itself, but alas, no help. If it's worth fixing for future upgrades please open a bug report with the specific case.

Matthew H. said: The sheet output also doesnt seem to be using the same template that it was using last version.  That's weird, but not the end of the world Hence the bump in the major version. Many fields have changed. Custom macros will need to update to the new name (should be as simple as changing a word in the macro). Script egnerated macros all upgraded to the new roll template.

Kryx said: Matthew H. said: The sheet output also doesnt seem to be using the same template that it was using last version.  That's weird, but not the end of the world Hence the bump in the major version. Many fields have changed. Custom macros will need to update to the new name (should be as simple as changing a word in the macro). Script egnerated macros all upgraded to the new roll template. I think I follow what you are saying.  However, for one of the broken NPC sheets I had (Guard), I re-imported his "Spear" attack from the SRD and while the fields did import correctly, the output template for the "Spear" action is still not using the correct template -- all of the information is there, but its just a different template (I guess maybe its just using the 'default' template). Any suggestions on the mangling of Attacks/Actions after the upgrade? Thanks for your help, I hope to recover my sheet functionality as Shaped is by far the best 5e sheet I have used.

Kryx said: Aiden said: The new spells layout (bug?) makes preparing spells rather clunky See&nbsp; <a href="https://bitbucket.org/mlenser/5eshaped/issues/156/" rel="nofollow">https://bitbucket.org/mlenser/5eshaped/issues/156/</a>... which has some screenshots of how it'll look in 9.1.0 Looks sharp, Kryx. 9.1.0 can't roll out soon enough.

I'd like to report a weird compatibility issue with monsters dragged from the monster manual on roll20. Basically any monster with regional effects has all their actions and abilities appear in the regional effects section instead of as actions and abilities. Some examples involve the beholder and most of the dragons, but young black would have been the most recent example. I was wondering if anyone else had run into this issue and if it was update related.&nbsp;

Personally I haven't experienced issues with the new version not already in the patch notes as known issues. As far as I can tell my NPCs modified with house rules like my Zombie are still modified with the house rule. Thumbs up Kryx!&nbsp;With that being said I have some feedback (feel free to redirect the blame of some of this to Roll20 if appropriate - I don't necessary know how the responsibilities are divided here): The 4 swirling balls used as indication of whether a sheet is updating is not great because: Comparing it to e.g. a busy mouse cursor people assume the conversion is still going on on while they swirl. It is not intuitive at all that the sheet is done updating to the new version when the balls stop lagging while swirling. Hence comments like it taking several minutes rather a matter of seconds tends to show here after patches like this. When I open e.g. a non-updated PC sheet it takes several seconds before something appears to change. The swirling ball image is not showing and the version is unchanged on the character sheet. I actually do not know if something is going on behind the what is being displayed at this point. What appear to be the same split of a second that the version of the PC sheet is updated the lagging swirling balls appear, then a few seconds goes by, the lag stop, and the sheet is updated. So basically unless people know that the character sheets needs an updated before trying to up a sheet, they might close it before the swirling balls even appear or while they lag. I doubt that half-converted sheets is a big as problem as this thread sometimes gives me the impression of, but it is an uncertainty that GMs and players can have. For a manual pro-version update the GM is 100% in control of when the sheets are updated. I think many GMs don't follow this thread and only read it if they experience problems, use the public version due to it being both easier and cheaper, and they get surprised by upgrades changing things just before a session start - which result in angry outbursts. They just want to roleplay - and just want the needed tool to always work. To be honest I think that if there was a popup saying "Character sheet is out of date. Press Ok to convert existing character, or cancel to leave current sheet untouched." and an "Update completed successfully" popup when done then most of this confusion wouldn't be there. Autoupdating is fine for people just using SRD monsters - they would complain if they had to do something manually for each NPC. Only applying changes to new NPCs sounds like a really bad idea - but reading this thread it looks like some people with many home-rule-NPCs would prefer this. Can't always make both extremes happy - maybe a disclaimer for those considering using the sheet warning what the implications&nbsp;using heavy home-rule-NPCs can have, and that this to some extend can be alleviated&nbsp;by as a pro manually updating the sheet - naturally also stating that issues reported in versions older than the public versions are ignored. Another thing that isn't helping this time, is that a big part of the patch notes can be found in the middle of page 4 of a 9 page thread due to the unusually long time Roll20 took to publish this version after it was pushed. I understand why you changed to a mega-thread - I'm just saying why I think so many people reported problems already mentioned in the patch notes. Sorry for wall of text.

Kryx said: Jim W. said: it can take 5-15 minutes to convert a sheet I think The upgrade should occur in 10 seconds or less in most cases. Maximum 40 seconds for the many spell cases In my experience, this depends on a few factors. Speed of the PC / browser Javascript engine, as the conversion runs locally. A machine that's out of memory and constantly swapping, while using a browser with very slow Javascript, would likely make upgrade painful. Any browser plugins that slow things to a crawl. Lastpass on Chrome is notorious for this. Ctrl-Shift-N for the roll20 tab (incognito / adult (hurr) mode) resolves that. NPC - definitely fast, 10 to 40 seconds like Kryx describes PC - I've seen it take upwards of a minute, and during the upgrade to 7.x, we had one PC that took almost 5 minutes. That was much faster when upgrading to 9.x though, I think about a minute and a half.

@Gediablo, I am pretty certain @Kryx doesn't have any better choices here. The sheet updates for the entire campaign when roll20 accepts the pull request. There is no versioning where you could choose to keep an older sheet. Since the attributes change, the character has to go through the upgrade script or it would definitely be broken. roll20 doesn't have the "hooks" he'd need so his upgrade script can update the "please wait" indicator when it is done. Certainly the script knows when it's finished, or I'd assume so, but it can't communicate that to what's being displayed. My understanding is that the roll20 devs are the ones to petition here, not @Kryx. @Kryx mentions something about a silent update, which would speed things up. I'm not sure what wizardry he's referring to, but certainly any additional wizardry would be welcome :). We've had updates take so long that Chrome pops up a note "the page has become unresponsive, kill or wait?" I can understand if someone clicks "kill" at that moment. That would also hose that character sheet. The right response is to tell Chrome to "Wait" - as often as it takes to let the update finish. One way that @Kryx can minimize this pain is to stabilize the underlying structure. That comes with a trade-off as well though: no optimizations. My naive understanding is that @Kryx keeps changing the way the sheet is structured not for the hell of it but in order to optimize speed / add features. That comes with upgrade pain. I'm willing to deal with that for those features, but I'd be lying if I said I wasn't looking forward to @Kryx running out of ways for major optimizations and the sheet's underlying structure to become stable. Stable as in largely unchanging.

Gediablo said: So basically unless people know that the character sheets needs an updated before trying to up a sheet, they might close it before the swirling balls even appear or while they lag. I doubt that half-converted sheets is a big as problem as this thread sometimes gives me the impression of, but it is an uncertainty that GMs and players can have. For a manual pro-version update the GM is 100% in control of when the sheets are updated. I think many GMs don't follow this thread and only read it if they experience problems, use the public version due to it being both easier and cheaper, and they get surprised by upgrades changing things just before a session start - which result in angry outbursts. They just want to roleplay - and just want the needed tool to always work. This * 100. Unfortunately, Kryx and my hands are somewhat tied on this issue. Short of building his own versioning system inside Roll20's data model (newsflash: not gonna happen), there's no way that Kryx can reasonably support multiple versions of the same sheet within the system that Roll20 has given us. That means that if he releases an update to non-pro users, it has to be a mandatory update. There's no reasonable way to give the user the option not to accept it. As far as we're both concerned, this is a HUGE limitation, but I'm not sure that there's much prospect of Roll20 addressing it any time soon. Realistically the only thing that we could do is to make non-pro updates much more infrequent, coming out after pro users had tested it for many months and things had stabilised somewhat more. But it's likely that people would still be unhappy about the forced update - particularly if it happens minutes for a game - and they'd also be frustrated at not being able to get access to the latest fixes and features for much longer. I'm going to be opening a feature request about this with Roll20, and I'll link to it from this thread - if you're unhappy about the way this happens I'd urge you to vote on it and encourage others to do so as well. For all pro users: please, please,please, always use a custom sheet, and never use the 1-click script install. I'm probably going to try and get the companion script removed from 1-click because of all the problems it causes at the moment. For the slight extra work involved in copy and pasting the code into your game settings, you can avoid an enormous world of pain by controlling exactly when and how you upgrade. Furthermore, it will allow Kryx and I to co-ordinate our releases properly so that you will always get a sheet and a script that work nicely together. I will be beating this drum heavily over the next few weeks, and I'm going to be updating my documentation to tell people not to use 1-click to try and get the message out. As time goes by, I anticipate that my ability to muster sympathy for pro users who haven't heeded this advice will diminish substantially! If you're a pro user and you're not installing the script and sheet from github, please change it as soon as you reasonably can, you won't regret it!

Lucian said: &nbsp;I will be beating this drum heavily over the next few weeks, and I'm going to be updating my documentation to tell people not to use 1-click to try and get the message out. As time goes by, I anticipate that my ability to muster sympathy for pro users who haven't heeded this advice will diminish substantially! If you're a pro user and you're not installing the script and sheet from github, please change it as soon as you reasonably can, you won't regret it! I'm one of the ones that use the auto-update feature. I am hosting 4 games on my account, as we have a group where people take turns running games. Copy/pasting for 4 games becomes cumbersome. It is nice to be able to rely on the 1-click to keep things in sync - mostly, that is, unless there is a major change in version. Could the other 3 DMs update their own API scripts on the games hosted on my account? In theory, yes. In practice - not so much. They break out in hives when you mention "github". That said, I understand your desire not to have to deal with roll20's release vagaries. It'd be useful if the OP in your script thread was updated to reflect version. Right now it claims github 4.9 and 1-click 4.6, when it is github 5.1 and 1-click 4.9.

Has the weird problem with every action defaulting to a melee spell attack as well as the damage die not actually being rolled been fixed?

Thorsten B. said: Kryx said: Jim W. said: it can take 5-15 minutes to convert a sheet I think The upgrade should occur in 10 seconds or less in most cases. Maximum 40 seconds for the many spell cases In my experience, this depends on a few factors. Speed of the PC / browser Javascript engine, as the conversion runs locally. A machine that's out of memory and constantly swapping, while using a browser with very slow Javascript, would likely make upgrade painful. Any browser plugins that slow things to a crawl. Lastpass on Chrome is notorious for this. Ctrl-Shift-N for the roll20 tab (incognito / adult (hurr) mode) resolves that. NPC - definitely fast, 10 to 40 seconds like Kryx describes PC - I've seen it take upwards of a minute, and during the upgrade to 7.x, we had one PC that took almost 5 minutes. That was much faster when upgrading to 9.x though, I think about a minute and a half. OK so some actual test figures.&nbsp; Not complaining about anything, just be aware I guess that all connections are not equal.&nbsp; No issues with sheets or attacks. Archer from VG1&nbsp; - a fairly simple NPC. 2 seconds to get the "processing NPC from SRD" box 40 seconds to NPC layout 90 seconds to get to apparantly complete.&nbsp; Scout - from 7.12.2 to 9 - 10 seconds Scout from SRD 9 seconds to get the "processing NPC from SRD" box 34 seconds to NPC layout 80 seconds to apparantly complete All weapon attacks are fine [ranged or melee] and useable display - although range on Longbow only shows 150' not long range.&nbsp; I have once seen a sheet that had no version number showing, and nothing populated, but deleted it and retried and all was fine - I think this must have been a failure to load something from Roll20.&nbsp; Output example: Imported Guard from SRD as well.&nbsp; Only odd thing is that 2-handed damage option is listed as text - exactly the same as Roll20 sheet so is an issue of SRD having it as one weapon in list - not two as I would prefer. "<span title=" Rolling d20 + 2[proficient] + 1[dex] = ( 15 )+2+1">or 5 (1d8 + 1) piercing damage if used with two hands to make a melee attack."

Lucian said: For all pro users: please, please,please, always use a custom sheet, and never use the 1-click script install. I'm probably going to try and get the companion script removed from 1-click because of all the problems it causes at the moment. All well and good, but it sorta bypasses the Defaults option completly? Not that they save or work for 9 - I know this is because you guys have no way to test/develop that stuff as yet, but if you plan to add this functionaility it can only be via 1-click surely?

Gediablo said: To be honest I think that if there was a popup saying "Character sheet is out of date. Press Ok to convert existing character, or cancel to leave current sheet untouched."&nbsp; This is a good idea if it is possible because at least it gives the owner a chance to go out and make a copy of the campaign before the upgrade. H

Spinda the Liar said: Has the weird problem with every action defaulting to a melee spell attack as well as the damage die not actually being rolled been fixed? Not as of yet as far as I can tell. &nbsp;I started a bug report on their JIRA, but the reproduction steps require unconverted 9.0.0 sheets, which is not possible for a Plus user to create now that the public sheet has upgraded to 9.0.1. Here is the link to the bug report in case you can provide any additional information:&nbsp;<a href="https://bitbucket.org/mlenser/5eshaped/issues/198/conversion-to-901-mangles-many-srd" rel="nofollow">https://bitbucket.org/mlenser/5eshaped/issues/198/conversion-to-901-mangles-many-srd</a>

Jim W. said: Lucian said: For all pro users: please, please,please, always use a custom sheet, and never use the 1-click script install. I'm probably going to try and get the companion script removed from 1-click because of all the problems it causes at the moment. All well and good, but it sorta bypasses the Defaults option completly? Not that they save or work for 9 - I know this is because you guys have no way to test/develop that stuff as yet, but if you plan to add this functionaility it can only be via 1-click surely? A few things here: There are no Roll20-level options for the script at present, and I have no plans at the moment to use them. The chat window UI of !shaped-config is more flexible for me and I don't see much benefit in moving to the Roll20 useroptions system for the script. So 1-click really delivers few benefits for the script at this point. As you point out, it's not really that credible for Kryx to use the default options for the sheet at the moment because there's no useful way to test it The functionality of the defaults stuff is currently available using the !shaped-config New Character Settings. These are slightly out of step with the latest sheet at the moment but they will be brought into line shortly When the default options functionality becomes testable, it will most likely be implemented by making these options available for custom sheets somehow. If this is the case, there may well be no requirement to use the list sheet to make use of it effectively All in all, as things stand, there's really very little reason for any pro user to be using either 1-click or list sheets - and considerable advantages to not doing so.

HLazar said: Gediablo said: To be honest I think that if there was a popup saying "Character sheet is out of date. Press Ok to convert existing character, or cancel to leave current sheet untouched."&nbsp; This is a good idea if it is possible because at least it gives the owner a chance to go out and make a copy of the campaign before the upgrade. Sadly there's no credible way to do this at the moment. Roll20 doesn't allow Kryx to maintain multiple versions of the sheet (except as a custom sheet), so the only way to do this would be to have the installed version include every previous version and allow the user to select between them. That's simply not a credible option - the sheet would be so huge it would crash everyone's browser most likely.

Lucian said: For all pro users: please, please,please, always use a custom sheet, and never use the 1-click script install I used to do this, until the sheet kept getting updates pushed out with frequency bordering on ridiculous. Frankly, my players and DMs are a little annoyed that the sheet keeps changing (I'm talking the major changes in UI and stuff like that, and they have to relearn it and there is no wiki on basics of how to use the sheet - just a document for more advanced usage - which has out of date images). However, that resolves itself after the first game and everybody has acclimatized to it. I'm one of the GMs who monitor the sheet threads and I know what is coming and how to help the players and DMs with the changes. But I'm not complaining, I think the sheet and script are awesome - even if I don't agree with some of the changes. But I have multiple games using this sheet and some of them using the companion script as well. I would rather spend my time on game prep than going through all the games and updating sheets and scripts manually. My request would be to release new versions less frequently, say keep a stable version out there for 6 months or so but I know that isn't going to happen. However, I might follow your advice Lucian, once the next version reaches a stable state (i.e bug fixes are done) and thereafter, only update if I feel the next release is worth it and only when it is stable. I appreciate all the hard work and time put into the sheet, Kryx, and the script, Lucian.

Jan D. said: So, it would seem the version 9.0.1. is a broken mess, sorry to say so. I am in 2 rather big westmarches-style campaign and a couple smaller ones. Each of them had their NPC sheets basically destroyed, with attacks and spells not working and the DMs breaking down in frustration over what seems like an untested Beta version of a sheet, modificators being a mess and anything homebrew basically either being gone or at least broken. It's a cointoss on that one, it seems. The same obvioulsy goes for player sheets, with anything that can not not just be added from the SRD broken and even that not working properly.&nbsp; (Like all the spells adding damage and saving throws, attacks being multiplied, text just not displaying in chat no matter what boxes you tick and what fields you fill out...) Now I know you keep saying stuff will be fixed in 9.1., but why push out a broken version of the sheet through an update to begin with? People and especially DMs usually have better things to do than repairing literally hundreds of sheets. So unless 9.1. hits the live update of roll20 very, very soon this is just plain silly and essentially unusable. There were people testing the sheet for a long time before Kryx sent out the updates, he was well aware he had to update before of roll20s new wrap around scripts , and he was also told people who followed the thread. &nbsp; Kryx is a nice guy, and has a big work load he would more than help you, but he has a linear workload , so if you write up a concise, and helpful post then I would have thought he'd probably be more able to help.&nbsp; If your DM homebrews out of the borders of 5e , then I would think no matter what sheet you chose to use your always risking losing information on updates. I am updating a game from Ver 2 with no issues, and no lag.&nbsp; Lag can be caused by having 52 spells in your spellbook (using unprepared ones) like one of the players did in my game. He always complained he was lagging every session. Well I just found his reason, deleted his spells. Only in pencil and paper would you have 52 spells "printed" out. Imagine trying to write those out every session, that's what your computers trying to do everytime you open your sheet.

Hey Doug, Broadly I agree with you. The trouble is that while there are a lot DMs and players who want stability, there are also plenty who want new features and improvements to how existing ones work. In commercial software development, we would maintain an LTS release of the sheet/script with only important bugfixes against it, and then have a more aggressive release for those that want to stay up to date with the latest changes at the cost of stability. The problem with doing this is that it's a PITA, because it involves developing, packaging, testing and maintaining multiple releases of the same software at the same time. That's what I used to do for my job, and I suspect Kryx still does, and it's seriously *&&^*ing dull. Since we're both doing this largely for the satisfaction we get out of it, neither of us are especially enthusiastic about going down this route. That being the case, we have to make a choice about whether we release for the users who want stability, or those who want functionality. There's no easy answer to that question, unfortunately :-( The best we can manage is to try and get some releases to a decent level of stability and then people who want stability will have to be content with installing those and staying with them until the next stable release, at which point they'll have to decide whether the update is worth the potential pain of upgrading. FWIW, Kryx is doing a lot of work at the moment on improving automated testing of the sheet in an effort to try and reduce the number of strange issues that people see, particularly with updates; it's unglamorous, boring and frustrating work, so cut him so slack! Cheers,

Doug E. said: once the next version reaches a stable state (i.e bug fixes are done) and thereafter, only update if I feel the next release is worth it and only when it is stable. Sheets don't just magically get stable. That process requires lots of users testing and using the sheet. Essentially everyone wants everyone else to test the sheet before they use it. EDIT: Lucian explained it above quite well. The process of maintaing a LTS and a current version are arduous and as I mention above there will be zero testers for LTS as those who can be bothered to test will likely use the latest version. So LTS isn't viable in this environment imo.

I'm going to go out on a limb and speak for everyone using the Shaped sheet -- The sheet is amazing and the work that has gone into it is astounding for a personal project. &nbsp;As users we should try and temper our frustrations when reporting strange things that we find. &nbsp;I am fortunate in the fact that I was not planning on running a large battle for my session last night. &nbsp;I rely heavily on the shaped sheet to make my life as a DM easier and combat smoother. &nbsp;I suspect that others were not as fortunate and if anyone else is having the issues that I am with the conversion between 7.12.2 and 9.0.1 then it would be incredibly frustrating and could have completely ruined the night. I am actively involved in the bug tracker with Mark to try and help debug this strange issue. &nbsp;I can only do so much as a Plus user, but we all want the same thing -- a bug-free 5e Shaped sheet! &lt;3

Lucian said: HLazar said: Gediablo said: To be honest I think that if there was a popup saying "Character sheet is out of date. Press Ok to convert existing character, or cancel to leave current sheet untouched."&nbsp; This is a good idea if it is possible because at least it gives the owner a chance to go out and make a copy of the campaign before the upgrade. Sadly there's no credible way to do this at the moment. Roll20 doesn't allow Kryx to maintain multiple versions of the sheet (except as a custom sheet), so the only way to do this would be to have the installed version include every previous version and allow the user to select between them. That's simply not a credible option - the sheet would be so huge it would crash everyone's browser most likely. I believe what Gediablo is talking about is a per character sheet pop-up not a per game pop-up. The new sheet updates gets pushed and when you open a character sheet it lets you know you are about to upgrade to the new layout, cancelling would just leave the sheet the way it was before it was opened, unconverted.

Thanks Lucian - did not really appreciate the amount of stuff in the script - I guess that's because I came into this quite recently - as was using a different [now obsolete - but works fine but not compendium-compliant and maybe pre-compendium] sheet since I moved from 2e to 5e on Roll20.&nbsp; Not sure I will use most of the stuff in there! Tested the basic functionality of the script - noted a few issues - updated to latest script from the github and this resolved some issues.&nbsp; Can't seem to get token defaults to work at all, not even when select one token and use !shaped-apply-defaults - not sure why or if me or a bug as yet.&nbsp;&nbsp; EDIT: I had wondered what the Link was about but as I did not want a link added...duh!&nbsp; So was me not the script/sheet! This issue is minor compared to the big step up having all those beautiful buttons show when I click a token! I can see nothing in the documentation about setting the "Passive Skills" checkbox for a new character - and not sure if this is a script or charsheet issue.&nbsp; [Reason: I like to have the 3rd bar as Passive Perception].

Kryx said: Doug E. said: once the next version reaches a stable state (i.e bug fixes are done) and thereafter, only update if I feel the next release is worth it and only when it is stable. Sheets don't just magically get stable. That process requires lots of users testing and using the sheet. Essentially everyone wants everyone else to test the sheet before they use it. EDIT: Lucian explained it above quite well. The process of maintaing a LTS and a current version are arduous and as I mention above there will be zero testers for LTS as those who can be bothered to test will likely use the latest version. So LTS isn't viable in this environment imo. For the record, I am one of those testers. Not as often as I'd like but I have a game dedicated to the latest sheet and script. Usually, when I find a bug it is already reported in your issue tracker.

Ed S. said: I believe what Gediablo is talking about is a per character sheet pop-up not a per game pop-up. The new sheet updates gets pushed and when you open a character sheet it lets you know you are about to upgrade to the new layout, cancelling would just leave the sheet the way it was before it was opened, unconverted. For the benefit of all who may not understand how this works, here's a bit more detail on what's happening and why what you suggest isn't possible. What you see as a character sheet is effectively two separate systems working together. Underneath, there is a big set of named "attributes" that contain information about your character in a particular format - things like "Charisma" and "Proficiency Bonus", but also internal settings that make the sheet work which aren't obviously part of a character's attributes. If you go to the attributes and abilities tab of a character you will see some (but not all) of these attributes. Some of them have values that are fairly obvious, others contain complicated information in specific formats that help the sheet do its stuff but make no sense to an end user. On top of this sits a presentation layer consisting of a limited form of HTML that can display these attributes in the format that you see on the screen. The way that the presentation layer is written depends on the way that the data it displays is stored, and vice-versa. Sometimes it's possible to change one without changing the other, but sometimes, changing the way things are presented requires the way that the data is stored to be change as well. When Kryx releases a new version of the sheet, he often has to change the way the data is stored in order to support new layouts/features. He tries to avoid this wherever possible, but the Roll20 character sheet system is relatively constrained, so he often doesn't have the choices that would be available to a web developer on a more open-ended platform, so he has to make do with what he can. When he updates the way the data is stored, he has to write scripts that upgrade the attributes of old characters to the new format, so that they will work with the new presentation system. These scripts get executed when you open a character sheet for the first time on a new version of the sheet. Now, what happens if you cancel that upgrade script? Well, the data is still stored in the old format. But the presentation layer is the new system, which relies on the attributes being in the new format. So now everything is broken. Well, you might ask, why can't he have an option to not upgrade the presentation side as well? That's what I was talking about in my previous post - doing that would entail effectively having a copy of the sheet HTML for every version that is supported, with some sort of switching mechanism between them. It's not clear to me that's even possible given the constraints on character sheet HTML, but even if it was, it would be incredibly unwieldy, slow, and error-prone in ways that would make people long for the level of problems that we have now! It might look like a case of "just make the upgrade optional", but what actually hides underneath that statement is a world of complexity involving versioning systems, data migrations and lots of complex testing; it's no coincidence that there are multi-million dollar companies whose entire purpose is producing systems to handle this sort of stuff. Expecting Kryx to be able to do it on his own on a platform that provides no support for it is obviously not realistic - but an understandable misunderstanding if you don't know much about how software development works under the covers.

Ed S. said: I believe what Gediablo is talking about is a per character sheet pop-up not a per game pop-up. The new sheet updates gets pushed and when you open a character sheet it lets you know you are about to upgrade to the new layout, cancelling would just leave the sheet the way it was before it was opened, unconverted. The problem is that this would not work, as for example, if the roll output had been changed to refer to new attributes, the "old sheet" would have calls to part of the old roll template, that no longer exists and therefore may have display issues. When the sheet's html & css is updated, there is no backup of the old sheet. This is why whenever you load a sheet after an update, the sheet already shows the new layout, even before the conversion process kicks in to convert attributes/weapons/spells/etc to be compatible with the new sheet version. It just is not possible given roll20's current system.

Jim W. said: I can see nothing in the documentation about setting the "Passive Skills" checkbox for a new character - and not sure if this is a script or charsheet issue.&nbsp; [Reason: I like to have the 3rd bar as Passive Perception]. There are a bunch of things that have been added to the sheet settings that aren't yet in the !shaped-config options. I need to add these and will do so in the next couple of weeks. I may also have to do something special for passive perception because it's not straightforward to reference skills since they are stored in a repeating section of the character sheet. I too would like the same functionality so it's likely to get done ;-)

Passive perception already exists. @{NAME|perception_passive} or&nbsp;@{NAME|passive_perception}

@JimW - btw, I'm always interested in hearing what new-ish users of the script find hard to understand from the script documentation. If you can't find how to do something that you think you ought to be able to do, or you don't understand some of the instructions, please let me know and I will try to improve the documentation to make it clearer. It's hard for me to know what's clear and what's not since (a) I'm a programmer and (b) I've worked with the script/sheet a lot for a long time now so it's hard for me to "forget" what I know. I don't have much patience for people asking for help when they haven't even bothered to read the information that has been provided, but I'm happy to be very patient with those who have made a bona fide attempt to do so and simply couldn't make sense of it. I've been there myself many times it can be immensely frustrating when you have actually RTFM but you still have no idea what to do!

Lucian, I think what Ed is saying is that he simply would like there to be a button press required before the process starts (which currently triggers when sheet:opened is fired). Not pressing the button would leave the sheet in the old state w/r/t the attributes, nonfunctional with the current sheet but unchanged in the data. Pro : less people closing the sheet before the upgrade completes, and no one can complain about suddenly losing data by opening sheets when something goes wrong. Con : one extra button press per sheet per version upgrade. I'm not too convinced, but it's not an unreasonable suggestion (if I'm understanding it correctly here).

Kryx said: Passive perception already exists. @{NAME|perception_passive} or&nbsp;@{NAME|passive_perception} Lol. I didn't even know that. Just goes to show ;-)

Jakob said: Lucian, I think what Ed is saying is that he simply would like there to be a button press required before the process starts (which currently triggers when sheet:opened is fired). Not pressing the button would leave the sheet in the old state w/r/t the attributes, nonfunctional with the current sheet but unchanged in the data. Pro : less people closing the sheet before the upgrade completes, and no one can complain about suddenly losing data by opening sheets when something goes wrong. Con : one extra button press per sheet per version upgrade. I'm not too convinced, but it's not an unreasonable suggestion (if I'm understanding it correctly here). Hmmm. I see where you're coming from. I can't say I'm especially convinced, though. What would you do next? If you're not a pro user, you're screwed anyway. If you are a pro user, and you're going to click cancel on an upgrade, you should have a custom sheet installed instead. I'm struggling to see how it's actually going to help anyone?

Lucian said: Jim W. said: I can see nothing in the documentation about setting the "Passive Skills" checkbox for a new character - and not sure if this is a script or charsheet issue.&nbsp; [Reason: I like to have the 3rd bar as Passive Perception]. There are a bunch of things that have been added to the sheet settings that aren't yet in the !shaped-config options. I need to add these and will do so in the next couple of weeks. I may also have to do something special for passive perception because it's not straightforward to reference skills since they are stored in a repeating section of the character sheet. I too would like the same functionality so it's likely to get done ;-) As long as I manually set "show passive skills" in the char sheet the value is picked up so it's litterally just the checkbox on the char sheet under tools.

Lucian said: @JimW - btw, I'm always interested in hearing what new-ish users of the script find hard to understand from the script documentation. If you can't find how to do something that you think you ought to be able to do, or you don't understand some of the instructions, please let me know and I will try to improve the documentation to make it clearer. It's hard for me to know what's clear and what's not since (a) I'm a programmer and (b) I've worked with the script/sheet a lot for a long time now so it's hard for me to "forget" what I know. I don't have much patience for people asking for help when they haven't even bothered to read the information that has been provided, but I'm happy to be very patient with those who have made a bona fide attempt to do so and simply couldn't make sense of it. I've been there myself many times it can be immensely frustrating when you have actually RTFM but you still have no idea what to do! Thanks Lucian.&nbsp; As a Pre-Windows programmer who decided in 1990's that Windows would never take off.... I may have fairly unique viewpoint lol.&nbsp; "Link" should have been obvious as "Link to sheet" - just..well... I've been linking from one roll20 campaign to the journal in another!

Lucian said: Jakob said: Lucian, I think what Ed is saying is that he simply would like there to be a button press required before the process starts (which currently triggers when sheet:opened is fired). Not pressing the button would leave the sheet in the old state w/r/t the attributes, nonfunctional with the current sheet but unchanged in the data. Pro : less people closing the sheet before the upgrade completes, and no one can complain about suddenly losing data by opening sheets when something goes wrong. Con : one extra button press per sheet per version upgrade. I'm not too convinced, but it's not an unreasonable suggestion (if I'm understanding it correctly here). Hmmm. I see where you're coming from. I can't say I'm especially convinced, though. What would you do next? If you're not a pro user, you're screwed anyway. If you are a pro user, and you're going to click cancel on an upgrade, you should have a custom sheet installed instead. I'm struggling to see how it's actually going to help anyone? It allows the user to exit the game, and copy it, then come back in and try the update.&nbsp; Then if any issues there's a copy game at least!

Jakob said: Lucian, I think what Ed is saying is that he simply would like there to be a button press required before the process starts (which currently triggers when sheet:opened is fired). Not pressing the button would leave the sheet in the old state w/r/t the attributes, Impossible, as Lucian explained: The HTML cannot be divorced from the code. To make such a button still results in, as Lucian stated, 2 separate copies of both html and code. Then when the next update happens, you have 3 copies, or else you force everyone 2 versions back to update.&nbsp; Not to mention how nightmarish that would be to bugfix. nothing would get done. The ONLY solution, since this is a volunteer platform, is more people to volunteer to test, and upload their character sheets. The second solution would be: if you know an update occurred then copy the game. Even then, the GM would have to know before the players. We've put warnings on the PF sheet to no avail.

chris b. said: Impossible, as Lucian explained: The HTML cannot be divorced from the code. To make such a button still results in, as Lucian stated, 2 separate copies of both html and code. Then when the next update happens, you have 3 copies, or else you force everyone 2 versions back to update.&nbsp; No, it's very possible. You'd simply have the sheet in a state where nothing works, display is wonky, et cetera - but all the attributes are the same. Probably even grey out everything as with the script-import overlay. The ONLY thing you could do with such a sheet to continue using it without updating is put it into a game that has the old sheet version. Again, I don't think it's super practical as Lucian said: it's basically another place where you could display a big "If you press this button the sheet will update. This could take a long time, don't close the sheet until spinning circle in the top right is moving" warning, plus it allows people to export sheets/copy game/whatever. But it's essentially useless for non-pro users, since they are screwed either way.

I'm trying to keep up with the thread but there's a lot going on, so apologies if this was already discussed. Do NPC traits/actions still have a freeform field? I had a fancy Undead Fortitude macro for my zombies set up in the freeform box prior to the upgrade. The macro still works, but the box appears to have vanished, so it's no longer editable.

Aiden said: I'm trying to keep up with the thread but there's a lot going on, so apologies if this was already discussed. Do NPC traits/actions still have a freeform field? I had a fancy Undead Fortitude macro for my zombies set up in the freeform box prior to the upgrade. The macro still works, but the box appears to have vanished, so it's no longer editable. Look at the settings tab, there is a toggle to show the freeform field.

Jakob said: Aiden said: I'm trying to keep up with the thread but there's a lot going on, so apologies if this was already discussed. Do NPC traits/actions still have a freeform field? I had a fancy Undead Fortitude macro for my zombies set up in the freeform box prior to the upgrade. The macro still works, but the box appears to have vanished, so it's no longer editable. Look at the settings tab, there is a toggle to show the freeform field. Much appreciated!

Jim W. said: It allows the user to exit the game, and copy it, then come back in and try the update.&nbsp; Then if any issues there's a copy game at least! Sure, but I'm still struggling to see how that's preferable to installing a custom sheet and then only upgrading (including taking a copy for safety) when you're ready to do so. I guess it could act as a kind of "there's an update available" notification, but to be honest, I think that's much better handled by following the forum threads where you get complete information about what's included in the upgrade, including UI changes, known issues etc. There really is nothing that having a cancellable upgrade offers that isn't better handled by installing a fixed version in the first place.

I also want to chime in to say that the shaped sheet is an excellent sheet, and I really appreciate the work the Kryx puts into it. I have a general question-- When I open a sheet an it says it's updating-- black box in upper right corner that says 'Processing'-- it seems to just keep going on forever. Yesterday, I left it for a couple hours to see if it would complete. But it never did. The note does say that you can push 'close' if the sheet seems to be working properly, but I'm not sure if something isn't getting finished. Is this normal? Generally the sheets seem complete. The processing just never stops. AD

The processing is complete when the spinning circles spin normally. If they jitter and are laggy the processing is still happening. It's incredibly rudimentary, but without revamping the whole sheet and how it calls functions other functions (which I'm doing as part of&nbsp; #166: Change all data saving to run silently ), I cannot tell when a function is complete.

Jakob said: No, it's very possible. You'd simply have the sheet in a state where nothing works, display is wonky, et cetera - but all the attributes are the same. Probably even grey out everything as with the script-import overlay. The ONLY thing you could do with such a sheet to c I see, you'd also need a check for every single eventhandler that says "did user upgrade yet? Then do nothing", slowing down everything. (and then the inevitable posts of "why doesn't it work" when they don't see the upgrade button). I have considered this in the past for our sheet, but haven't yet for the following reason: it would just make it slower and clunkier, and does not alleviate the issue that it still relies on the GM to know to backup the campaign or character first.&nbsp;

Gotcha! Now it makes sense. For some reason, I interpreted 'image is moving at normal speed' with my being able to drag the sheet around without lag. In retrospect, there is no good reason for me to have thought that. Now that I know, it's just a cosmetic thing.&nbsp; Thanks for the quick reply. AD

Kryx said: The processing is complete when the spinning circles spin normally. If they jitter and are laggy the processing is still happening. It's incredibly rudimentary, but without revamping the whole sheet and how it calls functions other functions (which I'm doing as part of&nbsp; #166: Change all data saving to run silently ), I cannot tell when a function is complete. that's our problem. actually we found, if you have a huge function that is calculating, the gif will not spin at all. As if the javascript is locking up whatever process animating gifs. So sweeping up everything into a few updates might not be the answer (though at least it's faster). I thought of creating a jerky process bar, so no there'd be no difference between a "frozen" one and moving one. That's all i could figure out.

That's the point - the gif should be spinning perfectly to indicate that everything is done and working. I hope to replace this when I have all the functions call each other instead of depending on "change:FIELD_NAME" events. I believe that's what you did, right? Does it work nicely for the Pathfinder sheet?