D&D 5th Edition by Roll20 (Q1Y2020)

Yes Keith , that is actually done by the script (5e rest). Haven't touched the script itself, just made it compatible by restoring dice from the highest to the lowest on my side. Wolf, I am hoping to discuss this with the team next week and see how much priority it gets ;)

Miguel said: Yes Keith , that is actually done by the script (5e rest). Haven't touched the script itself, just made it compatible by restoring dice from the highest to the lowest on my side. Wolf, I am hoping to discuss this with the team next week and see how much priority it gets ;)

Adding recovery rates to traits would be a phenomenal feature. I'll start crossing fingers.

Sweet!

Very, very good work. About the only thing I could say is that reducing the number of levels in a class should reduce both the actual and max hit dice. The use case is that someone who has spent some hit dice accidentally adds a level to a class. They then return the class to the correct number of levels. They now have some bonus hit dice that they can spend.

Brian , it does reduce if the number of dice available in a pool if it becomes larger than the maximum. A LV3 char has a maximum of 3HD, if he goes to LV2 his maximum goes down to 2HD. When that happens the current value will go to two if it is equals to 3. However, if it already lower than 3, it wont change. I believe you are the one who made that suggestion, did I get it wrong?

Amazing, Miguel. Thank you for this!

Miguel said: Brian , it does reduce if the number of dice available in a pool if it becomes larger than the maximum. A LV3 char has a maximum of 3HD, if he goes to LV2 his maximum goes down to 2HD. When that happens the current value will go to two if it is equals to 3. However, if it already lower than 3, it wont change. I believe you are the one who made that suggestion, did I get it wrong? No, you are correct, that was my original suggestion. After thinking of what were the most common use cases for reducing one or more levels, I realized that it was probably better for both current and &nbsp;max hit dice to be reduced, but my suggestion got a little buried, and I should have struck out the original. <a href="https://app.roll20.net/forum/permalink/9359947/" rel="nofollow">https://app.roll20.net/forum/permalink/9359947/</a> Mainly, I think that most of the cases where someone reduces the number of levels in a class are going to be tied to making a correction, which means that the player should not have that hit die that is being removed. The only bounds checking that needs to be done is making sure that the number of current hit dice is not reduced below 0. I don't think it is a big enough deal to hold back the rest of the release though.

keithcurtis said: Adding recovery rates to traits would be a phenomenal feature. I'll start crossing fingers. I wonder if that would be best served with a partial redesign of Resources to add how much of something recharges and when.

Random thoughts on the hit dice redesign: I still wonder if having bonus hit dice modifiers stored in settings might be "better" since so few people will use it. There is a chance for max hit dice to be desynced from the levels in classes (which is possible in the current page as well). This has benefits even for PCs that only have one class. The design and functionality are so nice, I wish there was a way to seamlessly transition everyone's current settings to max and current hit dice to using this as the default. Right now, someone would have to know to go the settings page to activate it.

Brian C. said: keithcurtis said: Adding recovery rates to traits would be a phenomenal feature. I'll start crossing fingers. I wonder if that would be best served with a partial redesign of Resources to add how much of something recharges and when. Upon further reflection, it might be a tough sell. Roll20 might not want the feature added if the relevant data is not in Charactermancer (i.e. if the recovery rate is only textual, buried in the description, instead of being a db field). I'd still use the heck out of it, even if filling out the recovery fields was manual.

keithcurtis said: Brian C. said: keithcurtis said: Adding recovery rates to traits would be a phenomenal feature. I'll start crossing fingers. I wonder if that would be best served with a partial redesign of Resources to add how much of something recharges and when. Upon further reflection, it might be a tough sell. Roll20 might not want the feature added if the relevant data is not in Charactermancer (i.e. if the recovery rate is only textual, buried in the description, instead of being a db field). I'd still use the heck out of it, even if filling out the recovery fields was manual. It would likely require extra attributes for the features in the compendium and a means for Charactermancer to read those attributes into the correct field. So it is feasible but by no means simple as multiple parts would need to work together.

