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
This post has been closed. You can still view previous posts, but you can't post any new replies.

New API Update: Sheet Worker Support in API Scripts, Speed Improvements

1484664865

Edited 1484752971
Riley D.
Roll20 Team
Hello all, Today we've rolled out a new version of the API that's now available for all games. This new update adds support to API scripts for the sheet worker functionality that has been available for a while now for character sheets. So for example if you set the "Strength" value on the sheet, and that should update StrengthMod and your attack rolls, the API can now just update the one value and all the others will update accordingly. To use this new functionality, take advantage of these two new functions: setWithWorker(properties) This function works just like the current set() function, except when called on an Attribute object it will also cause the relevant sheet worker code to be executed by the API server, just as if a player had changed the value on the client using the character sheet. Example: getObj("attribute", "-KUI1fO2L7Jv0Y4AOSFK").setWithWorker({ current: "Cleric" }); Note: Although the sheet translation functionality is supported for sheet worker scripts, the current language for the API will always be assumed to be "English" currently. In addition to that, you can use the new function onSheetWorkerCompleted(function() { //do something here }); to register code that will only run after all sheet worker execution has finished for the current 'stack' of sheet worker calls. You can register the callback before you call the setWithWorker() function. Note that each callback you register will only run one time. This sheet worker functionality is intended to be used primarily by API scripts which are "companion" scripts to specific sheets, as opposed to general purpose scripts that are meant to be used by any type of game/system/sheet. In addition to the sheet worker functionality, we've made major overhauls to many parts of the API that were previously bottlenecks, in particular findObjs() should now be much faster if you're only looking for "indexed" properties such as the _type, _pageid, and/or _characterid of an object. So for example, the following search should now return nearly instantly: findObjs({_type: "attribute", _characterid: "-ABC123"}); findObjs({_type: "graphic", _pageid: "-ABC456"}); We've also fixed some outstanding bugs such as making the default attribute fetching for both rolling and the getAttrByName() functions match the client more closely. Also, I want to say a special "thank you" to Lucian, who has been very helpful in being a big tester of this new functionality and helping us discover bugs, slowdowns, etc. to get it all ready for everyone to enjoy. Let us know if you run into any issues with this new functionality. Thanks!
1484666281
Ada L.
Marketplace Creator
Sheet Author
API Scripter
This all sounds great! Can't wait to update the It's A Trap themes to take advantage of this!
1484668191
vÍnce
Pro
Sheet Author
+1 Will sheet workers recognize changes to attributes from an API script as if the player made them directly from the sheet in order to trigger events/auto-calculations?  Thanks
Vince said: +1 Will sheet workers recognize changes to attributes from an API script as if the player made them directly from the sheet in order to trigger events/auto-calculations?  Thanks Your API script has to use setWithWorker() to set the value. But if you do that, then yes it will trigger all events/auto-calculations.
1484685574

Edited 1484729407
Jakob
Sheet Author
API Scripter
First of, very nice that it's live now! I've been looking forward to this for quite a while now :). So let me get started with my first observation: Something seems fishy with translations (related to the translation strangeness Lucian had reported in the old thread?). After playing around a bit with setting attributes for sheet workers, I get all sorts of errors that look like this popping up in the API console: "Translation Error: the key [SAVE] is not in the translation object." "Translation Error: the key [PROFICIENT] is not in the translation object." "TypeError: getTranslationByKey(...).toLowerCase is not a function" "TypeError: getTranslationByKey(...).toLowerCase is not a function\n    at Object.callback (eval at <anonymous> (evalmachine.<anonymous>:282:6), <anonymous>:26:12640)\n    at Object.eval [as -Kai6-fmARkO2hlthS6A//false//0.11598416627384722] (eval at <anonymous> (evalmachine.<anonymous>:282:6), <anonymous>:65:4777)\n    at _fullfillAttrReq (evalmachine.<anonymous>:257:31)\n    at messageHandler (evalmachine.<anonymous>:288:6)\n    at process.<anonymous> (/home/node/d20-api-server/node_modules/tiny-worker/lib/worker.js:68:55)\n    at emitTwo (events.js:100:13)\n    at process.emit (events.js:185:7)\n    at handleMessage (internal/child_process.js:695:10)\n    at Pipe.channel.onread (internal/child_process.js:440:11)" I guess that simply means it can (for some reason) not find the translation key, and then the sheet worker script crashes because something is undefined. I thought at first it would be related to me using a custom sheet, but it happens just the same if I use the sheet from roll20's list (it's the Shaped sheet here, but that should not matter - except for the fact that it seems to have a lot of getTranslationByKey calls). There was another instance for me where API-sheetworkers stopped working, but restarting the sandbox fixed the issue, so I'll hold off on reporting this until I can provide a good reproduction path. EDIT: So I think I can more or less safely say that all getTranslationByKey calls are failing   for me, leading to the above TypeError, and the sheet workers do not actually finish doing their job. I can't say if this is the only reason why the sheet worker changes are not actually made, but it's certainly a good candidate...
1484695462

