Weird collision behaviour.

[Saerothir]

For my enemy bullet collision-detection, I have multiple functions - within the main enemy fire function - checking whether or not the event.other.class is a bullet, PlayerTank, EnemyTank, PTmine, etc…
Here is what happens when I run the simulator –
If I collide with an enemy’s radar and the enemy begins firing at me, it works fines until I shoot one of the enemy tanks…
Now the enemy bullets are getting removed once they clear the radial sensor or once the collision with an IGmine ends.

I believe the issue comes from this statement
[lua]
        local onEnemybulletCollision = function( self, event )
         if event.phase == “began” then
             
             EBcollisions = EBcollisions + 1
[/lua]
after that statement, then it goes on to check if it collided with an object that has a class I mentioned above.

towards the end of the function I have this statement:
[lua]
        elseif  event.phase == “ended”  
            then
                display.remove(self)
                EBcollisions = 0
                print(" Projectile Removed. EBcollisions set to 0 ")   
            end
[/lua]

I can’t use a collision filter because if I try to specify what objects the bullet can collide with, it doesn’t work seeing as how all the walls, rocks and other barriers are created&generated via LevelHelper and therefore have no identifier.
I thought using a counter for keeping track of how many collisions have occurred would work, but since a collision is technically occurring when it hits the radar or an IGmine (which up until I shoot at something, the IGmine doesn’t collide with the bullets via my RGCC) it ups the collision-count +1 which then causes the bullet to remove itself once the collision with the radar or IGmine has ended.
I am having the same issue with my user-bullet collision and like with the enemy-bullet, I have PBcollisions being increased&decreased on the began and ended phase of the collision.

** Again, nothing weird happens until I shoot an enemy tank…? As if that is what 'kicks in the physics engine **

P.S. Obviously since I have display.remove(self) being called on the ended phase, the EBcollisions count would become void. I think the reason I have a counter for the bullet is because at one time I had an if statement that would remove the bullet if EBcollisions = 2 - just to clarify.

[Saerothir]

-bump-
:ph34r:

[bjsorrentino]

Hi Saer,

Can you simplify your description of the basic problem here? I’m a bit confused by what’s happening where (and not seeing the objects in question makes it harder).

If you’re using the “counting” method for collisions, as in +1 on “began” and -1 on “ended”, that’s perfectly valid. But you shouldn’t always remove the object on the ended phase… only remove it on the ended phase IF the count is 0 (after subtracting 1, not before).

Also, if you’re using this counting method, remember that a collision occurs when you PUT an object inside a sensor area. For example, if you spawn a bullet inside the radar zone, that actually counts as a collision between the bullet and sensor, even though the bullet didn’t come from outside and collide with the sensor bounds. The same is true when you remove an object… it will trigger an “ended” collision event on the sensor if you remove it.

Brent

[Saerothir]

Hi Brent,
I apologize for my delayed response, the past few weeks have been insane.

-quick update-
I will be recording a video (either today or tomorrow) of the weird collision behavior I’m experiencing, and will post it as soon as I can.

• Saer

[Saerothir]

Here is the video: link

• sorry if it sounds rushed… I was pressed for time -

• Saer

[bjsorrentino]

Hi Saer,

Hmmmm… this might take awhile (several steps).

First thing: I’m not sure how RoamingGamer’s collision calculator works and what strings it expects you to supply to its functions. So if you continue to use it, you’ll probably have to ask him if you have any questions.

What I can guess is that it’s using standard Corona collision filters, which is the feature you say Corona should have (and it does). This is how you ignore collisions between some objects without having to do any code in the actual collision listener.

If you’re willing to do this “manually”, I suggest you follow through my collision filter helper chart from a couple years back… it’s still completely valid, so don’t worry about when it was written. Although it might seem like a strange process, it’s actually pretty simple when you write it on paper (or print out the PDF chart), fill in the numbers, and add up the values.

http://forums.coronalabs.com/topic/2128-collision-filters-helper-chart/

