How plausible it is to implement a sticky-like global dictionary?
This is purely speculative, but the sticky dictionary as I understand it, is nothing more than a conventional dictionary that exists beyond the Grasshopper instance.
This means that you could define a sticky of your own in your server-side script. You just have to make sure that it doesn’t run out of scope, and thus get deleted in memory, until the rest of your script is done. Maybe even a global variable could do.
I have the feeling when using a global variable in the server script this variable is detached from grasshopper, only the value is transferred and it’s not what I want.
Could be, but I don’t think so, because when one of the inputs of the hops component gets changed, it needs to re-run the server-side script to refresh, but the server is running non-stop, which means that it should be possible to keep variables alive.
Seems like I was right yesterday. I’ve written a small example script to illustrate what I meant.
A three-dimensional point is stored in a persistent variable that exists beyond the Hops components in Grasshopper, on the server, and runs out of scope only if the server gets rebooted or shutdown.
It’s kinda like a walkie talkie or teleporter, if you will.
(I’ve purposefully set the Trigger to slow.)
from flask import Flask import ghhops_server as hs import rhino3dm app = Flask(__name__) hops = hs.Hops(app) sticky = rhino3dm.Point3d.Unset @hops.component( "/set_sticky", name = "SetSticky", description = "Set sticky variable", inputs = [ hs.HopsPoint("P", "P", "Point to store"), ] ) def set_sticky(pt): global sticky sticky = rhino3dm.Point3d(pt.X, pt.Y, pt.Z) @hops.component( "/get_sticky", name = "GetSticky", description = "Get sticky variable", outputs = [ hs.HopsPoint("P", "P", "Point from storage"), ] ) def get_sticky(): global sticky return sticky if __name__ == "__main__": app.run()
Before you run this, you need to install
I did it inside a virtual environment with
I think it would be way more elegant, if the Hops component had an internal clock or timer, like the Kangaroo solver does.
I’d also prefer to do the Grasshopper component myself as a Pythonic one, instead of this prebuilt Hops component. It would be way more flexible!
I’ve also noticed that both caching options should be turned off, while working on the server-side script. Otherwise, the Hops components don’t update often enough.