Open just-Nob opened 3 years ago
renyuneyun
commented
3 years ago Hi, sorry this made a confusion in the first place. But in fact there is a description in the wiki. If I get you right, your understanding is mostly right, except for a part of "persistent" (and its consequences) -- it will make the node persistently "true". It is useful though, when you combine that with an operation titled "Control Script Node Status".
Thanks for the comment for #285 too.
just-Nob
commented
3 years ago Sorry, you're right. It seems to me that you have spent some time during the last weeks or month to update the wiki. I should have looked there before I wrote - I knew only the old description that was not that good & detailed (as far as I remember, there was no "Control Script Node Status" operation at that time). I apologize once again for generating some additional work to you (because you had to answer my issue).
Nevertheless, one small suggestion for a small improvement concerning a better usability and understanding: Would it maybe be possible to grey out the repeatable option in case of the volatile/persistant switch being set to volatile (referring to the wiki's current description)?
As stated lately in issue #285, a detailed explanation of those two parameters (see issue's title) would be very helpful for some beta testing, because currently there's only the possibility to guess their intended behavior. This in turn means that it's nearly impossible to determine whether the behavior or one's own understanding is wrong in case of unexpected results of a test.
The following is my understanding or idea of how the parameters should work:
Volatile/persistant: As I assume that a "one shot" event makes no sense in most (all?) cases, I exclude the possibility that volatile means that the event can be retriggered whereas persistant means it can't. So I guess that if the parameter is set to volatile, all childs' conditions/events of the script under consideration are only checked in that one moment the "volatile event" occurs. Then the script turn immediately to false and its cilds' conditions/events won't be checked anymore (as long as the event doesn't rise again). In contrast to that, a script triggered by an event and with its parameter set to persistant, the script stays active/valid (marked with a green dot in the pivot view) as long as its predecessor stays active, i.e. the childs' conditions/events are also evaluated after the event occured. In turn this means also that a script with a persistant event and no predecessors will stay active as long as the Easer is running.
Reoccuring: Assuming that my guess for volatile/persistant is correct, I estimate that this defines whether a script's event can retrigger the scripts' children even if the script's predecessors weren't false in between (so it has to become false one time before a retriggering is possible). If so, this would have some consequences: