Publishing local files rarely ever actually publishes the local file

Describe the bug. Describe what is happening when the bug occurs. Describe what you would normally expect to occur.

When publishing a local file via File -> Publish to Roblox As..., the place is often not actually published. Exact conditions under which is fails are unclear, but some observations:

  • If opening the local place file, then immediately publishing, the publish seems to succeed in most cases.
  • If working on the local file first, then publishing, it’ll more likely fail in some way or another. It may appear that publishing succeeded to 100% according to the dialog (and then continue publishing in the background anyway?), then never actually publish at all.
  • It looks like running game:setPlaceId(...) and then publishing fails consistently as shown below:

How often does the bug happen (Everytime/sometimes/rarely)? What are the steps that reproduce the bug? Please list them in very high detail. Provide simple example places that exhibit the bug and provide description of what you believe should be the behavior.

Extremely frequently. See above.

Where does the bug happen (www, gametest, etc) Is it level-specific? Is it game specific? Please post a link to the place that exhibits the issue.


Would a screenshot or video help describe it to someone? If so, post one.

See above for a video of one of the failing cases.

For graphics bugs, it is sometimes helpful to know your system specs, especially graphics card.

Win 10

When did the bug start happening? If we can tie it to a specific release that helps us figure out what we broke.

Since or after Introducing Asynchronous Publishing for Places (Non-Team Create) was released.

Anything else that you would want to know about the bug if it were your job to find and fix it.



In Zombie Strike, we had this issue as well. We published our new update 2 days ago and didn’t realize until today that the place had never actually published.

1 Like

I’ve had a similar issue with team create not actually publishing.

I am confused. Is this a team create or non team create issue?
I am asking as the release was for non team.

I’m having this issue too, I’m trying to publish to a place in my game and publishing doesn’t seem to work properly - instead of using the newer version, it uses an older version instead and it’s really annoying!!

We will investigate the intermittent publishing problems. If anyone can provide information requested by How to post a Bug Report, that would aid in helping us identify the issue(s).

As for the publish window kicking you back a page if you’ve used SetPlaceId, that seems like an entirely separate bug (at least implementation-wise - not necessarily feature-wise). Can you provide more information on why you use SetPlaceId? This was not originally meant to be used by developers, so we may just lock it down to prevent getting Studio into a bad state if it’s not too important.

1 Like

This is critical to my workflow to allow me to access for example datastores for a game when using local files (I only upload changes to Roblox manually whenever I’m ready to update the game, never publishing any intermediate progress and tracking all changes using an external version control system). See also Upcoming removal of some methods with PluginSecurity .

A better system for this would be ideal, things like the game explorer, localisation tools, game settings and more all just don’t behave properly without publishing to Roblox first (don’t want to publish incomplete changes and it’s very slow to do so compared to just Ctrl+S) or loading a file from the Roblox servers first (very slow, not part of version control), both of which are nonideal workflows for me.

I’m also using SetPlaceId in a script that rapidly wipes user data across all my games. Manually running it for every single game is a huge pain, of course.


SetPlaceId is important for me. I need it to access DataStore while working on a update that I do not want to publish yet.

On top of that, I use SetPlaceId to comply with GDPR requests, by cycling through my games to remove a particular UserId from my Data from a single place.

Please do not lock it down without providing us with an alternative solution to our use-cases.


Highly agree to above (sorry, didn’t see this before). I wrote some scripts to deal with cross-game actions on datastores such as handling GDPR requests. If SetPlaceId is removed it would become nearly infeasible for me to keep doing this for all of my old games since I have a busy schedule and it’s already annoying to process them as-is. You can imagine what my train of thought w.r.t. the removal messages may or may not be if SetPlaceId were to be locked down.