Invisible physics bodies [SOLVED]

I’ve ment to ask about this earlier, but I recently noticed another bug of mine is probably caused by this. When I’m playing my game playing my game, sometimes an invisible object will be on my paddle that other objects sit on. After a few seconds, it inexplicably disappears. I’m going to take a shot in the dark that the object is destroyed when Box2D garbage collection happens.
Could this somehow be my bug, or a bug in Codea?
This is also a great reason why native debug Box2D drawing should be an option. I have no way of accessing where this body is, so I can’t draw it.
Any help would be great.

@zoyt suggestion, until you get access to box2d:
Implement your own class to generate an phisics object, with a objectDisplay global option which displays all objects (your own drawing from the class). Use only this class to create objects in your code. Then you will know if the strange object has been created by you (it will be visible then) or by a bug in box2d.

@Zoyt Are you destroying the physics.body when needed. I’ve never had a problem with bodies that I destroyed. I’ve had problems with objects being somewhere else than I thought they were when I tried using translate or rotate with joints. One way I could find them was to drop a bunch of ball objects from the top of the screen and see where they interacted with something. I found that the “sensor” variable of physics.body could be used so objects wouldn’t interact with the joint object but the joint would still work. I was probably doing something wrong, but I don’t remember what.

If I was a betting man I’d say that you didn’t call destroy() on your body. If you don’t, it will still hang around until the next garbage collection cycle, and since you aren’t using it anymore, it will seem “invisible” until then.

EDIT: For further clarification, this isn’t a “bug” per se. It’s just an artifact of dealing with managed objects in a garbage collected environment.

If you’re using a table of physics bodies or something along those lines then if you just set it to nil then it will sit around invisible until the garbage collector kicks in, I think that’s pretty much the gist of what everyone just said… Glad to help!

@Zoyt - as the others have said, you need to destroy physics objects before setting them ( or the tables they live in) to nil. The garbage collector takes about a minute to do so, otherwise, and then you have zombie physics objects in the meantime.

The way to think of it is that when you create a physics body and put it in a variable, that variable only contains the memory address of the physics object. Setting the variable to nil just gets rid of your copy of that memory address, not the physics object itself.

Codea does a periodic check of everything (not too often or it slows things down), and if there is anything that you can’t talk to any more because you have got rid of its address, ie you have no reference for it, it destroys that object. Like zombie physics objects.

I can’t tell you why this is not the same for non physics variables and tables, where setting to nil is all you have to do. Maybe Codea automatically destroys those things for you, behind the scenes.

See here:

Thanks guys. I’m destroying every object, then setting it to nil. If I am correct, my issue was that I was cycling through the table with “ipairs”, but that doesn’t work properly because I’m removing objects from the table. It hasn’t happened again, but it’s is pretty rare, so I don’t know if that fixed it.

@Zoyt Try using pairs, maybe?

Yep, use pairs

@SkyTheCoder, @Ignatz - It hasn’t happened agin. The method I’m using is cycling through the table in reverse, so there is no chance of error with the loop. Thanks!

@SkyTheCoder, @Ignatz - After all, the issue was a bug in Codea. When you call body:destroy() in the Codea app, it sets to false. When you do that in the runtime, it does nothing, so I have to manually say = false myself. Thanks for the help.

@Zoyt On the issue tracker?