Providing developers with optimization features and other frequently used features by default is a great convenience for a vast number of developers, but ultimately it also serves as a roadblock in terms of developer control.
Many games work fine with these features on, but there are plenty of games out there can’t do what they want or have to find a hacky workaround to be able to do what they need to do. For example, many developers are restricted to the limited render distance that Roblox allocates to the client, which can prove to be a major inconvenience many developers. A long dark hallway that isn’t supposed to have a hole at the end of it but now does because the engine automatically stops rendering far away parts breaks the immersiveness, as players are now able to see the skybox (which is undoubtedly unintended). They will then have to either increase the fog (which might block out some important indicators the user is supposed to see), or decreasing the length of the hallway which can make it shorter than anticipated.
Some examples of toggable features are:
automatic world physics
automatic character physics
shadow distance
render distance
Giving developers the ability to toggle these features would most definitely increase the amount of ingenuity that developers are able to spurt out as it gives them a part of their creative freedom they never had before.
While I don’t disagree, I think it is much smarter to write individual feature requests about the engine features that you want toggles on so you can supply a use case for each on how your development would benefit from having that toggle (hence the feature request format).
If you have to use a nonspecific word in the title or wording in the content body, then it already doesn’t work as a feature request. It’s too broad on scope and doesn’t help engineering or product directly understand the more fine print of the problems you’re experiencing while developing. Knowing the exact problem you’re having helps build discussion and considerations about supporting the feature or why they would prefer not to provide it (e.g. performance, infeasible, etc).
+1 on this, highly recommend creating a feature request per development issue that you are experiencing. The current post reads like a proposed solution instead of a development issue, which makes it very difficult to assess and resolve, because we don’t actually know your underlying problems.
There may be different solutions to the different issues alluded to here so a separate thread detailing each problem with specific examples (preferably, without focusing as much on proposed solutions!) would really help out here. Each issue may also be addressed by different teams at Roblox, so a separate topic for each specific issue is also helpful in that regard.
Sidebar: we’re thinking of some simplifications to the feature request template to make it harder to fall into the trap of writing a thread as a proposed solution, since specific proposed solutions are very hard for us to implement if we don’t know what problem it solves and if it is the best solution to said problem. We also try to devise solutions that solve broad ranges of problems rather than just one-off situations where possible.
I agree! I hate that no matter what I do I cannot remove roblox default dampening physics, despite making friction 0 or frictionweight 0, anything that moves just dampens automatically (i.e the player), its frustrating because I want to program my own way of handling such physics.