Sheet Worker Changes on Dev - September 8th, 2017

1504904049
Steve K.
Roll20 Development Team
Sheet Author
API Scripter
Compendium Editor
We pushed out a small update to sheet workers onto the Dev Server today. We've made a minor change to how default attributes are calculated in order to fix an undocumented problem. While we don't officially support having multiple attributes that share the same name, we've resolved an issue where default attributes were not being correctly set if there were more than one attribute with the same name and one was given a default and the other was not. Additionally we've added two more pieces of information to eventinfo for change events. These will now include eventinfo.previousValue and eventinfo.newValue. These are in the same spirit as the eventinfo.removedInfo that was added last month for the removal of repeating sections. The previousValue will give the value of the attribute before the change event that triggered the eventinfo and newValue will give the current value so that you don't need to getAttrs unless you need other information. Sheet authors, we'd appreciate it if you could take a minute to test your sheet works on dev and make sure there aren't any unexpected interactions or issues we need to fix before this goes live with the Fog and Functionality update.
1504927889
chris b.
Pro
Sheet Author
API Scripter
wow old and new values! This is awesome. This will really speed up calculations since we can calculate the difference, not have to go look up every value on the sheet, which could be 10 or more fields
1504967720

Edited 1504967798
Kryx
Pro
Sheet Author
It's possible to edit multiple fields at once via dragging from the SRD. Will that be supported for previousValue? It it not currently supported for field. It currently only returns 1 field as the changed field even though many could have changed.
1504971882
Steve K.
Roll20 Development Team
Sheet Author
API Scripter
Compendium Editor
Kryx said: It's possible to edit multiple fields at once via dragging from the SRD. Will that be supported for previousValue? It it not currently supported for field. It currently only returns 1 field as the changed field even though many could have changed. Are you saying you're not getting change events for every field changed by a compendium drop?
1504995275
Kryx
Pro
Sheet Author
Steve K. said: Are you saying you're not getting change events for every field changed by a compendium drop? When I drop a greatsword from the compendum I recieve the following eventInfo: { sourceAttribute: "repeating_offense_-ktcgu-7hpkxwifhecrj_properties", sourceType: "player" } All 5 attributes (Propertier, Weight, Damage Type, Item Type, and Damage) are added to the sheet, but the sheet only returns 1 field as being changed. My watch is simple: on(`change:repeating_offense`, (eventInfo) => { console.log('eventInfo', eventInfo); }); Though having 5 triggers for that event would be a very negative feature - it would exponentially increase calculations without additional code preventing multiple calculations in quick sucession.
1505157283
chris b.
Pro
Sheet Author
API Scripter
Things seem to work for the pathfinder sheet. In prod: before we were getting triggers on every field that is updated via compendium, which is why we changed our code around to only look for the Category field, and the other fields written to by the drop are either hidden or an unwatched field. I don't use the change:repeating_xyz at all. I haven't checked in awhile to see if it's still working that way.
1505175000
Scott C.
Pro
API Scripter
Hi Steve, These look really useful. I did have a question though. For the update to the 5e sheet, you are testing it as a drop-down sheet option on dev server. Is there a way for us community sheet authors to do similar?
1505176052
Steve K.
Roll20 Development Team
Sheet Author
API Scripter
Compendium Editor
Scott C. said: Hi Steve, These look really useful. I did have a question though. For the update to the 5e sheet, you are testing it as a drop-down sheet option on dev server. Is there a way for us community sheet authors to do similar? I'm not sure I understand your question. The new properties should be available to any sheet when pulling the eventinfo of a change event. I.E. on("change:repeating_inventory:itemmodifiers change:repeating_inventory:equipped", function( eventinfo ) { if(eventinfo.sourceType && eventinfo.sourceType === "sheetworker") { return; } var itemid = eventinfo.sourceAttribute.substring(20, 40); getAttrs(["repeating_inventory_" + itemid + "_itemmodifiers"], function(v) { if(v["repeating_inventory_" + itemid + "_itemmodifiers"]) { check_itemmodifiers(v["repeating_inventory_" + itemid + "_itemmodifiers"], eventinfo.previousValue ); }; }); });
1505177019
Scott C.
Pro
API Scripter
Right, but according to your intro to the 5e OGL sheet thread: In preparation for that we have the beta version live on the Dev Server. We've updated the entire plumbing of the sheet and made a lot of changes. Pro users, it would be very useful to us if you'd copy a game from production to the dev server and let us know if the character sheet updates to the new version without causing any issues for your existing characters. It sounds like the next version of the 5e sheet is just the sheet that is used when you select the 5e ogl sheet on the dev server. Is it possible to do this for other sheets as well?
1505178809
Steve K.
Roll20 Development Team
Sheet Author
API Scripter
Compendium Editor
I see what you're asking. Yes. When you've updated your sheet(s) and want them to be the default on Dev, I'll update it for you. This will only be until the end of the month though. When the Fog and Functionality update goes live, so will all dev changes, including these sheet changes.
1505182118
Scott C.
Pro
API Scripter
ah, ok, is that something that we could look at making a standard behavior? Might make rolling out sheet changes less disruptive.
1505185230
Steve K.
Roll20 Development Team
Sheet Author
API Scripter
Compendium Editor
Scott C. said: ah, ok, is that something that we could look at making a standard behavior? Might make rolling out sheet changes less disruptive. We're in the process of making major changes to how the Dev environment is going to work to make collaborating with a growing team much easier. I'll keep this request in mind when these changes start manifesting. 
1505185549
Scott C.
Pro
API Scripter
Thanks Steve
1505644537

Edited 1505644659
Natha
KS Backer
Sheet Author
API Scripter
Steve K. said: Additionally we've added two more pieces of information to eventinfo for change events. These will now include eventinfo.previousValue and eventinfo.newValue. These are in the same spirit as the eventinfo.removedInfo that was added last month for the removal of repeating sections. The previousValue will give the value of the attribute before the change event that triggered the eventinfo and newValue will give the current value so that you don't need to getAttrs unless you need other information. Sheet authors, we'd appreciate it if you could take a minute to test your sheet works on dev and make sure there aren't any unexpected interactions or issues we need to fix before this goes live with the Fog and Functionality update. I did a few tests on the eventinfo.newValue / previousValue novelty, and it seems to work fine. I didn't obvisouly tested all the possibilities on every sheet I made, but everything seem fine. Great new feature! Kudos to the devs. EDIT : PS : and it seems faster (obviously) when it allows to get rid of some getAttrs()
1505715456
Jakob
Pro
Sheet Author
API Scripter
The eventInfo.previousValue is very nice. Allows me to do some things I could not have done before without a workaround...