@sobhan.kouhestani sorry, I didn’t see that you were running in periodic mode. Unfortunately the old behavior in 1.3 will not be reproducible anymore in 2.0.
In 1.3 variables defined in the outer scope could be modified within the inner imperative scope. Therefore variables “t0” and “tCount” would update once written inside the imperative block and every time, “time” changed and the imperative block re-executed, the previously updated values of “t0” and “tCount” would be reused.
However, in 2.0 we changed the behaviour of imperative blocks and made outer variables read-only within them. This means that these variables are now copied and used as if they were local to the imperative block scope. Therefore when “t0” and “tCount” are changed in imperative code, only their local copies are modified and thus their new values do not reflect outside the imperative scope. Subsequently whenever the imperative code re-executes upon change of “time”, “t0” and “tCount” are reset to
null (in the outer associative scope), copied and reused in the imperative scope thus overwriting their previous states.
These changes were made to simplify complex associative update semantics between associative and imperative code and to make writing DesignScript in code block nodes more coherent to users. A lot of them do not make use of associative update workflows like in this case.