Brian C. said: keithcurtis said: Brian C. said: keithcurtis said: Adding recovery rates to traits would be a phenomenal feature. I'll start crossing fingers. I wonder if that would be best served with a partial redesign of Resources to add how much of something recharges and when. Upon further reflection, it might be a tough sell. Roll20 might not want the feature added if the relevant data is not in Charactermancer (i.e. if the recovery rate is only textual, buried in the description, instead of being a db field). I'd still use the heck out of it, even if filling out the recovery fields was manual. It would likely require extra attributes for the features in the compendium and a means for Charactermancer to read those attributes into the correct field. So it is feasible but by no means simple as multiple parts would need to work together. That seems to be the general blockade of progress, that which is not simple shall not be done.&nbsp; Yes, it would require an entire team working on various sections and by no means would be an easy task: Placing the {{uses=#}}{{per use=#}}{{max uses=#}}{{recharge=None|Short Rest|Long Rest|TurnAll|Turn26|Turn36|Turn46|Turn56|Turn6|Manual}} in the character and NPC sheets. Placing a Short and Long Rest button on both sheets, and Recharge on Turn button on NPC sheets Updating the API Companion to interpret and function these new fields Updating the Existing Compendium entries to include the fields for NPC/ Monster sheets Updating the Charactermancer functionality to use what has been added via #1, #2, and #3.&nbsp; This would also include reviewing these fields for updates in final results.&nbsp; For example, a Cleric's Channel Divinity increases by one at Cleric level 6 &amp; 18. We also have the common pool issue to deal with in resources.&nbsp; For example, Clerics use a common pool of Channel Divinity for each Channel Divinity option they get.&nbsp; So while one Trait may describe the Channel Divinity, and another might hold the pool, how do we get the charactermancer to set up that clicking the one will deduct from another?&nbsp; Other examples of Common Pools are Sorcery Points and Monk Ki.&nbsp; We may need to have another field added to identify the ones drawing on the common pool {{usescommonpool=repeating_trait_-fd513v1dxzrdg1cv5v41_1}} which would essentially just click the identified trait afterward to deduct its use

The other thing I suggested would be so very simple to add to every attack, spell, and trait:&nbsp; A Freeform field.&nbsp; The use of which is in Macros and API calls or other chat and related effects, and would essentially be at the end of all code related to that particular item.&nbsp; Currently we have to go into descriptions and do this: DESCRIPTION BOX: ...some description of the item... }} !AnAPICall %{Bob|MacroCall} /em Bob Swings For The Fences! (emote) /fx beam-holy -M1654D16541_12Gul @{target|token_id} (effect) ! (to cancel all that comes afterward, such as the generated }} from the description block that you had to type at the beginning) Which is very cluttery and can still break on things like spells and attacks, where the description may not be the final output of the item. By adding that field to those places - it opens up a no-holds-barred sense of versatility to the sheet, and is actually not a difficult thing at all.&nbsp; Think of all the API calls you can run on clicks.&nbsp; Even the free users can then add emotes and effects to their sheets.&nbsp; Win Win.

minor glitch I was experiencing with adding extra Legendary actions linked to additional npc actions I dragged an Aboleth from the compendium into a character sheet to populate it as an npc. I wanted to add it's lair abilities to the Legendary actions and I added buttons referencing the spell and additional actions added after enslave: grasping-tide &amp; water-rage. The buttons could not find the additional npc actions no matter what I did. It found the spell fine and if I changed the npc action number to 3 on the button in the legendary actions&nbsp; it would output the enslave npc action okay. I could trigger the npc actions directly from the sheet but the buttons just would not find the extra actions. reload - no good Fix: once I unlocked the actions and locked them again the buttons found the actions I haven't tried it on any other creatures dragged from the compendium

Bugs found with Versatile weapons and the Compendium: 1. When dropping a weapon with the "versatile" tag (i.e. can be wielded either 1-handed or 2-handed) from the compendium to a character sheet, it doesn't get set up quite correctly.&nbsp; The weapon gets set up to correctly add the relevant attribute (STR, DEX, etc.) for the one-handed attack, but does not set up the attribute for the two-handed attack. (See first picture below). 2. If the weapon is a magical weapon, the magical plus gets added to the damage roll for the one-handed attack (see second picture), but not the two-handed attack (3rd picture). I've tested this with several versatile weapons with magical bonuses, and they all fail.&nbsp; Non-magical weapons get two different entries - one for the 1-handed attack and one for the 2-handed attack.&nbsp; I think this is wrong - both magical and non-magical weapons should get set up the same way.&nbsp; I personally would prefer the way it sets it up for magical weapons - that is, one entry rather than two.

This might be a compendium issue. Try longsword and longsword +1, they seem to be set up correctly for me on a drag drop. Is this how you envision it should be working?

