I think we may not be on the same page... but we are very close.
First off I am nearly 100% certain that values changed that might effect a tools options will be updated immediately. Changing the name of a point group should also be immediately available to the script. this will of course require the script to "read" the changes if a tool is used to add keys stored in the name of a point group. I don't see the custom tools for these scripts to be used "all the time" but only to change values. This should be fine even if you have to "rewind" to frame 0. (For example my physics script can only work starting from frame 0.)
My other thought is that the layer script is on the layer that you want it to work on as usual. The same way we do it now. I wasn't thinking that any layer scripts would be on the data storage layer at all.
There would be no need at all for the user to have to create the data storage layer/s or import any scripts other than the one they need for the layer they want to use the script just as we do it now.
In the group "data layer" it is named "Do not delete" or "Data Storage" and that's all. The layers INSIDE would then be created by the layer script that uses the utility script to save and retrieve data.
It would only need to do this once since it would look for the "do not delete" layer first, create it if it doesn't exist and create the layer script data storage layer inside it. If the "Do not Delete" bone layer already exists then it checks the layers inside it for a layer that matches the script. If the layer exists then it stores the data. If it doesn't exist it creates the layer.
Now onto the confusion about the key frames on the vector storage layers. When I say confusion it's that I haven't explained it well or maybe I'm not clear how you see this working. I just want to make sure you see my idea clearly (so you can show me where I'm wrong which I could be of course
).
The "real" key frames on the storage layer do not contain actual data. The key frames on the data storage vector layers are ONLY so the user can see where the key frames are that are written in the name of a point group when they use a custom tool that writes data to the group name.
For example (I'm just making this up. It's overly simplified for example purposes). The following text could be stored in the name of a point group. I've included a header to show what the values represent:
Code: Select all
-------------------------------------------------------------------------------------------------------------------------------
Author script name variable frame value frame value frame value frame value frame value frame value
-------------------------------------------------------------------------------------------------------------------------------
heyvern hv_physics gravity 20 1.0 110 -1.0 230 1.0 300 1.0 479 1.0 567 1.0
(Another point group name for another key framed variable)
heyvern hv_physics collision 15 true 35 false 123 true 267 false 785 true
So the key frames are not stored in the "keys" at all. all the info is only stored in the point group name. The script would check a group name and look for keys. This will obviously mean we need individual points for groups so the key frames don't "overlap". This won't work with the idea of reusing the same points for multiple group names since the keys would overlap. You would need unique point/s to create groups. I don't see this as a problem since you only need one point for a group. You could have dozens of variables assigned to groups and not create that many points.
The script would "select" the key frames of the points. The user would use the "selected point" channel to see those key frames distinctly from other point group keys.
The actual "real" key frames on the points are only for visual reference and would contain no data at all.
All of this of course could be total nonsense until we actually test it.
-vern
