The debugger should trigger at break points in .gui_script files.
Actual behaviour
The debugger doesn't trigger break points in .gui_script files.
Steps to reproduce
I tried to put breakpoint in the following to two files in our project Presto:
shared/shared_gui/main_gui.gui_script
level/level_components/components/level_gui/level_gui_top.gui_script
I got this behaviour both when I started with debugger and when I attached debugger after previously starting the game. I could trigger break points in our main.script file but not in two two mentioned .gui_script files.
I heard that you and Mats could not reproduce it.
Perhaps this only happens on my computer. If so, then perhaps it's more return of investment to fix other bugs that more people have trouble with.
So you can close it for now if you wish. Hopefully this is a mysterious temporary problem. If it's still a problem after a couple of reboots and further editor/engine upgrades, than I can contact you again.
@olovn There is a sad reason for it not working in level_gui_top.gui.script :( There is currently a cap for how long paths the debugger can report - 59 chars tops - and that path is what .. 69?
According to @andsveking there is a #define somewhere, but we need to make sure we get the same behaviour across all platforms in plain lua and luajit. More of an engine issue.
Possibly not an engine issue after all. The buffer limit is inside Lua itself, but should be fine as long as we truncate paths the same way when we set breakpoints, etc. Currently it looks like we send the full paths to mobdebug from the editor. It could be as simple as truncating them in the same way, but it seems there is a special case for .lua paths becoming module names internally. Unsure if we should truncate those as well. We also get these truncated paths back in the messages from mobdebug, so I guess we'd have to resolve them into the full proj-paths.
Expected behaviour
The debugger should trigger at break points in .gui_script files.
Actual behaviour
The debugger doesn't trigger break points in .gui_script files.
Steps to reproduce
I tried to put breakpoint in the following to two files in our project Presto: shared/shared_gui/main_gui.gui_script level/level_components/components/level_gui/level_gui_top.gui_script
@olovn Can't repro in simple project - can you try? Is this both with Run with Debugger and Build + Attach?
I got this behaviour both when I started with debugger and when I attached debugger after previously starting the game. I could trigger break points in our main.script file but not in two two mentioned .gui_script files.
@olovn I did Build + Attach and put a breakpoint in update at
/shared/shared_gui/main_gui.gui_script:31and it stops nicely. Strange.I heard that you and Mats could not reproduce it. Perhaps this only happens on my computer. If so, then perhaps it's more return of investment to fix other bugs that more people have trouble with. So you can close it for now if you wish. Hopefully this is a mysterious temporary problem. If it's still a problem after a couple of reboots and further editor/engine upgrades, than I can contact you again.
@olovn Nope, we're not letting this go so easily :)
I tried to wipe that build directory. That helped a bit:
@olovn There is a sad reason for it not working in level_gui_top.gui.script :( There is currently a cap for how long paths the debugger can report - 59 chars tops - and that path is what .. 69?
Ah, so you've solved the problem, interesting. Is it possible to increase that limit? Seems a bit conservative
According to @andsveking there is a #define somewhere, but we need to make sure we get the same behaviour across all platforms in plain lua and luajit. More of an engine issue.
Possibly not an engine issue after all. The buffer limit is inside Lua itself, but should be fine as long as we truncate paths the same way when we set breakpoints, etc. Currently it looks like we send the full paths to mobdebug from the editor. It could be as simple as truncating them in the same way, but it seems there is a special case for
.luapaths becoming module names internally. Unsure if we should truncate those as well. We also get these truncated paths back in the messages from mobdebug, so I guess we'd have to resolve them into the full proj-paths.