Check Condition & Yield Return

[Driiade]

It seems YieldReturn value are totally bugged with FixedUpdate.

Because you use a yield return null, not available in fixedupdate. Modifying by yield return new WaitForFixedUpdate still don’t fix the issue (it’s worst, not working at all for us).

Removing the Flip coroutine in ConditionTask seems to be fine (why this coroutine ?)

I think you have to be clear between Graph Update, and similation. Your graph don’t have to be simultation dependant. The best way is to shut down all part of code which are Unity Update dependant, it cause use bugs for us ! I will take time after our delivery to send you our feedback.

[Gavalakis]

Hello,

The goal of the YieldReturn and the use of the Flip coroutine, is to keep the condition alive only for one frame after the condition has become true (instead of keeping it true until consumed on the next update loop). Please note that if you remove the Flip coroutine then the condition will only reset once it has been consumed (meaning that Check is called again). This might or might not be the desired behaviour (but it is the behaviour from day 1). Maybe I could add some option for that.

Having said that, I honestly don’t recommend using FixedUpdate as an update method for graphs (FixedUpdate is for physics) and the only reason I’ve added it in the inspector selection was due to a request (was it your request I can’t remember? 🙂 ). But please yes, let me know when you have and want to give some feedback (is always welcome 🙂 )

Thanks.

Join us on Discord: https://discord.gg/97q2Rjh

[Driiade]

Hello,

Yes that was my request.

Graph frame dependent are not good ! I insist but this is not the right way to do a game.

 

We used FixedUpdate because we wanted to have fixed step. It s not a physics things like people tell you it s just a fixed time step loop. Yes this is not good to keep it Unity Physics Update dependent, we keep this because we have short deadline now.

 

We want graph to be graph.Update dependent, not Unity.Update dependent.

 

FixedUpdate is the right way just before making your own fixed loop. I think all people have to call graph.Update(deltaTime) in a fixed time step loop to do good games !

 

Non fixed delta time cause all sort of trouble. Really !

[Driiade]

Hello,

On the same topic, It seems this condition really has a problem. Look provided screen (fig1), If you make a Subgraph starting like this, with a Dynamic selector (fig2) on top of it, you are obligated to put Reset because however, the graph is just in failed state, and will never check condition again.

But putting a reset decorator, just call the OnDisable of the CheckEvent condition. Making the frame look like -> OnEnable CheckEvent -> Reset Graph -> OnDisable CheckEvent. Thus adding / removing the callback to the router in less than 1 frame. So sending event is not received for this condition.

In our game we have what we call a “FrameDataBuffer”, it’s a buffer available for the next tick(and 1 tick is 1 graph update in our game). I think you have to manage to do the same things for the CheckEvent condition. Making an internal graph buffer where some data are available between 2 updates. And kill all the workaround with yield return and things like that ^^.

Thanks.

Attachments:

You must be logged in to view attached files.

[Author]

Posts