I think it would be useful (Mainly for people with less Lua knowledge) if I could store sets of particles into folders and have them work when the folder is parented to a part. At the moment the particles are not positioned where the part is but it defaults to the 0,0,0 position as the folder doesn’t have a position property.
Not really important, but I ran into it today and thought I’d bring it up since it caused me a while of not knowing why my auras weren’t working. Even through the part was in the right position and everything was inside of it. Turns out the particles were at the position 0,0,0 under the map where I didn’t think to look.
It exhibits the same behavior with models too. I guess the behavior of particles is center=(script.Parent.Position or Vector3.new()) or something like that.
GUI objects render inside folders if they’re a descendant of a ScreenGui – I don’t see why the behavior should be different with particles. Folder behavior should be consistent across all objects. Either folders should not affect game logic at all across the board like they currently do with GUI Objects, or they should not render contents across the board like they do with ParticleEmitters. It shouldn’t be arbitrary where it works with GUIs for whatever reason, but not ParticleEmitters, or the other way around.
I’m sorry, but you seem make too many baseless assumptions about how things work or should work. You may believe that the requirement is completely arbitrary, but there’s a very simple reason behind it - a particles system receives its position, rotation and emission box size from its parent part. The arrangement of relationships that works with GUIs is not arbitrary either, but it’s completely irrelevant to particles systems.
I’m referring to front-end usage – not back-end functionality. From a user’s perspective, it is confusing to be able to use folders for GUI storage as if they don’t affect the objects, but not be able to do the same thing with particles. I am not saying anything about your reasons for designing GUIs and particles they way you did: I am pointing out that discrepant behavior from folders is awkward behavior from a user’s perspective.
I, in no way, have taken part in the development of ROBLOX, and cannot say one thing or another regarding back-end functionality, but I do use it on a regular basis, and I sometimes notice front-end usage behavior that isn’t always necessarily intuitive that may not be picked up by someone who doesn’t create assets with ROBLOX’s APIs and objects as often as I do. This is one of those cases.
Well that’s the thing, you are erroneously assuming that folders not affecting object relationships in the hierarchy is how things are supposed to work. In reality, however, GUIs just happen to work mainly due to the way the GUI subsystem is internally implemented. An unintended side-effect, I should say.
Unintended side effect? It wasn’t always like that. They were intentionally updated at one point to work with folders. (update thread)
Side effect or not though, what I’m saying is that the behavior should be consistent across different objects within folders. If you need to squash unintended side-effects or implement new behavior, so be it. That being said, I’m not implying this is super important and needs to be changed ASAP. I’m just stating what I think the optimal behavior is that you can implement at your leisure.
Indeed, then this means, GUIs are an exception, not the rule.
Things that require a very specific parent/child relationship by design won’t work when you put a completely unexpected instance between them, unless support for folders is manually hacked in for these objects. This may be problematic, depending on the way the objects are implemented.
unless support for folders is manually hacked in for these objects. This may be problematic, depending on the way the objects are implemented.
I imagined that based on the contents of you previous posts. I’m just stating the ideal behavior – not the ideal implementation or priority of anything.
I think the two of you know each other’s point by now so I’ll ask a different question
Maybe it would be an idea to change ParticleEmitters, Sparkles, Fire, Smoke, etc to just not render unless they are parented to a proper parent? I don’t see the point of having them render at all at (0,0,0) when they’re parented wrongly, except for testing which is a niche use case that can be fixed by first inserting a part and then the emitter into that. If they don’t render at all unless parented right, then as a user we won’t start assuming the wrong things.
ParticleEmitters are not GUI objects and this referenced update does not and was never intended to modify the behavior of ParticleEmitters. They require a parent that is an object in the 3D word to work correctly.
The comparison was never particles v GUI objects. It was Folder behavior across multiple objects. “They require a parent that is an object in the 3D world to work correctly” could be rephrased to “They require a parent that is a GUI object in a ScreenGui to work correctly” and you just described the old behavior of GUI objects. I understand that functionally GUI objects and particles work fundamentally different at a low level. I understand that making the behavior consistent between the two is not easy, based on the existing posts. I am only pointing out that one object that renders based on its parent works in folders, and another object that renders based on its parent doesn’t.
The post you quoted referred to “GUI Objects in Folders”. It did not and was never meant to apply to Particle Emitters. ScreenGUI objects are NOT 3D objects and do not live in the Workspace. Objects in the Workspace work fundamentally differently than 2D GUI objects (that do not live in the Workspace).
The use case for ParticleEmitter in the wiki is fairly clear on how they are used and what can be a parent:
A particle emitter spawns particles at a constant rate anywhere within the volume of its Parent. This Parent must be a BasePart for the emitter to work.
The OP was making a request for ParticleEmitters to behave differently so they would only have to clone one folder and put it in a part instead of put multiple emitters in a part.
This is not a discussion of implementation. It is a matter of “I’m a new user. Why do folders work with GUIs but not particles?”
The wiki also covers how to make a module requireable from the site by naming it MainModule, but it’s going to be changed to be more intuitive anyway. It’s good for things to make sense without having to read any documentation on them.
Sometimes, some areas of programming require people to read some level of documentation.
We work hard to correct incorrect documentation and make it clearer when it’s not. The Module documentation appears to need some work. But the ParticleEmitter documentation, to me, appears to be clear and straightforward.
sorry for the huge bump, but i do believe this topic should be brought up again
folders should act like models/unions, currently they act independently and it requires a lot more steps to move the particles somewhere when they’re in a folder
