I found this a very helpful and complete tutorial on Bitwise - scroll down for the info on multiple terrain types <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

http://gamedevelopment.tutsplus.com/tut ... -cms-25673

Can't you just use 'within' and '45 degrees' instead?

On impact simply compare the angle of bullet and target, eg:

( Bullet.Angle - Target.Angle ) is within 45 degrees of angle 180 = Front

( Bullet.Angle - Target.Angle ) is within 45 degrees of angle 270 = Left

( Bullet.Angle - Target.Angle ) is within 45 degrees of angle 90 = Right

( Bullet.Angle - Target.Angle ) is within 45 degrees of angle 0 = Rear

You might need to switch your left/right on that, but something similar should work.

Just change 'on tap' to 'on touch start'!

Another options is:

Zombie is overlapping Zombie

Pick top instance of Zombie

Zombie: Pathfinding: Set Speed to <decreased speed>

Might work well enough with some tweaking - although collision checks will suck if you're planning L4D/DR-style hordes

Radulepy I would create the vector field by pre-filling an array with vectors (which are number pairs describing a 2D direction and speed of movement).

For each zombie, find all zombies within whatever range you want them to avoid one another. For each one of these, compare its location (relative to the first zombie) to a location on the array, which will contain a vector. Add these vectors together, and apply them to the X and Y position of the first zombie, and they will all automagically avoid one another.

For more detailed description please see the link I posted above. It describes the process far better than I can.

I have a suspicion that 'on tap gesture' relies on the user touching and releasing - similar to the difference between 'key is down' and 'key is pressed' in the Keyboard object, or 'mouse button pressed' / 'on click'.

I'm assuming your users will touch to begin aiming, and release to fire? I can't view the video (very poor internet connections here) so can't verify what you're trying to do, but this is my best guess. If this is the case, you'll want to use 'On any touch start' instead.

https://www.scirra.com/manual/119/touch ]

You might want to consider vector field collision avoidance. You can use it alongside existing pathfinding (if you're careful) to create the behaviour you describe.

Read more here:

buildnewgames.com/vector-field-collision-avoidance/

Only if every object in that family has its solid enabled, which it doesn't, and only if all objects required for collisions are of the same object type, which they're not. As I said - I tested both methods, it's more efficient and easier to read an angle check. All of these things have been discussed earlier, you should really read the thread before posting.

As discussed before, this would involve multiple families, multiple events, and it turns out an excess of collision detection. Angle check works like a charm using a single event. Alternative took ~15 events and made an absolute mess of the rest of the capx adding unnecessary properties to objects by family etc. Marking solved.

I am already. There are a few other sprites pinned to the bullet which give me usable angles for everything else thankfully, the bullet is JUST used to control movement angle of the collection of sprites so haven't used its common angle property at all.

Just the 1!

Grah.

Another more elegant suggestion from reddit: compound the angle changes made in a tick to a single variable without passing them to the bullet, store it for the next tick along with the bullet angle, then check the bullet's previous angle against its current angle, offsetting for the previous tick's angle-adjustment - if there's a difference it should mean the bullet a bounced. Out of frustration I've moved to another part of the game to work on that, but when I return to collisions I'll try both implementations I think.