[x3d-public] dynamic cycleInterval changes

[Don Brutzman]

Good point Patrick.  Thanks for your example too Holger.

Perhaps even trickier is that events within a single event cascade are not guaranteed to be ordered.  This slight relaxation on Script semantics was necessary when we reconciled internal scripting with external EAI to produce the combined SAI.  Avoiding reliance on event ordering is also necessary if events are being produced by parallel processes.  They might all be available at the beginning of an event cascade, but such arrival ordering can't be guaranteed.

Avoiding repetition of two values, please consider these variations on Holger's approach:

# http://stackoverflow.com/questions/3830244/get-current-date-time-in-seconds
timestamp = new Date().getTime() / 1000;
timestamp = Date.now() / 1000; // apparently equivalent

# stop then _start_
timeSensor.stopTime = timestamp;
timeSensor.cycleInterval = newValue;
timeSensor.startTime = timestamp;

timeSensor.enabled=false;
timeSensor.cycleInterval = newValue;
timeSensor.startTime = timestamp;

# reshuffled order of same events means (perhaps-ignored re)start then _stop_

timeSensor.cycleInterval = newValue; // ignored if running
timeSensor.startTime = timestamp;    // ignored if running
timeSensor.stopTime = timestamp;

timeSensor.cycleInterval = newValue; // ignored if running
timeSensor.startTime = timestamp;    // ignored if running
timeSensor.enabled=false;

Ouch.  Is the TimeSensor starting or stopping?  Coin flip.  No way to be consistent in one pass when event order isn't guaranteed.

Workaround: one way for an author to avoid nondeterminism is to perform one step before the other.  Two-phase commit.
a. first a script stop a TimeSensor (using either .enabled or .stopTime events),
b. await confirmation that TimeSensor has stopped (by receiving either isActive=false or stopTime/elapsedTime event),
c. then (meaning then in follow-on event-cascade loop) use that event as a trigger to change the cycleInterval and restart.

This workaround either takes a custom Script or perhaps a carefully crafted combination of event-utility nodes, along with corresponding ROUTE connections. It can be done, but is fairly detailed/onerous and certainly error prone.  Of course erroneous response is also maddening - user frantically clicking "why won't it STOP??!"

Back to X3D design, must wonder: why don't we just allow modifying cycleInterval while a TimeSensor cycle is active?  Avoids nondeterminism and programming overhead of two-phase commit.  Perhaps TimeSensor implementers could weigh in here...


On 11/21/2016 6:48 AM, Patrick Dähne wrote:
> Hello Andreas,
>
> Setting the cycleInterval does not work because your example javascript code does not comply with X3D. Have a look at the following lines:
>
> time.enabled = false;
> time.cycleInterval = 5;
> time.enabled = true;
>
> And now have a look at the spec (X3D Language Bindings : ECMAScript (JavaScript), 4.3.5.2.2 Accessing fields and readable fields of other nodes):
>
> … Events generated by setting an input-capable field on a node are sent at the completion of the initial function call made to the user code by the browser. … Assigning to the inputOnly field multiple times during one execution of the function still only sends one event and that event shall be the last value assigned.
>
> So in X3D conformant browsers, the lines above send only two events:
>
> 1. time.enabled = true
> 2. time.cycleInterval = 5
>
> The first assignment to time.enabled gets overwritten by the second assignment, so the timer never gets disabled.
>
> Bye,
>
> Patrick
>
>
>
>> Am 20.11.2016 um 21:36 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>>
>> I want to change the cycleTime of a TimeSensor in a x3d script:
>>
>> https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/tests/dynamicCycleTime.x3d
>>
>> cycleTime input events are ignored when the TimeSensor is enabled. So it is necessary to disable it first, then change the cycleTime and then reenable it.
>>
>> However, in all tested browser the above does not work as expected. These are cobweb, instant player and bs contact. bs contact also has this console message:
>> Script node speeder: parse error: line 16 "time.cycleInterval = 2;" ()
>> and therefore does not get to change the color to grey.
>> The javascript sai does not have a SFTime constructor and allows numbers.
>>
>> cobweb and instant player change the color but do not slow down the ball.
>> I first thought that cobweb does not correctly work through the sequence of events but since no browser works sofar I start to think that I am missing something.
>>
>> Any help or feedback appreciated,
>>
>> -Andreas
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman