What you need to do is save a copy of your project, then start deleting everything bit by bit until all that remains is the absolute minimum required for the bug to still exist. I did that with a recent bug and I was able to get a couple dozen object/couple hundred event project down to two objects and 22 events. It'll make it much easier to find out what the problem actually is, and if it is a C2 bug, for Ashley to debug it quicker.

A built in 'else' condition has been on the todo list for a while, it's just got a low priority because it's easy to work around (copy the event and invert it) and the implementation is actually quite tricky (it must use the exact opposite picked objects from the previous event).

Hmm... I kind of liked it the way CC worked, where the else event simply ran if the event above it didn't run, and it didn't affect the picking. With that, I could do things like check if no objects met the criteria of the event above it easily, and modify the picking of the else manually with conditions rather than have it be automatic.

I meant what what did you mean by the spam comment?

What?

Right, thanks!

Sounds like a bug. It should work as you described.

I doubt there's any easy way to stop people from uploading incomplete works. Perhaps instead there should be extra categories of some sort for unfinished and completed games, and people browsing the arcade could sort them as such.

The CSV plugin can also read JSON strings.

Seems like a good candidate for a stickied topic.

Whoops - missed that part. If you run the project and click, the black oval doesn't do much, it keeps moving towards x 300, y 300. That's the bugged behavior.

It's supposed to act like it was hit backward at an angle from 300, 300 when you click, sliding backwards and decelerating before moving forwards again.

To get it to act like its supposed to, do any one of the three things mentioned in the .capx. Then upon clicking it acts properly.

Disabling action 2 of event 3 makes it so there's only one instance in the layout instead of two. The number of instances shouldn't matter.

Moving event 19 out of the group certainly shouldn't make any difference, as it's still basically at the same level.

Condition two of event 20 being enabled or disabled shouldn't make any difference either because it's the same as the condition of event 15, and the object has already been filtered based upon that condition.

None of those things should make a difference, yet they affect the behavior.

Gah, I should have tried to simplify it earlier. Sorry! Here's a new version with only 2 objects and 22 events.

amirai.net/bugs/incorrectlyfilteredsimplified.zip

Yeah, I thought that might be the case. I'll give it another shot trying to make it simpler.