Sometimes I find the App trigger mechanism a bit much. For simple triggers, it works great. I have one case, though, where I’m building a state machine. There are 4 states, and one state variable (a number). Each time you get a trigger it figures out what to do with the outer layer of “IF current state ==2 THEN …” and then makes some decisions on what state to advanced to next based on other variables.
What I end up with is something that’s kind of long. It doesn’t all fit on one screen, it’s a little hard to read, and very tedious to initially enter.
It works great, but in a lot of ways it really goes against the philosophy of no-code / low-code development. What’s important to realize though is that the no-code approach is a little frustrating for more sophisticated users who realize that they can replace a complicated muilti-part trigger with a few, readable lines of code.
I appreciate that Tulip might not want some of this. I get the concerns, in particular, about impacts on performance and stability. My counterargument, though, is that you can always hose yourself somehow, if I do something that fork-bombs the player that’s kind of my problem. I think the other half of the concern is when that happens someone will call Tulip support demanding answers. I get the concern and sensitivity to things like that.
Regardless … this is all just food for thought, I’m curious what everyone else is doing out there.