I know I know, I used to have various hacky ways to 'force' an attribute to be stored in a cache. daisychaining them or storing userdata in the color or whatever ;) all of them have failed me at some point until I happened upon a demo ICE topo scene provided by Ciaran Moloney and saw that every single attribute used in the tree was diligently applied as a separate Custom attribute display. Even some built in attributes that you would expect to cache. when trying to recreate the exact setup, if any of those attributes were NOT in a custom display attribute then the topo caching / read /write system would fail.
so, like I said, to me, this is the ONLY way to reliably store user stuff in a cache that I have found so far. I like to think when I am setting up each of these custom display attributes (after a failed attribute cache) that each button press and menu select in the process is like hammering in a nail . that *hit* goddam *hit* attribute *hit* had better *hit* store *hit* this time!!! *Hit* *Hit* *Hit* On 6 February 2013 14:28, Sebastian Kowalski <[email protected]> wrote: > ...or multiply by 1 and key that param, or put an fcurve in between. > still i would prefer a "do what i told you to" switch ;) > > Am 06.02.2013 um 15:21 schrieb Rob Chapman <[email protected]>: > >> long way around but definitely a brute force approach. make a custom >> attribute display for each attribute you need storing. >> >> On 6 February 2013 14:14, Sebastian Kowalski <[email protected]> wrote: >>> +1 for brute cache ! >>> >>> Am 06.02.2013 um 15:06 schrieb Dan Yargici <[email protected]>: >>> >>>> While I appreciate the software's efforts to cache only the ICE attributes >>>> that it deems necessary (unless I list all the ones I want - in this case, >>>> many); can we please, please, get a "Just bastard cache everything, I >>>> don't care how big the cache files are" button? >>>> >>>> I've lost hours today trying cheap and dirty tricks to get a reliable >>>> cache.... grrrrr. >>>> >>>> DAN >>>> >>> >>> >> > >
