Is there the potential for a skybox update and skies are getting cloudy phase 2/3 in 2025 (referring to this: Dynamic Skies Are Getting Cloudy)? I think that would be awesome.
Are there any plans for masking of any kind?
For example, excluding parts of an image, UI element, or 3D model with another image, UI element, or 3D model. I’d like this specifically for ViewportFrames as well.
The ViewportFrame example might be wanting to create a portal, but you’d want to mask the edges so that the only visible part of the ViewportFrame is within the portal area. Another example might be a custom ViewportFrame reflection with rain puddles, but only showing reflections in the puddle. There’s plenty of use-cases within normal UI as well, which would be great if this worked with CanvasGroup as well.
This question may also be related to the following:
Are there any plans to add more post processing effects? The current ones are great and all, but I think they could be better. The main I want to see is cell shading.
Thank you for your time!
Hi!
A question about the Verified Badge, we haven’t had monthly waves since October, and there were reports that the system was being reworked or improved. Is there any news on this matter? Since October, many creators have become eligible for the badge but haven’t received it due to the program’s continuous pause.
I have a question about "Custom Logging - Allowing you to pass error locations through pcalls. (2025)
If we can navigate error lines by passing pcall error locations, could this also work for thread stacks?
One of the inconveniences when scripting in Roblox is that it’s hard to trace where a thread that caused an error was originally created.
For example:
local function createError()
error("Error!")
end
local function createErrorThread()
task.spawn(createError)
end
createErrorThread()
Currently, the output logs look like this:
Script:2: Error! - Script:2
Stack Begin
Script 'Workspace.Script', Line 2 - function createError - Script:2
Stack End"
But ideally, it should include where the thread was created, like this:
Script:2: Error! - Script:2
Stack Begin
Script 'Workspace.Script', Line 2 - function createError - Script:2
Script 'Workspace.Script', Line 6 - function createErrorThread - Script:6
Script 'Workspace.Script', Line 9 - Script:9
Stack End
Right now, if an error occurs inside a thread, the output doesn’t log where that thread was created, making it difficult to debug.
Especially for custom signal modules, it’s hard to trace which line fired the signal with invalid arguments.
I’m not sure how pcall would pass error locations, but I hope this feature can also help track where an errored thread was originally created.
I made a feedback for it Tool doesn't have ClickDetector support, Accessories plan to hide Particle Effects when in First Person
Recently a new Studio update came out.
And there’s FFlagImprovedCursors
. If you turn it on, it does change something about the cursor when equipping the tool, which isn’t good.
If such a feature gets added, it would also be cool if one can control the order of how items get put into the backpack through StarterPack. The only way is to probably unparent and parent it back. Since the order depends on something like that.
These would be cool to have, so they’re a “ready-to-with” feature. Since the Backpack is a built-in thing.
Q3:
Will anything in this suggestion be considered? These feature requests have been around for ages and most have no staff response.
https://devforum.roblox.com/t/whats-a-feature-you-want-added-to-roblox/2622128/97?u=timefrenzied
Hello! I wanted to ask regarding Dynamic Heads if in the future when users buy a dynamic head version of a face if they’ll receive the classic counterpart of that face too, since I know that if you own the classic version you’ll own the dynamic version too but I was wondering if the same could be said vice-versa.
Question about editable assets
When will be ID-verification requirement to use Editable Mesh/Image removed?
Is having a unique game name a crucial factor in a game’s success on Roblox, given that the algorithm prioritizes unique titles for traffic and visibility?
Hey everyone, thank you for all of your thoughtful questions! We will no longer be taking new questions so that we can continue answering the many we’ve received.
Thanks for joining, and see you in the next one!
We’re focused on automatically detecting tampering and leveraging our platform policy system to take the appropriate action, and doing so across all platforms we support, but we are also exploring ways to give creators control and input based on what we detect. Could you share what specific things you’d like to do with a tampering signal?
Thanks for the question! We’re hard at work on server authority and aim to have an opt-in system for server authoritative avatars to help address many client-side movement exploits (e.g. speed hacks). We’re also exploring a new script type, designed to unify client and server scripts, which can be run in either location and support features like prediction/reconciliation. This script type will make building experiences simpler, leading to more secure gameplay. We expect to have more details to share with you by this summer!
Thank you for this question. mTLS support for HTTP Service is still something we are interested in, and are continuing to explore for our future roadmap. Please share any specific use cases you may have for such a feature.
Thanks for the question. Could you share what type of control you’re looking for? One idea we’ve discussed internally that would provide extreme control is physics scripts, where you could create scripts that run at much higher frame rates to implement your own custom physics. However, we don’t have this on the roadmap, so any more info on your preferred use case would be helpful!
Great question! Attributes were our first big move towards ‘custom objects’, but we know there’s stuff still missing like custom events, class names etc.
Unfortunately - this isn’t something we’re currently prioritizing, but we’d love it if you could share your use cases with us so we can learn a bit more.
Unified lighting was the first step in our plans for lighting — with this release, we’re aiming to improve scalability and lay the foundation for future improvements. After this, we will address some long-standing requests like expanded light ranges. Our improved mid-range lighting model, which we previewed at RDC23, will provide improvements to shadow quality for most users, but this is on-hold right now and we don’t have a timeline to share on release.
We want avatar heads on our platform to be dynamic and expressive while respecting the broad range of aesthetics that our community loves.
To do this, we’re exploring ways to create dynamic heads from classic faces in a way that retains a face’s original look and feel. We are also exploring letting users choose if they want their faces to be dynamic or static.
Ultimately, we want to do all of this in a way that maximizes user expression while making things easy for our creators.
Great question! Currently in Preview, Script Capabilities allow you to sandbox code to control what it does and doesn’t have access to in your experience. We don’t currently have plans to make it easier to run code written by users in your experience beyond APIs such as loadstring, but it is something we are open to exploring. Let us know more about your specific use-case.