User Tag List

Results 1 to 10 of 10

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

  1. #1
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)

    Join Date
    Feb 2015
    Posts
    49
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

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

    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.

  2. #2
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    Volnaiskra's Avatar
    Join Date
    Jan 2014
    Location
    www.sprykegame.com
    Posts
    2,580
    Mentioned
    133 Post(s)
    Tagged
    0 Thread(s)
    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:


  3. #3
    Clicker Fusion 2.5 (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)

    Join Date
    Feb 2015
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Musta;
    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.

  4. #4
    Clickteam Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleUniversal Windows Platform Export ModuleInstall Creator Pro
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    BartekB's Avatar
    Join Date
    Aug 2013
    Posts
    667
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stiggits View Post
    @Musta;
    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, a.k.a Uppernate
    Join the Click Converse Discord! - https://discord.gg/R3WuvF3mHr

  5. #5
    Clicker Fusion 2.5 Developer

    Join Date
    Jul 2008
    Location
    UK
    Posts
    1,397
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    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).

  6. #6
    Clicker Multimedia Fusion 2SWF Export Module

    Join Date
    Sep 2006
    Posts
    1,544
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MuddyMole View Post
    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.

  7. #7
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    Volnaiskra's Avatar
    Join Date
    Jan 2014
    Location
    www.sprykegame.com
    Posts
    2,580
    Mentioned
    133 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #8
    Clickteam Clickteam

    Join Date
    Jun 2006
    Location
    France
    Posts
    14,047
    Mentioned
    279 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Volnaiskra View Post
    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).

  9. #9
    Clicker Multimedia Fusion 2SWF Export Module

    Join Date
    Sep 2006
    Posts
    1,544
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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

  10. #10
    Clicker Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Fusion 2.5+ DLC (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    Volnaiskra's Avatar
    Join Date
    Jan 2014
    Location
    www.sprykegame.com
    Posts
    2,580
    Mentioned
    133 Post(s)
    Tagged
    0 Thread(s)
    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.

Similar Threads

  1. Actions applying to entire group/none of group
    By DJT4NN3R in forum Multimedia Fusion 2 - Technical Support
    Replies: 2
    Last Post: 24th July 2015, 08:17 PM
  2. Fact vs. Fiction. Getting the details straight before I beginning a large project.
    By ratty in forum Multimedia Fusion 2 - Technical Support
    Replies: 6
    Last Post: 9th June 2012, 05:37 PM
  3. Disabled Menu Items?
    By LB in forum Extension Development
    Replies: 6
    Last Post: 15th October 2010, 12:32 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •