[Changes] Update Mode Design

NodeCanvas Forums Support [Changes] Update Mode Design

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #14604
    Driiade
    Participant

    Hello,

    Recently I saw some problems to run behaviour on Update, so I changed to FixedUpdate.
    There is actually no mode on GraphOwner to do this, so I decided to add an Update Mode on graphOwner (like the OnEnableMode).

    The problem of the actual design is that the autoUpdate things is in graph and not GraphOwner. Which I think can be reworked to be part of GraphOwner (As they are responsible of the “Unity part”).

    So I deleted all autoUpdate in graph things and it works perfectly !

    BUT

    In Dialog tree Node, there is a StartGraph with autoUpdate, which is nowhere else (in NestedFSM it is set to false).

    I think there is a big problem for those who update dialogue tree in FixedUpdate or Late Update, since these are obligatory updated on Update.
    This concern SubDialogTree and DialogtreeController.

    Cheers

    #14610
    Gavalakis
    Keymaster

    Hey 🙂

    Hmm. I could probably rework this to add an option to choose FixedUpdate or LateUpdate in GraphOwner inspector. The registration (and autoUpdate thing) will remain on Graph instead of GraphOwner however, since that way a graph can still be used outside the context of a GraphOwner (I know some people do it). I am curious what would a use case to use FixedUpdate be however for a graph update? Is that related to having physics tasks inside the graph, or something entirely different?

    Thanks!

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

    #14617
    Driiade
    Participant

    Hello,

    Yeah we make a platformer. And some state touch to velocity or are movement based. But more generally, a paltformer is sort of “time integral” of a game. And so we have to be sure the game run on the same way for different render framerate.

    For example, I don’t want my AI to wait for 0.5s on a platform and 0.5 + (delta render frame) on the other. So I decided to run most of the game in FixedUpdate.

    Hmm not sure it’s good for graph to auto populate MonoBehaviour. A Graph is just a graph, it’s data structure, what run the graph is up to them (GraphOwner or specific scripts). I know it can impact some projects, but also think it’s not a very good design, you have to keep data structure away from Unity runtime.

    And there is still the problem in Dialog node. ^^

    #14621
    Gavalakis
    Keymaster

    Hello again,

    The data structure of the graph is separated. We eventually need to tell the graph when to update though. If it is done through GraphOwner or MonoManager, it does not really matter. The GraphOwner is in control of the graph and in this case, it tells the graph to “auto update”. It could also tell the graph to not do that of course and update it by other means, or provide parameters to tell the graph to update in another program loop (like fixed update).

    If you want you can simply do this and utilize the graph itself manually.
    Event the Blackboardis not required in this example.

    You can also do this if you want to use a GraphOwner. If you do, you also have to set the “OnEnable” option to “Do Nothing” since we are starting the behaviour manually.

    With that said, I could add an “updating” option in the GraphOwner.

    Regarding FixedUpdate in general, it is really intended to be used for physics only and not as a way to make framerate-independent updates. For framerate-independent updates, Time.deltaTime should be used to adjust things that specifically matter to time, but it’s your game so you can use whatever you like 🙂

    Finally and regarding SubDialogueTree, it is indeed the only sub-node that still uses “autoUpdate = true”. I have just changed that now. I can send you the changes if you want ( to your registered email? ).

    Thanks.

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

    #14622
    Driiade
    Participant

    Yep thx.
    Don’t need a version. We don’t use Dialog Tree. It was for other people :p

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.