I haven't included the affect function call since this attribute is not involved in them
And that's is why it does not work.
This is why I don't really understands why the node should be reevaluated after modifing
an attribute that doesn't affect any output.
Because setting a variable marks the attribute itself dirty. Because you have no affects network there's nothing in Maya that can clean or dirty the attribute.
is an unconnected attribute.
No its not, its affected by something otherwise you wouldn't be writing anything into the attribute, ever. Since you are asking this question its pretty clear that you are writing something to this attribute even if just at save.
What is it connected to? Well its connected to whatever the thing is you store. So whatever causes your storage to change also affects your solution history attribute. Conversely your history affects the output as well but you dont need to model this in if you dont want. On the other hand if you do then maya will just handle caching for you and optimize accordingly.
How would that work out then? Well see your compute should basically allways look as follows:
- what attribute was asked (no not what attribute was set, what output was asked for)?
2-n. If it was this attribute run this to clean it up. Every such step does NOT need to worry about any other attributes calculation as maya will just recursively call whatever subsection you need based on you asking the data if its dirty. Thus sections not asked for need not be computed (yet), but if you get the computation for free then update away.
As a result your atrubute is an output for maya. When maya asks the value for saving it asks the value just as if it was a node. Thus it asks you to compute it if its dirty and not if its not. Therefore your attribute need to be on one of the lists of evaluable outputs and it needs to have a trigger that marks it dirty otherwise Maya will just blow you off completely.
If you arrange it as a normal output, then it can be internally queried by Maya for save. And it doesn't need to be dumped out in any other situation except user intervention which is the same thing. If you dont like this then you can implement your own MPxData.
What I really need to do is to get the attribute value at t-1 and save
the updated value computed at t. I currently do this internally, but I
need a mechanism to save it within the scene file.
Why cant you jsut reevaluate what maya has? Oh yes you can't since that would make batch rendering impossible. So your already fixing in your strategy. And im not saying it can be solved mind you. In fact maya has nodes for caching this data but they work badly for the reason I explain here.
Anyway this is a bit error prone. See while i can understand this need pretty well (I'm a mechanical engineer and one thing i did as a part of my job 5 for years was just that reverse engineer robot controllers into a simulation application) I also happen to understand maya users somewhat well. While from the perspective of reality this makes sense, it ensures a more optimum path. However in reality data flows one way from past to future. In Maya data flows 3 ways.
a. from past to future
b. from any random point in past to this point
c. random lookup.
Now b is a bit problematic, c not so much. See when a maya user keys data, which is what Maya users do for a living, data gets mangled into the past. They keying act changes something in n+1 frames before this frame. You dont know how what or how far. This gets bit ugly for the user if the data depends on its previous position. See what the maya user looses is the ability to get feedback on how his changing of the attribute changes the reality. So they have to set the attribute blind and playback to see what actually happened. cache or not cache.
there are strategies to attack this one is to take controll of the entire process of prediction, one is to ask maya to runup the values in background. But still it gets really convoluted and ugly.
Its not that maya users can't live with this. They can but its a bit unproductive thats all. Such things never become very popular. But something like a real IK system for a robot really works this way, as does a rolling ball etc etc. But animators avoid using such things all the time because its so unwieldy to control (which is after all the reason why animators exist).