search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
89.57k stars 20.73k forks source link

Improve tool script debugging #5983

Open Zylann opened 8 years ago

Zylann commented 8 years ago

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 https://github.com/godotengine/godot/issues/5984

reduz commented 8 years ago

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 https://github.com/godotengine/godot/issues/5983, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z21BXWMDkHE6yC2s8mkht4OuLijbEks5qa_IpgaJpZM4JY7eQ .

Calinou commented 5 years ago

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

Zylann commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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.

q4a commented 4 years ago

Signed for this bug. I would like easier to debug plugins.

Calinou commented 4 years ago

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

MikeSchulze commented 4 years ago

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 commented 1 year ago

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?