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.
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...)
on("change:COMinit change:COMprog change:COMprog2 change:COMproglib", function(){
getAttrs(["COMinit","COMprog","COMprog2","COMproglib"], function(values) {
var init = parseInt(values.COMinit) || 0;
var prog = Math.max(parseInt(values.COMprog) || 0,0) + Math.max(parseInt(values.COMprog2) || 0,0) + parseInt(values.COMproglib) || 0;
setAttrs({
COM: init+prog
});
});
});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. The worker looks fine to me.
I have no idea if it's part of the problem, but all the change event attrs names https://wiki.roll20.net/Sheet_Worker_Scripts#Events should be lowercase. Maybe jumpgate is not as "tolerant" of such discrepancies... I'll see if I can actually do some testing.
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 ;)
"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;
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.
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.
I mentioned that above but I just ran a quick test with lowercase change listeners and it didn't make a difference. ;-( Very odd.
I've played around with this a bit. I've culled things down to some minimal code for testing
<input type="number" name="attr_COMinit" value="0" />
<input type="number" name="attr_CNSinit" value="0" />
<input type="number" name="attr_COMinit2" value="0" />
<input type="number" name="attr_CNSinit2" value="0" />
<br>
<input type="number" name="attr_COM" value="0" readonly />
<input type="number" name="attr_CNS" value="0" readonly />
<input type="number" name="attr_COM2" value="0" readonly />
<input type="number" name="attr_CNS2" value="0" readonly />
<script type="text/worker">
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
});
});
});
</script>
Custom Jumpgate game;
The first and third column always fails to trigger the worker. 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... I've removed all sheet css and this happens in legacy and CSE.
Custom Non-Jumpgate game;
inputs trigger the worker as expected.
Fred said:
No pun intended, but I think that every odd column fails to trigger the worker.
Correct. 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.
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.
This is still a problem for Jumpgate games. 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.
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.
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.
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?
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. 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. Roll20 seems to have moved to an opt-in for beta testing over the last few years. Maybe that doesn't work with the Jumpgate update and the D&D 2024/2014 situation? IDK
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.vÍnce said:
I've played around with this a bit. I've culled things down to some minimal code for testing
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.
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. 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. Roll20 seems to have moved to an opt-in for beta testing over the last few years. Maybe that doesn't work with the Jumpgate update and the D&D 2024/2014 situation? 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.
