Objects not filtered correctly

Apologies for the messy .capx, but this is the first time I've managed to reproduce this reliably (.capx link sent via PM). The problem seems to be localized in two events - 122 and 137.

Event 122 should select the instances of enemybase where enemybase.hittimer is less or equal 0. This appears to not always be the case.

Run the .cap, hold the left mouse button in the direction you want to move. When you're close to the enemybase black oval, it'll move towards the hero. At that point - and only when the enemybase is moving towards the hero (otherwise the bug won't show) and the detector sprite overlaps it, click in the direction of the enemybase to attack it. Doing do will result in the enemybase.hittimer value getting stuck above 0, and the enemybase isn't hit backwards properly.

Next, enable condition 3, "enemybase.hittimer is less or equal 0" in event 137. Run it again, and it works properly.

It shouldn't make a difference if that condition is enabled or not, as that condition has already been checked in event 122.

Ashley I was wondering, did anything come of this? Or was there simply too much stuff in the .capx?

Sorry I haven't had time to try debugging it yet, problems like this are one of the most difficult and time consuming to fix. It would make it 10x easier if you could reproduce in a new project.

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

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

I still don't think I'm clear on what is happening and what is meant to happen. What do I do in the project and where does it go wrong?

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.

OK, I *think* I've fixed this for the next build. It's a pretty complicated issue but I think I got it, let me know your results on the next build.

Right, thanks!

Ashley You fixed it! Thanks again!

Great, thanks for the confirmation Arima!