keithcurtis said: This might be a compendium issue. Try longsword and longsword +1, they seem to be set up correctly for me on a drag drop. Is this how you envision it should be working? For longsword +1, and longsword +2, 2 entries get created - one for 1-handed, one for 2-handed.&nbsp; For longsword +3, only one entry gets created.&nbsp; For&nbsp; all other versatile weapons listed in the PHB: Quarterstaff, Warhammer, and Battleaxe with +1, +2, or +3 bonuses, only one entry gets created.&nbsp; As I said, I personally prefer one entry that does the right things because some characters can end up carrying lots of weapons and it reduces clutter.&nbsp; I can work around the problem, I suppose, by drag&amp;dropping the non-magical versions to get the two entries, and then edit them to have the magical bonuses but this should be fixed so that it works correctly.&nbsp; And, again, I prefer one entry for each weapon. I don't know if this is a compendium problem or a sheet problem.&nbsp; The compendium has the correct listings so it seems to me it's more likely to be a sheet problem.

With a single entry, how would you handle a weapon that deals multiple types of damage, like a flametongue? Also, through the front end of the compendium, you are always seeing interpreted data. The sheet interprets data the same way regardless of the name of the weapon. My guess is that the storage is done differently on the back end for those weapons.

keithcurtis said: With a single entry, how would you handle a weapon that deals multiple types of damage, like a flametongue? Also, through the front end of the compendium, you are always seeing interpreted data. The sheet interprets data the same way regardless of the name of the weapon. My guess is that the storage is done differently on the back end for those weapons. Flame tongue appears to have a separate entry.&nbsp; I'm not sure how it's supposed to be set up since it says nothing in the entry for fire damage once it's dropped into the sheet. But, I sort of see your point.&nbsp; There needs to be some place to put the "special" damage.&nbsp; On the other hand, how are sentient weapons or artifacts that might have more than 2 damage types handled? I don't know how the back end of the compendium is set up or works.&nbsp; All I know for certain is that 2 weapons appear to do something that looks correct, or at least works, and many more don't.&nbsp; I don't know where the fault is.

It probably needs a dev sweep to correct. If you fill out a&nbsp; Help Center Request , it will create a ticket.

keithcurtis said: It probably needs a dev sweep to correct. If you fill out a&nbsp; Help Center Request , it will create a ticket. Gotcha.&nbsp; Will do.&nbsp; Thanks for your input.

Saul J. said: keithcurtis said: With a single entry, how would you handle a weapon that deals multiple types of damage, like a flametongue? Also, through the front end of the compendium, you are always seeing interpreted data. The sheet interprets data the same way regardless of the name of the weapon. My guess is that the storage is done differently on the back end for those weapons. Flame tongue appears to have a separate entry.&nbsp; I'm not sure how it's supposed to be set up since it says nothing in the entry for fire damage once it's dropped into the sheet. But, I sort of see your point.&nbsp; There needs to be some place to put the "special" damage.&nbsp; On the other hand, how are sentient weapons or artifacts that might have more than 2 damage types handled? Probably not here or there, but I have a monster in one of my adventures that deals 1d6 fire and 1d6 necrotic in addition to weapon damage. In each attack action, I entered "2d6" for the secondary damage and "1d6 fire / 1d6 necrotic" for the secondary damage type. I find that having separate entries for versatile weapons, thrown weapons, barbarian rage, shillelagh, etc. helps the GM and are a nice way to do it. Space on the NPC sheet is cheap, and the GM just needs to select the correct entry from the list and roll. For my players, we have set up separate attacks for versatile weapons, sneak attack, etc. on their PC sheets.

keithcurtis said: With a single entry, how would you handle a weapon that deals multiple types of damage, like a flametongue? Also, through the front end of the compendium, you are always seeing interpreted data. The sheet interprets data the same way regardless of the name of the weapon. My guess is that the storage is done differently on the back end for those weapons. I'll give you an interesting way, as I had a custom spear I had to do this with recently.&nbsp; This is it's description box: - adds 1d6 fire dmg - abyssal &amp; infernal alloy - must kill Sumrath to ascend.}} {{globaldamage= [[1d6 + @{Dragnar Silverthane|global_damage_mod_roll} ]] }} {{globaldamagecrit= [[1*6+ @{Dragnar Silverthane|global_damage_mod_crit} ]] }} {{globaldamagetype= Fire + @{Dragnar Silverthane|global_damage_mod_type}}} ! In essence - you're tricking the Global Damage field and hardcoding it directly with the information, then allowing it to add whatever global damage modifiers exist beyond that.&nbsp; It's a great way to solve little issues like this. Output: And as you can see - it still loads other global damage when selected:

Things like above would be even easier to add with what was suggested HERE

I thought that description hack: something something}} {{more code}} didn't work anymore on the latest versions of the sheet?

