If multiple signals are emitted in a single gameplay frame, they may be reflected in the Signal Debugger pane in the incorrect order (older signals can appear below newer signals).
To Reproduce
To see this behavior for yourself:
Download attached file and extract to C:\projects\SignalDebugger_test_case\ or similar.
Open ('Import') the project in Godot 4.1.3 Stable.
Make sure the console shows no errors and that the Signal Visualizer and Signal Debugger have loaded successfully.
Start the application and return your attention to the editor; there will not be visible objects in the game window.
Navigate to the Signal Debugger under the main Debugger tab and choose Start.
Wait a few seconds and compare the order of print-statements in the Output pane to the order of signals listed in the Signal Debugger.
Expected behavior
The Petitioner node's petition_submitted signal is the initiating signal, which in turn triggers a petition_rejected or petition_accepted response from the Approver node. This sequence is correctly reflected in the Output pane via print statements — oldest messages first, newer messages beneath, making it clear that petitions are first submitted before they are approved or rejected. Parallel output should appear in the Signal Debugger.
Actual behavior
The Signal Debugger does not preserve the signal order, at least on the machine used to test this behavior.
I assume what I'm seeing is a quirk of EngineDebugger.send_message() using some kind of LIFO or other collection that won't (or may not) deliver messages in the same order they were sent. It presumably just empties this collection after some delay, dumping messages back in some non-FIFO order. This is confusing because it makes it hard to parse bursts of related signals (think dominoes) that may occur within a single frame. Knowing the exact order of signals occurring even within a single frame may be relevant to understanding bugs in game code.
A number of games developed by experienced Godot devs utilize signals every single frame to do things like update colors or animations to reflect game state. Others, like in my case, have a workflow that allows the player to attempt actions (sending a petition, in my very-dumb example here), which can then be accepted by the recipient or rejected, which in turn drives state-changes on the player object. Some of these responses will be instantaneous and simply occur within the same frame.
I wanted to highlight this issue because this is a really neat addon!
Describe the bug
If multiple signals are emitted in a single gameplay frame, they may be reflected in the Signal Debugger pane in the incorrect order (older signals can appear below newer signals).
To Reproduce
To see this behavior for yourself:
Expected behavior
The Petitioner node's
petition_submittedsignal is the initiating signal, which in turn triggers apetition_rejectedorpetition_acceptedresponse from the Approver node. This sequence is correctly reflected in the Output pane via print statements — oldest messages first, newer messages beneath, making it clear that petitions are first submitted before they are approved or rejected. Parallel output should appear in the Signal Debugger.Actual behavior
The Signal Debugger does not preserve the signal order, at least on the machine used to test this behavior.
Example Output pane output:
Example Signal Debugger pane output:
Desktop:
Additional context
I assume what I'm seeing is a quirk of
EngineDebugger.send_message()using some kind of LIFO or other collection that won't (or may not) deliver messages in the same order they were sent. It presumably just empties this collection after some delay, dumping messages back in some non-FIFO order. This is confusing because it makes it hard to parse bursts of related signals (think dominoes) that may occur within a single frame. Knowing the exact order of signals occurring even within a single frame may be relevant to understanding bugs in game code.A number of games developed by experienced Godot devs utilize signals every single frame to do things like update colors or animations to reflect game state. Others, like in my case, have a workflow that allows the player to attempt actions (sending a petition, in my very-dumb example here), which can then be accepted by the recipient or rejected, which in turn drives state-changes on the player object. Some of these responses will be instantaneous and simply occur within the same frame.
I wanted to highlight this issue because this is a really neat addon!
SignalDebugger_test_case.zip