Edited 1484695784
The Aaron
Pro
API Scripter
Riley D. said: ... In addition to the sheet worker functionality, we've made major overhauls to many parts of the API that were previously bottlenecks, in particular findObjs() should now be much faster if you're only looking for "indexed" properties such as the _type, _pageid, and/or _characterid of an object. Be sure to use the underscore-prefaced property names to get the maximum speed possible. So for example, the following search should now return nearly instantly: findObjs({_type: "attribute", _characterid: "-ABC123"}); findObjs({_type: "graphic", _pageid: "-ABC456"}); ... Is there any reason not to make references to the non-underscore names operate via the indices?   I've got 152 instances across 64 scripts that would need to be individually considered and updated... I'm already behind with updates as it is. =D  Besides, it seems like the only reason to not use the index for a lookup would be to prove just how much you really SHOULD be using it. =D
1484739153
Laurent
Pro
Sheet Author
API Scripter
The Aaron said: Riley D. said: ... In addition to the sheet worker functionality, we've made major overhauls to many parts of the API that were previously bottlenecks, in particular findObjs() should now be much faster if you're only looking for "indexed" properties such as the _type, _pageid, and/or _characterid of an object. Be sure to use the underscore-prefaced property names to get the maximum speed possible. So for example, the following search should now return nearly instantly: findObjs({_type: "attribute", _characterid: "-ABC123"}); findObjs({_type: "graphic", _pageid: "-ABC456"}); ... Is there any reason not to make references to the non-underscore names operate via the indices?   I've got 152 instances across 64 scripts that would need to be individually considered and updated... I'm already behind with updates as it is. =D  Besides, it seems like the only reason to not use the index for a lookup would be to prove just how much you really SHOULD be using it. =D I was also wondering if that's beneficial when some of the properties are not indexed. Or would it be faster to first use findObjs with all the indexed properties, and then filter the array?
1484750108
Ziechael
Forum Champion
Sheet Author
API Scripter
Not 100% sure this is related but since leaving my game yesterday (pre-launch of this change) and logging in this morning I've started getting the following error in my API console: TypeError: Cannot read property 'get' of undefined TypeError: Cannot read property 'get' of undefined at PlayerControl.OnPage (apiscript.js:2530:25) at apiscript.js:2850:21 at eval (eval at <anonymous> (/home/node/d20-api-server/api.js:146:34), <anonymous>:65:16) at Object.publish (eval at <anonymous> (/home/node/d20-api-server/api.js:146:34), <anonymous>:70:8) at TrackedObj.set (/home/node/d20-api-server/api.js:909:14) at updateLocalCache (/home/node/d20-api-server/api.js:1177:18) at /home/node/d20-api-server/api.js:1328:11 at /home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:560 at hc (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:39:147) at Kd (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:546) I've tried systematically disabling/enabling scripts to find a potential culprit but to no avail, at least nothing consistent anyway... could it be related?
Ziechael said: Not 100% sure this is related but since leaving my game yesterday (pre-launch of this change) and logging in this morning I've started getting the following error in my API console: TypeError: Cannot read property 'get' of undefined TypeError: Cannot read property 'get' of undefined at PlayerControl.OnPage (apiscript.js:2530:25) at apiscript.js:2850:21 at eval (eval at <anonymous> (/home/node/d20-api-server/api.js:146:34), <anonymous>:65:16) at Object.publish (eval at <anonymous> (/home/node/d20-api-server/api.js:146:34), <anonymous>:70:8) at TrackedObj.set (/home/node/d20-api-server/api.js:909:14) at updateLocalCache (/home/node/d20-api-server/api.js:1177:18) at /home/node/d20-api-server/api.js:1328:11 at /home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:560 at hc (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:39:147) at Kd (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:546) I've tried systematically disabling/enabling scripts to find a potential culprit but to no avail, at least nothing consistent anyway... could it be related? Anything's possible, but what that stack trace would seem to indicate is that there is a function called "PlayerControl.OnPage" inside of one of your scripts that is trying to call the get() function on a TrackedObj that isn't defined. The parts "higher" than that in the stack trace (like Object.publish() on line 146) are just the parts of the API sandbox that trigger events in the user scripts...
1484751916
The Aaron
Pro
API Scripter
Looks like it's in Matt's Door Script, on line 556 ( this is the PlayerControl object):     this.OnPage = function() {         return thisToken.get("_pageid");     } This fixes it:     this.OnPage = function() {         return (thisToken||{get:_.noop}).get("_pageid");     }
1484752023
Ziechael
Forum Champion
Sheet Author
API Scripter
Thanks Riley, I did suspect it was likely not directly linked but thought I'd best mention it just in case, especially because of the timing of the sudden 'issue'... I'm a basic debugger so likely missed something, which is why Aaron has now fixed the issue. Thanks for taking a look though!
1484752840

