Collision Issue on Spawned Items, Need a little help.

Games
#1

Hey Ya’ll I need a little bit of help.

I have a collision issue, so here is what is going on

Add BottomBar to my SceneGroup, Add my FallingItem to my SceneGroup

I spawn FallingItems in a loop.

Falling Item falls and hits the bottom bar and is removed (
using removeSelf() )

Falling Item 2 falls and hits the bottom bar and this error occurs.

Runtime error
…y\skydrive\corona-projects\icreamstoryboard\game.lua:84: ERROR: Attempt to re
move an object that’s already been removed from the stage or whose parent/ancest
or group has already been removed.
stack traceback:
        [C]: ?
        [C]: in function 'reHandling the unhandled error        …y\skydrive\co
rona-projects\icreamstoryboard\game.lua:84: ERROR: Attempt to remove an object t
hat’s already been removed from the stage or whose parent/ancestor group has alr
eady been removed.
Runtime error
…y\skydrive\corona-projects\icreamstoryboard\game.lua:84: attempt to call meth
od ‘removeSelf’ (a nil value)
stack traceback:
        [C]: in function ‘removeSelf’
        …y\skydrive\corona-projects\icreamstoryboard\game.lua:84: in function
'_listenerHandling the unhandled error  …y\skydrive\corona-projects\icreamstor
yboard\game.lua:84: attempt to call method ‘removeSelf’ (a nil value)

[lua]

if  event.phase == “ended” then

        if (self.myName == “mixin” and event.other.myName ==“oCollisionBarrier”) then
            if self ~= nil then
                timer.performWithDelay( 10, function() self:removeSelf(); end)
            end

end
 

[/lua]

the First Item always removes fine but the 2nd one crashes.

Any idea why?

Thanks

Larry Meadows

#2

update, this error was not happening until i started putting the images in a display group together.

Anyone have a clue? Maybe a small one?

Larry

#3

Hi Larry,

This is odd… can you post the code where you initiate the collision listener(s)? Are you (by chance) applying a collision listener to both the falling objects and the bottom bar?

Also, you can probably skip the timer-based removal in this case. Removing objects outright shouldn’t flag that warning about needing to perform the action on the “next frame”; you should be able to do this immediately upon collision.

Regards,

Brent

#4

So I create a Collision Barrier and then Spawn Random Ice Cream mixins every 2.7 seconds

[lua]

   -------------------------------------------

   – Spawn Random Icream Mixins

   -------------------------------------------