Yet another suggestion: 1. Creating a Universal template that can be formatted on output.&nbsp; In other words (which also includes some of my other suggestions) this, with bold indicating what determines output style.&nbsp; Any of the below could and should be omitted where it isn't needed (without causing errors or material to not print unless restricted by the main template, as you wouldn't need higher level damage from a dagger attack...), except the template tag itself, which would - without a style delimiter - default to the simple style.&nbsp; I think there is a alot more than this, but this is what is shown on the roll templates page, smooshed together to show how it could be simplified from one template. &amp;{template:5e-ogl} {{rname=rname}} {{name=name}} {{uses=uses}}{{per use=peruse}} {{max uses=maxuses}} {{usescommonpool=usescommonpool}} {{recharge=None|Short Rest|Long Rest|TurnAll|Turn26|Turn36|Turn46|Turn56|Turn6|Manual}} {{source=Source:Source type}} {{simple=1}} {{attack=1}} {{damage=1}} {{isNPC=1}} {{NPCAction=1}} {{mod=mod}} {{r1=r1}} {{normal=1}} {{always=1}} {{advantage}} {{disadvantage}} {{r2=r2}} {{range=range}} {{desc=1}} {{damage=1}} {{simple=1}}&nbsp; {{dmg1flag=1}} {{dmg1=dmg1}} {{dmg1type=dmg1type}} {{dmg2flag=1}} {{dmg2=dmg2}} {{dmg2type=dmg2type}} {{crit=1}} {{crit1=crit1}} {{crit2=crit2}} {{save=1}} {{saveattr=saveattr}} {{savedesc=savedesc}} {{savedc=savedc}} {{spell=1}} {{traits=1}} {{hldmg=hldmg}} {{spelllevel=spelllevel}} {{level=school level}} {{castingtime=castingtime}} {{target=target}} {{v=1}} {{s=1}} {{m=1}} {{material=material}} {{duration=duration}} {{description=description}} {{athigherlevels=athigherlevels}} {{ritual=1}} {{concentration=1}} ammo=ammo {{charname=charname}} {{additionalfeature=1}} {{freeform=freeform}} 2. Adding another Tab called "Additional Features"; wherein little used features are offset.&nbsp; For example, how often are you really clicking that Keen Senses entry?&nbsp; Or Menacing?&nbsp; Even Darkvision?&nbsp; Not very often, I suspect.&nbsp; So why are they helping create a HUGE list of traits if you rarely use them? My suggestion leaves them available, but gets them off the core page where only things relevant to the immediate everyday game session needs to be. 3. Adding a simple, chat listable check box in front of any and all equipment entries simply indicating attunement.&nbsp; This way it could complete an array when requested: @{selected|attuned_equipment} should show: Dragnar Silverthane: Lightning Axe, Helm of Comprehend Languages, Boots of Striding and Springing 4. Breaking down what are racial/ subracial features, class/ sublcass features, feats, all else (background info, for one example)

keithcurtis said: I thought that description hack: something something}} {{more code}} didn't work anymore on the latest versions of the sheet? I literally just took a screenshot of the results ... you be the judge ... lol

Wolf Thunderspirit said: keithcurtis said: I thought that description hack: something something}} {{more code}} didn't work anymore on the latest versions of the sheet? I literally just took a screenshot of the results ... you be the judge ... lol :D I just wanted to verify this was on the official sheet and not one of the ones derived from the legacy code. Last time I tried the trick, it did not work. Of course, I think the difference might have been that I did not fill out all the rest of the template, just that {{}} field. Manual addition of those fields would probably override other instances and allow it to work. Thanks!

Regarding Wolf's suggestions above: 1. I believe the Shaped Sheet handles it this way. It's a good approach, but I'm suspecting that it will anger a lot of folks who "like it the old way", like most changes. 2. I really would not like more clicking between tabs. 3. That would be handy. 4. This can already be done to some extent. Each one has a source(?) field. What did you envision here? I'd also like to add: 5. Related to 3, move the coinage slots somewhere else. Currently, they match the print sheet, but pen and paper allows a lot more creative entry. As they are, they remove about 25% of the width of the equipment column, making the list very cramped and abbreviating many entries. Perhaps they could be included in two rows across the top of the box?