Edited 1484753297
Riley D.
Roll20 Team
I've just pushed out another new update to both Main and Dev for the API. findObjs() Speedups You are now no longer required to use the underscore-prefaced version of the property name to get the new speedups from findObj(). However, note that currently "pageid", "characterid", and "type" are the only indexed properties.  The way that this functionality works is that we basically store an up-to-date pre-cached list of all objects for each value that exists of these -- so for example, we already know all the objects that are of type "attribute" in the whole game without needing to look through each object to find the ones that match. So if you are searching using only indexed properties, you will basically get a very fast result. If you also include a non-indexed property (or properties), we will first pare down the search to all objects that match the indexed ones, then only search through those for the non-indexed ones. So even something as simple as searching for "type: graphic" even if you are searching for non-indexed properties will now be much faster since we no longer search through all attributes as well looking for matches. Especially in large campaigns you should see a significant speedup from this right away. Translation Strings EDIT: Actually I think this is still broken. Looking into it now.
1484753475
The Aaron
Pro
API Scripter
FANTASTIC!!!!  Thanks Riley!
Translation Strings Okay, I finally tracked this down, and it took way longer than it should have because it was a very sneaky bug. Basically it was only happening if the campaign had an existing API State (e.g. something saved the global "state" variable in a previous API session). It just so happened that my test game on Dev didn't have one, and my test game on Main did have one, so I spent most of the morning trying to figure out why Dev and Main were acting differently, when really the issue had nothing to do with that. Anyway, long story short, it should be fixed now. I added an additional logging message that you should see if it's working properly: "Loading 384 translation strings to worker..." Also, just to point this out, the web worker scripts for the sheet (and the translation strings and all of that) will only be loaded if the API sandbox detects that you have at least one call to "setWithWorker()" somewhere in your code. Basically if you don't have that then your script doesn't use web workers so there's no point in doing all the extra work to spin up a web worker sandbox for your API scripts. So, if you're testing all this out, be sure you actually have at least one call to setWithWorker() in your test script to get it all to spin up. Okay, let me know if you run into any more issues!
1484758037
Lucian
Pro
API Scripter
Cheers Riley - thanks for your help on this! I will try to do some more benchmarking etc when I get a chance to see if we can get it working really smoothly for the more substantial cases with complex interdependent sheetworkers, but this is a great start!
1484759279
Jakob
Sheet Author
API Scripter
Awesome Riley, on both issues!!! I've checked out things with the new translations fix, and have found no further issues. Sheet workers seem somewhat slow, but everything seems to work (for my simple use case with ChatSetAttr changing only a few attributes at a time).
1484784731

