Studio drops into debugger for breakpoint that was not hit, and at wrong line

  • A detailed description
    I was debugging a server script and noticed that seemingly a breakpoint was hit, but the arrow showing where execution stopped was not at the line of the breakpoint. I was expecting code execution to stop at the breakpoint, but instead the debugger highlighted another line after the breakpoint.

  • Where it happens
    It happened in the attached place. I have removed all content I can find except a single script, and removed all the script logic except an if-then-else statement.

  • When it happens - Include the date and time (including timezone) when it started happening.
    2023-05-02 18.00 CET+1

  • Videos and images - Include visuals to demonstrate the problem.
    record_000002_New.wmv (8.2 MB)

Open the place file, press play to see if you can hit the breakpoint in the BreakpointScript in the workspace. You will see that studio drops into the debugger when NOT hitting the breakpoint, and does not drop into the debugger when hitting the breakpoint.

  • :exclamation: Required information
    Plugins are disabled as shown in the video when launching from the command line.
    EDIT: When I download the file and open it, the breakpoint seems to clear. But I can add it back in and then I get the same behaviour.

We’ve filed a ticket to our internal database, and we’ll follow up when we have an update!

Thanks for the report!


Hi Gothguy,
Currently this is a known issue with our Lua VM that results in incorrect line numbers returning for the debugger. We will let you know once this issue is resolved permanently, but in the meantime the main workaround is to add

--!optimize 0

to the beginning of your script. This will tell the compiler to not optimize any of the lua code. There may be a decrease in performance, but this should resolve your issue.


We have a fix ready for this issue, it will be included in one of the upcoming updates. (silly stuff for devforum limits)


I’m having the same issue, both old and new debuggers.
--!optimize 0 makes no difference.

A bit vague, isn’t it?
I hope you can release this fix immediately.

1 Like

Yes, sometimes it’s hard for me to predict when changes to the codebase will be approved/tested by colleagues.

Right now I see that the fix is included in the Studio update that’s coming out next Wednesday.


A fix for this issue has been released in 0.576 Studio update.


It’s the same issue of my bug report Intuitive Debugger: Breakpoints not working in some cases and at least for me, it’s solved.