That’s right, a debugger is useful for debugging!
But without the skill to use one, it won’t be much help. When you have the skill to use one, you actually won’t need it as often.
That’s right, a debugger is useful for debugging!
But without the skill to use one, it won’t be much help. When you have the skill to use one, you actually won’t need it as often.
Will this by any chance improve the speed for when starting a test?
Yeah man, print() debug for life.
This is a great update. Now I can work on more peer-sensitive and lag-sensitive scripts in APS, because it makes debugging games in APS less of a pain. Nice!
The debugger is most useful for me when it’s set to break on errors and I use its variable watches (including hovering over variable names in code while game is paused). It often saves me from having to stop, write print(something)
somewhere, and then restart to find out what logical error was happening before stopping again and attempting to fix it. I often only need to examine the variables surrounding the error, stop, and then fix it.
I admit that though I have been using APS more frequently, I still like and use single-data-model Play Solo much of the time, at least until it is either removed or starts getting broken, then I’ll just keep it for nostalgic purposes. I use it for several reasons: It discourages straying away from the server’s version of the data-model too much (which can cause problems), it’s fast on single-player games, it lets me play with very old creations which are now broken, it does not require switching peers to make changes both can see, and it doesn’t display a colored border around the screen, which otherwise gets distracting when I’m trying to be fully immersed in a game running in Studio.
I’m going to need this to be explained to me…
How is this different from the old behavior?
What is APS?
APS stands for Accurate Play Solo, which is explained in more depth here on the release page. It basically runs the server and client on two separate data models like the game client and therefore provides a more uniform testing experience as it’d be in game. Many errors along the lines of, “It works in Studio, but not in game” are way less common.
So what has changed with this update? From why I can tell, it was already the case that server/client outputs were differentiated with a blue/green color when printed out to the console.
Is this for other debugging tools as well? (I wouldn’t know because I never use them)
This update allows the lua debugger to run on the client and server at the same time. Before, you’d have to go into the settings to switch between the server and client for debugging, I rarely used it for this reason. The output has always ran for the server and client together (afaik).
The old play solo was only one data model so the debugger worked for both the client and server. And now that this has been addressed, it’s being removed.
Play Solo has always been APS for me as far as I’ve been aware… I’m not sure if I just had right the settings/flags enabled, but I’ve always been able to switch between server/client in a solo test…
Unless there is a difference between Play (f5) and Play Solo (f6)?
I stopped using f6 because I thought it was going to be deprecated, despite f5 sometimes hurting my workflow, especially in the event of a crash.
I don’t believe there’s a difference between F5 and F6 (not sure tbh), but using the Play Solo button always activated the old Play Solo until APS was released. Now it activates APS by default and you have to disable APS in settings to use the old one.
Switching between the client and server is new to APS if I remember correctly. Before you could access everything during the play solo session, things that were both on the client and server. This is what caused all the ‘works in Studio, but not in game’ errors because things could be accessed on the client from the server which wasn’t possible in game.
With the switching in APS, it shows only things on the respective data model which is how it works on the game client and server.
I recommend reading the linked post above (especially the flavour text ). It explains the concept really well.
Aww! I guess we need to wait to use it. I still can’t debug both peers at the same time and I still see an option in settings for attaching the debugger to either the client or server. Guess that explains what @CycloneUprising said in this post:
Yep. I saw one debugging error in APS myself. I tried to isolate it, but then it stopped happening while I tried.
This is not related to the output or switching between the client/server. The issue is the debugger (i.e. breakpoints). Currently, if you set a breakpoint in a client script and then another one in a server script, both will be hit in non-APS mode, but with APS only one will be hit, depending on whether you have the debugger set to client/server (which you can’t change without restarting Studio). After this change, the debugger will work for all breakpoints regardless of whether you are using APS or not.
tbh I should probably start using the debugger, it seems so useful but there is a learning curve.
That’s probably the reason some people still use prints.
I may use this, I definitely know LOTS of people will use this.
If only this was still enabled.
Will it be obvious whether your on the server or client? (Similar to how the blue and green bars were added to the F5 console output.) This would be great (when it’s fixed and re-released).
There’s already a little dot that shows you what side it’s on. Blue for client, green for server.
I believe he is referring to the debugger, not scripts.
Excuse me? Are you saying that you can debug a server script using the client debugger? No, that’s not possible. The colored dot that shows you what ‘side’ the script is on shows you what side the debugger is on for that specific script. How could it not? Please elaborate.
Right, I was interested in knowing if the IDE would indicate whether you’re stepping through code on the server versus the client. For instance, if you’re in a module script, it’s code that could be running on either so ideally the IDE should show where the current code is being executed. A blue versus green colored dot as shown in the screen capture would do the job.