Particles are rendered at 0,0,0 when ParticleEmitter parented by script in workspace.
simple example in screenshot:
Expected behavior
I expect that the particles will not be rendered until the emitter is parented by a part or attachment in the workspace.
-- This isn’t really a bug, this is just how particles have always worked. Just disable the ParticleEmitter, or don’t store your Scripts in Workspace. (You shouldn’t be doing that anyways.)
Okay, but just because its always been this way doesn’t mean it makes sense and shouldn’t be changed.
Maybe this should be a feature request. Why render particles at 0,0,0 when they have no parent(in the 3D space)
Just disable the particles while its in the script ,and enable it when it gets loaded!
This is how I worked around the issue. But they should not be rendered at 0,0,0 when they have no part/object/attachment as a parent.
-- That is actually a very valid reason to not change it. The expected behavior of any visual object is for that object to be visible when it is placed anywhere the Workplace. Your one specific use case that, to be completely honest involves bad practices anyways, isn’t urgent enough to warrant changing the behavior.
The current behavior makes no sense, why not change it.
Is there a use case for having particles emitted at the point 0,0,0 when the particle doesn’t have a defined parent 3D object?
-- It makes perfect sense. These effects should render at the origin of whatever object they are placed in. The origin of the Workspace is 0, 0, 0. It especially makes sense when you consider that Workspace inherits from Model.
-- Either way, you shouldn’t be placing general Scripts in the Workspace. The ServerScriptService is there for a reason.
A script or a model(with no baseparts in it) is not the workspace and it makes no sense to render the particles at 0,0,0 in this case.
I’m content to leave it at this and let the staff ignore or respond as they will.
-- You placed the Script in the Workspace so, yes, it is in the Workspace. If you place a Part in that Script it also appears in the Workspace.
-- And again, you shouldn’t be placing Scripts in the root of Workspace ever.
workspace being the parent’s parent doesn’t mean it should render there.
The script isn’t a child of workspace, it is a descendant. My example screenshot was just made to show the most simple example that they can reproduce the bug.
You expect something to render at the parent’s parent’s parent’s origin? Its unexpected behavior. There is no use it it rendering the particle in this case.
they forgot to mention that if parented to an instance with no 3D representation(or even a model with other objects in it) that it will spawn particles at 0,0,0 (which would never be needed by anyone)
Anything that renders in 3D space WILL and ONLY renders when parented under Workspace. If the thing in question has a parent that does not hold a CFrame property, you should expect it to render at the origin (0,0,0). If you don’t want to see it, then turn it off. It doesn’t matter if there is an ancestor that does have a CFrame property, it only considers the parent.
A model with a worldpivot and a primary part will still render particles at 0,0,0. Does that make sense to you?
I think they should restrict the parent the way attachments are done currently or else make them not render unless parented to a basepart or attachment.
Anyway If Roblox engineers think this is expected then they can feel free to close and/or ignore this report.
It still needs a BasePart or Attachment to define where to render. Excuse me for being vague with “parents that hold a CFrame property”, it’s usually limited to Attachments and any instance that inherits BasePart.
I somewhat agree that it should consider the model’s PrimaryPart, however I find it more organised to just parent it under the part/attachment it should emit from.
Right well that is where the particle emitter should be, but my point is that it should not emit from 0,0,0 just because it doesn’t have a valid 3d object parent. I don’t expect it to keep going up the ancestry tree till it finds workspace and render at 0,0,0.
Its not even using ancestry, its just using workspace if it’s parent isn’t a basepart or attachment:
This is not a bug. All particle effects work like this except explosion. This includes fire and smoke as well. What happens is that the particle emitter does not have a CFrame, so it relies on it’s direct parent for that info. Since a script doesn’t have a CFrame, particles render at [0, 0, 0] which is the default. If you want it to render at some other location, it needs to be parented to either a BasePart, MeshPart, UnionOperation, or IntersectOperation. You can also parent it to an attachment that’s in turn parented to one of those aforementioned classes. The thing about an attachment is that you can move it around if the part is large.
This is apparently by design and it’s in the documentation, so they are not going to change it.
Is it? I didn’t find it in there.
First paragraph of the ParticleEmitter class.
Hmm… I couldn’t find it either. But the documentation does say that it has to be parented to a base part or an attachment. So if it’s not, the default is 0, 0, 0. Even though, it’s still not a bug since the documentation does say to parent it to those classes. If it’s not, unexpected results may occur.
