Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

It seems Jumpgate Beta causes issues with character sheets

I there ! I created a game using the Brigandyne V1 community sheet, and opting in for beta at game creation. I noticed the sheetworker doesn't work properly. Only one operation out ouf two are processed by the sheetworker (weird...) When I create a game with the very same sheet, but without activating jumpgate beta on creation, the sheet is properly handled. I filled a bug report, but I elected to post here too, because other sheets could be impacted.
1724004451

Edited 1724004722
vÍnce
Pro
Sheet Author
Just giving a little info that may help figure out the issue; The Brigandyne V1 sheet is a legacy sheet and does not appear to be using any html-calculated attrs ie disabled inputs. Natha is the sheet's author. Here is one of the workers that appears to not be calculating (just going off your image posted in the Jumpgate thread...) &nbsp;&nbsp;&nbsp; on("change:COMinit change:COMprog change:COMprog2 change:COMproglib", function(){ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; getAttrs(["COMinit","COMprog","COMprog2","COMproglib"], function(values) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; var init = parseInt(values.COMinit) || 0; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; var prog = Math.max(parseInt(values.COMprog) || 0,0) + Math.max(parseInt(values.COMprog2) || 0,0) + parseInt(values.COMproglib) || 0; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setAttrs({ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COM: init+prog &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }); &nbsp;&nbsp;&nbsp; }); All of the column attr totals for the sheet use this same "boilerplate" of code, so if there was an issue with one, it seems it would affect them all.&nbsp; The worker looks fine to me. I have no idea if it's part of the&nbsp; problem, but all the change event attrs names&nbsp; <a href="https://wiki.roll20.net/Sheet_Worker_Scripts#Events" rel="nofollow">https://wiki.roll20.net/Sheet_Worker_Scripts#Events</a> should be lowercase.&nbsp; Maybe jumpgate is not as "tolerant" of such discrepancies... I'll see if I can actually do some testing.&nbsp;
1724006200