keithcurtis said: Regarding Wolf's suggestions above: 1. I believe the Shaped Sheet handles it this way. It's a good approach, but I'm suspecting that it will anger a lot of folks who "like it the old way", like most changes. 2. I really would not like more clicking between tabs. 3. That would be handy. 4. This can already be done to some extent. Each one has a source(?) field. What did you envision here? I'd also like to add: 5. Related to 3, move the coinage slots somewhere else. Currently, they match the print sheet, but pen and paper allows a lot more creative entry. As they are, they remove about 25% of the width of the equipment column, making the list very cramped and abbreviating many entries. Perhaps they could be included in two rows across the top of the box? RE: #2 That's the point though.&nbsp; Offsetting the rarely used items that currently populate the traits area to a different tab that never get clicked in any game I know of (Darkvision is clicked so rarely, items that give skills like Keen Senses or Menacing never get clicked, etc.).&nbsp; Having these populate on a different tab than the Core Tab means there is more room for things you actually DO click on in game, like your Dragonborn's breath weapon, etc. RE: #4 Like the Shaped Sheet - each area separated so that racial items are grouped together, class items are grouped together, feats are grouped together, etc.&nbsp; Sorting them alphabetically in these types so they are easier to reference rather than looking at a sheet that just slaps all of them together would also be great, as we humans tend to like a bit of organization.&nbsp; I can't speak for the orcs ... they are okay with poor hygiene and scrub their floors in the blood of their last victim... so orcs are probably ok with traits spattered anywhere they appear on the sheet.

