Improve tool script debugging

[Zylann]

I am currently developping a GDScript editor plugin, and just like developping a game, I make mistakes and am getting countless errors, yay!
But the problem here is that I only get the error and the line where it occurred. I am currently spending a lot of time trying to figure out a bug happening everytime I use Ctrl+S that makes the editor hang for 30 seconds (it was 5 minutes when it first occurred!). Because I edit the tool in the editor, it is becoming a PITA to debug. Godot even froze at some point but not a clue what happened.

It would be a great improvement if we could get the call stack of tool script errors, because mine just tells invalid index in get_value(x,y), which can happen in a lot of different ways, so I'm screwed to the point I have to print everywhere (making the test even longer!), erase stuff and wait for a while everytime just to find the culprit code path.

FYI: the bug was caused by #5984

[reduz]

If you are brave you can run godot editor with -d and use commandline
debugger

On Jul 30, 2016 21:54, "Marc" notifications@github.com wrote:

I am currently developping a GDScript editor plugin, and just like
developping a game, I make mistakes and am getting countless errors, yay!
But the problem here is that I only get the error and the line where it
occurred. I am currently spending a lot of time trying to figure out a bug
happening everytime I use Ctrl+S that makes the editor hang for 30 seconds
(it was 5 minutes when it first occurred!). Because I edit the tool in the
editor, it is becoming a PITA to debug. Godot even froze at some point but
not a clue what happened.

It would be a great improvement if we could get the call stack of tool
script errors, because mine just tells invalid index in get_value(x,y),
which can happen in a lot of different ways, so I'm screwed to the point I
have to print everywhere (making the test even longer!), erase stuff and
wait for a while everytime just to find the culprit code path.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5983, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21BXWMDkHE6yC2s8mkht4OuLijbEks5qa_IpgaJpZM4JY7eQ
.

[Calinou]

@Zylann Is this still relevant in the current master branch?

[Zylann]

Technically there still isn't a call stack printed, however I now use the commandline debugger, which is still the only way to debug a tool script running in editor at the moment.
Unless there is a magical way to debug and break into scripts running in the editor itself, I would say this issue isn't really relevant anymore... although it's the only issue I can point to for people who wonder how to debug their tool scripts.

[wyattbiker]

I want to make a plugin and to my surprise found out one cannot debug them.
What are the difficulties using the built in debugger? Maybe there is a way to at least debug in a sandbox without the tool keyword, and allow EditorPlugin and EditorInterface to be instantiated since they inherit from Node.

[Zylann]

@wyattbiker while using the command line debugger I was able to inspect the code and variables when a problem occurs, however I don't know how to setup breakpoints, so I've been using prints and breakpoint keyword instead.
Separating code and scenes outside of the plugin class may also help.

[wyattbiker]

Didn't know about the breakpoint keyword. Nice to have. The debugger has way too many issues. You can also use prints and run inside the editor. Of course you have to inactivate and activate plugin from Project when you make changes.

I would like to understand what the tech road blocks are that one cannot debug plugins.

[Zylann]

@wyattbiker because if you suspend plugin code running in the editor, that means you suspend the main loop, which includes input handling and drawing of the interface. It is consistent with what happens when you debug games as well. The debugger might be working but the whole editor will be frozen... so that's why it only gets usable from command line, I guess.

[Calinou]

@q4a Please don't bump issues without contributing significant new information; use the 👍 reaction button on the first post instead.

[MikeSchulze]

Just a question why the plugin code must run in the same debuger thread?
Would it better to run each plugin in a extra thread to have better control?
Than you can allow to debug without run into deadlock of the main debug thread

[berarma]

I can't understand how the commandline debugger works. I've tried the "-d" option in Godot 3 and 4 and I only get debug messages in the terminal. Is that all?

I'm still fairly new to Godot, so I might be missing something but I think the following would be the feature that Godot needs to fulfill this issue and more.

There could be two instances of Godot, the one I'm testing my plugin on, and the one where I'm working on the plugin and debugging it. Remote debugging would be needed for this. This way one instance debugs another instance and there are no possible lockups. This wouldn't only be useful for plugins but for developing the Godot editor and any Godot based apps. Is that already possible?