This is the first step: getting your collision filters working. We can then take the next step, why bullets only “sometimes” collide but other times not.

Have fun!

Brent

[Saerothir]

Oh joy lol… :rolleyes:

Yeah, I’m not sure. You can take a look at the file if you want - link
My guess is that you are right in that it most likely utilizes Corona’s “standard Corona collision filters.”
RG’s code, I’m assuming, simply bypasses the “standard” and allows the user to use strings instead of messing with ‘Bits’ 'n such.

I’ve looked at your collision helper chart in the past (though that was when I was still very new to Corona) and having to organize objects via ‘categoryBits’ and ‘maskBits’ made me go “whaaaa?!” Probably just my brain over-complicating things, because the idea/concept seems simple enough.
I’ll give it another go and post back when I have it working.

• Saer

 

[Saerothir]

-bump-
:ph34r:

[bjsorrentino]

Hi Saer,

Can you simplify your description of the basic problem here? I’m a bit confused by what’s happening where (and not seeing the objects in question makes it harder).

If you’re using the “counting” method for collisions, as in +1 on “began” and -1 on “ended”, that’s perfectly valid. But you shouldn’t always remove the object on the ended phase… only remove it on the ended phase IF the count is 0 (after subtracting 1, not before).

Also, if you’re using this counting method, remember that a collision occurs when you PUT an object inside a sensor area. For example, if you spawn a bullet inside the radar zone, that actually counts as a collision between the bullet and sensor, even though the bullet didn’t come from outside and collide with the sensor bounds. The same is true when you remove an object… it will trigger an “ended” collision event on the sensor if you remove it.

Brent

[Saerothir]

Hey Brent,

I was at a conference all weekend, and just a bit earlier had a chance to actually sit down and work on implementing the collision filter… all I can say is wow.

I’ve spent a decent amount of hours trying to “fix” what I thought was an error on my part, when in fact the simple answer was indeed using Corona’s standard form of collision filters.
I don’t know why it looked confusing when I first read your post a while back, because when I re-read your post it made perfect sense and within about ten minutes I had it all working perfectly!

I’ve run the simulator multiple times and tried to produce different collision-scenarios and it all seems to work just great –
 - IGmines only collide with the Player
 - bullet only collides with the Player
(the bullet interacts with the walls,rocks,barriers but does not collide with the IGmines)
 - Radar only interacts with the Player etc… etc…
The only lines of code I had to add were were the following:
[lua]
local PlayerCollisionFilter = { categoryBits = 1, maskBits = 6 }
local RadarCollisionFilter  = { categoryBits = 8, maskBits = 1 }
local IGmineCollisionFilter = { categoryBits = 2, maskBits = 1 }
local bulletCollisionFilter = { categoryBits = 4, maskBits = 1 }
[/lua]

Obviously I’ll have to add more filters for my enemy-tanks and a few other objects, but all 'n all everything seems to be working exactly how it should.
I can’t off the top of my head think of anything else collision-related that I’m having an issue with.

Thank you once *again Brent for your assistance. You’ve been a major help throughout my endeavor in mobile app development using Corona.

-Saer
 

[bjsorrentino]

Great to hear! Collision filters look “evil” at first, but they’re not so bad in the end.

Brent

[Saerothir]

lol yeah.

– this is a bit off topic –
I’ve been working on this game for almost a year (with more time being dedicated within the last 5/6 months) and while creating levels, coding scenes, writing basic functions for my various objects and animations is really easy stuff, it’s getting all the “little things” to work seamlessly that has proven to be challenging at times. Quite frankly I’m getting tired of it.

I’d hate to become a “forum whore”, but seeing as how I am essentially a newbie when it comes to programming of any kind there’s not much else i can do when things come up that just baffle me to the point of wanting to punch my computer. :lol:

Are there people who work as a kind of consultant? Not necessarily someone to take over and finish the project, but more of an assistant type position - an experienced person that would be available to assist in the final stages of development, whether it’s writing code or just being there to give advice/clarification on something when needed.

-Saer

