My bad. Fixed.
6 Likes
Fantastic update. Any chance that test servers could be revamped to use this? I’d love to test multiple players without slowly booting up a bunch of entire studio windows.
5 Likes
I love this feature! Just a small design suggestion:
Seeing as we identify studio with a blue version of the Roblox logo and the client version is identified with the red Roblox logo, should we not use those colors to more intuitively identify which data model we are viewing?
16 Likes
This is great, allows us to test in studio without having to join the game separately to test for bugs.
Thank you!
2 Likes
Super awesome update! I’m running into an issue, however. Before this update I could tell if the server was in a Play Solo environment via. RunService:IsClient() - which is no longer possible. Is there a way to get around this? This is especially frustrating with the BindToClose yield issue.
4 Likes
There’s a fix for that BindToClose bug in the pipeline, will take a couple weeks or so to be rolled out. I’d recommend using regular Play Solo for the time being so that the hacky patch for BindToClose works.
3 Likes
No idea what any of this means, pretty confused.
3 Likes
Ah yes, absolutely love this update. Makes testing convenient. 
3 Likes
There’s a difference between old-school Play Solo and actual game servers, for example:
- If you require a module from a Script and from a LocalScript in Play Solo, it will return the same value even though they should be on different network clients. This doesn’t happen in real servers, the client gets its own version of the required module, just like the server.
- RunService:IsClient() and RunService:IsServer() both return true in Play Solo, while in real servers this only returns true on the client/server respectively.
- Play Solo lets you break FE principles: if you insert a part into workspace from a LocalScript, that part is actually there in the DataModel from the server’s point of view, while it should only be visible on the client that inserted it.
- Everything in Play Solo runs on one thread. So code that runs for a long time in LocalScripts will actually interrupt Scripts from being able to run.
- etc…
All of this can cause a lot of issues if the developer is not aware of these differences. You have probably heard some of your colleagues say something along the lines of “it works in Studio, but not in-game” before.
This is solved by running the client and server in separate contexts in Studio when you hit Play Solo, and each of the client/server part has a dedicated thread of its own, and this is what is called “Accurate Play Solo”. It is meant to accurately depict what your game will do if you were to play it on your own in a live game / were to do “Test Server” + 1 test player.
13 Likes
This is amazing! Thanks so much for the update!!
2 Likes
Hey, now I don’t need to constantly be running servers with just me in it to test how things actually work. This update is great, you guys did very well with this.
2 Likes
I had a dream where everything in test mode was the same as your real game. And today, it came true!
2 Likes
Awesome! Now I don’t need to worry about the annoying Windows Authorisation pop up when starting a test server, or having to publish the game and join it from the website!
3 Likes
You should probably take note of all your ’ flavour text’ and put them in a book. Fantastic read well done.
APS is pretty nice as well.
3 Likes
I agree—we definitely need a way now to detect when we are in APS. I distribute an additional set of debugging modules to the client, but only when in Play Solo. There are many more use cases, not just working around temporary bugs like the BindToClose mess. We need a new function RunService:IsAPS or :IsAccuratePlaySolo or perhaps if it is completely replacing Play Solo, simply :IsPlaySolo.
Please consider adding this feature.
3 Likes
@BuildIntoGames @tbradm Is there a reason you don’t just disable the BindToClose saving with IsStudio() instead of specifically in Play Solo?
You should be able to get everything you need with the current methods.
| Mode | Check |
|---|---|
| Edit (non-TC) | IsEdit() and IsServer() |
| Edit (TC) | IsEdit() and not IsServer() |
| Run mode | IsRunMode() |
| APS player | IsStudio() and IsClient() and not IsServer() |
| Test player | IsStudio() and IsClient() and not IsServer() |
| Team test player | IsStudio() and IsClient() and not IsServer() |
| APS server | IsStudio() and IsServer() and not IsClient() |
| Test server | IsStudio() and IsServer() and not IsClient() |
| Team test server | IsStudio() and IsServer() and not IsClient() |
| Legacy play solo | IsStudio() and IsServer() and IsClient() |
| Live Player | not IsStudio() and IsClient() |
| Live Server | not IsStudio() and IsServer() |
The only modes you can’t distinguish between is the three types of players and the three types of servers, but they’re all pretty much the same. With APS you shouldn’t have to write special cases where something runs in play solo but not a test server. E.g. it should be fine to run your debugging modules on any of the studio clients.
31 Likes
Edit: This makes sense. Thank you.
1 Like
Didn’t know these existed, really appreciate it!
1 Like
Sounds cool and everything, but I am simply unable to use APS. With it enabled, once you press Play, Studio pretty much becomes unusable. Buttons won’t respond, neither the shortcuts or the widgets (explorer, properties, plugins, etc.) - the game won’t load and you need to bring the Task Manager to shut it down (Studio become unusable but doesn’t really crash or go into Not Responding mode.) as the close button doesn’t work either.
I didn’t bring up a Bug Report as it seems I’m the only one being affected with this.
1 Like
You can still make a bug report if only you are experiencing it. This is why some bugs involve including your computer’s specs. Chances are if you’re experiencing it, someone else who isn’t on the forums is also experiencing it.
2 Likes