Currently Attachments have to be parented inside of a part, otherwise the parent is rejected.
In some circumstances however, I have wanted to use attachments as a static anchored point that isn’t influenced by any object. Some use cases include:
Emitting a particle effect at an arbitrary point without those particles being spread out by a part’s bounding box.
Emitting a 3D sound effect at an arbitrary point without needing an invisible part.
Emitting a flash of light at an arbitrary point without needing an invisible part.
Rendering a beam or trail arbitrarily without needing an invisible part.
Currently if I want to satisfy any of these criteria, I have to have an anchored invisible part at the origin. Allowing attachments to be parented anywhere would eliminate this need.
Some code samples where I’ve had to do this to pull off a certain effect:
Total support. It’s really annoying and inconvenient that we are limited by the Attachment’s parent. I’d love to have floating points in space for multiple different effects, but this limitation simply does not allow that.
I would also use this for scripting reasons. For example, I could make a teleport using two attachments as positions instead of parts.
That would be easier than the latter since all I have to do is click somewhere to place them and (although minimal) two attachments are better for performance than two parts.
Yes! I wanted this for use as fast parents for sounds and particles but was sad to see I couldn’t do it without a part as a parent. While you can put it in terrain, that means I end up with a terrain full of random attachments that make it very hard to keep track of.
As a developer, I would like to have the control to parent an attachment anywhere I want in my game. This limitation is forcing me to use hacky work-arounds and the behavior is inconsistent with other features as well. LocalScripts only work parented to Characters and Players for example, but Studio does not prevent me from parenting it to other instances — as it should be.
I use attachments for “effects” and I clone them to apply preset BodyMovers and visuals to parts created dynamically. Right now, I have to parent attachment to “dummy” parts which I never use, or clone the dummy and switch the parents. I can also create the attachment and setup the properties dynamically.
There are solutions of course. But my point is that it shouldn’t require so many steps for me work around a problem that purely exists because I cannot parent a specific class where I want. This issue reminds of the removal of negative WalkSpeed which seem to be another arbitrary limitation.
As a professional platform, please allow us developers more freedom to create.
Another thing I’d like is to be able to parent attachments to attachments. I ran into an issue with a car chassis I worked on where I wanted to realistically simulate axle offset, yet it turned into a mess since I had to code the offsets instead of having them update automatically.
Another example I can think of is applying force at different points while also keeping them at a common base offset.
I’d like to revive this as working with Packages that contain Attachments is a pain without this.
In my packages, I use attachments for positioning lights and sounds in my builds, however it blows that I have to parent them to some random BasePart instead of just putting them inside a model/folder like any other instance. At least give us the ability to do even when it won’t work instead of erroring!
Being forced to parent attachments to baseparts is so inconvenient.
Often it’s really necessary to be able to parent objects to temporary storage folders for later use, but you can’t store attachments, which means you are forced to make messy exceptions in your code.
This seems like a dumb feature for an object that’s used so much. So many of the new bodymovers, constraints and effects require attachments to function.
Just want to bump this thread. Still a huge frustration.
There are tons of times I want to place nodes on the maps for all sorts of metadata reasons. And I hate that I have to arbitrarily make tiny parts every single time.
Along with that, having emitters that can spawn at specific locations parented to attachments is nice, but the requirement of having it under a basepart adds pointless complexity.
There’s just a ton of usecases where you don’t want attachments and baseparts to be coupled together, it’s just adding bloat to dev time.
Bumping this thread and reviving it again, this is genuinely insufferable and I have no clue why this isn’t a feature yet.
It makes scripting and VFX work exceedingly annoying when working with effects, I shouldn’t have to work myself around in circles just to make a couple of things emit or place a few lights in areas.
This would be nice to have considering using a Part as the only way to determine a location is highly inefficient and needs to make sure all its Collide-able Properties are disabled etc.
Parent-specific instances are probably my least favorite aspect in the entire Roblox engine. Attachments, Bones and Animators all do this-- and speaking of Animators, there’s even an FFlag to allow them anywhere!
I’m tired of putting my attachments in Terrain just to make them globally spaced. It’s inefficient, unorganized and stupid. Even if they laxed the restrictions to PVInstance I would at least be able to parent them freely to models.
