Andrew Start

In some quick testing, it seems like when multiple objects that use composite colliders are present, only the collider of the first one is picked up.

Yes, it is intended that you don't use an emitter after destroying it. If you just wanted all your particles gone but to continue using the emitter, use [`Emitter.cleanup()`](https://pixijs.io/particle-emitter/docs/classes/Emitter.html#cleanup).

Would you be able to share your project for me to look at?

The isInteractive stuff I have no idea about, but probably stems from a similar issue that the `Texture` class that this library imports from `@pixi/core` isn't the same as the...

PixiJS doesn't have a new way of exporting textures - your Typescript config combined with newer module features in Node/Webpack/etc were resulting in your imports of `pixi.js` pulling in the...

Sounds like the same configuration issue, see above.

It depends on your use case, but in general the constant adding/removing children that this library does isn't what ParticleContainer (or normal Container) really likes - see https://pixijs.io/particle-emitter/examples/particleContainerPerformance.html

I can defend against this by flagging such lists as stepped, but the expectation here was that any editor would check the user's data and use the simpler static behavior...

The second parameter for `upgradeConfig()` must be an array of textures or urls to textures - it is throwing the error because you have an empty array there.

Because texture usage and urls are specific to your build process and hosting, there is no way for the editor to give you a url - you have to generate...