Allow Transition nodes to be triggered via signals or code

[mixemer]

I am currently working on a game using your framework and I would like to request a feature that allows Transition nodes to be called from code or triggered by signals to start a transition.

In my project, I need to allow a signal from a component to trigger a transition, and I want to be able to initiate the transition from within the editor using my custom signals rather than solely relying on the state machine's built-in functionality.

I have implemented the following solution in the transition.gd script. This method allows signals to be connected to a transition. When the signal is emitted, it calls the parent node (which in turn calls the state chart to start the transition). This ensures we are still going through the proper flow to trigger a transition.

func _take() -> void:
	var parent_state: Node = get_parent()
	if parent_state == null or not (parent_state is StateChartState):
		push_error("Transitions must be children of states.")
		return
	parent_state._run_transition(self)

I want to get your thoughts on this solution. Does this approach fit the intended usage of Transition nodes?

[derkork]

Could you give some more insights on what you need this solution for? E.g. what is the underlying problem you're trying to solve with this? Couldn't your component just send an event to the state chart to trigger this transition?

[mixemer]

There is no problem really. This is just for convenience.
As you said, I can send an even to the state chart to trigger a transition. But I want to use a signal to trigger it instead of code. This way, the node/code does not need to know about the state chart, and we can easily hook it in the editor with signals.

Example: one of my node/code exposes a signal, and when that signal is emitted, I want to trigger a transition. Having a function in transition.gd I can just hook that signal to the function.

[derkork]

I think I understand this better now, thank you for explaining it to me! One thing I'm not quite sure about is how this would work with delayed transitions. Right now once a transition, which has a delay, is run, the transition will be enqueued. It can be replaced later by another transition while it is pending. I imagine this can be confusing behaviour if one calls transition.take() (or something along these lines) and then the transition would just be enqueued. So maybe the API could look like:

## transition.gd
func take(immediately:bool = true):
   .. 

This would give the caller the flexibility to decide what happens, while at the same time doing the thing that most people would expect (I hope 😉). So calling it with true (the default) will bypass any delay that might be set on the transition, while calling it with false will play out any existing delay before actually taking the transition. What do you think?

[mixemer]

That is so true, it might be confusing if the transition enqueued and executed later. I like your solution :). I will work on it and have a PR for you this week.

[derkork]

Released with 0.18.0. Thanks for submitting the PR! I have added C# integration, docs and a few automated tests and seems to be working nicely.

[mixemer]

@derkork Thank you for taking time to review my PR. Going to start using the new release!