Change Events for Journals

Do they secretly exist?

Yup! You have to watch add:handout, change:handout, and destroy:handout. There's a second set for characters. If you want to know when people reorganize the Journal, you can watch change:campaign.

Odd, why isn't this documented in the Wiki?

It's alluded to in this passage: There are also events for all the other object types, and sub-types, such as: change:path, add:path, destroy:path, change:text, add:text, destroy:text, change:token, add:token, destroy:token, change:card, add:card, destroy:card See the Objects reference for a complete list of all object types and sub-types. Of course, that mentions destroy:token and destroy:card, which I believe I've found don't actually get called (though destroy:graphic does, and you can always check the subtype). =D

There is a change:$type, add:$type, and destroy:$type for every object type the API recognizes. You can also further specify the change event to only trigger when a specific property is being changed, such as change:handout:archived.

Well that's minimal as far as documentation goes :/ The devs need to resolve that if they really see this as a selling point (as discussed on the mentor forum). Thanks Aaron.

:)

Brian said: There is a change:$type, add:$type, and destroy:$type for every object type the API recognizes. You can also further specify the change event to only trigger when a specific property is being changed, such as change:handout:archived. hmmm

Ken L. said: Well that's minimal as far as documentation goes :/ The devs need to resolve that if they really see this as a selling point (as discussed on the mentor forum). The wonderful thing about wikis Is wikis are wonderful things! Their tops are made out of titles Their bottoms are made out of strings! They're informative, transformative, enumerative, explanative Coo, coo, coo, coo, coo! But the most wonderful thing about wikis is You can edit them, too! (With apologies to Tigger)

+1 @ Brian

Stephen S. said: Brian said: There is a change:$type, add:$type, and destroy:$type for every object type the API recognizes. You can also further specify the change event to only trigger when a specific property is being changed, such as change:handout:archived. hmmm Just thought of something, didn't you? :D

Brian said: You can edit them, too! Hate to say this, but if you're paying for something (a service) and you need to self-document the service you just bought, there's something wrong. It's easy to say 'but you can edit it too, support us!' which is great, but the fact that you're relying on paying members generating value for other paying members, it's an odd business model that depends on the charity of your own customers. Now I'm not saying that I wouldn't contribute, I'm pressed for time as I do quite a few FOSS projects which are truly community supported. Neither am I saying that there isn't already some documentation (by tracking the edits) done by the devs; but the developer documentation has been minimal. Much of the more in depth documentation was done by the community, or more accurately the paying community at least in respect to the API interface. Here on Roll20 I'm actually paying for something to save time as opposed to donating my time and effort. I still release scripts, but not as frequently as others for the same reason. Before we skirt CoC too much, that's all I needed Aaron, thanks!