I've been spending a lot of time lately trying to minimalize the footprint of my ORK processes--attempting to level out those pesky spikes in Unity's Profiler and bring them as close to 60fps as possible--and I've had some luck, but not enough to brag about. I was wondering whether, for steps like variable checks and changes which can either be handled directly by adding Event nodes or by way of a formula, does it make a difference which process is used? Furthermore, is it more efficient to create (very) large events with many checks and changes to manage a host of interconnected processes, or to cut down on some of those checks by running smaller scale, individualized events tied to a single auto-event? I'm also curious whether it's more efficient to run auto-events in a closed loop, or to run them constantly from beginning to end using an ORK managed time-checking process?
  • Generally, looping an event within itself will always perform better, as it doesn't have to do the whole start/stop event related things.

    Other than that, there's no golden rule or best way to do this, as it always depends on the individual use cases. E.g. using a formula in an event only to change a variable will have an unneeded overhead isntead of directly changing it in the event, but if the formula also does other things that'd otherwise require additional nodes that are more costly that simply doing some operations in the formula it could be better having it in a formula.

    The spikes might be related to combatant HUDs, though - e.g. if your events change something on your combatants (e.g. a status value, or apply/remove a status effect, etc.), that'll cause a recalculation of your HUDs.
    This will get a lot better in the next update, as the HUDs will only change when an actually displayed value changed (mostly :D).
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • "The spikes might be related to combatant HUDs, though - e.g. if your events change something on your combatants (e.g. a status value, or apply/remove a status effect, etc.), that'll cause a recalculation of your HUDs.
    This will get a lot better in the next update, as the HUDs will only change when an actually displayed value changed (mostly :D)."

    -That should help a lot. I've got quite a few Status Values for keeping track of things, and I think much of my problem stems from garbage dumping. Concerning looped events, I've found the need to always place lockout checks at the start of them to prevent multiple instances from overrunning. Is there a built in solution for ORK to bypass running a new instance of currently running events or, if not, is that something to look forward to in the next version?


  • No, there's no built-in way and currently there's none planned for the future.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
Sign In or Register to comment.