It used to work in 5.6.3 but since particles have undergone so many changes since then it’s hard to say if this is a regression or just how things are now…
the sub emitter is a child of an emitter so the error isn’t worded well enough to fix this…
any idea?
1 Like
Hi, it’s how things are now, for multi-threading purposes. The sub-emitter must be a child (or grand-child, etc) of the system that is spawning it. (I don’t know how the message can be made any clearer, you are welcome to suggest better wording though)
It may change again in the future, if we can figure out how to relax the requirement, as a few users have reported it as annoying for them.
However, are you saying that this sub-emitter is a child of the emitter that is spawning it, or is it just the child of “an emitter”, and not the correct emitter?
I like if an error message contains the affected GameObject names. This is especially helpful if such error occurs in a build, because there you have the log only.
For example, the following error message is clearer in my opinion, as it kind of acts like a baby-step list what you’d have to change to fix the problem:
Clicking this error message should highlight/ping the Sparks GameObject as well. Even more useful than just the GameObject name is the full path in the Hierarchy, eg Scene1/VFX/Grenade_Big/Explosion. The reason for being full path more useful is that sub-object names are often identical between things.
To further improve such error message, we have a rule at work to mention WHY you should change it. This educates and provides more purpose in doing something, because people suddenly understand, rather than being just monkey workers 
We prefer highlighting the affected game object in the Hierrachy where possible. This is true of this error message.
I agree that in this case, because 2 game objects are relevant, we could use names in the error message to improve clarity. Thanks for the suggestion. (Currently the parent emitter is the one we highlight)
1 Like
This does help when working in the editor, but is obviously non existent in a build. Therefore names in debug messages are really useful and should be added to provide just the right information when dealing with these kind of issues.
Imagine you work with (an external) QA. They report a bug about some effects are look not right sometimes. However, they did attach a .log file! Unfortunately, the only information you can find in the log is “Sub-emitters must be children of the system that spawns them”. This is not very helpful, it provides no information what effect is causing the error.
It’s a child of an emitter and is not a sub-emitter. The hierarchy is spawned like a normal object.
I’ve been looking at this issue today, but haven’t been able to find the cause yet.
I did want to get back in touch though to say that your setup is indeed ok, and the problem appears to be on our side somewhere.
From what I’ve found out so far, I think the error is erroneous and shouldn’t give you any problems, other than the annoyance of seeing it pop up each time.
I’ll keep investigating, anyway…
1 Like