Simplify redudancies from Trigger Once limitations

0 favourites
  • 8 posts
From the Asset Store
Change the size and position of everything without calculating anything!
  • Is there a way to simplify the below so I don't have to create two huge event blocks? It seems redundant, but I can't think of how to make it simpler.

    <font face="Courier New, Courier, mono">Event 1


    |[Condition A ]:[Action A]|

    |[Condition B ]:          |

    |[Condition C ]:          |

    |[Condition D ]:          |

    |[Condition E ]:          |

    |[Trigger Once]:          |


    Event 2


    |[Condition A ]:[Action B]|

    |[Condition B ]:[Action C]|

    |[Condition C ]:[Action D]|

    |[Condition D ]:[Action E]|

    |[Condition E ]:[Action F]|


    Both event blocks have the exact same Conditions, except Event 1 triggers once on the first time with unique [Action A]

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • If I'm understanding this right, the first event block handles the first occurrence of those conditions, and the second block handles all subsequent occurrences of those conditions. Is that correct?

    If so, could you get by with setting a Boolean from ON to OFF when these conditions are run, and include Action A in a sub-event of Condition A that only runs when this Boolean is ON? Likewise, include Action B in another sub-event for Condition A that only runs when the Boolean is OFF. Alternatively, use the new 'else' logic so you only have to test for the Boolean once. Does that work? And let me know if I need to elaborate.

  • That's correct Dalal. For some reason I was hoping there would be a more elegant solution than creating a variable every time I have to do this. If not, it's okay, my curiosity was just getting the better of me.

    Thanks for your response!

  • A variable-less option might be to have a 'Trigger Once' 'Else' structure as sub-events for each condition. Still a bit repetitive, but now you only have one event block, have to define the conditions only once, and use no variables.

    <font face="Courier New, Courier, mono">


    |[Condition A ]:              |

    |    [Trigger-Once]:[Action A]|

    |    [Else]        :[Action B]|

    |[Condition B ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action C]|

    |[Condition C ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action D]|

    |[Condition D ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action E]|

    |[Condition E ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action F]|



    How's that?

  • Perhaps I'm misunderstanding, but how I generally do it is:


    5 conditions | actions to be performed each tick

         sub event:

         trigger once | actions to be performed once

  • Dalal - Else doesn't really make much sense following a 'trigger once'...

    Arima has the best solution - simply put 'trigger once' in a subevent. However the action will be run after the other actions instead of before. If that makes a difference, you can use a blank subevent after 'trigger once' and move your actions there.

  • Thanks all. That works perfectly.

    Under that logic, a solo "Trigger Once" at the top level basically functions the same as a "On Start of Layout" then? (wish I could Construct at work)

  • Mulkaccino, oops, I actually misunderstood the question. I thought you wanted 'on A do B ONLY', and for all subsequent continuous occurrences of A 'do C ONLY'. In addition, I somehow thought you wanted separate actions for each condition. Sorry for the misunderstanding!

    Ashley, I'm curious to know why Else does not make sense after 'Trigger Once'? I thought that Else fires if the previous condition did not. Trigger Once will only fire once in a row, and Else will fire every OTHER time, right? So if you wanted something totally different to happened the first time in a series of repeated actions, this seems to me a viable solution. But perhaps there's logic better suited for this circumstance that I overlooked.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)