I posted this topic before, but I accidentally deleted it. Oops! Anyways, my former problem still stands: I have a problem with a sheet workers script being triggered "out of context", so to speak. Okay, so this is the script: on("change:Skl_total change:Lck_total change:Hitmod change:repeating_weapons change:_reporder_repeating_weapons remove:repeating_weapons", function(eventInfo) {
getSectionIDsOrdered("repeating_weapons", function(idarray) {
fID = idarray[0];
getAttrs(["Skl_total","Lck_total","Hitmod","repeating_weapons_"+fID+"_hit"], function(v) {
log(JSON.stringify(v))
let wHit = parseInt(v["repeating_weapons_"+fID+"_hit"])||0;
log("wHit is " + wHit)
let Skl = v.Skl_total;
let Lck = v.Lck_total;
let Mod = v.Hitmod
setAttrs({
Hit: Math.round((Skl * 3) + wHit + (Lck / 2)) + Number(Mod)
});
console.log(Math.round((Skl * 3) + wHit + (Lck / 2)));
console.log("Hitmod is" + Mod)
});
});
}); It gets the required stats and performs the calculation
necessary from there, and works fine when altering values directly on
the sheet. However, it seems to be triggering within the context of
an API script specifically, as the logged messages appear in the API
console rather than the browser console, and it keeps getting
"repeating_weapons_"+fID+"_hit" as NaN, setting the value to 0 even if
the actual repeating field on the character sheet exists. The
weird thing is that as far as I can tell, there are very few things in
the API script that directly modify these values, with most of them not
occurring in 99% of cases when running the script (the error still
occurs regardless), and even if there is something that's doing so,
there's no reason why "repeatingweapons"+fID+"_hit" should return as NaN
in the context of a worker if the field exists on the sheet. So what on
earth is going on? The API script is here ,
if you're interested, though I don't think it'll be very helpful for
figuring out why the sheetworkers is triggering when it shouldn't.
Still, I might have missed something in there that might be causing it,
so there you go. Things to note: The script has actually been triggering for hit at the end of the
script for a while, but it didn't actually do anything, so I largely
ignored it. It's only been recently, when I changed up my hit formula,
that it started doing this. I'm going to try scouring the script to see
if I can find what's calling it in the first place, but I don't expect
to find anything. In my test cases, JSON.stringify(v) returned this: {"Skl_total":7,"Lck_total":2,"Hitmod":0,"repeating_weapons_-l84jfnwkee27telqkyy_hit":"90"} Confirming
that the repeating_weapons value does indeed exist in this test case,
though introducing a default attribute doesn't seem to be working either
as it keeps getting wHit as 0 (and presumably, setting it as such in
the callback). The results logged to the console in said test case are: "[object Object]"
"wHit is 0"
"25"
"Hitmod is0"
"4"
"[object Object]"
"[object Object]"
"wHit is 90"
"115"
"Hitmod is0"
"4"
"[object Object]" Which to me, seems to suggest that the error is
occurring in the function callback somewhere, but that doesn't really
answer many questions. I'm trying to look for any lines in the script that may be inadvertently triggering changes in the values, but none of the attributes that factor into Hit seem to be changing in my test case, so I doubt I'll find anything. Unless somehow reading the values themselves counts as a change, but that seems unlikely. Edit: Logging eventInfo.newValue returned two slightly different logs: "{\"Skl_total\":7,\"Lck_total\":2,\"Hitmod\":0,\"repeating_weapons_-l84jfnwkee27telqkyy_hit\":\"90\"}" & "{\"Skl_total\":7,\"Lck_total\":2,\"Hitmod\":\"0\",\"repeating_weapons_-l83zfufutm5g0sa5kyv_hit\":\"90\"}" It seems unlikely, but might it be possible that hitmod and the repeating section being strings instead of integers is causing the error somehow? (Though that doesn't explain why hitmod is a number in one log and not the other.) Also, Jakob brought up this point: This will not perform as expected when you reorder the section;
it will always use the weapon that has been created first, since
getSectionIDs does not care about reordering. If that's the case, then as an aside, how would I go about getting the firstmost repeating section, if not my current method?