Edited 1724006673
Fred
Pro
Thanks Vince ! Just so you know, I have heavily modified this sheet, and also changed it to CSE standard (it doesn't require to check the "legacy sanitation" option to run perfectly). And I have exactly the same problem with this custom sheet (which is no longer legacy). Not so long ago you (yes! you !) solved a weird problem with my custom sheet (the one I mentionned above) that was caused by using the select and option commands in upper case ! Not sure what you mean by boilerplate tho ;)
1724006700

Edited 1724007756
vÍnce
Pro
Sheet Author
"boilerplate;" meaning each block of code is nearly identical. So examining this one block is very likely representative of all the other auot-calc sheetworkers. Just looking at the live version of the sheet;&nbsp; it's very odd that it's failing to trigger the worker on every other column total Also, I've noticed that once you modify something other than the top row attr, ie the checkboxes or bonus, the calc seems to trigger and then works going forward. Even tabbing through those fields seem to trigger. This seems to indicate that maybe these fields/attrs are not being set initially under Jumpgate for some reason even though they include a default value.
Yes I noticed too that any subsequent input will 'awake' the calculation.
1724016763
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Something I notice in the code posted by Vince is that the change listener uses capitalization. This is a known cause of listeners not firing.
1724017231
vÍnce
Pro
Sheet Author
I mentioned that above but I just ran a quick test with lowercase change listeners and it didn't make a difference. ;-(&nbsp; Very odd.
1724018349
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Ah, missed that in your message. Strange issue then.
1724022448

Edited 1724111067
vÍnce
Pro
Sheet Author
I've played around with this a bit.&nbsp; I've culled things down to some minimal code for testing &lt;input type="number" name="attr_COMinit" value="0" /&gt; &lt;input type="number" name="attr_CNSinit" value="0" /&gt; &lt;input type="number" name="attr_COMinit2" value="0" /&gt; &lt;input type="number" name="attr_CNSinit2" value="0" /&gt; &lt;br&gt; &lt;input type="number" name="attr_COM" value="0" readonly /&gt; &lt;input type="number" name="attr_CNS" value="0" readonly /&gt; &lt;input type="number" name="attr_COM2" value="0" readonly /&gt; &lt;input type="number" name="attr_CNS2" value="0" readonly /&gt; &lt;script type="text/worker"&gt; on("change:cominit", function(eventInfo){ getAttrs(["COMinit","COMproglib"], function(values) { console.log(eventInfo.sourceAttribute); var init = parseInt(values.COMinit) || 0; setAttrs({ COM: init }); }); }); on("change:cnsinit", function(eventInfo){ getAttrs(["CNSinit","CNSproglib"], function(values) { console.log(eventInfo.sourceAttribute); var init = parseInt(values.CNSinit) || 0; setAttrs({ CNS: init }); }); }); on("change:cominit2", function(eventInfo){ getAttrs(["COMinit2","COMproglib2"], function(values) { console.log(eventInfo.sourceAttribute); var init = parseInt(values.COMinit2) || 0; setAttrs({ COM2: init }); }); }); on("change:cnsinit2", function(eventInfo){ getAttrs(["CNSinit2","CNSproglib2"], function(values) { console.log(eventInfo.sourceAttribute); var init = parseInt(values.CNSinit2) || 0; setAttrs({ CNS2: init }); }); }); &lt;/script&gt; Custom Jumpgate game; The first and third column always fails to trigger the worker.&nbsp; I can swap the column positions in the html and the first input of the first and third column always fails to trigger. Every odd column fails to trigger the sheetworker. I have no clue why...&nbsp; I've removed all sheet css and this happens in legacy and CSE. Custom Non-Jumpgate game; inputs trigger the worker as expected.
No pun intended, but I think that every odd column fails to trigger the worker.
1724110903

Edited 1724224316
vÍnce
Pro
Sheet Author
Fred said: No pun intended, but I think that every odd column fails to trigger the worker. Correct.&nbsp; I've updated my test code to include some additional inputs to help substantiate that each odd column's input is failing to trigger the worker under Jumpgate. help ticket [#253078]
Reading through this I'm glad to see that it has been noticed. My sheet has been having the issue with every other row not calculating. I'm the Author of TableTopDefined's character. It'll start to update after closing and opening it. It's good to see I'm not the only one who has noticed this. Are we able to follow that help ticket number on the problem?
All I can say is that this bug is not fixed yet. My request was filled under the #252497 and I recieved a mail from Roll20 explaining that they were aware of this issue and would fix it asap.
1725058840
vÍnce
Pro
Sheet Author
Weird, I don't think I've actually received an email acknowledgement yet... #253078
I'm really glad to see this has been acknowledged by Roll20, because it's a real pain for my players (and myself, creating a new campaign from the start !) right now. Very interesting investigation on your side as well guys, thanks for looking into that for us players and GMs.
1725743967
vÍnce
Pro
Sheet Author
This is still a problem for Jumpgate games.&nbsp; I can only imagine that it's actually affecting lots of sheets on Jumpagte games but given how it only fails to trigger events on the odd attributes (which may or may not cause sheet calc problems depending on the particular workers involved...) people aren't even aware there's an issue.
1726929961

Edited 1726930983
Fred
Pro
Now the very same issue happens also in non-jumpgate beta games ! I'm pretty sure loads of sheet are impacted. In the meanwhile, I got no feedback from Roll20 about the #252497 ticket since they replied that they would fix it asap 1 month ago.
1727376676

Edited 1727481331
GiGs
Pro
Sheet Author
API Scripter
Fred said: Now the very same issue happens also in non-jumpgate beta games ! I'm pretty sure loads of sheet are impacted. In the meanwhile, I got no feedback from Roll20 about the #252497 ticket since they replied that they would fix it asap 1 month ago. This is my experience too. It's definitely not limited to jumpgates, and it seems very predictable and reproducible. In a repeating section, it appears the change event is triggering only (and exactly) on every second change event. On odd-numbered change events, no change event is being triggered.
I don't see anything in the changelog that would explain why the bug, which was affecting jumpgate beta games since over 1 month ago, as aknowledged by Roll20, extended to non-jumgate beta since last week. I'm far from being able to understand the implications of each line of the changelog, tho. A wild guess would be a relation with the release of the DD2024 sheet, that might have required some rushed hotfixes.
1727631420

Edited 1727635539
GiGs
Pro
Sheet Author
API Scripter
Fred said: A wild guess would be a relation with the release of the DD2024 sheet, that might have required some rushed hotfixes. This would be my guess, too. Also, the fact that they saw the issue a month ago, then went ahead with something that would propogate it to the entire userbase, is a failure of quality control, but sadly pretty typical for roll20.
I'm ignorant of how this works but can't they just remove the new sheet and run a private copy of the site to bug test it, see if that fixes the issue?
1727639304
vÍnce
Pro
Sheet Author
Kevin said: I'm ignorant of how this works but can't they just remove the new sheet and run a private copy of the site to bug test it, see if that fixes the issue? Roll20 used to have a Developer server that Pro/Mentor users had access to for testing new features.&nbsp; I believe it was felt that the effort to keep the Dev server updated for a very small sample size of testers was not worthwhile.&nbsp; Roll20 seems to have moved to an opt-in for beta testing over the last few years.&nbsp; Maybe that doesn't work with the Jumpgate update and the D&amp;D 2024/2014 situation?&nbsp; IDK
1727640089

Edited 1727641585
GiGs
Pro
Sheet Author
API Scripter
vÍnce said: I've played around with this a bit.&nbsp; I've culled things down to some minimal code for testing I've played around with the code (which is very helpful btw), and found that sometime sthe third column does update. I can't figure out any consistency - whicvh makes it worse, since we could create odd numbered columns and hide them, but we can't rely on that now. Something else that makes it bad: it's not necessarily the odd numbered columns that are affected, but the odd number you have chnaged this session . If you change the second column first, nothing happens. If you then change the thirf column, sheet workers are triggered. But if you try to change the second column again, no sheet workers are triggered.
1727640222

Edited 1727640269
GiGs
Pro
Sheet Author
API Scripter
vÍnce said: Kevin said: I'm ignorant of how this works but can't they just remove the new sheet and run a private copy of the site to bug test it, see if that fixes the issue? Roll20 used to have a Developer server that Pro/Mentor users had access to for testing new features.&nbsp; I believe it was felt that the effort to keep the Dev server updated for a very small sample size of testers was not worthwhile.&nbsp; Roll20 seems to have moved to an opt-in for beta testing over the last few years.&nbsp; Maybe that doesn't work with the Jumpgate update and the D&amp;D 2024/2014 situation?&nbsp; IDK When they did have that server, they didn't listen to feedback from it anyway. Anyone else remember the nested query fix and computed property trials? Problems with both of them were pointed out, then ignored as they pushed features live - then fixed them or withdrew then later.
I'm having this issue in my games jumpgate and non-jumpgate now. I really hope its fixed soon.