Neat. Maybe the OP can use a little bit more body so less technically inclined / observant / informed people can understand what’s happening easier since this is in the announcement category
EDIT: 
1 Like
Yyyyaaaaassss, this is going to be super useful. Thank you 
1 Like
Any idea if it is possible to make Attachments work outside of parts too, like when parented directly to Workspace, Models, etc? (i.e. they would act as if they were adorned to a part at CFrame.new())
2 Likes
Terrain? Would still be nice to be able to parent to Models/Folders without it being a descendant of a BasePart
2 Likes
Oh, never thought of that, although a little arbitrary (but useful)
1 Like
Certainly would be possible, but it would have to be proposed. This one gives me the feeling that it would get shot down. Just parent it to a part, and if push comes to shove have .2x.2x.2 anchored, transparent, non-collide part in the workspace at the origin and parent the attachment to that.
3 Likes
Would be sweet to be able to use attachments with joints like welds/motors as well.
2 Likes
Been wanting something like this for particles practically since they were added, so I’m definitely excited! 
1 Like
Isn’t this the hack we’re trying to avoid by allowing parenting of these items to attachments?
2 Likes
Kind of, I guess? But it doesn’t make sense for the Attachment object to be parented to the Workspace. Model, maybe, but then it would just use the PrimaryPart of the model, so why not just put it there?
It would kinda make sense I guess if it would assume world coordinates if it’s not parented to a physical object, but that could be an issue if it’s in a folder that’s parented to- say a part.
1 Like
2 Likes
If enough users are having to resort to a hack like that, isn’t it reason enough to make it a feature? I can’t think of another game engine where lights or sounds are tied to collidable/raycast-blocking objects, so it’s a little odd that these kinds of effects require them to begin with. Would be great if these effects just had a CFrame property of their own, didn’t affect in-game physical calculations, and appeared as a marker in-studio like attachments do e.g.
5 Likes
This has been suggested internally and shot down above my paygrade in favor of the Attachments ideas.
4 Likes
The looped death sound at the end hipnotised me
I just want a thing that has a CFrame and a Size, which works with everything that uses the CFrame and/or Size of parts.
7 Likes
Would be great if these effects just had a CFrame property of their own, didn’t affect in-game physical calculations, and appeared as a marker in-studio like attachments do e.g.
That’s a bunch of extra features that we’d have to support (also placing all of these objects in the world, editing the properties, dragger, etc.) - it’s not clear that the usecase is so central to require that. The way I look at this is that we need to provide first class support for the 90% use case, and the remaining 10% don’t need to be solved.
Our model used to require a part purely because part was the only “placeable” object in the world, now you can use an attachment to refine the part’s position. This maintains a single way to model spatial relationships which seems nicer/more unified than “some things get a CFrame and this CFrame changes meaning when the parent is a Part”.
P.S. Our current model is, as far as I understand, similar in some way to Unity’s component model where effect objects by themselves don’t have a transform, but they can be combined with a transform-carrying object to get one.
7 Likes
Makes sense. Sensible reason for not de-linking them from parts.
My main issue with using parts for effects is that because they’re parts they can interfere with the game (namely raycasts, Touched, GetPartsInRegion3, etc). To easily keep track of them to add them to ignore lists and whatnot, I either have to listen to workspace.DescendantAdded (yuck!) or parent all of might effects to a common container instead of grouping them where they make more sense (e.g. inside a light post model). If I want to use or distribute free models with these effects, it becomes even more painful.
A global way to flag parts for being there but not really there for calculations like raycasts, Touched, GetPartsInRegion3, etc would probably be a better way to handle this than building part-like support for all existing effects.
4 Likes
Eta on the release?
Soon™
4 Likes