Jumping throw an exception about open-project-1

[ErikBehar]

yes the issue is that the pool gets created in the Active Scene, when the active scene is destroyed, the pool goes with it.

There is clearly a line already in the code that is commented :
ComponentPoolSO: ( line 24 ) //DontDestroyOnLoad(_poolRootObject);

The problem here is that this is a generic system, so I think some pools we do want to destroy and some pools we don't !

One solution might be to pass in a transform where you want your pool to exist at, that way if you want your pool to survive scene loads, you can instantiate it with a root transform in a scene that is not destroyed, otherwise you can pass in null and that should put it in the active scene.

[Matcheryt]

I reproduced it on my machine, and by asking unity to not destroy the SoundEmitterPool on load, seems to fix the issue.
I'm new to the project and would like to continue with the fix. I'm not very experienced with Unity, if someone has a better approach on this let me know!

[rainaldisatria]

A good first issue.
Yeah, since it's generic, we want to have control of both approach (Destroyed after scene loaded, or the opposite).
My proposition is to add boolean property to ComponentPoolSO called Global or something like that. Then in the SoundEmitterPoolSO, we set the Global = true (Not destroyed after scene loading) in the OnEnable() method

[davejrodriguez]

Hah I actually was just working on this. I'm not super familiar with this issue, but if it's caused by DDOL, it should be fixable once #215 is merged.

Solution would be to call Pool.SetParent(t) where t is a transform of an object marked DDOL.

[ErikBehar]

Hah I actually was just working on this. I'm not super familiar with this issue, but if it's caused by DDOL, it should be fixable once #215 is merged.

Solution would be to call Pool.SetParent(t) where t is a transform of an object marked DDOL.

so in your solution the parent is always assumed to be the object the script is on ? Do you prefer to surface the transform as a user facing variable instead ? I see a code path, but not something a user can tweak with out code, I guess can expose that on the using script.

[davejrodriguez]

so in your solution the parent is always assumed to be the object the script is on ? Do you prefer to surface the transform as a user facing variable instead ? I see a code path, but not something a user can tweak with out code, I guess can expose that on the using script.

No assumptions. I think it's easiest in a manager architecture to just use the manager's transform, but there is no preference as far as the pool is concerned. As for changing the targeted transform for parenting in the editor, yes, I would expose a field for the script in the inspector and use that instead.

[ciro-unity]

Should be fixed by the changes that @davejrodriguez did to the Object Pool. I'll verify later and close it, if necessary.
Thanks @rainaldisatria for reporting it!

[ErikBehar]

ok you added the setParent line yourself @ciro-unity so yes feel free to close this.