I find this unacceptable. You can simply add a “trigger once” condition block to the “advanced” conditions - to trigger it every time when it is true- only one time. I know I know, you may say- Like construct2 does it right? Yes, it does it that way. But if you think about it- this saves a lot of extra work and over-complication of code.
I dont mind doing it for specific things - like states that must be tracked. But if you do it everytime you want to trigger a chain of events once, you end up with a lot of variables.
Overcomplicating
Ok its not totally unacceptable. Not a game breaker. But you have to admit that having a trigger once option for the condition would be nice
What I find totally unacceptable is that the only way I found to implement this is to add a condition that must be placed at the end of the condition list to work properly… And I’m afraid lots of users would get stuck because they put the condition in the middle or even on the beginning on the condition list.
How does it work in Construct 2 ? Can the condition be placed at any position?
Maybe I could tweak the events editor to force the condition to be put at the end of a condition list, but I’m not fond of such tweaks and that’s why it was not implemented for now.
I am not entirely sure how it works internally, but to the end user this is what it does:
The event sheet sort of forces “trigger once” to be the last condition in a conditions container. If it is not- then it colors it in red- making it disabled.
Another thing you can do:
If you run the game, it wont run and a dialog will tell you that trigger once should be moved to the bottom. It’s a small price to pay for the benefits it brings to speeding up workflow.
I have to admit that the first thing that struck me is that I need to create more logic in gamedevelop in order to trigger once - a new variable,a new condition and a new action. 3 blocks. Trigger once does it in one block.
Trigger once would be the condition and it would still require an actions, so it reduces three blocks down to two. I think however, there is a danger in bloating the software horribly if something like this is added. I mean, if you start adding trigger once blocks when you need only one variable declaring to make a normal event into a trigger once, where do you draw the line for what should be available to instantly put it and what you need to do one or two steps to do yourself? At the moment, GD has a pretty good way for doing this and many other things and I think there are much better feature requests than this one that would address more difficult problems and cause less bloating of software.
Nevertheless, I agree that it is also annoying to use variables when you want something to be trigger only once in a row, so maybe I could add it and ensure that the condition is put at the end of the condition list.
But I also agree with Mats that a dialog would be annoying as hell, this is something I absolutely do not want in GD, lots of users are afraid of “errors dialog boxes” and no error should be triggered in any condition when launching a preview
In the same way, coloring is better but annoying.
I think the better solution would be to have the condition automatically added at the end and it would be moved again to the end if you add other conditions.
This way it would be a nice and not error-prone feature ( At least I think )
Do you agree or have you other ideas?
I think that your solution is the best design. Always adding it at the end of a condition block is a very clean way to do it.
Yeah the pop up is annoying. In construct2 you get a pop up if you create an event using the “else” condition block in the wrong place.
I am happy to hear that this is on the map. It will simplify things for me at least. I use the trigger once block a lot in construct2 and keep the variables only for things that I want the game to keep a track of. Boolean variables are handy that way- but i guess an engine doesnt really need them to be useable - one can use 0 and 1 as a switch just as well.
I’ve implemented this condition for the next version.
Would make sense, but it would be hard to use and event type are more designed to be analog to classic programming language control flow instructions (While, if, for…) whereas the new “Trigger once” condition is just like using a hidden variable to prevent something happening for more than once while other conditions are true
In construct2 trigger once is in the same class as the “on collision” and all the condition blocks with the green arrow icon. The green arrow signifies that it is a condition that will trigger it’s events only one time when it has been met. Of course that does not stop it from being executed each time the conditions it goes with have been met.
The video I posted earlier explains their design logic pretty well.
I agree that it is kind of strange at first, as it does seem like something that is an option to execute a chain of events, rather than a condition to execute them.
Having the UI force it always be at the bottom of a condition cell would help distinguish it from the other conditions.
well, it really is up to 4ian to decide on the design. I personally like his suggestion- forcing “trigger once” to be at the bottom on the condition block.
It’s just the way my brain reads things - it seems clearer.
Now, if you do like to put it on top of everything, you can call it
“do once every time conditions are met”
I like the word “trigger” more than “do” personally, but it does sound like the one used in construct2. Is that a good thing or a bad thing? I think that if you wanna lure construct2 users to gamedevelop, having things named in similar ways is a good thing.
I dont think anyone would judge you for it, as gamedevelop already has some features that make it different.
)