Yeah man, print() debug for life.
1 Like
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.
1 Like
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.
2 Likes
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.
2 Likes
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.
But thatâs exactly what the dot is for!
It shows the dot for module scripts!
That dot has been there for months!
Sorry if it wasnât obvious but I was trying to validate your post, i.e. you answered my original question in that it indicates where the code is running. Not trying to say it doesnât.
1 Like