User Tag List

Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 11 to 20 of 34

Thread: [Bug?] For each object in filter condition

  1. #11
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleiOS Export Module
    conceptgame's Avatar
    Join Date
    Apr 2011
    Location
    Switzerland
    Posts
    759
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BartekB View Post
    If the for each loop would iterate through all objects rather than just the selected, you would not be able to choose which objects should go through the for each loop which becomes a worse feature.
    Mixing event context (signal) and action context (slot) is also a worse feature. But it is also a more direct approach which corresponds to the natural language most of the time. No miracle here as long as it is implicit.

    Quote Originally Posted by BartekB View Post
    There is the following:

    Why should Set X Position only execute on the object that was clicked on, but the loop to execute for every object? It doesn't make sense.
    I agree and it is exactly what I said. It is better so because it is consistent for the whole engine. But it is still an implicit rule. In most cases it corresponds to the natural language: "if click on object A then move object A".
    But this is not corresponding to natural language: "if click on object A then start a loop 'Move' for each object A. For each object A by loop "Move", move object A". It is misleading. Nobody will think by reading this, that only clicked object is moving.

    Quote Originally Posted by BartekB View Post
    It was most likely not a design choice, as any action within an object will automatically use objects in the currently selected list, not the all objects list like your first coding example.
    For one, I use For each loops like functions, so it would be very annoying if I had to execute the loop through every object, not just the ones I want.
    How can you say that it is not a design choice? All languages I know gives an explicit context. If you look at the example attached, the context is changing because of this same implicit rule and it does not make sense. All other programming languages/scripts would behave differently. It is a design choice.
    I do not understand why you created the scoping extension (which is a great idea) if scoping is already ergonomic and not misleading.

    DesignChoice.mfa

  2. #12
    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
    634
    Mentioned
    13 Post(s)
    Tagged
    0 Thread(s)
    I don't find the scoping misleading at all. The extension was to expand it as currently Fusion hands you very little tools for controlling it, as well as create functions that will simply perform better being made in C++ and not events.
    Sure, the example you have given is rather weird, it is due to how selection and fast loops were implemented and is what limited what I could do with the extension.

    But it's not a mystery either, Fusion only has one selection list and the fast loop changes it, any actions afterwards will use the fastloop's selection/scope.

    I think I've not explained myself well in that last quote. What I was referring to with "most likely not a design choice" is how this for each action was added to objects. This, either intentionally or accidentally, had the effect of using the selected object list due to how all Fusion's actions work inside objects.

    Though, I know that I'm being biased here, my point of view isn't the common one. 99.999% of users won't study scope to make a scoping extension so you're right on that part, users wouldn't know what's going on without being told or with thorough testing. Suffice to say, I'm all for easier to understand scoping, and I'm looking forward to seeing Fusion 3's take on it.
    - BartekB, a.k.a Uppernate
    Join the Click Converse Discord! - https://discord.gg/7RNXFrC
    Dungeon Raiders! - Link soon™

  3. #13
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleiOS Export Module
    conceptgame's Avatar
    Join Date
    Apr 2011
    Location
    Switzerland
    Posts
    759
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BartekB View Post
    Though, I know that I'm being biased here, my point of view isn't the common one. 99.999% of users won't study scope to make a scoping extension so you're right on that part, users wouldn't know what's going on without being told or with thorough testing.

    If we all shared the same opinion, it would be sad.
    Quote Originally Posted by BartekB View Post
    Suffice to say, I'm all for easier to understand scoping, and I'm looking forward to seeing Fusion 3's take on it.
    I can only agree on this.

  4. #14
    Clicker Fusion 2.5 MacFusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    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)Firefly 3D Module (Steam)
    Phi's Avatar
    Join Date
    Jan 2010
    Location
    England
    Posts
    1,903
    Mentioned
    22 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by conceptgame View Post
    But this is not corresponding to natural language: "if click on object A then start a loop 'Move' for each object A. For each object A by loop "Move", move object A". It is misleading. Nobody will think by reading this, that only clicked object is moving.
    That's because you're applying common sense logic, not computer logic. Common sense says you can only click on one object A, and any loop should have more than one object, therefore the logical common sense thing to do is loop all objects from a condition that only selects one.
    However, if two object A's overlap, and user clicks, they have technically clicked on both with one click. A loop would run for two clicked-on objects. Or should it only be the one that's visually on top? What if it's semi-transparent, and both are visible? That depends on use scenario, so selection now can't be standardised to top-most or both.

    But if you want "on click, run loop on all objects" (not just the ones selected by conditions), you can discard the condition's scoping by running a fastloop, and in the fastloop running a foreach. Since a fastloop doesn't take along scoping, you effectively reset scoping to all objects.

  5. #15
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleiOS Export Module
    conceptgame's Avatar
    Join Date
    Apr 2011
    Location
    Switzerland
    Posts
    759
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    I must say that I did not get the point. I do not know any progamming language or framework with these implicit rules, which have nothing to do with computer logic.
    It is the strength of Clickteam's event sheet but also its weakness when it goes to scoping. It reduces verbosity for most of the intuitive cases but when it goes against natural language meaning, it is counter-productive.
    Quote Originally Posted by Phi View Post
    Since a fastloop doesn't take along scoping, you effectively reset scoping to all objects.
    It is not completely true. The scoping is only reset when you have actions with objects selected in condition before. I am not saying that this design choice is wrong, just that it is in some cases completly counter-intuitive and complex, although it should be simple and easy to catch.
    I am sure there is a way to improve this with more explicit scoping to make it clear without changing the whole design.

  6. #16
    Clicker Fusion 2.5 MacFusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    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)Firefly 3D Module (Steam)
    Phi's Avatar
    Join Date
    Jan 2010
    Location
    England
    Posts
    1,903
    Mentioned
    22 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by conceptgame View Post
    I must say that I did not get the point. I do not know any progamming language or framework with these implicit rules, which have nothing to do with computer logic.
    It is the strength of Clickteam's event sheet but also its weakness when it goes to scoping. It reduces verbosity for most of the intuitive cases but when it goes against natural language meaning, it is counter-productive.
    In most languages, this would be expressed similarly to:
    + on mouse click event:
    - select object under mouse position, store as currentObject
    - run object_click(currentObject)
    -- on object_click: currentObject.doAction();
    // action applies only to the instance(s) clicked
    -- on object_click: currentObject.ForEach(doThing()); // loop only runs for instance(s) clicked

    You would have to manually discard the currentObject and use something else, if you understand the OOP being employed here.
    In Fusion terms, to start a function that doesn't take along currentObject, that's running a fastloop
    ->> on object_click: runtime.ForEach(currentObject.type);
    ... as it doesn't pass currentObject selection.

    Quote Originally Posted by conceptgame View Post
    It is not completely true. The scoping is only reset when you have actions with objects selected in condition before. I am not saying that this design choice is wrong, just that it is in some cases completly counter-intuitive and complex, although it should be simple and easy to catch.
    I am sure there is a way to improve this with more explicit scoping to make it clear without changing the whole design.
    It's reset in a fastloop, yea, maybe you misunderstood.
    + On click on "A"
    - A: Do thing
    // applies to clicked "A"
    - Run fastloop "B"
    - On fastloop "B"
    - A: Do thing
    // applies to all "A"

  7. #17
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleiOS Export Module
    conceptgame's Avatar
    Join Date
    Apr 2011
    Location
    Switzerland
    Posts
    759
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Phi View Post
    In most languages, this would be expressed similarly to:
    + on mouse click event:
    - select object under mouse position, store as currentObject
    - run object_click(currentObject)
    -- on object_click: currentObject.doAction();
    // action applies only to the instance(s) clicked
    -- on object_click: currentObject.ForEach(doThing()); // loop only runs for instance(s) clicked

    You would have to manually discard the currentObject and use something else, if you understand the OOP being employed here.
    In Fusion terms, to start a function that doesn't take along currentObject, that's running a fastloop
    ->> on object_click: runtime.ForEach(currentObject.type);
    ... as it doesn't pass currentObject selection.
    Yes. It is what I said. You chose explicitly which object is selected with the click event and to only apply the event to it, it is a design choice. You are not forced to do it. By object_click event, you could also have:
    on object_click:
    ForEach(currentObject.type obj in scene)
    {
    obj.doThing();
    }

    Quote Originally Posted by Phi View Post
    It's reset in a fastloop, yea, maybe you misunderstood.
    Yes it seems that we were not talking about the same thing. I meant if you do something in the for each loop with a fast loop you are loosing the object selection raised by the event, which in a "standard" code won't happen because you do not want to change the event arguments of your for each loop with a local fast loop (for loop).

    ForEachAndForLoop.mfa



  8. #18
    Clicker Fusion 2.5 MacFusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    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)Firefly 3D Module (Steam)
    Phi's Avatar
    Join Date
    Jan 2010
    Location
    England
    Posts
    1,903
    Mentioned
    22 Post(s)
    Tagged
    0 Thread(s)
    Yea, there's some nonsense afoot, don't get me wrong. I highlighted it in the events, behaviour which I can imagine were retained for compatibility with MMF1, or something. Personally, I would've just added different conditions.

    You've misinterpreted again, although now I see why. I've attached what I meant:

    Attachment 29031

  9. #19
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleiOS Export Module
    conceptgame's Avatar
    Join Date
    Apr 2011
    Location
    Switzerland
    Posts
    759
    Mentioned
    14 Post(s)
    Tagged
    0 Thread(s)
    Indeed I misinterpreted you twice. It is always better to read carefully. ^^

    Actually, to answer Xenon3000 question, I think also that it is not a bug and that it was intended like this.

  10. #20
    Clicker Fusion 2.5 MacFusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    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)Firefly 3D Module (Steam)
    Phi's Avatar
    Join Date
    Jan 2010
    Location
    England
    Posts
    1,903
    Mentioned
    22 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Phi View Post
    I've attached what I meant
    Reuploading my MFA:
    ForEachAndForLoop.mfa

Page 2 of 4 FirstFirst 1 2 3 4 LastLast

Similar Threads

  1. Help with active object condition
    By fafikozoom in forum Fusion 2.5
    Replies: 5
    Last Post: 18th October 2016, 07:25 PM
  2. Flash object while [condition]
    By Hidronax in forum Multimedia Fusion 2 - Technical Support
    Replies: 2
    Last Post: 13th August 2016, 06:23 PM
  3. Replies: 2
    Last Post: 26th September 2015, 07:23 PM
  4. nearest object condition event
    By Lukiester in forum Fusion 2.5
    Replies: 4
    Last Post: 21st August 2015, 06:24 PM
  5. Graphics Filter, Audio Filter, and Transition SDK
    By kraminator in forum Extension Development
    Replies: 7
    Last Post: 27th March 2011, 08:40 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
  •