Please decouple interactions that don't require you to publish a game from game publishing, like setting gravity

Hi!

As a Roblox developer, it is currently too hard to do a variety of interactions with studio that aren’t coupled with a published game. For example:

  • Configuring Workspace.Gravity (What? that doesn’t require a published game!)
  • Configuring HttpService.HttpEnabled (What? That doesn’t require a published game!)
  • Uploading images or meshes in bulk (Wait, hold on, images aren’t linked to games!)
    • On an even bigger note, this doesn’t even require a place open. Why is this in the game explorer? Come on Roblox.
  • Even changing the avatar type!
  • What if I want to test with rthro? Guess I have to publish the place!


Not all of the things in game settings are actually cloud game settings! Almost none of them are.

Fixing this would let me prototype and test things in Roblox a lot faster. I hate waiting for stuff to publish, it’s glitchy, slow, and overwrites a random place file I didn’t need to update.

Sometimes I open a new place because I want to test something really fast. I don’t want to save it to the cloud, and I don’t need a backup, and I absolutely know I can do these things if I want. For this reason, uploading the place to another place is silly.

If Roblox is able to address this issue, it would improve my development experience because I could use studio without having to arbitrarily perform actions to do common-place prototyping actions.

121 Likes

Hey @Quenty,

  • 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.

8 Likes

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.

HttpService does not show up in the explorer. To select it, you have to run this command

game.Selection:Set({game:GetService("HttpService")})

At which point, you might as well just write the command on the command bar.

image

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.

4 Likes

@Quenty

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! :slightly_smiling_face:). 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.

2 Likes

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.

31 Likes

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.

Also check this out, lol:

10 Likes

This.

I was happy when they made it so we could change character model types without having to publish a place… to revert it back.

3 Likes

Related to this : Allow published game-places to read game-settings from the place-file instead of the web settings

It’s impossible to change + publish game settings from a local place file, which causes a lot of issues with my workflow.

1 Like

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.

15 Likes

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.

23 Likes

@nsgriff
This was posted 2 years ago. Are there any updates on this?

6 Likes

Game Settings > Avatar?

Sorry, it’s been 2 years. What are you looking for?

The ability to change avatar settings on an unpublished place without needing to use Internal Mode features or modifying the raw place file.

The easiest solution is to just unhide them from StarterPlayer

image

4 Likes

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.

Even better, we should be able to overwrite cloud settings with local datamodel settings : Allow published game-places to read game-settings from the place-file instead of the web settings

3 Likes

@nsgriff You mentioned moving avatar settings out of game settings:

4 Likes

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.

2 Likes

Only in published places. In local place files, these are read from the datamodel.

2 Likes

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.

1 Like

That’s true, but that would require more work besides just unhiding the properties

1 Like