Streamed level crash with particle emitter

Branch: Binary

Build: 4.6.1

Description of the issue:
It looks like particle emitters are trying to bind some delegate multiple times. Toggling “Should be Visible” off then back on again for a streamed level that contains a particle emitter causes the editor to crash (log file attached).

Reproduction Steps:

  1. Create two new levels; add one as a sublevel of the other

  2. Place a particle emitter in the sublevel

  3. In the persistent level blueprint, make a key toggle the value of the sublevel’s “Should be Visible” variable

  4. Play in the editor and press the toggle key to make the sublevel invisible, then visible again

The crash happens 100% of the time when a particle emitter is present in the sublevel; once the emitter is removed, everything works as expected.

EDIT: I should also mention that this doesn’t seem to effect particle emitters that are components inside blueprints

Hi,

Unfortunately, I’m not able to get the same results you’ve described in my testing.

I have setup a level streaming with my persistent level and one sub-level. I’ve setup up in the level blueprint two variation. One where I can toggle by key press for the levels to switch and a automatic time delay switch. For the particle I created a basic particle system and didn’t change any settings from the default.

With this setup I did not get the crash mentioned.

Can you elaborate on your setup?

  • Is this happening if you setup a blank project with a newly created default particle system?
  • If not, what template are you working from and what particle system are you using? Is it one included with the starter content or from another Epic released project?
  • Can you also provide the call stack (copy and past to a txt file from the crash reporter) and the dmp file (project folder > Saved > Logs) ?

Thanks!

Tim

Hi Tim,

Thanks for the quick reply. This happens with a blank project and newly created default particle system. [Here][1] is a video showing exactly what I’m doing.

Here’s the [log file][2] and [dmp file][3] (I had to change the extension to .txt to upload)

Thanks again,

Dan

[1]:
[2]: 25181-log.txt (1.54 KB)
[3]: 25182-dump-772486320.txt (331 KB)

Hi Dan,

Thanks for the video and setup. I was able to reproduce this with 4.6.1 just as your video showed. I used the same setup in the 4.7 preview 1 that is available via the launcher and the I tried with our latest internal build. This appears to have been resolved already.

If you need this functionality you can give the 4.7 preview 1 a shot, but there are known issues and other potential bugs since it’s still actively being developed until it’s final release.

Thank you for submitting the report!

Tim