[Script bug?] TokenMod odd behaviour

I've send the command below to token-mod, and get an odd set of messages in the sandbox console !token-mod --ignore-selected --ids -N9wJUqcnMxBH95QK2M8 --set bar1_value|+4 --set bar2_value|+4 The result in the sandbox console is: "(node:25) UnhandledPromiseRejectionWarning: TypeError: rollExpression.trim is not a function &nbsp; &nbsp; at isRollValid (eval at messageHandler (evalmachine.&lt;anonymous&gt;:713:6), &lt;anonymous&gt;:32523:37) &nbsp; &nbsp; at Object.eval (eval at messageHandler (evalmachine.&lt;anonymous&gt;:713:6), &lt;anonymous&gt;:32561:21) &nbsp; &nbsp; at _fullfillAttrReq (evalmachine.&lt;anonymous&gt;:688:31) &nbsp; &nbsp; at messageHandler (evalmachine.&lt;anonymous&gt;:721:6) &nbsp; &nbsp; at process.&lt;anonymous&gt; (/home/node/d20-api-server/node_modules/tiny-worker/lib/worker.js:65:55) &nbsp; &nbsp; at process.emit (events.js:314:20) &nbsp; &nbsp; at emit (internal/child_process.js:877:12) &nbsp; &nbsp; at processTicksAndRejections (internal/process/task_queues.js:85:21)" "(node:25) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see <a href="https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode" rel="nofollow">https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode</a>). (rejection id: 8)" Is anyone else getting odd issues with TokenMod, or is there someting I might have done to get this?

Hi Richard @ Dameyr! I couldn't find any of those functions in the Roll20 script repo. I've seen similar reports to this that are actually sheetworker errors, but I'm out in the weeds with the error log. What sheet are you using?

Thanks for coming back so promptly. OK, further diagnosis shows that the token with the ID given had a non-printing character (possibly a space, but I've tried reproducing it with a space and no luck) in its bar1_max field - the bar1_max field was not displaying "max" in it as it does when it is blank. Deleting that non-printing character has stopped the error message coming up in the console. Odd, as the !token-mod command is only altering bar1_value &amp; bar2_value, and is not touching bar1_max, but there we go. Looking at the error message above would seem to indicate some error happening, but being in a spawned async promise which has not been paired with a catch() statement, so the error gets mishandled.&nbsp; All the async promises spawned by my RPGMaster APIs have paired catch() statements (as far as I can see) and the processing should anyhow not be touching my APIs if using the !token-mod command directly in the chat entry (though I've not disabled them and tried to reproduce it, to be honest). Anyhow, I can't now seem to reproduce the problem having got rid of the non-printing character that was in the bar1_max field, so just have to watch things and see if it occurs again.

BTW, the sheet is Peter B.'s Advanced AD&amp;D2e sheet. Though on this token, the bars are not linked to the character sheet

I'm 99% sure that callstack is in the Mod Sandbox.&nbsp; If you still have the token around, can you dump out the character code for the non-printable character?&nbsp; I'll try to reproduce it in a script and pass it off to the devs.

I've reproduced the error, and queried the character code in the bar1_max field of the token using a bit of code. It is just a space, char 32. But the odd thing is I can't reproduce it if the space, (char 32), is typed into the field: I can only reproduce it if the space is put there using code in the API (not exactly like this - the code in the API has error checking that the tokenID is valid, and the getObj() returns a valid token object). getObj('graphic',tokenID).set('bar1_max',' '); Then, if I perform the token-mod call, I get the error and callstack. Querying the field returns just the char 32. FYI, I've removed the bit of code that was putting the space into the field - it does not need to do it, and for me and my APIs that has fixed the issue.

Interesting, I'll give it a try, thank you!