[Feature] Provide multi-level connections

[Sch1nken]

Really like this tool!

My use case is a bit special as I have some signals that sort of "bubble up" from a point and get more "generic" on the way.

Concrete example: I have a unit with (several) weapons, the weapons fire projectiles, the projectiles create a damageinstance on impact.

Signal looks like this:
Damage Instance - damage_dealt -> Projectile - damage_dealt -> Weapon - damage_dealt -> Unit - damage_dealt

The signal is a different one (just named the same, but could also have a different name like unit_damage_dealt, weapon_damage_dealt etc).

Maybe it would be possible to "follow" this signal chain visually by inspecting multipe nodes at once?
Select Unit, Select one Weapon -> You only see the the Unit->Weapon signal connection (and not other weapons).

In addition, this would also need some sort of automated updating of the nodes? Since projectiles are created on-the-fly and those create damageinstances on-the-fly as well.

Sorry for the confusing write up, I'll see if I can provide some screenshots and cleanup my messy idea :)

[yannlemos]

Hey @Sch1nken, I've given this some thought:

I think it's doable, with an important caveat.

What is doable right now

Implementing support for multiple nodes makes a lot of sense and feels like the perfect next step for the plugin. I think it's worth targeting this for version 1.2 or 1.3.

The caveat

It would be more feasible and easier to implement the situation you're describing by using debug breakpoints rather than something in real-time. After working with the GraphEdit API, I found it to be a bit finicky when updating information in real-time. I had to set up manual internal timers just to avoid certain bugs. Because of this, I think focusing on an "on-demand" approach for signal inspection makes the most sense right now.

While real-time support isn't necessarily impossible, we might discover a better solution for it in the future. For now, I’d recommend focusing on adding support for breakpoints. This would allow you to inspect signals step by step—starting from breakpoint 1, then moving to breakpoint 2, and finally breakpoint 3. You’d see the connections happen in real time, but in a controlled way where the simulation is paused so you can analyze what’s happening.

I’d also mention that I tried using this plugin before building Signal Lens: https://github.com/Ericdowney/SignalVisualizer.
It didn’t work for a lot of the scenarios I tested, and I suspect it’s because it tried to do too much, too instantly. When it worked, it significantly tanked the frame rate because signal data can be computationally heavy to parse and draw in real-time.

With that in mind, I think evolving the plugin step by step—starting with a debugging pipeline that focuses on on-demand inspection using breakpoints—feels safer and more future-proof at the moment.

Would love to hear your thoughts on this!

A first step

I think the perfect first step would be creating a good test scene based on your current project. If you’re able to create a scene that reproduces the environment of your use case and provides directions on what you’d like to happen at each point, it would be incredibly helpful. We can even create a dedicated branch for this.

[Sch1nken]

Thanks for the datailed explanation and thoughts. I'm currently somewhat busy but maybe I can provide an example project during the next week.

I think the breakpoint approach would be a valid first step. (Either breaking on signal connect/disconnect or signal emit). What I am mostly after is visualizing the following:

a) A broad overview of the scenario at hand (i.e. not necessarily a single projectile but see the whole chain from Unit->Weapon->Projectile etc at once to see if I am missing something, get a birds eye view so to speak). Though maybe something more akin to a static analysis of my code would work better here. Haven't given it much thought yet.

b) Not super important but maybe nice to have would be a way to step-by-step follow a signal (+ payload) through multiple connections. Basically start at the projectile and follow the signal as it calls back "up the stack". Since signals can't be passed like events (or exceptions in other languages), my setup right now is something like this:
Projectile -> emits "unit hit" -> weapon receives signal -> calls corresponding Callable -> emits their own "unit hit" signal -> Unit receives signal -> calls corresponding Callable -> etc etc....

Maybe a way to define a "path" through several signals would be a solution for this scenario. Like stepping through a debugger but ignoring all other signals the user is not interested in (somewhat like breakpoints but not completely).

I'll give this some more in depth thoughts and will try to setup an example project :)