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
1 Like
This is now enabled for
- Light objects
- Sound objects
- BillboardGui objects
on production. ParticleEmitters likely next week (they took a bit longer in code review).
14 Likes
Looking forward for this to be fully released, seems like an interesting feature to mess around with.
This is really interesting, can’t wait to use it. This will be super helpful!
Can you add Sounds to Attachments please?
1 Like
???
1 Like
o wot.
I need the sleep. Thank you.
4 Likes
Also ParticleEmitters will have to wait a little bit. They crashed like a lot of people for unknown reasons. Will update soon.
2 Likes
This is perfect!
How long until particle emitters work ?
2 Likes
Probably this week. Waiting on some platforms to push to the latest version.
3 Likes
I estimate Monday
5 Likes
Hello! Its almost Tuesday knocking on your door, will particle emitters be live today?
2 Likes
My estimate was very early, but likely this week. Apologies for the delay! Maybe next time I won’t add a null pointer reference to my code
6 Likes
the wait is fine (: better a long wait then a bugged feature
3 Likes