Hi, I have a lot of DAT Execute nodes that trigger when a global scene/shot setting changes, and generally this works great (using onTableChange or onCellChange).
All except in one situation: on file open. There, what appears to be happening is that since the file was saved with the last setting of the scene, when all the pieces get rebuilt on file open, none of those triggers get invoked because the scene hasn’t changed. My (crappy) workaround is to change my scene/shot setting to another scene and then back again to get those DAT Executes to trigger.
Is there a best practices way to overcome this? I found that for a Dat Execute op ‘d’, I can call
d.module.onTableChange(d.par.dat.val)
and that will spoof it into thinking that the table changed. I suppose I can go do an opfind of all DAT Executes in the entire file and just retrigger them, but that seems really hardcore. The other approach I’ve looked at is clearing the shot/scene global on file save, but then every time I save I basically shoot myself in the foot because now my setup doesn’t have a valid scene/shot setting.
Rather than clearing your shot, you might instead of a “default” scene that loads and setting your table value to these scene / shot at application close.
When you open you’ll start in your “default” which will give you a valid scene / shot setting, and then when you change your executes should all still work as expected.
Hmmm, I’ll have to think about that approach. I have a DAT Exec that whenever the scene changes, it writes it to disk which is then read at the start of the session (to maintain continuity across TD invocations). Thus if I were to set to a default scene, that would be loaded at startup and I’d be in the same boat I’m in now. I suppose I could read the data from disk, zero out the scene but then do a quick timer delay and then re-reset the scene to what was on disk.
Is there a way to query if we’re in a write-before-save context?
Executes that are based on table changes can be a little tricky in this regard - exactly because of the state questions that you’ve identified.
Depending on your structure - I might refactor to use a module on demand or an extension to write the file to disk. This would make the process of updating the behavior of your executes much simpler in the future… though it might take a minute to make all those changes.
You might consider decoupling the record action from your table change - like a pulse par that triggers recording your shot / scene. Your table changes could pulse that par, or you could pulse it separately - that might give you the flexibility you need, though it would be a bit of code clean-up to get there.
