A long standing issue I’ve had is inserting a Part, forgetting it’s unanchored, and finding out long after once testing the game. This results in a lot of backtracking to anchor everything, which can lead to mistakes of missing a part, or anchoring something I actually intended to be unanchored.
In the past, this has also resulted in large, unanchored Parts existing inside other Parts, and tanking a game’s FPS from the constant physics updates. My first thought when the game’s FPS dips is that something is up with the game’s code, rather than what should be a static map.
Given that build mode is dead and we’re no longer able to simulate physics until the game is explicitly played by the developer, it makes more sense for Studio to default to anchoring parts when inserting them. The Instance.new("Part") defaults could stay the same, but specifically when opening up the Insert Object menu and inserting a Part, having it anchored would be helpful.
We will likely never outright make it the default in Studio, but we have looked at solutions in the past to allow you to make this change yourself. No guarantees on timeline, but thank you for the report.
Why is Roblox so adamant about not changing this behavior?
I don’t think anyone expects parts to fall over by default. I remember years ago, I was so confused as to why my builds would fall apart. I didn’t even know what the anchor tool did. So if anything, this makes studio more frustrating for new users.
I’m sure I can speak for many developers when I say it’s fruitless having parts unanchored by default.
I build in studio all day and when I forget to anchor a part it really sucks.
It gets in the way especially when you’re working around programmers who need certain parts un-anchored, since you can’t just select everything and anchor without breaking the game, that one wedge you quickly needed to add really comes back to haunt you.
It’s not directly what you want: But if you’re trying to look for unanchored parts, you can go into the studio settings and turn on “Physics → Display → Are Anchors Shown” to show which parts are anchored and which aren’t.
A temporary solution to this might be a plugin with the given code. This plugin will create a button in the Plugins tab of studio called “Anchor Inserted Parts”. Clicking on it will toggle this feature on or off.
Unfortunately, this has a number of critical caveats that I need to mention, for instance, cutting/pasting parts or copying/pasting parts will cause the pasted part to be anchored even if the copied part was unanchored. Of course, an official feature would be able to mitigate this problem.
You could probably upgrade the code to use a table to store these parts so that it knows which parts already existed, but that has some issues of its own as well.
If Attributes were live, this would be orders of magnitude easier, as it would be possible to set an attribute that effectively says “I already existed”, and this would be persistent so the plugin wouldn’t forget which parts are new and which aren’t between sessions. Oh well.
local Toolbar = plugin:CreateToolbar("Anchor Utility")
local Button = Toolbar:CreateButton("Anchor Inserted Parts", "When enabled, parts added to the workspace or one of its descendants will be anchored", "")
local IsActive = false
local InsertConnection = nil
Button.Click:Connect(function ()
IsActive = not IsActive
Button:SetActive(IsActive)
if IsActive then
InsertConnection = workspace.DescendantAdded:Connect(function (object)
if object:IsA("BasePart") then
object.Anchored = true
end
end)
else
InsertConnection:Disconnect()
InsertConnection = nil
end
end)
Yes, unfortunately, hence why it’s not exactly a good solution. It’s about as good as it’s gonna get, it’s probably possible to hack something together that can detect if a part is new or not like I said originally, but for lack of official support, things won’t look so hot for now.
roblox please fix this issue its very irritating when i forget to anchor parts, i think roblox will never add a setting for any default setting but we just NEED anchored parts because i will always forget…
Thank you for the feature request - as you know already, we haven’t done this because we want to promote natural physics / emergent gameplay when building. However, I completely understand that when you don’t want this, it can be very annoying.
Some questions to better understand how we can address this while maintaining a simulation-first mindset:
Do you find that most of the parts you spawn in are on the ground, in the air, or a mix? Asking because we could make it so that by default, if you place a part or object on something, it welds it to that surface (e.g. to the baseplate).
What percent of objects in your games would you say never get unanchored, no matter what, during gameplay?
Most parts i place are connected to other parts(not in air) but having the parts be welded together would just be annoying and would start to add lots of unnecessary instances when it could just be anchored
I would say 95% of my games parts never get unanchored
Depending on scenario. If I build town - it’s on ground or smth else, if I build floating islands - then ofc in the sky. My main project is skylands, so it inserts into empty workspace, gets built, and then moved as model into ReplicatedStorage.
Due to the fact that my game involves destroyment objects - all objects can get unanchored. But initializtion of game requires them to be anchored to behave properly - nothing just should fall in the void.
And the above use case is SOLELY mine, I would REALLY prefer to have default anchored parts instead of unanchored. I anchor them while making smth 99.9% of time.
I want to point out that this sort of “we do X because we want Y” thinking is entirely at odds with the goal to empower creators to create. You’re creating worse UX for the majority of developers in Studio so that you can push physical simulation on us, but almost every single one of our games have no place for physical simulation as the default. We are building static worlds with carefully curated physically simulated pieces. What you’re doing in this case is flawed because it only serves to inform new developers that the physics engine exists. For experienced developers, it is only a pain to work around.
90% of the time I am building props that I place around the world, or the world itself. These props will never be unanchored the majority of the time, and if they will be unanchored then I have to carefully author them to work with an existing prop system anyway, so I would be very carefully tuning the properties of each involved part. These props are often trees and plants that need to be sunk into the ground, and don’t need to be welded down. As I am building a systemic game, I don’t want them to unintentionally detach from the ground due to influence from explosions or other effects, ever, unless specifically designed for, so they will be entirely anchored.
As it stands under the current situation, every single time I import a new mesh, I forget to anchor it and nearly crash studio under the weight of a million moving parts because by the time I’m testing the game, I’ve built props with it and placed them everywhere. This happens infuriatingly often. I’ve written a plugin to mitigate the chance of this happening, and it still happens too often because I cannot detect the difference between a new MeshPart and a copied one to change the default properties.
Please start thinking about building a comprehensive default instance settings system, this is a massive papercut in Studio that has followed me since 2008. Almost 17 years.
If I had to guess, I bet 95% of the time the Part button is clicked, it’s to build a prop or a piece of the map. Not to integrate it into some sort of physics assembly. Nobody wants auto-weld behavior. Please just give us the option to define default Instance insertion settings if it’s too challenging to make parts anchored by default.
Probably somewhere near 99%. If the parts are unanchored, it’s done deliberately through a script and I design entire game systems around the part being unanchored. Damn near everytime you go to click the Part button, it’s to build a static piece of the map or some sort of structure.
It would cause much less friction if I had to disable anchoring on select parts, rather than enabling every time.
I remember in 2008 I spent days trying to figure out why my first studio builds would come crumbling down when I went to play them. The word “Anchor” wasn’t in my vocabulary and so finding a solution was difficult. Eventually it took a friend who was also into Roblox at the time to tell me what was wrong.
About a decade later, a young family member pursuing Studio came to me with an all too familiar question: How do I keep my parts from moving around? I taught him what Anchored was and all was well.
17 years later, I continue to wonder how many potential new creators are scared away by their builds crumbling down. And I’m tired of seeing my own new builds crumble down. It is very rare you need an object to be unanchored.
It’s almost always on the ground, I don’t really do much work on actual game development but rather scripting, so whatever I build is mostly for testing purposes and nothing final for an actual game release.
Probably ~99%. Currently working on some construction objects that are unanchored just for the purpose of playing animation tracks. Previous to that, I had to use unanchored objects for a custom character system I wanted to make, back in 2024…
From my perspective as a scripter, I’d rather have objects to be anchored by default (or as suggested in the past, an option), because again, I code, I like writing instructions to make things work (as corny as it sounds lol). Either way, some simulated physics I handle are done with some custom physics handlers for a more specific usage and optimization in mind, since the built-in one is more generalized.
Do not do this. If you do, make it an option. Old-heads will remember when everything snapped together based off surfaces; it was deprecated because it wasn’t necessary in many cases. The same thing would happen with any replacement. People who want to weld things together already have the tools to do so.
100%. 100% of my parts are never unanchored at any point in time.
Parts being unanchored by default made sense over 15 years ago when the primary way of building on Roblox involved walking around with your character in-game, dragging plastic bricks around with HopperBin-based building tools, and snapping them into place using the Stud/Inlet surfaces which were always available on parts back then. And then blowing them up with classic BrickBattle weapons.
But that’s ancient history! HopperBin-based building tools were phased out around the early 2010’s, Build Mode was removed in 2015, and surface-based joint connections were removed several years ago, leaving surfaces as purely an optional aesthetic detail which are now hidden by default.
Yes, you can still automatically weld parts together with the “Join Surfaces” toggle in Studio, but why would you want to do that; you’d have to keep track of unnecessary weld instances, the welds themselves would probably increase memory usage and file size, you can’t clip into any parts when building unless you manually weld them as well, and you’d also have to worry about things like Explosions breaking the welds. It’s much simpler to just anchor the part if you know for sure that you never want it to move.
The first thing I do whenever I insert a part is anchor it. It’s nothing but a hassle. If I actually want the part to be affected by physics then it should be an explicit toggle on my end. Almost everyone has had the problem where their house collapses because they forgot to anchor it.
I also typically use WeldConstraint or RigidConstraint for joining parts instead of the actual Weld object (RigidConstraint is typically better since it isn’t broken by Explosions). Again, this is a very manual thing on my end.
I just spent a couple hours troubleshooting code only to realize my trigger part wasnt anchored and was falling into the void whenever I tested the game… I am really bad at remembering these kinds of details and know for a fact this will be far from the last time I forget and lose multiple hours to something that could have been easily prevented with a change default setting. No unanchored parts so far btw.