+3
Planned

Trigger events with popup menu

Zefugi 3 years ago updated by Lazlo Bonin (Lead Developer) 1 year ago 3

When laying out my logic, I use state machines with no flow logic, and I click through them at runtime (ForceEnter/ForceExit) to validate that my logic is working, before building the flow macros that bring the machines to life.

I'd like to see the same option for custom and unity events. Right click->Trigger event. This would help in the design phase and make some debugging tasks more fluent.

Maybe the logical/faster implementation would be an option at runtime on all flowable nodes to right-click and select Run/Execute/Trigger or something like that.

Bolt Version:
Unity Version:
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):

Sounds like you want a Debug Console which accepts a function (in this case, one for each type of event, be it a Unity Event, or a CustomEvent), and an argument for the Trigger Id and parameter array, correct?


So for example, you have a CustomEvent.Trigger Unit with a TriggerId of foo, and no parameters, so you would manually force trigger that Unit by typing into the console that CustomEvent.Trigger(foo)?


It's an interesting idea, and one that I've actually started implementing into my projects using a Debug Console asset from the asset store (that way I can define and trigger many more functions than just events).


May not be too difficult to create one, honestly, for just events. What you need is an in-game canvas, with a text field, and a button to invoke that entered command. You could simplify it further by using a dropdown in the canvas to select the type of event, and then use the text field to enter in your TriggerId and your array of parameters.


The neat thing about this tactic of implementation is that you could use it in a build project as well.


I may actually consider implementing this into my event subscription plugin, when I get some time to go back and start working on it again. So thanks for that idea! :)

A console is not actually what I suggest. A picture is worth a thousand words, so let me throw down 2000 words worth of images. The first one is what we got now. The second one is what I would like implemented (everything is at runtime)





Planned

That's a very interesting idea, and would be very simple to implement! I'll try to cram it in for v.1.4.

Basically, the context menu would be on the control port, not on the unit itself (because it would be ambiguous which control port you want to trigger).