- Doesn’t happen with APS off?
- Can you please provide very detailed example: e.g. open script type, hit Run, expect to see X, actually see Y.
Thanks!
1 Like
On, production, on a Mac:
I open baseplate, I add a script, I Play Solo (APS).
I edit the script. I can see my edits, I can type in script just fine.
I hit stop.
My edits are still in the file.
So with that brief test things seem to be working as expected w.r.t. being able to edit scripts while playing.
Where exactly do things go off the rails for you?
1 Like
Here is my simple repro
This script, in Workspace:
The goal: swap which lines are commented so the reverse string prints in console
With APS off:
- start the simulation (I use Play Here)
- Hello World! is printed
- double-click the script to edit it
- swap the comments to print the reversed string
- Disable the script then un-Disable it to restart it with the new code
- !dlrow olleH is printed
- Press the stop button to end the simulation
- I am asked if I want to keep the changes
All as expected.
With APS enabled:
- start the simulation (I use Play Here)
- Hello World! is printed
- double-click the script to edit it
- swap the comments to print the reversed string
- Disable the script then un-Disable it to restart it with the new code
- nothing is printed, !dlrow olleH is expected
- Press the stop button to end the simulation
- I am asked if I want to keep the changes
About a week ago I experienced a case where edits would be discarded immediately after closing the script which did not happen in this simple repro.
The expected outcome is that the script will start running with the new code when its Disabled property is refreshed. As a developer the ability to make code changes live is invaluable, which is currently not available in APS.
If studio were to restart the script when the editor is closed during simulation, this would not be ideal as I may be consulting other scripts or resources in the game to ensure the code I am editing will work.
4 Likes
Any update yet on this?
1 Like
Can’t you just copy + paste the script after you’ve edited it? I’ve been doing that for years and never had an issue. I would expect the disabled property to not restart the script anyway
when set from true to false.
1 Like
setting disabled to true stops execution (usually)
setting disabled to false begins execution at the top of the script
1 Like
I mean that as a developer not knowing which behavior might happen, I would expect the behavior currently seen in APS. The word “disable” would not make me think that the script would restart, just stop running.
It might take a few more steps, but can’t copy/pasting the script to the same parent after you’ve disabled it and edited it be enough? I’ve been doing that for years and never had any issues.
2 Likes
I’ve been testing this feature and I’ve decided that I am not in favor for removing traditional Play Solo. Accurate Play Solo, although it is more true to the data model expected of online games, has features to allow better manipulation of the server side of the data model than Accurate Play Solo, has better physics quality than Accurate Play Solo, and better framerate than Accurate Play Solo.
Physics objects in Accurate Play Solo jitter frequently, which is unwanted behavior when, for example, recording for an animated video. If traditional Play Solo is removed, the barrier of entry of recording physics objects behaving smoothly is raised.
3 Likes
Have you tried setting the network ownership of the jittery object to the player?
My vehicles are completely physics based, using constraints, yet I don’t have issue with physics, even when recording.
1 Like
Yes I have.
1 Like
Hi Developers,
We are planning to remove Inaccurate Play Solo on April 2nd. At that time, all Studio users will be automatically upgraded to Accurate Play Solo and the setting to opt out will disappear. This will allow us to move more quickly and spend our engineering time to changes that will help all Studio users.
One of the major concerns brought up in this thread is Studio crashing more frequently because Accurate Play Solo takes more memory. We are in the process of rolling out 64-bit Studio on Windows which should alleviate this problem entirely.
If there is anything else preventing you from switching over to Accurate Play Solo, please let us know immediately so we can take it into account. If you are having performance issues, please file a bug report with details about your system.
18 Likes
Can you file a bug report about this issue, including your system details?
1 Like
Looking forward to this. Accurate Play Solo and studio in general will be a lot better
5 Likes
Is Studio on MacOS already 64-bit?
1 Like
Yes.
3 Likes
What are the benefits of Studio being 64-bit? Is it more memory allocation?
1 Like
32-bit studio cannot use (or address) more than 4 gigabytes of RAM, whereas 64-bit studio can use way way more RAM (E.g. If you have more than 4 gigs of RAM, then studio will be able to use those extra gigs instead of being clamped to 4 gigabytes) than it’s 32-bit counterpart can.
There are others benefits (in fact a lot, but too many to list here) too, but the main one still is extended memory allocation.
5 Likes
Finally. No more “works in studio but not in game” like EchoReaper said.
4 Likes
Extremely useful especially when trying to find bugs related to FilteringEnabled. Thanks roblox!
1 Like
Are there plans to allow the debugger to “just” debug the client + server at the same time? It’s such a hassle to debug with APS currently because it only supports debugging one of the two. Even when just debugging the client or server on its own the switching process is rather painful.
2 Likes