Open Zylann opened 4 years ago
What is the difference to doing this:
if mob.name == "Yolo":
breakpoint
You modify the source code and re-run the game. The whole point is not having to do it.
It would be also nice if those breakpoints could be enabled/disabled and if they would persists between sessions (even when disabled)
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.
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
Is this going to be shipped in 4.3?
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:
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 totrue
. IfPrint
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.