How do I Detect When my Bullet has Bounced?

I have a bullet which bounces off solids. When it bounces, I want it to decrease in speed, and generate a particle effect. How can I detect a bounce, in order to do this without performing a bajillion 'on collision with' conditions?

Edit: Other factors control the angle of the bullet - so detecting an angle change isn't accurate enough unfortunately

If all else fails pin an invisible circle sprite to each bullet, make it just a little wider than bullet sprite and use an on-overlapping with anything condition. When it detects an overlap or collision (if you choose) then have it play/generate an invisible particle player set to play then delete and to act on the "closest" bullet instance to change speed.

Would that not have the same effect as doing the collision checks on the bullet itself?

My bad I misunderstood the problem. I saw "bounces off solids" and assumed it was a problem detecting the collisions on the bullet instance due to physics behaviors.

Short of putting everything your bullet could "bounce" off of into a family... I got nothing.

Any particular reason why you don't want to use collisions on the bullet? If you have bouncing and solids enabled, those collisions will be calculated regardless, in case you're worried about performance, so you might as well utilize them for your effects.

Here is a past example I made for someone else that may be relevant, but it does use collision conditions - https://www.dropbox.com/s/6cliwidu8f51p ... .capx?dl=0

Because the events might end up getting complex in the future as I add more solid objects, and not all objects carrying the solid property have this enabled.

Construct classic had this functionality OOTB - you could select the 'Solid' attribute in place on the selected object in the 'on collision with...' dialog - hence my hope there is some way of simply checking for collision with a solid.

Ah I understand. Then as previously mentioned, I think putting the relevant objects into a family (then check on collision with family) would be my suggestion as well.

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.

How many bullets will be bouncing ?

Just the 1!

Then that 'angle change' seems a neat idea.

Just use the sprite.bullet.AngleOfMotion expression, it can differ a lot from the sprite.angle.

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.

If it's just one bullet, I wouldn't be concerned with performance issues simply calculating collision.

As already suggested, anything the bullet can "bounce" off of, just add it to a family and make a single event (if bullet collides with family -> do stuff).

That would easily be the, easiest solution.

If you had zillions of bullets, then using angle comparison might be better, but for a single bullet (or even 100 bullets) I wouldn't bother with a complex solution like that.

~Sol

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.

You have one bullet colliding... there's not "multiple collision checks".

If your bullet is bouncing and producing the same particle effects no matter what it's hitting (I assume it is, because checking for angle change is going to give only a single result with nothing else to compare) then you only need ONE family with EVERY object that can be collided/bounced by the bullet.

It's up to you how you do it, but either way would work fine and performance would be (probably) the same.

~Sol