[bjsorrentino]

Hi Saer,

You might consider posting your request in the “Collaborations” sub-forum. It sounds like you’re seeking a teammate or “mentor” of sorts who would be generous enough (or charge an affordable fee) to critique your code and work through toward the final polished game. That sub-forum would be the best place to ask this.

http://forums.coronalabs.com/forum/572-collaborations/

Brent

[Saerothir]

Alright, thanks for the advice.

[Saerothir]

Hi Brent,
I apologize for my delayed response, the past few weeks have been insane.

-quick update-
I will be recording a video (either today or tomorrow) of the weird collision behavior I’m experiencing, and will post it as soon as I can.

• Saer

[Saerothir]

Here is the video: link

• sorry if it sounds rushed… I was pressed for time -

• Saer

[bjsorrentino]

Hi Saer,

Hmmmm… this might take awhile (several steps).

First thing: I’m not sure how RoamingGamer’s collision calculator works and what strings it expects you to supply to its functions. So if you continue to use it, you’ll probably have to ask him if you have any questions.

What I can guess is that it’s using standard Corona collision filters, which is the feature you say Corona should have (and it does). This is how you ignore collisions between some objects without having to do any code in the actual collision listener.

If you’re willing to do this “manually”, I suggest you follow through my collision filter helper chart from a couple years back… it’s still completely valid, so don’t worry about when it was written. Although it might seem like a strange process, it’s actually pretty simple when you write it on paper (or print out the PDF chart), fill in the numbers, and add up the values.

http://forums.coronalabs.com/topic/2128-collision-filters-helper-chart/

This is the first step: getting your collision filters working. We can then take the next step, why bullets only “sometimes” collide but other times not.

Have fun!

Brent

[Saerothir]

Oh joy lol… :rolleyes:

Yeah, I’m not sure. You can take a look at the file if you want - link
My guess is that you are right in that it most likely utilizes Corona’s “standard Corona collision filters.”
RG’s code, I’m assuming, simply bypasses the “standard” and allows the user to use strings instead of messing with ‘Bits’ 'n such.

I’ve looked at your collision helper chart in the past (though that was when I was still very new to Corona) and having to organize objects via ‘categoryBits’ and ‘maskBits’ made me go “whaaaa?!” Probably just my brain over-complicating things, because the idea/concept seems simple enough.
I’ll give it another go and post back when I have it working.

• Saer

 

[Saerothir]

Hey Brent,

I was at a conference all weekend, and just a bit earlier had a chance to actually sit down and work on implementing the collision filter… all I can say is wow.

I’ve spent a decent amount of hours trying to “fix” what I thought was an error on my part, when in fact the simple answer was indeed using Corona’s standard form of collision filters.
I don’t know why it looked confusing when I first read your post a while back, because when I re-read your post it made perfect sense and within about ten minutes I had it all working perfectly!

I’ve run the simulator multiple times and tried to produce different collision-scenarios and it all seems to work just great –
 - IGmines only collide with the Player
 - bullet only collides with the Player
(the bullet interacts with the walls,rocks,barriers but does not collide with the IGmines)
 - Radar only interacts with the Player etc… etc…
The only lines of code I had to add were were the following:
[lua]
local PlayerCollisionFilter = { categoryBits = 1, maskBits = 6 }
local RadarCollisionFilter  = { categoryBits = 8, maskBits = 1 }
local IGmineCollisionFilter = { categoryBits = 2, maskBits = 1 }
local bulletCollisionFilter = { categoryBits = 4, maskBits = 1 }
[/lua]

Obviously I’ll have to add more filters for my enemy-tanks and a few other objects, but all 'n all everything seems to be working exactly how it should.
I can’t off the top of my head think of anything else collision-related that I’m having an issue with.

Thank you once *again Brent for your assistance. You’ve been a major help throughout my endeavor in mobile app development using Corona.

-Saer
 

[bjsorrentino]

Great to hear! Collision filters look “evil” at first, but they’re not so bad in the end.

Brent