For Gravity, and HttpService, you should be able to enable these through Workspace. Please let me know if this no longer works. We agree, there needs to be a better way to interact with these items and we will investigate this.
Uploading images and meshes has been like this for some time. We have a long term vision around asset management in Studio. This will be moved to the Asset Manager within the next couple of weeks (still requires publishing a place).
Changing the Avatar type, we agree, this should be easy to modify and will figure out next steps to move this out of Game Settings as it is not a Game Setting (same with everything in World!).
We have plans this year to make iterating in the cloud quick, and easy. Right now its not ideal, it should be in the cloud automatically (and not create a place you don’t need in the process).
Thank you for the feedback, we are looking into this.
Thank you for your prompt and thorough response! I appreciate it!
Let me provide some more feedback on the first item.
For Gravity, I want to use this super useful preset section. It lets you adjust jump height and power, along with other properties. Super useful, especially to pick a preset. You can’t do this when the game is published. Currently, we cannot use this without publishing the game.
At which point, you might as well just write the command on the command bar.
I can’t easily figure out the avatar settings at all, so I don’t know how to switch to R6 right now unless I publish. Kinda weird.
I’m glad to hear an asset manager is coming! I hope we can use it without opening a place. Launching studio is already much slower than visiting the website.
Ahh yes, valid point. Those are valuable! Please keep in mind that you can access those in Workspace & StarterPlayer. The only thing missing will be the presets, which I can see being a bummer (correct me if I am wrong! ). We should still look into a location for this that isn’t Game Settings, and agree that it’s not an ideal experience. I have submitted a UX issue internally to discuss.
As for HttpService, that is likely the fastest way besides the Game Setting option. You can also expose hidden services, but that isn’t ideal. I have wrapped this into the UX request above.
I am not trusting enough to leave my projects in the cloud. If I ever get terminated or something happens to my account then I lose all of my projects if they exist only in the cloud, that’s unacceptable. I must have local copies on my hard drive. My workflow is to open a local file, or a copy of a local file to treat it as a “branch” since I’m a solo developer. I don’t want to work out of the cloud at all. These widgets should absolutely, flatly, without negotiation, not require the game be published or in the cloud to function. Making these work regardless of “cloudiness” benefits everyone, whereas the alternative is to benefit only a portion of people. The correct thing to do is pretty clear.
Please stop forcing Studio features to be tied to published games or games in the cloud. As an example, I was initially excited about bulk mesh uploading because it seemed useful for importing character models all at once, but because I work out of local files I have literally never even seen this feature once in practice.
I’ll note that Roblox talks a lot about “long term vision” and “cloud only futures” but I think there’s some deep misinterpretation of what it means to be cloud based. Please consider the user, not just blindly sticking to “the vision”. I feel like sometimes with these new “cloud based” features Roblox is actively dis-empowering me–which is not how the cloud should feel.
I want this issue to stay on the radar. Addressing this actively going forwards is critically important.
Another example of unexpected cloudism is the heightmap importer requiring an uploaded game asset (not just a regular asset, it must be part of the published game). Because of this and because of my workflow, I haven’t even had the chance to test this feature out, let alone actually use it for a real project. I know that this is because of moderation reasons, but it seems strange that it’s locked specifically to game assets only.
My workflow in Studio is literally to open a local place file, and publish it to a development game so Studio doesn’t arbitrarily prevent me from using features. From that point I continue to save my game locally. This workflow is a broken workaround for problems that are completely absurd and should not exist. Many of these features have absolutely no good reason to be locked to games in the cloud.
As Roblox tries to push for everything moving to the cloud, they are slowly breaking and inhibiting the workflows of many developers on this platform. While Roblox, I’m sure, has justifiable reasons for gating certain features off for local files, they have to understand that many developers don’t want to be forced into this position.
I have a few reasons for not wanting to embrace this new cloud vision. For starters, I simply don’t trust it. There have been issues in the past that can cause huge data loss in Team Create. I can easily backup local place files to a separate hard drive and off-site storage. If Roblox has one of its famous outages (there’s been a lot lately) then I’m stuck wasting potentially hours without being able to do anything.
Using Git, I can rely on an industry-proven file syncing method that provides far more data integrity and makes me and my team considerably more efficient and productive than Team Create ever can in its current state.
Another big reason for using local files is that my home broadband is massively unreliable. Often, it’ll just randomly drop out and suddenly I’ll be disconnected from Team Create. I can work out of local files without a stable internet connection and that is amazing for me.
Local files will always, always, always, be more reliable than the cloud.
Locking developers out of Studio features just for not using a published game is, in my opinion, foolish. It does nobody any good. From my perspective, all I see is Roblox trying to force their cloud vision on me and others. All this does is frustrate and anger developers, nothing else. It benefits Roblox is no way whatsoever and I can’t think of a rational reason why Roblox would be keeping it like this.
It would be great to be able to modify this in a local place file. Right now, in order to modify avatar settings, we need to be under a published place which is problematic for my workflow.
These are pulled from the web API at runtime, so “just unhiding them” wouldn’t solve anything. I believe a larger refactor would be required to decouple these from the web API.
These properties are read when using a local place file, and anyway, updating them in a online place file can easily just update it quietly through the Web API.
Bump. I do not like having to publish one-off place files just to import an asset using the studio widget. It’s a waste of time and bloats my already packed place backlog.
). We should still look into a location for this that isn’t Game Settings, and agree that it’s not an ideal experience. I have submitted a UX issue internally to discuss.