From what I can tell, ORK appears to run in the background as a co-process along with everything else on the main thread, which tends to spike the CPU whenever it runs an event with a lot of nodes and formulas to check, even when adding intermittent 'Wait' nodes that give the processor time to breath. Garbage collection probably doesn't help either. I understand multi-threading carries its own set of issues, but could allocating all of the ORK processes to to a separate thread, such as they've done with the physics engine, help to improve frame lag?
  • It might, but it might also break the whole system. A lot hangs on calling/using Unity functionality (e.g. depending on what is going on in your event) and I have no idea how thread-safe that currently is (and this might also depend on which Unity version you're using).

    Are you actually running into performance issues due to large events?
    There's the Max Event Steps setting (default in Base/Control > Game Controls > Interaction Settings, can be overridden by each event) to automatically wait for the next frame after the defined number of steps/nodes.
    If you're enjoying my products, updates and support, please consider supporting me on!
  • That's part of my problem. Initially, my primary attack event caused a whopping 2+ seconds of frame lag with around 10,000 calls hitting it the whole way through along with garbage collection. Adding 'Wait' nodes to that particular event at stages helped smooth things out from a freezing catastrophe to a stuttering mess, but it doesn't prevent the script spikes that hit the CPU every time the event runs into a formula. Strangely, even when I disable everything and link straight into running an animation and ending the event I still get a slight stutter along with a huge blue spike over the 15 FPS mark in the Profiler. On a side note, it's unfortunate that Unity decided to use two different shades of blue for Scripts and Animations on the CPU profiler, Texture and Material on the RAM and so forth.
  • edited November 14
    What's going on in your events that they'd cost that much performance?
    Usually an event has near to no impact at all and it's only something to concern with if you're running a lot of events ...
    Things that cost performance are mostly general performance pitfalls, like spawning/destroying prefabs. Also, using the new UI with a HUD constantly updating can impact performance.

    I'd only expect that kind of spikes when using the profiler with Deep Profile activated.
    Post edited by gamingislove on
    If you're enjoying my products, updates and support, please consider supporting me on!
  • What I've discovered is that it's not simply what the event does--i.e. the rout it decides to take--there's a spike whenever a new event loads based on how many nodes it contains. Even if an event ends up doing something relatively simple, there might still be a large performance drain at the beginning when it loads if it contains multiple branches. Placing a one or two second 'Wait' node at the beginning and end of these events has shown this to be true.
    The 'variable Fork' node can also cause large performance drains if there are a large number of branches to check, and of course any node that checks a complex string of formulas. The processor can run these formulas in a nanosecond, as it does whenever the test calculation runs, but that's without having to run VSync and rendering and everything else that inevitably causes large scripts to bottleneck. I can also notice a slight UI up-tic at certain intervals, probably when the console updates, but it's mainly the scripts themselves that cause slowdowns. It seems like, if they're just used to run calculations and work off local variables from start to finish, at least some of these events could be allocated to a separate core and feed their data back to ORK either when they've finished or at intervals.
  • Naturally, the larger your event, the longer it'll take to load the data. Same goes for complex events, if your events contains 1000+ nodes it might be best to take some of the complexity out of it.

    I'd be interested to check out one of your large events, though. Could you send me one to That'd allow me to check it out and see if I can somewhat improve this.
    If you're enjoying my products, updates and support, please consider supporting me on!
  • Sure, I'd very much appreciate that, but will you need the accompanying formulas?
  • No, the event should be enough (for now).
    If you're enjoying my products, updates and support, please consider supporting me on!
  • I'll send you Three linked parts of my primary attack formula. The first part checks whether an attack was 'Blocked', 'Deflected' or 'Dodged' or if it hit. Part two will be the contingent branch following a 'Torso' hit that first checks for which part of the 'Torso' was struck and then cycles through every relevant equipment slot to see whether it has any armor equipped and whether the attack hits it or bypasses. The third follows up by checking whether the proceeding event marked an equipment part as hit, and if so runs a looping formula which expends the force of an attack until the force is expended or the armor is breached and in the latter case proceeds to the next equipment part. The formula run by this event also creates damage variables (Dinged, Chipped, Scratched, Breached etc.) for both the weapon and armor piece involved in each step. Those three parts are about as large and demanding as any in my event chain.
  • edited November 19
    Sure, I'll check it out - however, if your setup is getting too complex, you could start writing custom nodes to do those checks (or order a commission for it :D) to take stress and complexity out of the system.
    Post edited by gamingislove on
    If you're enjoying my products, updates and support, please consider supporting me on!
  • I may need to do that, but the lag seems to stem largely from a front loading issue with the individual events themselves, possibly in conjunction with the garbage collection feature. Spacing out the time after the event loads and then adding another period of wait time before it ends, I've noticed that running through the events themselves--even with all of the complex looping formula chains calculated at various stages--rarely spikes my game above 30 fps, which is not ideal, but manageable. Loading the events, on the other hand, is where it tends to spike above 15 fps. One thing I'm not yet entirely sure of is whether calling an event before proceeding causes an original event to reload, aka double load.
  • Did you get a chance to look at the events I sent you?
  • When (and where) did you sent them? I didn't get any emails with events in the last days, also didn't find anything in my junk/spam folder ...
    If you're enjoying my products, updates and support, please consider supporting me on!
  • I sent them Monday 18th to
  • Ah ... ok, got them - please send it to next time, I pretty much never check the gmail address :)
    It's not mentioned anywhere and only used if I need access to google drive, as they don't support access with alternate emails ...
    If you're enjoying my products, updates and support, please consider supporting me on!
  • I'll update the contact, thanks. Keep in mind, however, that Google is one of the pillars keeping these markets afloat and they'll have a harder time doing so without full access to all of your personal data for them to sell to the highest bidder. We all need to do our part.
Sign In or Register to comment.