Edited 1484787095
James W.
Sheet Author
API Scripter
For some reason, this doesn't seem to be triggering the sheet workers on the Pathfinder character sheet; even when I set "recalc1" to 1, which should trigger a sheet-wide recalculation on the sheet, I'm seeing the recalc button light up showing it's been hit, but then... nothing.  I know setWithWorker is at least setting  the attribute, seeing as it's clearly changing the recalc button, but if the sheet workers were running, it should eventually turn it back off (not to mention I should see the results of the recalculation). I also tried a customized version of the sheet to throw a console.log() when recalc1 changes; I can see this in my browser's console when I manually click the button, but it doesn't show up in the API console when I update it via setWithWorker... For the record, I am seeing the "webworker" script spinning up in the API console, along with the console.log() calls the sheet makes as it starts up. EDIT:  Here's a link to the script I'm currently trying this with. EDIT: Restarted the sandbox again, and now I'm seeing the console.log() I set up, but it's still not recalculating things; looks like this may be more related to the sheet itself. EDIT, the Third of His Name: Yep, definitely the sheet.  The Pathfinder sheet checks the event's sourceType, and only updates if the source is "player"; setWithWorker has a sourceType of "api", which means the sheet doesn't update.  Is there any way we can get an optional parameter for setWithWorker to set the sourceType of the update event?
James W. said: EDIT, the Third of His Name: Yep, definitely the sheet.  The Pathfinder sheet checks the event's sourceType, and only updates if the source is "player"; setWithWorker has a sourceType of "api", which means the sheet doesn't update.  Is there any way we can get an optional parameter for setWithWorker to set the sourceType of the update event? Good catch, glad you were able to figure that out. I'm not really sure how I feel about this, because on the one had the API in theory should emulate a player almost exactly, but on the other hand there could be things that the API isn't so good at that we just haven't discovered yet. So I guess really it comes down to, do we want to put the onus on the sheet author to "opt in" to allowing API scripts to do this stuff or the onus on the script author to thoroughly test it with the sheet and understand it may work slightly differently? I guess the latter probably makes the most sense. So yeah, I'll add a parameter to allow you to change the sourceType to "player" in an update tomorrow.
1484792936

Edited 1484798130
Yay! Riley Fixed Creature Gen.  Thanks!
1484794076

