• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

GMS 2.3+ Issues with debugger suddenly and eradically disconecting.

Luigi1000

Member
Hey everyone, ever since updating to 2.3.2 I have had issues with the debugger suddenly resuming the game despite being paused at a breakpoint all on it's own. It says that the client refused and disconnected in the output but I got no idea why that would be case. (As shown in the code block below.)
I'm on IDE version 2.3.2.560 and Runtime version 2.3.2.426 on Windows 8 with 16 GB of RAM. If anyone has and ideas on how to resolve this easily I'm open to suggestions and before anyone asks yes it used to work perfectly fine prior to updating and yes I did already manually force port 6509 allowed both through windows firewall and my antivirus and doing that did nothing.

Example of output:
Code:
Start debug server
Creating Debugger server port:6509
[DbgServer]6509
Collision Event time(microsecs)=10243
Waiting for debugger to connect...
Client(-1) Connected: 127.0.0.1
Debugger connected
6826 code buffers added (356538)
Total memory used = 140447010(0x085f0d22) bytes
**********************************.
Entering main loop.
**********************************.
Client Refused: 127.0.0.1
Client(0) Disconnected: 127.0.0.1
Debugger disconnected
Client(-1) Connected: 127.0.0.1
Debugger connected
Client Refused: 127.0.0.1
Client(0) Disconnected: 127.0.0.1
Debugger disconnected
Client(-1) Connected: 127.0.0.1
Debugger connected
Client Refused: 127.0.0.1
Client(0) Disconnected: 127.0.0.1
Debugger disconnected
Client(-1) Connected: 127.0.0.1
Debugger connected
 

Luigi1000

Member
Ok after spending a good amount of time trying to trouble shoot this by my self since no one managed to get back and offer any assistance and after learning a bit about GMS2's configuration files I can say that my issue with it is resolved.

It was resolved by going into the C:\Users\<Account Name>\AppData\Roaming\GameMakerStudio2\<GMS2 Login id>\Cache\<Game ID> directory and by removing the file called debugger.json. This file has the definition of all your watch variables which the IDE keeps track of when debugging. It seems that there are issues with the debugger keeping it's paused state when at breakpoints if there happens to be either too many watch vars or duplicate watch vars in same list. You can either remove the file completely and re add the ones you wish to watch in editor or edit the file to only have the vars you need to watch atm and remove duplicates as these seem to be what causes it to disconnect like that on it's own. I have not tested the boundary to get exact numbers of where it breaks but it seems not to like having 130 vars in watch of which some may be duplicates, that being said it seems to be able to do fine with about 55 UNIQUE vars in watch without issues.

I leave this bit of information for anyone else who may run into this weird behaviour the program has if they need it.
 

rIKmAN

Member
Ok after spending a good amount of time trying to trouble shoot this by my self since no one managed to get back and offer any assistance and after learning a bit about GMS2's configuration files I can say that my issue with it is resolved.

It was resolved by going into the C:\Users\<Account Name>\AppData\Roaming\GameMakerStudio2\<GMS2 Login id>\Cache\<Game ID> directory and by removing the file called debugger.json. This file has the definition of all your watch variables which the IDE keeps track of when debugging. It seems that there are issues with the debugger keeping it's paused state when at breakpoints if there happens to be either too many watch vars or duplicate watch vars in same list. You can either remove the file completely and re add the ones you wish to watch in editor or edit the file to only have the vars you need to watch atm and remove duplicates as these seem to be what causes it to disconnect like that on it's own. I have not tested the boundary to get exact numbers of where it breaks but it seems not to like having 130 vars in watch of which some may be duplicates, that being said it seems to be able to do fine with about 55 UNIQUE vars in watch without issues.

I leave this bit of information for anyone else who may run into this weird behaviour the program has if they need it.
Glad you found the issue, but you should also file this as a bug with the repro steps so that YYG can take a look at it and see what is going on.

Attaching the offending json file to the report might also help so they can take a look at it.
 
Top