#955 Sprite: Overlaps OR Collides & Destroy with sub-event, crash

[AshyRaccoon]

I am using Construct 0.98.9

If I have an event checking for a sprite Overlapping "OR" Colliding with a TiledBackground, with the action "Sprite: Destroy", and have a sub-event to this, my application will crash when it is previewed.

Steps to reproduce:
File, New Direct-X game
1. Create a sprite.
2. Created a tiled background.
Position them so the sprite overlaps the tiled background.

In the Event Sheet Editor, add a new event, containing the conditions:
-Sprite: Is overlapping with another object.. TiledBackground
-System: OR
-Sprite: On collision with another object.. TiledBackground

Insert a sub-event. Either with no conditions, or:
--System: Compare value. 0 equals 0.
Either in the main event or the sub-event, add the action: Sprite: Destroy

When I preview this application, it crashes with: "Runtime error", "An unexpected error occurred and the application was terminated. You may be able to find out more information about the crash by Debugging, and attempting to reproduce the bug."

If I do either either one of the following, it does not crash:
-Move "Sprite: Destroy" to the main event, and remove the sub-event.
or -Keep the sub-event containing Sprite: Destroy, but replace OR with ELSE

Curiously, if I leave my included crash test .cap file open, and close Construct, Construct will usually generate a few errors after closing. It does not behave that way with other cap files.
My included cap file has some other events which are toggled off, variations which do or do not crash the app when previewed.

I have a similar variation on this: In the main application I am working on, I have this sort of event/sub-event combo applied to some sprites I'm using as raindrops (with bullet behavior). It doesn't crash if I keep my other event sheets included (which handle controls, animations, etc.). If I keep only my effects sheet, with the raindrop stuff, it does crash. I do not know what is going on there, and would have to sort that out.
When it's set up so it doesn't crash, what happens is that all the raindrops are destroyed at the same time.However, it is still related to having "Sprite collides with tiledbackground OR Sprite overlaps tiledbackground" with a Sprite: Destroy in this event, and a sub-event (even an empty one). If I remove the sub-event to it, then the raindrops work okay.

[AshyRaccoon]

[AshyRaccoon]

Another possibly related OR crash case

[AshyRaccoon]

Concerning ashyraccoon_crashtest2.cap:
ashyraccoon_crashtest2.cap shows another previewed application crash I encountered using OR.
I am unsure if it is related exactly.. as I can't seem to get it to reproduce by starting a new Direct-X game, and attempting to duplicate what exists in this cap.. I wonder if my cap is corrupted somehow?

For this second cap, I actually took the game I was working on, and deleted all of the other objects, tiles, events, event sheets, layers, etc., cutting it down to only having what was making it crash.
I changed both layouts to use the same event sheet.
Then I added another sprite.

In short, I have a sprite named Player with the Platform behavior. I have two Layouts, using the same event sheet. I have another event to change the layout when the player goes off-screen (choosing the first or second layout randomly, but it does not matter if it's random or not, so long as the transition is to a different layer.)

I have an event:
-Player: Value 'wallclimb' Equal to 0
-OR
-Player: Value 'wallclimb' Equal to 3
with a sub-event.
It does not seem to matter whether the sub-event has a condition or not.

If any other sprites besides Player exist, it will usually crash on me upon the change of layout.
If I remove the sub-event, it stops crashing. If I delete the other sprite, it stops crashing. If I change it to something like,
- NOT Player: Value 'wallclimb' 1
- NOT Player: Value 'wallclimb' 2
with a sub-event.. it does not crash.

After loading this cap file and previewing the app, Construct will give a few errors after I close it (close Construct, that is).

I was doing the layout transitions differently in my actual project, by the way. (By collision with background tile, reading a variable on them.) So it is not to do with heading off-screen..