Objects going past obstacles, why?

[AyreGuitar]

Outcast - After some further examination of your example, I think the problem might be this line (although haven't seen it happen):
2. Pick one of "Ball" + 1 chances out of 100 at random = Set direction to (any direction at random)

Even though you have this before your collision with backdrop (line 4), the collision (in red) will happen first, so a Ball could bounce, but then randomly be selected and have it's direction changed so that it ends up inside an obstacle. You might want to set a flag when a ball bounces and only select Balls with that flag clear when you set them to a random direction. then at the end of your conditions clear that flag for all Balls.

Another thought is it might be your Load On Call being ticked for Ball - if there are none on screen and memory is low, it might be unloaded and only reloaded when comes back on screen. Try unticking this option and setting Inactive if too far from window to No.

Hope that helps!

[Outcast]

Outcast - Loading your example file and it said that that effect file Lens.fx is missing. I ignored it, and ran it. I don't see any of the yellow blocks getting outside the play area, although they do stop after a while. So perhaps the Lens.fx effect is the problem? I've never worked with effect files (seems to be different from the Lens object extension which I have installed)

Lens.fx is unrelated, its missing because I took this stripped down example out from my original project. Here is a video of what is happening: https://dl.dropbox.com/u/4047131/MyP...-21_200544.wmv

I did ask about on the chat yesterday and it seemed the problem is the fact that I use backdrops for obstacles and they go inactive when far from the screen. I had no idea about this and it came like a chock really. I thought using obstacle backdrops was the "regular" way to do stuff like this. I got the suggestion to replace all the backdrops with actives, but that was not an option to me because I have over 1000 of them and to replace them all would be to much work. Another suggestion was to take a screenshot of my level with just the backdrops in it and make a big active of it to use as the collision. This actually seem to work very well.

[EE]

Wait what? Who told you to replace all bg's with actives?
That's utterly inefficient and plain dumb. Use backdrops, that's what they're there for.
It's better to find the problem instead of using random workarounds.
I haven't looked at your file yet, but I'm gonna do that tonight.

[EE]

I couldn't reproduce your bug, though I noticed that all "balls" are set to automatic on "inactivate if too far...", are they supposed to inactivate? Also, why are you using 12 layers? I don't know if that's fixed, but some time ago the use of many layers could really mess with your fps and stuff.

[Outcast]

Wait what? Who told you to replace all bg's with actives?
That's utterly inefficient and plain dumb. Use backdrops, that's what they're there for.
It's better to find the problem instead of using random workarounds.
I haven't looked at your file yet, but I'm gonna do that tonight.

But the problem was apparently that backdrops go inactive when far from the frame. So even if you have your actives set to not go inactive they wont collide with an inactivated backdrop. I was as surprised as you because I also thought one of the main uses for backdrop set to obstacle was for platforms.

About many layers I also got told that my big frame size would make my game run like a snail, but so far when I test it in FLASH (my full app, not this small example) it runs in 60fps

[EE]

I have never ever had this problem with backdrops, and I've made huuugh levels. I've only ever heard of similar problems when there are conflicting events or properties. You could try and set all bgs and balls to fine detection, just to try it out, I recall someone somewhere talking about collision issues when using both of them.