keithcurtis said: I thought that description hack: something something}} {{more code}} didn't work anymore on the latest versions of the sheet? I literally just took a screenshot of the results ... you be the judge ... lol :D I just wanted to verify this was on the official sheet and not one of the ones derived from the legacy code. Last time I tried the trick, it did not work. Of course, I think the difference might have been that I did not fill out all the rest of the template, just that {{}} field. Manual addition of those fields would probably override other instances and allow it to work. Thanks! One minor correction: the roll template closes the description field, so you don't want to close the final handlebars, or you'll break the rest of the macro: something something}} {{more code You only need the ! API command if you're trying to replace a field which comes after the description, which is pretty much just the global fields (like Wolf's example). Also, fully support Wolf's suggestion for a 'freeform' field. If sheet real-estate is a concern, even just moving {{description}} to always be output last in the roll template would allow it to be used to overwrite other fields as needed.

I still can't be on board with #2. Some traits are clicked on often, some are not. Often you need to send something to chat for reference. There's no setting a universal line there. People can sort them so that more referenced ones are up top if they wish (though that might interfere with #4). As a refinement or alternative to #3, would you find a easily clickable button for equipping/unequipping to be more generally useful than one indicating attunement? It's probably a more common action. (donning and doffing armor, for example). I say "easily" clickable, because the current one requires extra steps. Attunement can be handled in other ways. I just make it the top three slots and put a placeholder after them.

Wolf Thunderspirit said: keithcurtis said: Regarding Wolf's suggestions above: 1. I believe the Shaped Sheet handles it this way. It's a good approach, but I'm suspecting that it will anger a lot of folks who "like it the old way", like most changes. 2. I really would not like more clicking between tabs. 3. That would be handy. 4. This can already be done to some extent. Each one has a source(?) field. What did you envision here? I'd also like to add: 5. Related to 3, move the coinage slots somewhere else. Currently, they match the print sheet, but pen and paper allows a lot more creative entry. As they are, they remove about 25% of the width of the equipment column, making the list very cramped and abbreviating many entries. Perhaps they could be included in two rows across the top of the box? RE: #2 That's the point though.&nbsp; Offsetting the rarely used items that currently populate the traits area to a different tab that never get clicked in any game I know of (Darkvision is clicked so rarely, items that give skills like Keen Senses or Menacing never get clicked, etc.).&nbsp; Having these populate on a different tab than the Core Tab means there is more room for things you actually DO click on in game, like your Dragonborn's breath weapon, etc. RE #2: If something it isn't used; delete it. If it's something that you may want to reference later (how far is my darkvision?) then copy and paste the text to the already existing tab "Bio" under "Additional Features and Traits". There are already enough tabs and sub-tabs to sort through to find something.&nbsp;

Ugh - what's the point of suggesting any improvements in this forum if people poo-poo it or say its too difficult to do.&nbsp; If I could do it myself, I already would have.&nbsp; I'm not afraid of rolling up the sleeves and getting to the business - I just lack the knowledge on how to do it, personally.&nbsp; Not afraid of hard work, I find the challenge exhilarating.&nbsp; Apparently, I'm alone in this. And also one with the concept that change is good for progress.&nbsp; :-( I'll go shut up in my corner now.

You made four suggestions. Some of them were met with agreement, some weren't. Some were bandied about with suggested refinements, or your suggestions inspired further suggestions. I would hope you are not discouraged from keeping the conversation going. There's a lot of value in it.

I know the Matt Mercer effect has been widely and broadly criticized, but I will say that the Improv method he recommended has been very useful in my games,&nbsp; as well as other areas of my life. When we focus and stay in the negative, we never advance, adapt, or change. All I'm saying is that what I've seen, collectively in responses, is a lot of "Please no", not "Yes, and...".&nbsp; That is very discouraging. And, not to be the grammar Nazi, but Keith... double negative = positive, or they cancel.&nbsp; So I guess you DO hope I'm discouraged?&nbsp; Lol?

As a designer myself, I would find extremely useful if folks could share ideas using visual instead of words. I am not asking anyone to write HTML/CSS, a pen and paper sketch would be more than enough to communicate your ideas properly across the board. And please bear in mind we keep a very close eye to this forum, so, even your comment or idea does not get a direct reply, we will always evaluate it internally and possibly turn it into an actionable item. The short and long rest buttons, for example, just became a 'thing' in our backlog. Have a nice weekend and good games for you all ;)

Miguel said: As a designer myself, I would find extremely useful if you folks could share your idea using visual instead of words. I am not asking anyone to write HTML/CSS, a pen and paper sketch would be more than enough to communicate your ideas properly across the board. And please bear in mind we keep a very close eye to this forum, so, even your comment or idea does not get a direct reply, we will always evaluate it internally and possibly turn it into an actionable item. The short and long rest buttons, for example, just became a 'thing' in our backlog. Have a nice weekend and good games for you all ;) Easier: Take a look at the Shaped Sheet and run it through it's paces.&nbsp; Kieth mentioned the JSON scripting WAS a detriment to the design, I can agree with that as the parsing (which was needed) did bog things down.&nbsp; But when it ran, it ran well, with endless versatility in the back end that was about a 4 month learning curve for me, but once learned, was deemed vital by comparison. It would take you a bit to go through the Shaped Sheet.&nbsp; I'm not asking you to recreate the wheel.&nbsp; All I'm asking is that it gets looked at objectively, so that it inspires what would be useful for the OGL Sheet.&nbsp; @Miguel - I can invite you to the same Group I made for Victor to understand the Shaped Sheet - where it is already set up and ready to be played with.&nbsp; I can GM you if you can't do so yourself. For now, other than this, I'm bowing out of this discussion any further - resorting to just monitoring it.&nbsp; I think peeps are sick of my ideas, and even I am a bit sick of mentioning what is eventually what I just listed in the two paragraphs above.&nbsp; There was a lot that was great in that sheet, and it is unfortunate that it was abandoned - though I certainly understand why - it was a huge undertaking for someone without a team of people at his disposal. Thank you for all considerations thusfar, and I look forward to seeing how short and long rest is implemented in the future!&nbsp; :-)&nbsp; Thank you for taking that suggestion seriously.&nbsp; By the By, never really had an issue with our interactions, Miguel, am only discouraged when change is immediately shot down by other posters for essentially similar reasons of 'it's too hard', 'i wouldn't like it', 'there's something you can do so it doesn't effect me'.&nbsp; All of those, In my opinion, will always be the excuse to stagnate and never see significant change.&nbsp; As a Pro subscriber, I have invested in Roll20, and if OGL is their standard, I would enjoy seeing that standard be the most versatile and dynamic sheet possible, that has future-proofing built in.&nbsp; Most of the suggestions I've made - or at least I thought - were in that vain.&nbsp; The current standard is very simplistic and has no room for growth without changing (trying to reconstruct the thought processes in its design reminds me of how my son, in the US Army, described the origination of the Bradley ).&nbsp; Technology is always changing, and when companies refuse to change, they lose their consumers to the companies who offer what is missing from stagnation.&nbsp; I do not want to see Roll20 go that way.&nbsp; That is the motivation behind my suggestions, while I find the naysayers a bit rooted, stagnant, stuck, and resistant to change.&nbsp; Since my normal hangout is the API forum posts (feeding my addiction to new APIs), I am actually shocked at the responses I got here (since they adore change over there - poor scripters can't keep up!), which is why I'm withdrawing to a monitoring-only position. Good luck moving forward.

Wolf Thunderspirit said: All I'm saying is that what I've seen, collectively in responses, is a lot of "Please no", not "Yes, and...".&nbsp; That is very discouraging. And, not to be the grammar Nazi, but Keith... double negative = positive, or they cancel.&nbsp; So I guess you DO hope I'm discouraged?&nbsp; Lol? Derp. Fixed. Sloppy sentence editing on my part. Sorry you feel discouraged. I don't have the same take on the conversation. I thought it was a discussion of what we wanted, how much we wanted it, and prioritizing. Miguel, I'll see what I can put together visually for my suggestion about the coinage area.

Cool!

I have a feature request, spellpoint a variant rule in DMG. I know other sheets has it but I buy the WoTc books and they use D&amp;D 5th Edition by Roll20 (Q1Y2020),

Blade Master said: I have a feature request, spellpoint a variant rule in DMG. I know other sheets has it but I buy the WoTc books and they use D&amp;D 5th Edition by Roll20 (Q1Y2020), Hm, the DMG should be released by the end of the year, maybe the sheet might get an update then? I noticed in the PF2E thread that it's documentation will get an massive update due to a large update done yesterday, but I wonder if the 5E sheet's documentation could be updated? Currently it lags behind severely, and show pretty old images in most sections, and have still several errors that comes from when it was copied form the community wiki. Currently I've updated the D&amp;D 5E by Roll20 wiki page now and then with info on the sheet, and list some of the know issues it have, which makes it currently much more useful than the helpdesk page version. Due to the 5e sheet acquiring a slow but steady number of updates over the years, there seems to not have been any specific point when the documentation would have been updated, leading to even the wiki version(that I've overhauled at one point), to be left behind.

