Insert code that would generate a message on the console.

Most scripts have a log feature to show they have started in the console, some dont. Is there an easy 'bit' of code you can add to the end/start that would run and display a message telling you the script started.

My script-fu is still at the fledgling stage but a lot of scripts have this near the beginning: on("ready", function() { log(<insert log output here>); });

Ziechael is correct. Anytime you use "log()" the contents of the () will be put in the console any time it gets executed within the script. Some common starting points for scripts are: on("ready", function () {                      --------- Runs when campaign starts on("chat:message", function(msg) {   --------- Runs when a chat message is sent  on("change:token", function(obj) {     --------- Runs when a token is changed It is also important to think about where you put your log() in the script so it gives you the right information. For example, if you put your log() immediately after on("chat:message", function(msg) { then it is going to log each time a message is sent. You would want to put it after the checks for the command and api message check. For example: on("chat:message", function(msg) { var cmdName = "!diplomacyCheck"; var msgTxt = msg.content; if (msg.type !== 'api' || !playerIsGM(msg.playerid)) return; if (cmdNamePortion !== cmdName) return; log (<log input goes here>) Hope that helps. If you have any specific problems with a script let me know and I'd be happy to help!

Brent T. said: on("change:token", function(obj) {     --------- Runs when a token is changed It's 'change:graphic', actually. Change events may also specify a single property to observe (change:graphic:top for example), and the callback accepts two parameters (obj and prev), although nothing breaks if you only write one (you just won't have direct access to the second).

'change:token' seems to be working as well. The code I cited is from a functional health tracking script and I used an example from the  wiki as a template . Are there unintended consequences of using 'token' rather than 'graphic' that i might be opening myself up to? Regardless, I didn't know about the extra parameters and single property so thanks for the insights Brian!

Brent T. said: Are there unintended consequences of using 'token' rather than 'graphic' that i might be opening myself up to? Regardless, I didn't know about the extra parameters and single property so thanks for the insights Brian! If change:token is working, then it's simply been aliased and you shouldn't have any serious problems. change:token might  restrict itself to graphics which are not drawings or to graphics which are not cards, but I'm not certain; if it does restrict itself and you tried to write a script assuming it doesn't, you'd miss event triggers, or if it doesn't restrict itself and you tried to write a script assuming it does, you'd get extra event triggers. Even if you don't include the prev parameter for the callback, it can still be accessed with arguments[1]. Hell, you could omit the obj parameter and still access it with arguments[0]. Having both prev and obj is convenient because it lets you see exactly what's changed; obj has the object's current values after the change event occurred, and prev stores the object's values from before the event, so you can compare them. Note that while obj is a Roll20 object (obj.get('type') === 'graphic'), prev is a plain old JavaScript object (prev._type === 'graphic').

Thanks for the insights once again Brian. That helped me make a script far more efficeint.

Brian said: Brent T. said: Are there unintended consequences of using 'token' rather than 'graphic' that i might be opening myself up to? Regardless, I didn't know about the extra parameters and single property so thanks for the insights Brian! If change:token is working, then it's simply been aliased and you shouldn't have any serious problems. change:token might  restrict itself to graphics which are not drawings or to graphics which are not cards, but I'm not certain; if it does restrict itself and you tried to write a script assuming it doesn't, you'd miss event triggers, or if it doesn't restrict itself and you tried to write a script assuming it does, you'd get extra event triggers. Even if you don't include the prev parameter for the callback, it can still be accessed with arguments[1]. Hell, you could omit the obj parameter and still access it with arguments[0]. Having both prev and obj is convenient because it lets you see exactly what's changed; obj has the object's current values after the change event occurred, and prev stores the object's values from before the event, so you can compare them. Note that while obj is a Roll20 object (obj.get('type') === 'graphic'), prev is a plain old JavaScript object (prev._type === 'graphic'). change:graphic -- any graphic change:token -- graphics that are not cards change:card -- graphics that are cards Changing a card will get you both the change:graphic and change:card events, changing a graphic that isn't a card will get you both the change:graphic and change:token events. There are also add:graphic , add:token , and add:card  events that behave as above, however adding a graphic by dragging it in from the journal will trigger the add:graphic , add:token , change:graphic and change:token , while copy/pasting it will only trigger the adds .  Dragging a card from the deck or the hand will only trigger the adds , but copy/pasting a card triggers the adds and changes . Additionally, there are destroy:graphic , destroy:token  and destroy:card , but only destroy:graphic is ever triggered.