# How do I Crush Sprites? [IMG EXAMPLE]

Get help using Construct 2

### » Sun Feb 05, 2017 8:48 pm

Hey guys. I'm trying to properly implement crushing sprites. I want to be able to defeat some blob enemies by crushing them with a box. Now I know there are many ways to implement this but I'm trying it against a tilemap surface when the box is approaching the sprite at high velocities. Also, the box should be able to crush it from different angles. Meaning the sprite can also be crushed on the ceiling. Now this is the code I used:

My problem is illustrated in the picture below.
While I'm able to achieve the desired results as you can see with the first and second examples:

At the third example the pink box is also destroyed even if it isn't being crushed but only because it's overlapping the tilemap at an offset when it's the one falling on the metal box. How do I make it so it only gets destroyed when getting crushed?
"The intent is to provide subscribers with a sense of pride and accomplishment for unlocking different features...."
B
42
S
18
G
32
Posts: 818
Reputation: 20,779

### » Sun Feb 05, 2017 10:19 pm

Depending on where the hotspot is, the pink box should always have a greater y than the brown on when they are overlapping.
B
177
S
50
G
205
Posts: 8,684
Reputation: 127,196

### » Sun Feb 05, 2017 10:59 pm

Dont really understand why it works at all. On collision the squared speed should be close to zero.
I dont know how many VulneraBox's you have.
Assuming there are more then one ....
I would:

Give the VulneraBox a instance boolean 'CanCrush'.

VulneraBox > Compare velocity ... overall velocity .. > .. 400
_______ VulneraBox > Set boolean 'CanCrush' .. true

VulneraBox > Compare velocity ... overall velocity .. <= .. 400
_______ VulneraBox > Set boolean 'CanCrush' .. false

VulneraBox on collision with TM_box
VulneraBox > Is boolean instance variable set ... 'CanCrush'
________TM_box > destroy
B
33
S
18
G
29
Posts: 2,493
Reputation: 21,450

### » Mon Feb 06, 2017 4:12 am

newt wrote:Depending on where the hotspot is, the pink box should always have a greater y than the brown on when they are overlapping.

Actually I did consider this. But here's the catch: It's a rotating layout. I'm actually thinking of inserting a decoy sprite to be used as the relative 'higher Y' that keeps its position relative to the viewport.
I'll have to do some tests.

Also I forgot there's a 3rd case I just thought of last night:

For this case I'm thinking of put Tilemap and BOX_METAL inside a family (if C2 allows) and replace the:

overlapping TM at offset with

overlapping SOLID_FAMILY at offset.

Now hypothetically using the hotspot method it should work but I'm anticipating a whole other set of problems.
"The intent is to provide subscribers with a sense of pride and accomplishment for unlocking different features...."
B
42
S
18
G
32
Posts: 818
Reputation: 20,779

### » Mon Feb 06, 2017 4:15 am

99Instances2Go wrote:Dont really understand why it works at all. On collision the squared speed should be close to zero.

Oh actually the illustration isn't clear. In that case, both VULNERABOX and BOX_METAL are sliding down thus both reached the maximum velocity.
"The intent is to provide subscribers with a sense of pride and accomplishment for unlocking different features...."
B
42
S
18
G
32
Posts: 818
Reputation: 20,779

### » Mon Feb 06, 2017 4:42 am

MPPlantOfficial wrote:
newt wrote:Depending on where the hotspot is, the pink box should always have a greater y than the brown on when they are overlapping.

Actually I did consider this. But here's the catch: It's a rotating layout. I'm actually thinking of inserting a decoy sprite to be used as the relative 'higher Y' that keeps its position relative to the viewport.
I'll have to do some tests.

Also I forgot there's a 3rd case I just thought of last night:

For this case I'm thinking of put Tilemap and BOX_METAL inside a family (if C2 allows) and replace the:

overlapping TM at offset with

overlapping SOLID_FAMILY at offset.

Now hypothetically using the hotspot method it should work but I'm anticipating a whole other set of problems.

Um layer, or layout rotation don't change object y values, and you still have the same circumstances in the third case
brown overlaps pink
-pink has greater y than brown
It's just a matter of picking
You can filter that the other way
brown y is less than pink y
-brown is overlapping pink
B
177
S
50
G
205
Posts: 8,684
Reputation: 127,196