User Tag List

Page 2 of 2 FirstFirst 1 2
Results 11 to 15 of 15

Thread: 2.5+ Parent & Child events: When to use it?

  1. #11
    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
    1,954
    Mentioned
    51 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Julian82 View Post
    I think deactivation in the middle of a set of grouped events even closes the group immediately, allowing to skip the remaining part of events.
    Yes, I can confirm this. I use this method extensively in my code (and my performance went up noticeably when i started using it!)


    I totally agree. For larger chunks, the group method has many advantages over child events. Though child events are pretty good for small chunks with 3 or 4 events.

  2. #12
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleiOS Export Module
    conceptgame's Avatar
    Join Date
    Apr 2011
    Location
    Switzerland
    Posts
    737
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Volnaiskra View Post
    Yes, I can confirm this. I use this method extensively in my code (and my performance went up noticeably when i started using it!)


    I totally agree. For larger chunks, the group method has many advantages over child events. Though child events are pretty good for small chunks with 3 or 4 events.
    I do not completely understand why the group method has many advantages over child events. Using group method won't make your code more readable. marbenx' examples are a good illustration of this.
    Moreover, repeating the same conditions will automatically make the engine evaluating several times the same condition. It will reduce your performance (except if optimisation is made by compiler).
    And finally, using the group method requires not to forget to deactivate the event group in the proper context. In other words, it needs to handle 2 actions (activating and deactivating) instead of 1.
    In contrary to child events where the context is given in situ and only in 1 event line.
    For example, for the method group:
    If X("Player") < 10 --> Activate Group "Player Lost"
    If X("Player") >= 10 --> Deactivate Group "Player Lost"
    ...
    Player Lost Group
    --- All your events ---
    compared to the following for child events:
    If X("Player") < 10 -->
    --- All your nested events ---

    The only advantage of groups that I see is the possibility to gather together similar events, using an object oriented or functional approach. Which is what groups are meant for, I suppose.

  3. #13
    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
    1,954
    Mentioned
    51 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by conceptgame View Post
    Using group method won't make your code more readable.
    IMO the group method is definitely more readable. For one thing, you can collapse them, which makes all the code around them more readable. For another, it doesn't have "new condition" actions awkwardly sandwiched between parent and children.

    Finally, child events visually divorce conditions from actions, which is especially a readability problem if you scroll down and the parent goes off-screen. This is true also of groups, but the problem is mitigated somewhat by the more overt visual hierarchy of a group, and the fact that you can close it (so you're less likely to look at an event without remembering its context, because if you're looking at the event, it probably means you just opened its group on purpose)



    Moreover, repeating the same conditions will automatically make the engine evaluating several times the same condition. It will reduce your performance (except if optimisation is made by compiler).
    You may have misunderstood what we mean when we refer to the 'group method'. The whole point of this method is to avoid repeating conditions, just like child events. It's basically another way of doing child events, which we used before true child events were possible. For example, here I've avoided repeating the condition if onGround = 1:




    And on the topic of performance, some testing a couple of us did in another thread showed child events to bring a performance decrease...at least when combined with fastloops. This is probably something that can be fixed by Yves, but I don't believe it has been fixed yet.


    And finally, using the group method requires not to forget to deactivate the event group in the proper context. In other words, it needs to handle 2 actions (activating and deactivating) instead of 1.
    In contrary to child events where the context is given in situ and only in 1 event line.
    For example, for the method group:
    If X("Player") < 10 --> Activate Group "Player Lost"
    If X("Player") >= 10 --> Deactivate Group "Player Lost"
    ...
    Player Lost Group
    --- All your events ---
    compared to the following for child events:
    If X("Player") < 10 -->
    --- All your nested events ---
    No, you don't do it that way. Or, at least, I wouldn't. This is how I do it:

    If X("Player") < 10 --> Activate Group "Player Lost"
    [[[Player Lost Group]]]
    [[[--- All your events ---]]]
    [[[----Always Deactivate Group "Player Lost"]]]


    So, the group comes immediately after the 'parent' condition. And the group is immediately closed once its events are processed. Structurally and logically, this is near-identical to how true child events work.


    The only advantage of groups that I see is the possibility to gather together similar events........
    Really? That's the only advantage you see? What about the one that we were just discussing just before you posted? That I'm in fact discussing in the very post of mine that you quoted Namely, that you can abort a group at will, whereas you can't with a child event.

    In some cases, you will want all child events to be checked each time. But sometimes, there will be a child event that, if true, makes the others irrelevant. In this case, you can close a group and force Fusion to ignore all subsequent child events, which can benefit performance.

    Another advantage of the group method is that you can use green events in there. So, you can call a fastloop in a group, but not in a child event. Also, dragging an event with a green condition into a child event flat out doesn't work, even if it's just never, which I've found to be an annoyance at times.

    Yet another advantage of the group method: you can set them up with hotkeys. I have a 15-button mouse, and I have some of those buttons mapped to insert condition, insert action, insert group, and home and end (which move between conditions and actions in the event list editor). Because of this, my workflow is quite fast and friction-free. But if I want to create a child condition, no such luck: I'm forced to do it the slow way, by right clicking and selecting from a drop-down menu.

    Finally, I really don't like the process of converting regular events into parent/child events. You can't just ctrl-drag an event in another to nest it, or something like that. Instead, you have to create a 'fake' child event, choose a 'fake' condition, then delete the fake event. Only then you end up with a little indent into which you can drag other events. This isn't something that's exactly better in the group method (which is clunky in its own way), but I thought I'd mention it too.


    To be clear: I want to use child events. I love the concept of them, which is why I've been using the group method workaround for years. And so I was excited that true child events were coming to town, as I figured that they'd take them to the next level and/or make them easier to use. The group method workaround is just that: a workaround. It's somewhat time-consuming to set up, and it's not 100% elegant.

    But so far, child events haven't offered me much (if anything) that I wasn't already doing with groups, while bringing their own disadvantages. To reiterate, those disadvantages are: readability, no collapsability, questionable performance at times, no hotkey support, no green conditions, no interruptability. But, I hope (and believe) that they'll eventually be tweaked by CT to make them better. And, as I've said elsewhere, I'm not particularly bothered, because the 2.5+ DLC has 100 other things that are absolutely superb!

  4. #14
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleiOS Export Module
    conceptgame's Avatar
    Join Date
    Apr 2011
    Location
    Switzerland
    Posts
    737
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Volnaiskra View Post

    To be clear: I want to use child events. I love the concept of them, which is why I've been using the group method workaround for years. And so I was excited that true child events were coming to town, as I figured that they'd take them to the next level and/or make them easier to use. The group method workaround is just that: a workaround. It's somewhat time-consuming to set up, and it's not 100% elegant.

    But so far, child events haven't offered me much (if anything) that I wasn't already doing with groups, while bringing their own disadvantages. To reiterate, those disadvantages are: readability, no collapsability, questionable performance at times, no hotkey support, no green conditions, no interruptability. But, I hope (and believe) that they'll eventually be tweaked by CT to make them better. And, as I've said elsewhere, I'm not particularly bothered, because the 2.5+ DLC has 100 other things that are absolutely superb!
    I have been using groups in a similar way for years so I do not mean at all that it does not makes sense to use group to isolate features/function.

    I agree with almost everything. Collapsing and interruptability is part of the features I meant before by "to gather together similar events, using an object oriented or functional approach".None of these features are incompatible with "nested if" or child events. You can use them together, each for what they are meant for.
    Using an implicit rule by using additional events/actions before and after the group is what bother me. It makes your code less readable and reusable because it requires to know this rule, on top of all other implicit rules that the game engine itself already has (green and red conditions for example). Since we did not have any child events before, I can fully understand the workaround.
    But now it should be the right way to do when we need a parent condition, like any programming language. Groups and child events are complementary and not alternatives.

    But with the arguments you gave above, it seems that they need improvements. It does not mean that they are not useful for their specific purpose.

  5. #15
    Forum Moderator Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleMac Export Module
    AndyH's Avatar
    Join Date
    Jun 2006
    Location
    UK
    Posts
    1,444
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I think like all new features it takes some time to get used to them. When best to use and why.

    I do agree they really need a code folding option in the future as they are very vertical in nature

    I've also been using groups in much the same way, it works very well and feels the right approach as it can remove a number of unneeded condition tests each game loop.

    I have found child events to be very welcome for specific conditions and I seem to have settled on around two or three child events (sometimes more) as a good fit so far. A recent example I had an event that did something, but then two child events applying a different action depending upon the direction of the object, it worked out nicely and created some very readable events. So I'm using them sparingly at the moment, rather than using them just because I can.

    Creating a new child event is a bit awkward at times. Not ideal, but the easiest way I have found is to add an Always child condition and then either right click and replace or drag and drop another event (with the key modifiers to force a copy if necessary) over the always child rather than deleting.

    I used to have a lot of shortcut keys defined some years ago but lost them at some point and never set up more than a couple since then. I like how you have done it and sounds very productive with the extra mouse buttons. Hopefully we will get something to insert a blank child event in an update, along with child event folding
    Andy H @ ovine.net
    Awful Jokes - a new cartoon every day: http://awful.ovine.net/
    Ovine's games: http://www.ovine.net

Page 2 of 2 FirstFirst 1 2

Similar Threads

  1. Replies: 2
    Last Post: 25th January 2017, 02:03 AM
  2. Parent Child Help please
    By Nicholas Martin in forum Fusion 2.5
    Replies: 11
    Last Post: 15th October 2016, 11:13 PM
  3. Parent-Child?
    By xhunterko in forum File Archive
    Replies: 2
    Last Post: 6th December 2009, 08:18 PM
  4. 2-parent, 1-child creation
    By Ultimo240 in forum Multimedia Fusion 2 - Technical Support
    Replies: 3
    Last Post: 25th November 2009, 10:26 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
  •