Event Arguments do not behave as expected

Please report bugs in this group. We will maybe populate a list of known bugs with a possibly modified description at a later time.

Moderator: Support

Post Reply
User avatar
Posts: 31
Joined: 18 Jan 2012, 17:54

Event Arguments do not behave as expected

Post by squiggle » 09 Sep 2013, 16:15

Here's something that I can't figure out:according to the manual I can use Event-Arguments to discern different events.... very handy to e.g. see which button was pressed: you assign an Argument to each of the Button-Pressed-Events, collect all the Events at one central Event (i.e.: the event can be triggered by many others) and read out the Argument received. So far so good.


This method becomes completely unpredictable when using more than one Event--Event connection, or when you want to make a "jump" out of a Container (exposed Events) even when you manually "carry" the Event Argument.

It's not easy to explain... I've built a small example (Ventuz 3 Pro) so you can see what I mean. Note that the Event Argument sometimes is carried immediately (but only to some nodes, even though they're daisy-chained) or is carried to all synchronously -- but buffered until the next Event is invoked.

Is this behaviour actually intended?

(30.05 KiB) Downloaded 269 times

User avatar
Posts: 497
Joined: 10 Jan 2012, 12:07

Re: Event Arguments do not behave as expected

Post by Karol » 11 Sep 2013, 14:56

Hi squiggle!

If there would be an award for the most complicated Ventuz question ever - you would be nominated :)

This is not a bug - just a special behaviour of the event and method bindings and the Event node.
There are 2.5 reasons which make the behaviour in your scene kind of strange:

1. Event and Method bindings are handled different than the normal value property bindings.
Nodes which are bound via value properties are validated in an order according to the dependencies which are created by the binding structure.
If you have nodes bound like that
A -> B -> C and
D -> E -> B
the validation order of the nodes is
A, E
to make sure that information from node A and E are processed at the same time in node B.
Event binding do not have this dependency tree. They are processed in a kind of lazy mode:
I. Fired Events are processed
II. Scene is validated
III. Events fired due Scene validation are processed. If this caused new events to be fired proceed at III.
IV. If new Events have been fired at III. proceed at II.

2. The argument which comes from Event node E1 and triggers 'Invoke' of Event node E2 is not used as argument in E2 when it fires its 'Fired' event!

(3.) The Mover in Random + OneShot mode creates a new value on Nudge immediately independent to the Duration value.

In your scene with Delay OFF this causes the following:
In frame N the Fire Button triggers the 'Invoke' on the first Event node with the argument from the Mover created in frame N-1. -> 'Fired' event on the first Event node in the chain is fired!
The Invoke method of the next Event is triggered and fires the 'Fired' event. This mechanism moves through the complete Event chain.
The Event node is build that way that it sets its 'Argument' output when the 'Invoke' method is fired.
The next Event node in the chain is triggered and reads the output Argument from the previous Event...
Pressing the Fire Button will also cause the Mover to create a new random value for use as Event argument but the Events already have been fired in frame N so it will be used in frame N+1 at first.

With Delay ON things get more complicated. The main problem here is that the delaying Event node is triggered in frame N with according argument but fires its 'Fired' event in frame N+1 with a new
different argument set at 'initial' Event node. This causes the alternation of the Event arguments through the Event chain.

In Ventuz 4 we added a property to the Event node to make it use the argument of the event bound to the 'Invoke' method.
Hope this makes things a little bit more clear.

Best Regards

Post Reply