Edited 1484798667
Riley D.
Roll20 Team
Steve, Sorry that you're having issues with the new API update. I don't think anything that we did should have affected any existing scripts in a negative way, but I'm more than happy to take a look for you. Can you point me specifically at the game you're using the script in? I'll take a look and see if I notice anything. I tested a wide array of scripts with the changes, and it's been in testing on the Dev server for about 3 months now (see here: <a href="https://app.roll20.net/forum/permalink/4124691/" rel="nofollow">https://app.roll20.net/forum/permalink/4124691/</a> ) but of course there are always edge cases that we can't catch until it's out in the wild. Anywho, get me the info on the game and script you are having trouble with and I'll do my best to help. EDIT: Just to double-check, is it the 5E Shaped Companion script that you are using? Or a different one?
I'm using Pathfinder's Creature Gen script. &nbsp; My game is The Trials of Korvosa.
Link to Creature Gen
I have tried copy/pasting from Hero Lab (using the output stat block that has always worked beautifully) and copied from the d20SRD for a different monster to see if I was doing something wrong (I picked a super basic creature - an ogre that I've used before and knew worked). &nbsp;Let me know if you need more information. &nbsp; I also restarted the API sandbox. &nbsp;That usually fixes whatever ails it.
Okay, I'll take a look and let you know what I find.
Steve S. said: I have tried copy/pasting from Hero Lab (using the output stat block that has always worked beautifully) and copied from the d20SRD for a different monster to see if I was doing something wrong (I picked a super basic creature - an ogre that I've used before and knew worked). &nbsp;Let me know if you need more information. &nbsp; I also restarted the API sandbox. &nbsp;That usually fixes whatever ails it. Since I'm not super familiar with the script, can you tell me exactly what steps you're taking to cause the problem? Like, you're going to X entry on d20SRD, you're copying this text, you're pasting it where, then what API command you're running? That will help speed up the process since if I can get straight to where I'm seeing the error I can debug it hopefully.
Sure. &nbsp; drag a token onto a map open the token up Go to a creature on the d20srd - use this&nbsp; ogre select the text starting with the name "Ogre" all the way to where it says languages giant (end after giant) right click copy go back to roll20 token paste as plain text into the GM notes of the token Click save Make sure the token is selected Run creature gen script - !CreatureGen It should resize the token to large (2 x 2) and auto fill in hit points, AC, and create scripts for it's attacks and saves and initiative as token actions.
And thanks!
Steve S. said: And thanks! No worries, I'm looking at it now. Hopefully I can fix it for you.
1484796383
chris b.
Pro
Sheet Author
API Scripter
I updated the sheet just for James :) so now it will allow both 'player' and 'api' , so we'll see if everything works correctly
1484796633

Edited 1484797203
Riley D.
Roll20 Team
Okay, so I *think* I found the problem...but it's still not working for me, but now it's giving a different error, about not being able to find the "Str" attribute to parse it. And sure enough, there is no "Str" attribute in what it's dumping out. But I thought maybe you might be more familiar with that type of issue? So try this new version and let me know if you can get anywhere with it: <a href="https://gist.github.com/rileydutton/f3d099af31773435d27a0d8744af0675" rel="nofollow">https://gist.github.com/rileydutton/f3d099af31773435d27a0d8744af0675</a> EDIT: It seems like when I paste the stat block from the site into the GM Notes section there's like an entire part that's not pasting properly, but hopefully that's something you know a way around?
I believe that worked! &nbsp;Way to be able to read garbely goop and fix it!
Steve S. said: I believe that worked! &nbsp;Way to be able to read garbely goop and fix it! Okay, great, happy gaming :-)
So just in case any other script authors come by this, if you were previously relying on there being a changed._fbpath property on a newly created object, that is no longer available. This was never a documented part of the API which is why I didn't really think anything of it when I changed it, but it seems like there are a few older scripts that are 1+ year old that were using it for something similar to this: if (obj && !obj.fbpath) { &nbsp; &nbsp; &nbsp; obj.fbpath = obj.changed._fbpath.replace(/([^\/]*\/){4}/, "/"); } That particular example is actually fine since obj.fbpath is set, but just in case anyone is coming across any "replace is undefined" errors after the new update, do a search for "fbpath" in your code and make sure you weren't using it. The fix that the code was intended for is for a bug that's been fixed for like 2 years now anyway, so you can just delete that part of your code, but that's what was causing this issue. I manually reviewed all of the API Scripts in our official Github repo, and none of them should be affected by this, but I'm just putting this note here in case there are any scripts from outside the repo that are really old that break. Thanks Steve for letting me know about that so we could get it tracked down!
1484798537

Edited 1484798818
@Riley D Thanks as well for fixing that, I was gonna put up a thread later to see if I could get help on it, but lo and behold, one of the r20 devs already solved whatever broke in Cgen with the update. Thanks man. This is the kinda stuff you and the other devs do that keeps my Pro subscription chugging on.&nbsp;
Tatsuya T. said: @Riley D Thanks as well for fixing that, I was gonna put up a thread later to see if I could get help on it, but lo and behold, one of the r20 devs already solved whatever broke in Cgen with the update. Thanks man. This is the kinda stuff you and the other devs do that keeps my Pro subscription chugging on.&nbsp; You're welcome! And thanks for your support. Appreciated.
1484809512

Edited 1484809550
The 5e Shaped sheets seem to work but the companion scripts for monster generation seem to be broken.&nbsp; Stack trace: "5eShapedCompanion 1484807909211 ERROR : TypeError: Cannot read property 'remove' of undefined\n at apiscript.js:2649:21\n at Function._.each._.forEach (/home/node/d20-api-server/node_modules/underscore/underscore.js:158:9)\n at ShapedScripts.applyCharacterDefaults (apiscript.js:2644:8)\n at ShapedScripts.monsterDataPopulator (apiscript.js:2583:11)\n at apiscript.js:2501:46\n at Function._.each._.forEach (/home/node/d20-api-server/node_modules/underscore/underscore.js:153:9)\n at apiscript.js:2501:12\n at Function._.map._.collect (/home/node/d20-api-server/node_modules/underscore/underscore.js:172:24)\n at _.(anonymous function) [as map] (/home/node/d20-api-server/node_modules/underscore/underscore.js:1496:34)\n at ShapedScripts.importMonsters (apiscript.js:2488:9)"
1484814885
Lucian
Pro
API Scripter
Hi Riley, There appears to have been an undesirable change in behaviour in findObjs, albeit in area where there was no formal specification for what should have happened previously. The following script: on('ready', function() { &nbsp;&nbsp;&nbsp; const searchAttrs = {_characterid:'-Kapm1x2gzHklNs1rGhL', _type:'attribute', name:'output_option'}; &nbsp;&nbsp;&nbsp; log(searchAttrs); &nbsp;&nbsp; const attr = findObjs(searchAttrs); &nbsp;&nbsp; log(attr); &nbsp;&nbsp; log(searchAttrs); }); used to output an unmodified version of 'searchAttrs' in the second log statement. Since pushing the sheetworker changes, the object passed to findObjs is modified by the function, and generally contains fewer properties than before the call: {"_characterid":"-Kapm1x2gzHklNs1rGhL","_type":"attribute","name":"output_option"} [{"name":"output_option","current":"/w GM","max":"","_id":"-KappUSCKBb1fO-6QZP1","_type":"attribute","_characterid":"-Kapm1x2gzHklNs1rGhL"}] {"name":"output_option"} My script was doing a findObjs followed, where necessary, by a createObj, using the same properties object for convenience. This obviously fails now because findObjs has mangled the properties object. Such a change risks breaking lots of other scripts as well + it's also bad practice for an API function to modify its parameters in this way - could you clone the properties object before modifying it? Cheers,
1484815766
Laurent
Pro
Sheet Author
API Scripter
Riley D. said: I've just pushed out another new update to both Main and Dev for the API. findObjs() Speedups You are now no longer required to use the underscore-prefaced version of the property name to get the new speedups from findObj(). However, note that currently "pageid", "characterid", and "type" are the only indexed properties.&nbsp; The way that this functionality works is that we basically store an up-to-date pre-cached list of all objects for each value that exists of these -- so for example, we already know all the objects that are of type "attribute" in the whole game without needing to look through each object to find the ones that match. So if you are searching using only indexed properties, you will basically get a very fast result. If you also include a non-indexed property (or properties), we will first pare down the search to all objects that match the indexed ones, then only search through those for the non-indexed ones. So even something as simple as searching for "type: graphic" even if you are searching for non-indexed properties will now be much faster since we no longer search through all attributes as well looking for matches. Especially in large campaigns you should see a significant speedup from this right away. Great!&nbsp; One more question: I suppose this means that we shouldn't be using filterObjs as soon as one of the criteria is one of the indexed properties?
1484816197
Jakob
Sheet Author
API Scripter
Laurent M. said: Great!&nbsp; One more question: I suppose this means that we shouldn't be using filterObjs as soon as one of the criteria is one of the indexed properties? It would probably make sense to use findObjs() first and filter afterwards.
Lucian said: Hi Riley, There appears to have been an undesirable change in behaviour in findObjs, albeit in area where there was no formal specification for what should have happened previously. I've pushed out a new update just now which should fix this problem. Is this the same issue that Chase would have been experiencing? Or is that a different issue?
Jakob said: Laurent M. said: Great!&nbsp; One more question: I suppose this means that we shouldn't be using filterObjs as soon as one of the criteria is one of the indexed properties? It would probably make sense to use findObjs() first and filter afterwards. Yes, I would always use findObjs() first now, since filterObjs() will not take advantage of the faster indexing.
Perhaps this is a silly question, but as a Character Sheet Author, do I need to do anything with my sheets to get the full functionality of the new Sheet Worker/API integration?&nbsp; Or is the only changes for the API devs.
1484851693
The Aaron
Pro
API Scripter
If you want the sheet workers to respond to changes by the API and you are checking the source of an event for 'player', you will also need to check it for 'api'. &nbsp;No other changes on the sheet side.
So that is a NO, I will not need to add anything to my sheet workers code?&nbsp; Correct?
1484852196
The Aaron
Pro
API Scripter
Right. &nbsp;If you aren't checking the source of events in the sheet worker, you don't need to do anything.
And if I use Scripts like the ChatSetAttr?
1484852592
The Aaron
Pro
API Scripter
Once those scripts have setWithWorker() calls, using them will trigger sheet worker events. &nbsp;I'm pretty sure ChatSetAttr has that
1484853206

Edited 1484853218
Jakob
Sheet Author
API Scripter
The Aaron said: Once those scripts have setWithWorker() calls, using them will trigger sheet worker events. &nbsp;I'm pretty sure ChatSetAttr has that If and only if you are using the Github version (1.2) and haven't chosen to disable setWithWorker(). The one-click version doesn't have setWithWorker() yet.
1484853734
Lucian
Pro
API Scripter
Riley D. said: I've pushed out a new update just now which should fix this problem. Is this the same issue that Chase would have been experiencing? Or is that a different issue? Thanks Riley, that's sorted. Chase's issue was caused by this same problem I believe. I have a getOrCreateAttribute function that assumes that it can pass the same properties object to createObj that it passed to findObjs; this was having the characterid property stripped out of it, causing the createObj to error and return undefined in a place where this shouldn't normally have been possible.
Lucian said: Riley D. said: I've pushed out a new update just now which should fix this problem. Is this the same issue that Chase would have been experiencing? Or is that a different issue? Thanks Riley, that's sorted. Chase's issue was caused by this same problem I believe. I have a getOrCreateAttribute function that assumes that it can pass the same properties object to createObj that it passed to findObjs; this was having the characterid property stripped out of it, causing the createObj to error and return undefined in a place where this shouldn't normally have been possible. Great, let me know if you run into any other issues. Thanks!