Is there any way to save the fact that a group has been disabled?

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
  • I'm not actually using this method to disable things like events, I always set AVs that can be saved in an Array.

    But I was laying in bed last night, I remember seeing somewhere else a post where person new to Fusion 2.5 said he disables Groups in an event when something is done, like say you run a cutscene and it's over so you just disable the group its in an forget about it.

    I thought maybe that's a bad idea, I've only ever put stuff in Groups just as a organization thing, like commenting your code. But who knows, maybe you can save that info in an array or something? I have no idea.

  • I don't think you can do it directly. But it would be easy enough to do with altVals (or flags). Just do something like this, and then the altVals will tell you whether the group is open or closed:

    Please login to see this picture.

    Please login to see this link.
    My Fusion Tools: Please login to see this link. | Please login to see this link. | Please login to see this link.

  • [MENTION]Musta[/MENTION]

    Quote

    I've only ever put stuff in Groups just as a organization thing

    If you mean you never deactivate groups, you are missing out on something important !
    Fusion reads and checks every line of code every frame( 60xsec),
    but if a group is deactivated, it skips it completely.

    Eg,
    1. if button clicked--------turn flag1 on
    2. if button clicked--------add 10 to altvalA
    3. if flag1 on--------------do something
    4. if flag1 on & A=10-----do something
    5. if flag1 on & A=20-----do something different

    above, every frame fusion checks all 5 lines,

    1. if button clicked--------activate group1
    2. Group1 (inactive at start)
    __3. if button clicked--------turn flag1 on
    __4. if button clicked--------add 10 to altvalA
    __5. if flag1 on--------------do something
    __6. if flag1 on & A=10-----do something
    __7. if flag1 on & A=20-----do something different
    __8. on group activation----deactivate group1

    this time fusion only checks line 1 every frame, and only checks the others when the group is activated
    by the button click.

    this can make a BIG difference to the speed your app runs.

  • [MENTION]Musta[/MENTION]
    Fusion reads and checks every line of code every frame( 60xsec)

    When Fusion goes through each event, it ignores events starting with green (e.g. user clicked mouse button), because they're triggered/called from somewhere else. So they're preferred over other events (always/comparisons).

    - BartekB

    Join the Click Converse Discord! - Please login to see this link.

  • Clickteam may well have fixed this issue by now (I haven't been keeping up), but back in the day, the main way groups affected performance was when fastloops were involved. As already stated, on every event loop, Fusion cycles through the event list - but that's only 60 times per second, and probably not really enough to affect performance (compared to using a flag to indicate if an event is "enabled").
    However, on every loop of a fastloop, Fusion also searches through the event list, looking for events with the "On loop" condition and the correct loop ID - and if you've got a loop that repeats a few hundred times, now it's not 60 times per second, but 12,000+ times per second, which actually can make a big difference.
    The solution is to split your events in to groups, with fastloop events in their own separate groups, and then when you run a fastloop, you temporarily disable every other group apart from that one.

    As for the green "immediate" events, the only ones I use as such are "On loop" events. The rest I move lower down the condition list - they'll still work just fine, but it forces Fusion to handle them in the order they're listed, which makes for fewer bugs (if it's the only condition, I'll add an "always" condition and put that first).

  • Clickteam may well have fixed this issue by now (I haven't been keeping up), but back in the day, the main way groups affected performance was when fastloops were involved. As already stated, on every event loop, Fusion cycles through the event list - but that's only 60 times per second, and probably not really enough to affect performance (compared to using a flag to indicate if an event is "enabled").
    However, on every loop of a fastloop, Fusion also searches through the event list, looking for events with the "On loop" condition and the correct loop ID - and if you've got a loop that repeats a few hundred times, now it's not 60 times per second, but 12,000+ times per second, which actually can make a big difference.
    The solution is to split your events in to groups, with fastloop events in their own separate groups, and then when you run a fastloop, you temporarily disable every other group apart from that one.

    As for the green "immediate" events, the only ones I use as such are "On loop" events. The rest I move lower down the condition list - they'll still work just fine, but it forces Fusion to handle them in the order they're listed, which makes for fewer bugs (if it's the only condition, I'll add an "always" condition and put that first).


    Its my understanding that one of the more recent updates made fastloops far more efficient and now directly jump to any fast loop with an uninterpreted string as their index, but still evaluate those with interpreted strings as their index. IE, if you have a loop named "Alice", the runtime will ignore all other loop events and only 'see' the events with the immediate condition of a loop named "Alice". But if you have an event with a loop named "Alice + str$(global value a)", it will need to evaluate that on any loop being run, and will always be 'seen' unless its hidden inside a closed event group.

    I might be wrong about all that, but I think that was in one of the patchnotes.

  • If so, it'd be nice if they did that with forEach loops too. I recently noticed that forEach loops with longer (though still uninterpreted) names take a little more performance to run. Which makes me think they don't just default to an index internally.

    Please login to see this link.
    My Fusion Tools: Please login to see this link. | Please login to see this link. | Please login to see this link.

  • If so, it'd be nice if they did that with forEach loops too. I recently noticed that forEach loops with longer (though still uninterpreted) names take a little more performance to run. Which makes me think they don't just default to an index internally.

    They default to an index internally, however as it was not as easy to optimize as normal fatloops and we needed a fast fix, the number of optimized foreach loops is limited (about 35 different names iirc). Maybe we can improve this in a future patch.

    PS: I'm talking about the internal On Each loops, not about the old For Each object that is not optimized.

    About fast loops, the optimization was done in 2.5 however it was only partial, we've fixed a bug in the latest patch (when a loop has several Start Loop actions only the first one was optimized), and in the next update we've fixed another case that was not optimized for some reason (a Start Loop action with a variable expression was not optimized even if the On Loop conditions use constant names).

    Edited once, last by Yves (March 21, 2021 at 9:30 AM).

  • I'd very much appreciate if foreach loops could be extended to a nice large number if its not a big hassle in a future patch, I've got ~300 in my project so far, not sure how many are duplicates but that's what a ctrl+f popped up. Thanks for the previous fix too, all my testing showed optimized loops running much more efficiently

  • Yeah, I guess the more of them you have in your MFA, the more the optimisation is needed. So an extended limit would be nice.

    Thanks for your tireless improvements, as always, Yves.

    Please login to see this link.
    My Fusion Tools: Please login to see this link. | Please login to see this link. | Please login to see this link.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!