SOLVED Need a trick to turn my collision mask on and off

I got my level boss all set up and things are really shaping up, but I found an issue and hope I can correct it with a small piece of code instead of having to do an overhaul.

My level boss ducks into a bunker and tosses objects at the player, pretty cool huh? Except the player can still shoot the collision mask where the boss is outside his bunker and kill him even though he's hiding.
I'm using a combo of state machines and "Modes" that give me plenty of options for If statements to activate and deactivate the mask.
Suggestions?
 
Last edited:

Slyddar

Member
If you are using states, when the boss is in the bunker, put him in a state. Then in you bullet collision event, only process it if the boss is not in that state, or process the collision, but destroy the bullet and deal no damage.
 
If you are using states, when the boss is in the bunker, put him in a state. Then in you bullet collision event, only process it if the boss is not in that state, or process the collision, but destroy the bullet and deal no damage.
Yeah that worked. I thought I set up my player's bullet object to just be a kill-all object but opening it up I have collision events for every enemy, I just wrapped the With statement for what's to happen with the collision in an if statement for that specific state and now he's invincible while in his bunker.
Only downside is the bullet still stops on the mask, would be nice if it just kept going.
 

Slyddar

Member
Only downside is the bullet still stops on the mask, would be nice if it just kept going.
Then set it to be.

One way is in the collision event, set a local variable at the top called ignore to false. Then where it processes the bosses state as in the bunker, set ignore to true. Then ensure the code to destroy the bullet is at the end of the collision script, but if ignore is set to true, don't destroy it.
 
Then set it to be.

One way is in the collision event, set a local variable at the top called ignore to false. Then where it processes the bosses state as in the bunker, set ignore to true. Then ensure the code to destroy the bullet is at the end of the collision script, but if ignore is set to true, don't destroy it.
Thanks again, was as simple as just moving my instance_destroy into the if statement.
 

Slyddar

Member
Thanks again, was as simple as just moving my instance_destroy into the if statement.
Only reason I didn't suggest that was I thought you had multiple enemies using the same collision code, and they relied on the instance_destroy code being there. Guess you could duplicate it to multiple areas if you needed though, but my solution offered better long term scalability.

As long as you worked it out, all good.
 

Yal

🐧 *penguin noises*
GMC Elder
I got my level boss all set up and things are really shaping up, but I found an issue and hope I can correct it with a small piece of code instead of having to do an overhaul.

My level boss ducks into a bunker and tosses objects at the player, pretty cool huh? Except the player can still shoot the collision mask where the boss is outside his bunker and kill him even though he's hiding.
I'm using a combo of state machines and "Modes" that give me plenty of options for If statements to activate and deactivate the mask.
Suggestions?
To explicitly remove the collision mask for an instance, you can create a 1x1 pixel sprite named spr_nomask, have that pixel be empty (aka don't paint anything in it), and then go to its collision mask settings and set it to precise collisions with the alpha sensitivity all the way up - now you have a sprite with no pixels in the collision mask. Just set mask_index to this sprite to turn off collisions, and back to -1 (or your desired hitbox sprite) when you want to turn them on again.
 

Slyddar

Member
To explicitly remove the collision mask for an instance, you can create a 1x1 pixel sprite named spr_nomask, have that pixel be empty (aka don't paint anything in it), and then go to its collision mask settings and set it to precise collisions with the alpha sensitivity all the way up
If you are changing the alpha sensitivity anyway, to ensure no pixels in the mask, why does it matter if it is 1x1? Wouldn't any size mask result in no pixels with that method?
 

TheouAegis

Member
Or manually draw the sprite. If you don't assign a sprite_index and don't assign a mask index, there will be no collision detection.

Even if the transparent precise pixel method worked, which I can't help but wonder if it works with all collision detection methods (Does it really make a 0x0 mask, rather than a 1x1 mask? Is it treated as empty, rather than a point?), wouldn't making it precise unnecessarily slow down all your collision checks?
 

Yal

🐧 *penguin noises*
GMC Elder
If you are changing the alpha sensitivity anyway, to ensure no pixels in the mask, why does it matter if it is 1x1? Wouldn't any size mask result in no pixels with that method?
Because GM's gonna check all the pixels in the sprite for collisions, and that's more efficient the fewer pixels there are in total - I don't think it builds a list of all pixels actually present in the collision mask for speed, it loops over the entire bounding box every time... so we want to keep it small. (In either case, precise collision checks first check the bounding box and then does a precise check with anything that intersected the bounding box, so the smaller the bounding box is, the fewer things we need to do precise collisions with)
 

Slyddar

Member
I don't think it builds a list of all pixels actually present in the collision mask for speed, it loops over the entire bounding box every time... so we want to keep it small
If it's precise, it probably wouldn't do a bounding box check, but a pixel to pixel comparison. I could see a small pixel being quicker though if it loops through every pixel first to build a list with which is then checks against, but the saving would be the initial loop through to build that list, which would end up being empty in both cases anyway.

precise collisions with the alpha sensitivity all the way up
After some testing, the alpha sensitivity change does nothing. Just an empty sprite with precise is all that is needed for collisions to be ignored. Nice to know that's a workable method though.
 

Yal

🐧 *penguin noises*
GMC Elder
If it's precise, it probably wouldn't do a bounding box check, but a pixel to pixel comparison. I could see a small pixel being quicker though if it loops through every pixel first to build a list with which is then checks against, but the saving would be the initial loop through to build that list, which would end up being empty in both cases anyway.


After some testing, the alpha sensitivity change does nothing. Just an empty sprite with precise is all that is needed for collisions to be ignored. Nice to know that's a workable method though.
But it doesn't build that list, that's what I'm saying. It's checking every pixel in the sprite for collisions. And if you do tons of collision checks every step (you need to do one collision check for every instance of the object you want to collide with) the savings can be pretty significant.
 
Top