A couple "bugs" ?

1) As a GM, set yourself as owner to a character sheet. Reconnect as player. The biosheet is not viewable, nor is the character sheet, but if you have token macros on you can shift click, and see attributes and token macros, but the bio will be stuck at loading. I help with scripting for our GM, so I edit our campaign as a GM and then when we play I want to switch to a player and would like full functionality. Is this just me? 2) Can't trigger msg.type = api via sendchat for other scripts <a href="https://app.roll20.net/forum/post/537282/calling-o" rel="nofollow">https://app.roll20.net/forum/post/537282/calling-o</a>... I want one script I have via sendchat to trigger API for a second script on("chat:message", function (msg) in the second script msg.type should be "api" if sendChat(who,"!whatever") is sent from another script. Unless there's a way to call another script's on function directly?

1. Are you setting the owner as GM or as your player name. If you do player name, the sheet will be viewable. 2. The api will not be able to trigger another api script. That is a protective measure to prevent infinite loops.

1) As player name, and then as All Players, neither work for when I rejoin as a player. Only one char sheet is visible for some reason. It's happening in multiple browsers - 27.0.1 and Safari. I know it's working fine for non GMs. 2) Could that protective measure be removed? There's a lot of ways to trigger an infinite loop - in this case you just must be careful to not have two scripts endlessly output to chat !somecommand that will execute an if branch that will trigger the alternate script that does the same thing to the first script. You could have bad math in a for loop, a bad do-while loop, bad recursive functions, etc that can trigger an endless loop. Why protect programmers from themselves? Additionally the protective measure can be worked around as seen in the thread, people writing out API for the who. Or you can just remove the check for msg type to bypass the safety measure. I think the feature is important, so you can extend and build frameworks around other users' frameworks. In this case, actually, I'm building something around your Power Card script, I want to avoid editing it and keep automation and power card separate. I have a "Rally" token macro for 13th age. If you press it, it will type !recover ?{Recoveries to Spend|1} into the chat. My script will find the char sheet of the token selected, decrement "recoveries" in attributes, do the math for HP recovery and add it to the char sheet's HP, and then I actually want to write out !power --Name|Recover --Effect|concatenated string of what just happened

About #2, I've been working on a plugin infrastructure, and the way I allow scripts to call other scripts is to expose my on("chat:message") callback to other scripts. So basically instead of defining the callback inline, you can bind it to a variable like this: var onMessageCallback = function(msg) { // if (msg.type === "api") { // ... blah blah // } // blah blah } on("chat:message", onMessageCallback) and you can call that onMessageCallback function with a modified msg: var new_msg = _.clone(msg); msg.content = "whatever my new message is"; onMessageCallback(msg); (Note, I'm just typing this out based on what I've done, and I haven't tested these exact code samples - so it might not work due to some typos or whatever. In any case, the general technique works)

Neat, thanks!