local function spawnIceCream(event)

    local myMixinx = icreamMixins[getRandomValue(1,#icreamMixins)].mixin
    
    local mixinImage = display.newImage(screenGroup, “images/” … myMixinx … “.png”)
    
    mixinImage.x = getRandomValue(40,300)
    mixinImage.myName=“mixin”
    mixinImage.Attached=false

    physics.addBody( mixinImage, “dynamic”, physicsData:get(myMixinx))
    mixinImage.collision=onCollision
    mixinImage:addEventListener(“collision”, mixinImage)
end
 

    local oCollisionBarrier = display.newRect(screenGroup,0,_H-5,_W,20)
    oCollisionBarrier:setReferencePoint(display.CenterLeftReferencePoint)
    oCollisionBarrier:setFillColor(200,20,20); oCollisionBarrier.alpha=0;
    physics.addBody( oCollisionBarrier, “static”, { friction=0.7, isSensor = true} )
    
    oCollisionBarrier.myName = “oCollisionBarrier”
    oCollisionBarrier.collision=onCollision
    oCollisionBarrier:addEventListener(“collision”, oCollisionBarrier)

   ------- Spawn every 2.7 seconds

    _G.TimerCache.icecreamTimer = timer.performWithDelay( 2700, spawnIceCream,0 );

[/lua]

#5

do you see any issues that stick out ?

Larry

#6

Hi Larry,

At a quick glance, I notice you apply collision listeners to both the “mixins” and collision barrier. Do the mixins queue any kind of reaction if/when they collide with each other, or only when they collide with the barrier? If you only need to perform some action on collision with the barrier (and not on mixin+mixin collision), then you can eliminate the listeners on the mixins and only apply one to the barrier. This is better for performance too. Then, the barrier becomes the “self” object in the listener and “event.other” becomes the particular mixin which collided with it.

Note that in this approach, the mixins will still technically collide with each other and exhibit whatever bounce properties you put on them (assuming you didn’t make them sensors or apply collision filters to prevent it). You just won’t be able to get a code-level reaction… but quite possibly that doesn’t matter in your scenario.

If you need everything to collide and report a collision event to you (like mixins+mixins, mixins+barrier, etc.) then I suggest you use a Runtime collision listener, not a “local” one. This gives you the flexibility to detect any collision between any two objects in the world… but if you don’t need that amount of sensory detection, I suggest the method I describe above since it’s a bit easier to handle IMHO.

Hope this helps,

Brent

#7

That is a good Idea, I’ll try that approach and see what happens.

But Yes I need to test for mixin+mixin collisions and mixin collisionbarrier collision.

When the mixins collisions occur I use a WeldJoint to join them together.

I am creating a sample for a meetup based on the Game Zombies Al Mode ice cream falls and you catch the scoops with a Cone.

Thanks for the idea. I’ll try that and see what happens.

Quick Question… On the Runtime Listner does it still work the same using event.other.myName and self.name?

Sometimes it seems like depending on how event listeners aer setup you use different parms ( which is confusing )

( unless I was doing something wrong way back whenever - which is highly possible )

thanks

Larry Meadows

#8

Hi Larry,

Indeed, the params are slightly different for Runtime collisions. It’s “event.object1” and “event.object2”. This is because, in a collision of that type, there really isn’t any “self” differentiation. Which one would be “self” in that case? :wink:

https://developer.coronalabs.com/content/game-edition-collision-detection

Brent

#9

yep found it before I got your response.

I’ll keep ya’ll posted

Thanks

Larry

#10

update, this error was not happening until i started putting the images in a display group together.

Anyone have a clue? Maybe a small one?

Larry

#11

Hi Larry,

This is odd… can you post the code where you initiate the collision listener(s)? Are you (by chance) applying a collision listener to both the falling objects and the bottom bar?

Also, you can probably skip the timer-based removal in this case. Removing objects outright shouldn’t flag that warning about needing to perform the action on the “next frame”; you should be able to do this immediately upon collision.

Regards,

Brent

#12

So I create a Collision Barrier and then Spawn Random Ice Cream mixins every 2.7 seconds

[lua]

   -------------------------------------------

   – Spawn Random Icream Mixins

   -------------------------------------------

local function spawnIceCream(event)

    local myMixinx = icreamMixins[getRandomValue(1,#icreamMixins)].mixin
    
    local mixinImage = display.newImage(screenGroup, “images/” … myMixinx … “.png”)
    
    mixinImage.x = getRandomValue(40,300)
    mixinImage.myName=“mixin”
    mixinImage.Attached=false

    physics.addBody( mixinImage, “dynamic”, physicsData:get(myMixinx))
    mixinImage.collision=onCollision
    mixinImage:addEventListener(“collision”, mixinImage)
end
 

    local oCollisionBarrier = display.newRect(screenGroup,0,_H-5,_W,20)
    oCollisionBarrier:setReferencePoint(display.CenterLeftReferencePoint)
    oCollisionBarrier:setFillColor(200,20,20); oCollisionBarrier.alpha=0;
    physics.addBody( oCollisionBarrier, “static”, { friction=0.7, isSensor = true} )
    
    oCollisionBarrier.myName = “oCollisionBarrier”
    oCollisionBarrier.collision=onCollision
    oCollisionBarrier:addEventListener(“collision”, oCollisionBarrier)

   ------- Spawn every 2.7 seconds

    _G.TimerCache.icecreamTimer = timer.performWithDelay( 2700, spawnIceCream,0 );

[/lua]

#13

do you see any issues that stick out ?

Larry

#14

Hi Larry,

At a quick glance, I notice you apply collision listeners to both the “mixins” and collision barrier. Do the mixins queue any kind of reaction if/when they collide with each other, or only when they collide with the barrier? If you only need to perform some action on collision with the barrier (and not on mixin+mixin collision), then you can eliminate the listeners on the mixins and only apply one to the barrier. This is better for performance too. Then, the barrier becomes the “self” object in the listener and “event.other” becomes the particular mixin which collided with it.

Note that in this approach, the mixins will still technically collide with each other and exhibit whatever bounce properties you put on them (assuming you didn’t make them sensors or apply collision filters to prevent it). You just won’t be able to get a code-level reaction… but quite possibly that doesn’t matter in your scenario.

If you need everything to collide and report a collision event to you (like mixins+mixins, mixins+barrier, etc.) then I suggest you use a Runtime collision listener, not a “local” one. This gives you the flexibility to detect any collision between any two objects in the world… but if you don’t need that amount of sensory detection, I suggest the method I describe above since it’s a bit easier to handle IMHO.

Hope this helps,

Brent

#15

That is a good Idea, I’ll try that approach and see what happens.

But Yes I need to test for mixin+mixin collisions and mixin collisionbarrier collision.

When the mixins collisions occur I use a WeldJoint to join them together.

I am creating a sample for a meetup based on the Game Zombies Al Mode ice cream falls and you catch the scoops with a Cone.

Thanks for the idea. I’ll try that and see what happens.

Quick Question… On the Runtime Listner does it still work the same using event.other.myName and self.name?

Sometimes it seems like depending on how event listeners aer setup you use different parms ( which is confusing )

( unless I was doing something wrong way back whenever - which is highly possible )

thanks

Larry Meadows

#16

Hi Larry,

Indeed, the params are slightly different for Runtime collisions. It’s “event.object1” and “event.object2”. This is because, in a collision of that type, there really isn’t any “self” differentiation. Which one would be “self” in that case? :wink:

https://developer.coronalabs.com/content/game-edition-collision-detection

Brent

#17

yep found it before I got your response.

I’ll keep ya’ll posted

Thanks

Larry