As a VR user I finally am happy to see the VR updates (although minor).
Since the performance of physics midphase is out , I wonder if it’s normal that the memory is rising? (Played in Jailbreak)
After a few minutes of playing I got into 20+MB
After some testing look like it’s only occuring when the terrain are loading (Streaming Enabled?)
I’ve noticed many of our HttpService requests have been getting a HttpTimedout error occasionaly in SCP: Roleplay as of about 3 weeks ago.
I’m unsure if it’s related to this new “Http Timeout” change, but it has been causing issues.
We rely on a server browser for player hosted servers with their custom experiences to be available for more players to join. These are usually big servers (60 people or more online at once), some times reaching numbers such as 130 players.
This causes server stress, and it appears that when the server is under heavy load or operating slowly, almost all http calls begin to drop under “httptimedout”.
I’m not sure if it’s related but I’d assume so, and if it is, this is something that we’d appreciate an investigation on so it could be potentially resolved…
Just one question, will you fix the run camera? If you go into Studio with the new camera and click to run the game, your camera will be stuck in the position you ran it in. It’s extremely annoying for me, whose game involves cutscenes and movement.
This is a bug with the “New Studio Camera Controls” beta feature. It’ll be fixed next week, until then you can disable the beta feature to resolve it.
For how long does the request have to stay alive until it times out? Is this a feature that can be disabled?
Yeah I also have noticed a few things. Ever since about 2-3 weeks ago, (my plugin makes heavy usage of external github content) my plugin has taken almost minutes to install 16 files, before it would take only 5 seconds at max. In this case I do not get any errors though, it’s just very slow.
VR follow camera?! Any info on it’s behavior?
And thanks for fixing the dev console network overhead.
I am so thankful for UpdateSourceAsync, the hacky “create a script, open it in studio so a ScriptDocument exists, type stuff, close” hack is so wrong
Is the 200,000 character limit still enforced on this method?
I’ve been waiting for some news on subscriptions for a while but seeing them being tweaked in releases lately makes me think we’re finally getting some progress on them. Policy being sorted out, paving the way for the technology and more of their APIs being released from RobloxScriptSecurity.
I didn’t see them on the roadmap but I hope I can continue to remain hopeful that, like when I first saw them introduced in the API, they’ll be a third monetisation route available to developers. 
Messed up… lol
Finally!
No more traceless errors when using RenderStepped:Wait()!
Could we finally get :SeparateAsync() in baseparts, please? At least a way to separate unions that were created with scripts in that running server? 
How is this not a fix?
How is this not an improvement?
These two should be swapped.
But finally!
I had no idea we could
:Destroy connections.Oh…
Does this affect HTTP long polling? This might break some code that communicates to webservers this way, it’s a common way for realtime communication to occur in Roblox because it allows for data to be streamed nearly instantaneously, especially with more than one connection open.
By the way, for those that are unaware, HTTP long polling works by sending an HTTP request from Roblox to a webserver. The webserver then simply does not respond until an event has occurred, and tells the client not to time out. This allows the data to be streamed back to the Roblox server at the same or similar speeds to a websocket.
This allows for data to be streamed quickly and efficiently from an external server into Roblox.
Prior to HTTP/2 servers can specify Connection and Keep-Alive headers to tell the client not to close the connection. In HTTP/2 the expectation is that the server/client should simply close the connection when they desire to close the connection, they don’t communicate that intent via a header.
This likely means that Roblox would have to be providing an option locally not to timeout HTTP requests, they could not automatically detect that the server wants to stay open.
Yeah, I don’t understand that either. Though I wish it was the opposite since it can create a bit of confusion between the normal Destroy we already know on Instances that disconnects everything and does everything possible to get the Instance ready for garbage collection; while this Destroy function seems to just disconnect and leave things subject to run…
Where do you see that ? (Like you’re not the first seeing update like this)
