I recently switched to your persistence node and ran into an issue that could be fixed with a simple? change. Here's the problem. I am using the package to remember the state of a UI Graph node. This graph node outputs its state whenever a new value is given it. This output feeds to a set-shared-state node. The input to the graph is feed from a matching get-shared-state node to reset the graph on a restart. But as the get-shared-state node also outputs whenever a matching set-shared-state receives data, an infinite loop results. I have implements a work around to only allow the get-shared-state output to get to the graph on init, and block all others.
A more graceful solution would be to enhance the get-shared-state node to be configurable to trigger on init, or trigger on a new value being stored, or both.
Do you have any interest in doing this? If not I am inclined to clone the node and attempt it myself.
Regards,
Colin
I recently switched to your persistence node and ran into an issue that could be fixed with a simple? change. Here's the problem. I am using the package to remember the state of a UI Graph node. This graph node outputs its state whenever a new value is given it. This output feeds to a set-shared-state node. The input to the graph is feed from a matching get-shared-state node to reset the graph on a restart. But as the get-shared-state node also outputs whenever a matching set-shared-state receives data, an infinite loop results. I have implements a work around to only allow the get-shared-state output to get to the graph on init, and block all others.
A more graceful solution would be to enhance the get-shared-state node to be configurable to trigger on init, or trigger on a new value being stored, or both.
Do you have any interest in doing this? If not I am inclined to clone the node and attempt it myself.
Regards,
Colin