Hi there, since the update a few weeks back attacks not requiring an attack roll have now a field to roll damage and damage type when activated. I noticed today that the same is missing for legendary actions. Could we have that field for legendary actions, too? That would be awesome.

Blade Master said: I have a feature request, spellpoint a variant rule in DMG. I know other sheets has it but I buy the WoTc books and they use D&amp;D 5th Edition by Roll20 (Q1Y2020), Out of interest, why don't you just use a Resource field to track spellpoints? Isn't it just a single pool of points for all spells? I've never used the rule. Having it on the main tab actually seems better than stuffing it into the Spells tab, IMO. Not that I'm against having more options, it just seems like a pretty simple fix.

Oosh said: Blade Master said: I have a feature request, spellpoint a variant rule in DMG. I know other sheets has it but I buy the WoTc books and they use D&amp;D 5th Edition by Roll20 (Q1Y2020), Out of interest, why don't you just use a Resource field to track spellpoints? Isn't it just a single pool of points for all spells? I've never used the rule. Having it on the main tab actually seems better than stuffing it into the Spells tab, IMO. Not that I'm against having more options, it just seems like a pretty simple fix. And I imagine there is a way to have the API listen for spells being cast and decrement the correct number of spell points.

Brian C. said: And I imagine there is a way to have the API listen for spells being cast and decrement the correct number of spell points. Yep, should be as simple as a custom Companion script pointing it to the chosen Resources field, and applying the spelllevel = x spellpoints math, before modifying the Attribute. Obviously that's a bit trickier than naming a Resources field and throwing a number in it, but that's always going to need API to decrement anyway. Just had a quick look - it should be a reasonably simple change if you're interested, Blade Master?

