Server freeze on plugin loading

[gv1222]

Couldn't it be that the flashing ZBS is actually in a breakpoint and waiting for you to continue execution? It would happen if you changed the debugger.runonstart value (or didn't change, I've forgotten which way

Hmm possibly, i don't think i changed any user or system settings yet so unless its default it may be something else. After using zerobrane on the second computer for a while it has also stopped function but I have figured out somewhat of a workaround for it, (hitting F5 again after the debugger has already started) and seems to temporarily fix the issue. I have also noticed that when you stop the debugger using the stop button, MCServer isn't closing by itself (works fine if you don't double tap F5). I will attempt to downgrade to .52 of mobdebug and figure out if it still is a commit from that time period causing the issue.

Okay.. i've gone gone through commits starting with V .52 and this commit seems to break it : https://github.com/pkulchenko/MobDebug/c...f5b0918045

[xoft]

If "F5" is fixing it for you, it means ZBS is in a breakpoint (and the second F5 is telling it to Continue). That is regular wanted behavior for regular Lua debugging - as soon as you start the script, you want the execution to halt and to give you a chance to set up breakpoints.
With MCS it's not so great behavior, so I used a configuration value debugger.runonstart to govern whether the debugger should break immediately or not. I'm not sure now what the default is, so if it's wrong for you, you may want to set it to the other value. In ZBS, select menu Edit -> Preferences -> Settings: System (or User) and ZBS will open the settings file for you, there you can set the value; I've got it set to true on my dev machines.

[gv1222]

If "F5" is fixing it for you, it means ZBS is in a breakpoint (and the second F5 is telling it to Continue). That is regular wanted behavior for regular Lua debugging - as soon as you start the script, you want the execution to halt and to give you a chance to set up breakpoints.
With MCS it's not so great behavior, so I used a configuration value debugger.runonstart to govern whether the debugger should break immediately or not. I'm not sure now what the default is, so if it's wrong for you, you may want to set it to the other value. In ZBS, select menu Edit -> Preferences -> Settings: System (or User) and ZBS will open the settings file for you, there you can set the value; I've got it set to true on my dev machines.

Yup, just tested and it worked. Thanks for the help, you should definitely add it to the setup page so other people know how to fix it.

[paulclinger]

> With MCS it's not so great behavior, so I used a configuration value debugger.runonstart to govern whether the debugger should break immediately or not. I'm not sure now what the default is, so if it's wrong for you, you may want to set it to the other value.

Mattes, you may want to change the default in your interpreter code; instead of "ide.config.debugger.runonstart == true" you can use "ide.config.debugger.runonstart ~= false", which will turn it on by default:

DebuggerAttachDefault({
runstart = (ide.config.debugger.runonstart ~= false),
basedir = ExePath:GetFullPath(),
})

[xoft]

Paul, but this is somewhat counter-intuitive - one would set "RunOnStart" to true to actually NOT run on start.

I know it makes sense to have a reasonable default, but I'm not sure this is the correct way to go about it. Perhaps I should hard-code the value in, since almost nobody will want to break into the debugger on start - especially when it's in an auto-generated file.