godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.12k stars 69 forks source link

Add conditional/printing breakpoints #909

Open Zylann opened 4 years ago

Zylann commented 4 years ago

Continuation from https://github.com/godotengine/godot/issues/6576

Describe the project you are working on: Any game project. More precisely, situations where you have to debug a lot of data, or a real-time behavior that would break if the game was interrupted.

Describe the problem or limitation you are having in your project: Breakpoints are a nice feature to debug, however they interrupt the entire game. There are known situations where you want a breakpoint to not always trigger. For example, in a tight loop iterating many element, a few of them named "Yolo" cause a bug. So you have to step a hundred times until "Yolo" shows up... Another situation is printing in realtime. You could add a print to your source code, but this is assuming you can reliably reproduce the situation in a short amount of times. Some bugs can take a while to reproduce, and when you finally get to them, that's where you can place breakpoints and investigating, and being able to configure breakpoints can save time.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: Conditional breakpoints allow to filter situations when a breakpoint should actually trigger, without having to modify the code. Printing also allows to keep the code as it is. The point being, if you have a situation to debug right now, you can do it without having to restart the whole game. The top situation would then be debugging a game running remotely, on a device. It saves the burden of modifying code to print stuff, re-export to target and re-run reproduction steps.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: Conditional breakpoints are standard on pretty much any serious debuggers I know (In C#, C++, Java, Javascript at least). After placing a breakpoint, right-click on it to choose extra settings.

Here is a mockup:

image

By default, nothing is checked and the breakpoint will "break". If Condition is checked, the breakpoint will trigger only if the expression on the right evaluates to true. If Print is checked, the breakpoint will not suspend the game, and instead will print a formatted string with access to the same variables available at the line where the breakpoint was added.

If this enhancement will not be used often, can it be worked around with a few lines of script?: You would have to use print, which defeats the point. So not really. It's just more time-consuming.

Is there a reason why this should be core and not an add-on in the asset library?: The debugger is a core feature and cannot be modded with scripts.

Jummit commented 4 years ago

What is the difference to doing this:

if mob.name == "Yolo":
   breakpoint
Zylann commented 4 years ago

You modify the source code and re-run the game. The whole point is not having to do it.

kubecz3k commented 4 years ago

It would be also nice if those breakpoints could be enabled/disabled and if they would persists between sessions (even when disabled)

ComfyZenny commented 1 year ago

Possible alternative; to reduce the amount of user clicks/keystrokes, there could be another button that simply prints a default string when the code line is reached. The button is either next to break or press the break button again to cycle to "print_test". To yet again make things easier on the user, the "print_test" button could have a customisable hotkey and string output in project settings.

PrintTest

vPumpking commented 1 month ago

What is the difference to doing this:

if mob.name == "Yolo":
   breakpoint

also I could be wrong but it seems like this doesn't work and reaches the breakpoint no matter the condition

smedelyan commented 1 month ago

Is this going to be shipped in 4.3?