Oh, this is intended and happens to any object like BillboardGui, ParticleEmitter, ProximityPrompt, Explosion, Fire, Smoke, etc…
It has been a thing for years. (Maybe make a feature request since you are requesting a change in behavior?)
Since the workspace should mainly be used for objects you want to render (you can have other objects of course, but the way you are using it isn’t intended) and not for storage, switch for services like ServerStorage(use this if the client doesn’t need those objects) and ReplicatedStorage(if you need the objects to exist on the client).
Why are people even claiming is just a bug?! (Staff members don't need to read this, Off Topic.)
No matter how much I tell them is just not a bug because is the behavior Roblox decided to have, is not something unexpected that they don’t know at all.
Literally, they state in the documentation for Workspace that this is intended. I don’t know why people are just replying to me just stating is a bug because they didn’t expect that to happen?!
The dev-forum gets weirder and weirder every time.
You never know who even uses this behavior in their game, who knows, probably their map is centered on 0, 0, 0 and they insert certain particles to maybe nuke the map, make something show up in the middle. Now I don’t have any evidence of it, but because I don’t have one, you can’t either claim it doesn’t exist.
Don’t wanna sound like those people that comes to correct people on every post, but you should be using a Storage service to store those particles and then a script to clone, parent, or do whatever.
For this problem, I would parent the Test folder with particles and proximity prompt to ServerStorage and then have the script in ServerScriptService handling the rest.
Unrelated
This is similar to the whole thing of people parenting objects to nil and then wanting to know if they are destroyed. In my opinion they are mainly bad behaviors Roblox has left, and we have used them to our advantage when we shouldn’t be doing so. (With the time I have realized this)
That’s not quite comparable though. And perhaps this isn’t that organized, but it doesn’t change the fact that this is pretty lazy behavior and it shouldn’t do this.
Ok then, whatever you all say. Just note that the workspace is similar to a Model Instance and they kinda have the same behavior.
These are all the objects suffering from the “issue”: (That’s why I said a feature request would be better because you want to change a current intended behavior)
This is irrelevant. Roblox supports non-ideal design patterns such as scripts in the workspace, so this behavior is not correct given the pattern of storing template instances inside scripts. These instances are effects on their parent.
They should not follow the hierarchy upwards to the workspace to choose their affected parent (I only expect that behavior in the case of folders), nor should they default to workspace, whichever is happening here.
This is just an artifact of old Roblox (and may in itself prevent this from being fixed for compatibility reasons ).
Roblox states in their documentation on Workspace: The Workspace is the service in which any objects that are to be rendered in the 3D world exist. Objects that are not immediately needed in the Workspace are generally stored in ReplicatedStorage or ServerStorage.
They also state: Objects that require adornment, such as ParticleEmitters and BillboardGuis will be adorned to the 0, 0, 0 position when adorned to the Workspace (parented to it without an adornee otherwise being set)
This is why a feature request must be done instead of a bug report.
EDIT: (No Need To Read)
@PeZsmistic
First of all, if is documented it means it is the correct and intended behavior. Why would they document an unintended behavior? Stop being rude by claiming my opinion is irrelevant and pedantry.
This should be a feature request because you want the current behavior to change.
All this long discussion happened after you replied to me claiming they didn’t intend to have such behavior when in reality they even state it behaves like that. From now on I will just shut up and let the regulars reply to the owner of the post.
Bad behavior being documented doesn’t make it intentional or correct behavior. Please stop spamming this thread with pedantry. The use cases are obvious, FR is not required, this issue is borderline between both bug and FR, thread will be seen by the same people all the same.
To me it seems like there 0 reason that anyone would want particles/prompts/billboard gui’s to work like this.
In what scenario would you want all those things to appear at 0,0,0 while also not being placed on a part or attachment?
I wasn’t 100% if this was a bug or not but it just didn’t seem like it was intentional.
Thanks for the report! We’ve looked into this and determined that the behavior is expected. I agree that this is a matter of debate as to which is correct. A prompt with no position - does that mean it should be disabled or does that mean it’s at (0,0,0)? You bring up a good point that there isn’t a great reason for a developer to want these to appear at (0,0,0). However there may not be a clear intention for an object in this somewhat invalid state anyway. You have listed an appropriate workaround - these objects can be disabled or deleted. Please let us know if anything else is needed. Thanks!
).