There are two C# components with the same code (the IceRay script). The first script passes the polygon to the second one. The first and second scripts also differ in the max_area input parameter. All other inputs are the same in both scripts (the ratios). Refer to the image bellow:
In Grasshopper if I change the “Module Tesselations (m2)” slider it only causes the second script to expire. This means that the structure is not changed. Likewise, changing “Tessellations Max Depth” slider only affects the bumps in the cork modules.
On ShapeDiver, changing “Tessellations Max Depth” or “Module Tesselations (m2)” seems to be causing the first script to expire and produce new polygons for the second script, yet the structure stays the same. This causes a mismatch between the structure and the modules.
On most cloud instance-based systems like ShapeDiver, relying on the state of an instance before computation is not a great idea, unless you are sure that your instance will persist across all computations (i.e. you have access to a dedicated instance).
In this specific case, your ‘first script’ is also being recomputed every time the backend cloud system switches to a different instance to compute for your viewer. This does not happen every single time a new parameter change is passed, which is why it seems like it re-computes only sometimes and not other times.
As a general rule of thumb [unless you’ve got an Enterprise license* ] assume that your script cannot recall anything from a previous computation. Every time you change a parameter, it may just re-compute the entire script by opening it in a new instance, hence losing any state it had prior to that.
A part of this blog post explains how ShapeDiver scales Grasshopper instances on the cloud using a taxi-system, which should help in understanding why this behavior is unavoidable.
If your script is behaving erratically but only sometimes, this may be a possible explanation for it.
*The computation dispatching logic is still applicable for Enterprise accounts as well, but the chances of a new instance being initialized for a computation is greatly reduced. So generally, it’s not a good practice to depend on the state of Grasshopper before a computation.
As a side note - if applied smartly, this could actually be quite a useful feature for certain use cases
@praneet Thanks for the explanation. My scripts had a global variable of the class Random which was declared and constructed on a global scope without a seed value, i.e. it used the system clock as seed. By making the constructor local and using a seed value the problem was fixed.
My interpretation of this behaviour is that ShapeDiver is using a cache system. Said cache system is recalling the results of the previous computations for specific combinations of values. Since I’m using a time-based random generator, there is a mismatch between the results of the computation of the first script and the second.
