The wiki, it says: Note: Events are only triggered by changes made by players/the GM
playing the game. Events will not be triggered by API changes. So if a
player moves a piece on the tabletop, you would receive a
"change:graphic" event. If you modify the same graphic's property in an
API script, there will not be a "change:graphic" event triggered. The wiki, it lies. Code: on('change:attribute', function(attr) {
log('Attribute changed: ' + attr.get('name'));
});
on('chat:message', function(msg) {
if(msg.content === '!test2') {
const char = createObj('character', {name:'foo'});
const attr = createObj('attribute', {name:'myAttr', characterid:char.id, current:'myVal'});
log('after creation');
attr.set('current', 'myNewVal');
attr.remove();
char.remove();
}
}); Log output: "ERROR: You cannot set the imgsrc or avatar of an object unless you use an image that is in your Roll20 Library. See the API documentation for more info."
"Attribute changed: myAttr"
"after creation" It would appear that object creation by the API generates a change event but object modification does not. Furthermore, it looks like this applies even to objects that are created by Riley's new setWithWorkers function - when the API sheetworkers update a value, you don't get an event firing, but if they cause an attribute to be created, it fires a change:attribute event. Given that the sheetworkers are effectively a black box to the API scripts, this behaviour is extremely unhelpful because it's very hard to predict whether you're going to get a change event firing or not, where it has come from, and whether it is significant. I think the behaviour should be made consistent one way or the other; probably the safest option is to make it conform to what the wiki claims is the case, to help prevent horrific cycles. In a perfect world, this would be an option of some sort, but that's probably going to be hard, especially now that sheetworkers are coming into the mix as well.
