SignalVisualizer draws Godot's signal graph instead of guessing at it

The problem is Godot's signal web is invisible

SignalVisualizer is a plugin for Godot 4.x that displays the current scene and autoload signal connections in an easy to read graph and tree dock. The problem it addresses is not a bug but an absence. Godot's signal system is the backbone of how scenes talk to each other, and a growing project ends up with connections declared in scene files, in autoloads, and in code, with no built-in view that shows the whole picture at once. When a signal stops arriving, the usual procedure is to open the scene file, read the connection list, and hope the culprit is in that file rather than in an autoload three scenes away. The plugin turns that into a visual question. It is published on the Godot Asset Library, it is MIT licensed, and the repository carries a Demos/ directory along with a project.godot, so it is a real Godot project rather than a loose collection of scripts.

Only persistent connections and no @-prefixed nodes

The mechanism is straightforward and the restrictions are explicit. Signal Visualizer creates the signal graph by mapping the persisted signal connections in the current scene and the project autoloads in the Godot editor, and the bottom dock uses the built-in GraphEdit and Tree nodes to display the result. Two filters decide what appears. Only signals carrying the CONNECT_PERSIST flag are shown, and every node whose name begins with @ is ignored. The first filter is the important one, because CONNECT_PERSIST is what marks a connection as stored in the scene file rather than established at runtime. So the graph is a picture of your saved scene wiring and nothing else. The @ exclusion removes editor-internal nodes that would otherwise clutter the view. The practical consequence is that the graph is trustworthy for what it covers, which is exactly the connections that a human hand edited in the editor, and blind to the ones your code creates in an _ready function.

Generating the graph and rearranging it

The workflow in the editor is short. With a scene open you open the bottom dock, and in the Signal Visualizer toolbar you click Generate Graph. There is also an Arrange Nodes toggle, which enables and disables automatic node arrangement when generating the graph, and when it is enabled the GraphEdit arrange_nodes() function is called once all the graph nodes are generated. That call is the useful part when a graph has a few dozen edges, because hand positioning is otherwise tedious, and it is also the risky part, since the troubleshooting section says that if Godot freezes and crashes when clicking Generate Graph you should toggle Arrange Nodes off and try again. The plugin also offers an Open button next to a signal's connected function that opens the corresponding source file at the function's line number. That is the feature that turns the graph from a picture into a navigation tool, because a graph that can only be looked at is a diagram, while a graph that takes you to the line of code that handles the signal is a debugging aid.

Reading the two formats in the graph and the tree

The same information appears in two shapes, and the format convention is documented so you can read either one. An outgoing signal is written as a signal pointing to a connected node, and an incoming signal is written as the signal, the double colon, and the callable method.

Signal -> Connected Node

Signal::Callable Method

The distinction matters more than it looks. An outgoing entry tells you who a node notifies, which is the direction you care about when you want to know what a button press will cause. An incoming entry tells you what a node listens to, which is the direction you care about when you want to know why a value changed, because you can trace the chain backwards from the symptom to the source. Having both in the same view, in the same notation, is what makes the graph navigable. A tree dock sits alongside the graph with the same content, which is the right choice when a graph has a hundred nodes, since a tree can be expanded selectively and searched by eye while a graph has to be panned. The documentation for the plugin also has screenshots of both cases, one showing a player node with outgoing signals and one showing a game UI node with incoming ones.

The debugger panel logs what actually fired

The second half of the plugin is the Signal Debugger, and it solves the problem the graph cannot. The Signal Debugger connects to a running scene instance to allow automatic logging of live signal executions, which includes signals connected through code at runtime, and it removes the need to add print statements to your own code when debugging signals. The panel has two main components. The first is the signal tree, where all relevant scene and autoload signals are displayed, similar to the visualizer. The second is the signal log output, the main body of the panel, containing all log messages for signals that have been triggered in the scene. The interaction is explicit: with the game scene running you open the panel under the Debugger dock, click Start to begin signal logging, and the tree appears with a started message in the log output. Every relevant signal then logs a timestamp, the node that fired the signal, and the signal name. Clicking Stop disconnects from all relevant signals, and closing the scene does the same. So the two tools cover different halves of the problem, with the graph showing what is wired and the debugger showing what is live, including the runtime connections the graph cannot see.

Installing it, from the Asset Library or by hand

Installation is either one click or three steps, and the README gives both. From the Asset Library you open Godot's AssetLib tab, search for SignalVisualizer, and download and install. The manual route is to download the repository, copy the addons/SignalVisualizer directory into your project's res://addons/ directory, and then enable the plugin under Project Settings, Plugins. Once enabled, the Signal Visualizer tab appears in the bottom dock region, and the Signal Debugger tab shows up as a new panel in the Debugger dock, so the two halves of the plugin land in different places in the editor and it is worth knowing where each one is before you go looking. The repository root confirms the layout, with the addons/ directory holding the plugin, Demos/ holding a demo project, plus images/ and an icon.svg. The plugin is on the Asset Library as asset 2067, and the author also runs a YouTube channel with a visualization demo of the graph.

Where SignalVisualizer falls short

The main limitation is the one the CONNECT_PERSIST filter implies. Signals connected in code at runtime are invisible in the graph, and in a project that wires most of its behaviour dynamically, the graph shows a fraction of the real surface. The debugger covers that gap, but the debugger is a runtime tool, so it can only show what fires while the game is running, and only after you know where to look. The second limitation is scale, and the README is candid about it: a freeze and a crash on Generate Graph is a documented possibility with the fix being to turn Arrange Nodes off, which means a large graph with many nodes becomes a manual layout job. The third is version coupling. The plugin targets Godot 4.x, and the release history is uneven, with 1.8.0 released on 2026-07-23 after 1.7.0 and 1.6.0 in May 2024, so the two year gap suggests releases come when a Godot change requires it rather than on a schedule, and a plugin that has not been touched since July 2026 may not keep up with a new Godot 4 point release. The fourth is scope. This is a visualisation and logging tool for signals, and it says nothing about the other half of Godot's message passing, and a graph of connections will not tell you whether the data a signal passes at runtime is correct.

Editorial conclusion

Adopt SignalVisualizer if you maintain a Godot 4 project with a wide signal surface, since a graph of who listens to what and a runtime log of what actually fires will save you reading code. Skip it if your signal connections are made at runtime, because the graph only shows connections flagged as persistent, and skip it if the automatic node arrangement is what you need at scale, since the documented workaround for a freeze is to turn that toggle off. Before you rely on it, check the version you install against your Godot build, since the plugin targets the 4.x line and 1.8.0 is the most recent release, and keep the Arrange Nodes toggle off until you have confirmed the graph renders on your own scene.

Frequently asked questions

Official sources

1. Ericdowney/SignalVisualizer on GitHub
2. Issues
3. License: MIT
4. README
5. Releases