Event without previous TimeConstraints are PENDING even if they are into a TimeNode with events which are not

[nvuaille]

On execution the event on the end of the playing constraint is not set to "pending", while other events status of the same timenode are correctly set.
In this image, yellow == pending :

[theod]

hum. actually it is quite normal that the end event of the playing constraint is not PENDING as the constraint is not flexible. it will become PENDING when the constraint will be done and will become HAPPENED immediately after.

so the problem is more about why the other events are PENDING ? if you add a first constraint before the playing constraint, are they becoming PENDING when the second one starts ? or are they PENDING when you start the scenario ?

[bltzr]

IMHO, they should be pending only if the previous constraint is flexible so, everything should actually stay in its initial color, in this case...

[nvuaille]

After some test, my conclusion. Event is actually set to pending if :

• it has no previous constraint
• a constraint ending on the timenode is playing

[theod]

ok thanks for doing this test @nvuaille.
is there any chance you saved this beautiful scenario to send it to me ?

[nvuaille]

Here an example

2016-02-26 11:48 GMT+01:00 theod [email protected]:

ok thanks for doing this test @nvuaille https://github.com/nvuaille.
is there any chance you saved this beautiful scenario to send it to me ?

—
Reply to this email directly or view it on GitHub
#33 (comment).

Nicolas VUAILLE
[email protected]
06 42 36 84 90

[cbossut]

In my opinion, an Event is :

• IDLE (or whatever, I don't remember the first state) by default ;
• PENDING when his expression is evaluable (maybe we need another state if
  we can listen before the evaluation is possible) ;
• HAPPENED or DISABLED according to the result of the expression after it
  has been evaluated.

Al I right ?

2016-02-26 11:24 GMT+01:00 theod [email protected]:

hum. actually it is quite normal that the end event of the playing
constraint is not PENDING as the constraint is not flexible. it will become
PENDING when the constraint will be done and will become HAPPENED
immediately after.

so the problem is more about why the other event are PENDING ? if you add
a first constraint before the playing constraint, are they becoming PENDING
when the second one starts ? or are they PENDING when you start the
scenario ?

—
Reply to this email directly or view it on GitHub
#33 (comment).

Clément Bossut

[theod]

yes, a TimeEvent status is :

• NONE by default
• PENDING when his expression is evaluable
• HAPPENED or DISPOSED according to the result of the expression after it has been disabled.

[theod]

what should be the status of a TimeEvent without any previous TimeConstraint ?
as it is for now it is PENDING but I'll change to be NONE as this should solve this issue.

[nvuaille]

from @theod

PENDING when his expression is evaluable

TimeEvent expression is evaluable only during one tick : when the timenode is triggered. So I suggest to modify that a little bit :

• NONE by default
• PENDING when its trigger is evaluable
• HAPPENED or DISPOSED according to the result of the expression after it has been disabled.

That would solve your question about previous timeconstraint

[theod]

but if we do so it means we need to add a flexible TimeConstraint to the event in order to make it PENDING otherwise the scenario will be blocked in this state :

so I would say this not a bug as we can consider a TimeEvent without any previous TimeConstraint as PENDING because it not constrained by anything. of course without adding a Trigger this TimeEvent will never become HAPPENED (yes it is maybe useless but it is meaningful).

so I would say, if you don't want to display this information in i-score you can turn the event in yellow according to the following test :
event->getStatus() == OSSIA::TimeEvent::Status::PENDING && event->previousTimeConstraints().size()-> 0

[theod]

TimeEvent expression is evaluable only during one tick : when the timenode is triggered.

no. a TimeEvent become PENDING once all its previous TimeConstraints have reached their minimal bound.

[jcelerier]

I guess the current behaviour is ok for everyone ?

[bltzr]

yep