Bug: Weapon damage calculations corrupting Attribute values As reported in this thread (and another one linked in that thread, and others that pop up from time to time), sometimes a character sheet will bug out and an Attribute will be massively boosted and can't be brought back down to earth. I think I've found the cause. When the Damage or Secondary Damage fields (and corresponding _itemmodifiers repeating field entries) contain an @{Attribute call}, and are not the last comma-separated entry in the _itemmodifiers field, they fall through the itemmod part of the update_attr sheetworker, have everything but integers stripped out and are applied as a bonus. For example, pasting these into the item mods field of a weapon in the inventory will not bug out an Attribute (replacing the entire field): Damage: 1d10 + @{dexterity_mod} or Secondary Damage: 2d4 + @{strength} But if you paste these in then tab out of the field, they should give a big old boost to the corresponding Attribute: Damage: 1d10 + @{dexterity_mod}, Secondary Damage: 1d8 or Secondary Damage: 2d4 + 5 + @{strength}, Damage: 3d4 The main offender is the update_attr function, line 766 in the 5e Legacy code. I'm assuming this function is still almost the same, as the functionality matches the Legacy version pretty closely. I'm not understanding why this bug only occurs if the Attribute call is not the last entry in _itemmodifiers , but the solution doesn't really rely on that. So this bit: var mods = v["repeating_inventory_" + currentID + "_itemmodifiers"].toLowerCase().split(","); _.each(mods, function(mod) { if(mod.indexOf(attr) &gt; -1 &amp;&amp; mod.indexOf("save") === -1) { if(mod.indexOf(":") &gt; -1) { var new_base = !isNaN(parseInt(mod.replace(/[^0-9]/g, ""), 10)) ? parseInt(mod.replace(/[^0-9]/g, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ""), 10) : false; item_base = new_base &amp;&amp; new_base &gt; item_base ? new_base : item_base; } else if(mod.indexOf("-") &gt; -1) { var new_mod = !isNaN(parseInt(mod.replace(/[^0-9]/g, ""), 10)) ? parseInt(mod.replace(/[^0-9]/g, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ""), 10) : false; item_bonus = new_mod ? item_bonus - new_mod : item_bonus; } else { var new_mod = !isNaN(parseInt(mod.replace(/[^0-9]/g, ""), 10)) ? parseInt(mod.replace(/[^0-9]/g, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ""), 10) : false; item_bonus = new_mod ? item_bonus + new_mod : item_bonus; } }; }); I'm an absolute novice with JS, but since I've already looked at it, a couple of suggestions that might save time: Change the third line to a RegExp search, though this might not be necessary if the below 'if' structure is changed: const regex = new RegExp (`^\\s*${attr}`,'i'); // attribute name must be the first characters, excepting whitespace or const regex = new RegExp (`[^{]*${attr}`,'i'); // ignore attribute name if it is preceded by more than 0 braces { Still though, may as well stop the garbage falling in in the first place I guess. And change the&nbsp; 'if' statement... obviously the big problem is having everything that isn't a static bonus (a la Belt of Giant Strength) or a - malus fall through to the + bonus section... then strip out everything that isn't an integer, turning garbage into a massive Attribute bonus. I'd also rearrange it (though this bit is personal preference), as I think it's unintuitive to have the colon : (Belt of Giant Strength style) as the priority 'if'. I would expect "Strength: +4" to add 4 to Strength, rather than set Strength to a static 4 (if it is lower than 4). So I would shift the colon to the bottom, so it only kicks in in the absence of a '+' or a '-', then put a bin under it, but that might just be me! It seems people would be more likely to put "Strength: +4" in to give a 4 strength bonus, than they would be to put "Strength +28" in to indicate a minimum strength score of 28. Maybe also sneak an '=' in to the colon 'if', since Strength=28 might be a valid assumption to set an Attribute to 28??? Not sure about that one. So... if (mod.indexOf('+') &gt; -1) { apply +bonus to attr } else if (mod.indexOf('-') &gt; -1) { apply -malus to attr } else if (mod.indexOf(':') &gt; -1 || mod.indexOf('=')) { set attr at 'X' if attr is less than 'X', Giant Strength style item} else { ignore.... surely people can get their syntax close enough that turning garbage into a legal modifier is not necessary } Maybe a regex match() with the \digits already (grouped up)? const regexBonus = new RegExp (`${attr}:?\\s*\\+\\s*(\\d*)`,'i'); if (mod.match(regexBonus)) {item_bonus = mod.match(regex)[1]} Well that was quite the rabbit hole.... I guess I should go and do my actual job now.

Miguel said that this forum is looked at, so I'd like to make a suggestion. If realized it would be very helpful for me (and maybe many others). I'm talking about the split between the PC side and the NPC side. Although I understand why it is coded the way it is (and it is absolutely reasonable when dealing with standard 5e compendium monsters) I often have NPCs with features of PCs and sometimes vice versa. A simple example is Legendary Actions for PCs, or feats for NPCs etc. Also damage resistance: one of my players has a ring of cold resistance, that shows up in the inventory but does nothing else. An NPC has Improved Critical Range, and I don't know how to handle that as I can only enter the attack modifier, not the cs&gt;19. A separate sheet for each side is not a feasible solution, especially during mass combat. A simple link for some of those would be absolutely sufficient, so I don't have to always switch sides during combat (three times during one combat round in case of legendary actions is way too much). Also, if the NPC side were just another tab like the spells sheet for PCs so switching were more simple, that could be, from a coding point of view, the fastest first step on the way to go.

Miguel said: As a designer myself, I would find extremely useful if folks could share ideas using visual instead of words. I am not asking anyone to write HTML/CSS, a pen and paper sketch would be more than enough to communicate your ideas properly across the board. And please bear in mind we keep a very close eye to this forum, so, even your comment or idea does not get a direct reply, we will always evaluate it internally and possibly turn it into an actionable item. The short and long rest buttons, for example, just became a 'thing' in our backlog. Have a nice weekend and good games for you all ;) Hi Miguel, This is very quick and dirty, but is the layout for equipment that I was proposing. Coinage in a row across the top allows for every item row to be much wider. Wide enough so that not only can you see more of the name, you could have a check box for whether it is equipped. I'm sure others may have some ideas for how the space extra space could be leveraged, but right now, by following the print design in this instance, we are winding up with wasted/underutilized space. (The box sizes and styles could use some work, too).