Physics Issue / Question

Solar2D General Questions/Discussion
#1

I haven’t had much experience working with the physics engine, though I have used it on occasion for special effects and animations.  I’m now working on a project that’s more physics-oriented and am having an issue.  

I attached an image with the post.  I have the player object (top-most dynamic rect) and have ground (bottom rows, static) that seem to have the physics attached to them properly in debug mode, but the player falls right through the ground every time.  I have a global listener for collision events and it doesn’t even seem to get called as the player passes through them, either.

One thing I thought was maybe since I was calling physics methods in different files, it was messing up somehow.  So that middle rect I’m creating in the same file and area where the ground is being created as a test, and as you can see the player’s physics body collides and is stopped by it as it should be, and I’m seeing the collision function being called from that happening.  I’m also calling physics.start() first thing in the :create() scene function before anything else happens.  

I also tried making the ground tiles dynamic for the heck of it, and though they were affected by gravity they still didn’t collide with the player or with each other (visually), BUT it did fire the collision listener.  I’m wondering if anyone has any other ideas?  

The only physics methods I’m using at the moment is start, setDrawMode, setGravity, and addObject.  I’m not even modifying the attributes of the physics objects yet, either, so all I’m doing is displaying images on screen and converting them to physics objects at the moment.  

#2

Zip up your example and share it with us so we can run the test.

attaching_files.jpg

#3

Sorry for the delayed response.  Ugh, I figured out what it was.  Apparently it wasn’t on the same layer/display group as the other elements.  Dumb mistake.  Sorry about that.

#4

No prob!  Thanks for posting back and telling us what the source of the issue was.  That helps a lot!

#5

Alright, so I finally had some time to work on this some more and I’m realizing I still have this issue, even though I revamped the project so every display object is in the same group/hierarchy.  

The target scene is scenes.scene_gameplay which is loaded when you hit the play button.  The functions forgePlayer and forgeTileMaps handle the player and the tiling I’m trying to do respectively.  Inside the tilemap folder are the Lua files I’m using for this.  Section.lua represents one whole section of “blocks.”  Block.lua represents a set of three “tiles,” and tile.lua is the 128x128 square that could be ground, a hole, an obstacle, etc and the tile.lua display groups are the elements actually being put into physics.addBody function in setPhysics.

I have a testrect block (currently commented) in the setphysics  function that creates that middle rect I had in the original image for testing, where the player CAN collide with it normally, but the weird thing about that especially is it’s not being added to the same group/hierarchy (or any at all), though it DOES work.  So my original thought that it was due to the layers/grouping was wrong, at least in this case.  

Only thing I can think is that, because the tile group is inserted the block group, and the block group is inserted in the section group, and the section group is inserted into the layer group in scene_gameplay, that all that insulation is somehow messing with the physics engine?  I’m not sure.  Maybe someone can offer some insight, I’m attaching the project here.

Edit - I tested adding the tile display group (un-inserted into the other groups) as a physics object and it is working and colliding.  However, the moment I add that tile display group to the block display group (a group inserted within a group) that does seem to be when the physics stops working with the player object.  Is this the way physics was meant to be?  Or is there some other issue that’s causing this to happen?

#6

Hey I saw your post, but I’ve been super busy all day.

I just ran it and reproduced the issue.

I’ll give it a look this weekend and see if something shakes out.

-Ed

#7

OK, I’ve looked at the code (briefly) and the news is not good.

  1. There is simply too much code for me to examine in any depth.  Sorry, but I have to be careful with my time.

(Typically I ask that folks make a micro-example demonstrating their issue, but in this case I can see you might not be able to do that easily.)

  1. I did look at your body code and a few other things.
  • I noticed you added bodies to groups.  While others may do this and it may work, I don’t see why you can’t add the bodies directly to the display objects.  Maybe I’m not understanding the structure of things, but that is a suggestion.
  • I didn’t see you offsetting any groups, but if you are, don’t.  At least don’t offset groups with objects in them that need to collide.  That won’t work and can’t be resolved.

  1. I strongly suggest you try to test your object creation code in stand-alone cases to verify it works and collisions work.  

  2. Consider refactoring or re-writing the project.  It looks like it needs some love, including consistent formatting, updates of old style modules, consolidation of common code into modules, etc.

Note: An old style module starts like this:

module(..., package.seeall);

These are terrible and should be updated to modern-style modules as the old ones are essentially big global bags of messiness.

Modern style is like this:

local mod = {} -- any name internal to the file will be fine function mod.exposed\_function\_1() ... function mod.exposed\_function\_2() ... ... function mod.exposed\_function\_N() ... return mod

So, while I wish I had been able to help you resolve this directly, there just isn’t any way I can in my limited time.  Sorry.

#8

It’s no problem, thanks for trying to take a look.  The thing is, though, what I wanted to do conceptually was have a kind of scrolling segments of ground/obstacles that worked with the physics for the player to walk on/jump over/fall into.  I figured the best way for this was to have one group that could represent any of those given states (hole/ground/wall), turn the physics bodies on/off depending if it’s the ground/obstacle or if it’s a hole, set the proper image visible and the rest invisible and all that.  Reason being, once these pass and are not visible on screen more, I could simply move them ahead and randomize/reset them instead of recreating a new object/loading new images every time, which seemed like it could be a problem if the level was moving too fast, or perhaps on older devices.  

If using display groups is as much of a problem as it’s sounding, though, it seems I’m going to have to go about it a different way.  Either way, thanks again, I do appreciate you taking the time to try.

#9

Tip: You can turn bodies on and off irrespective of what they are attached to.  Sot the block, unblock functionality you seek is doable.

I’m just saying (above) that I’ve never been a fan of adding bodies to groups.  If you can get it to work for you, then more power to you.

#10

Zip up your example and share it with us so we can run the test.

attaching_files.jpg

#11

Sorry for the delayed response.  Ugh, I figured out what it was.  Apparently it wasn’t on the same layer/display group as the other elements.  Dumb mistake.  Sorry about that.

#12

No prob!  Thanks for posting back and telling us what the source of the issue was.  That helps a lot!

#13

Alright, so I finally had some time to work on this some more and I’m realizing I still have this issue, even though I revamped the project so every display object is in the same group/hierarchy.  

The target scene is scenes.scene_gameplay which is loaded when you hit the play button.  The functions forgePlayer and forgeTileMaps handle the player and the tiling I’m trying to do respectively.  Inside the tilemap folder are the Lua files I’m using for this.  Section.lua represents one whole section of “blocks.”  Block.lua represents a set of three “tiles,” and tile.lua is the 128x128 square that could be ground, a hole, an obstacle, etc and the tile.lua display groups are the elements actually being put into physics.addBody function in setPhysics.

I have a testrect block (currently commented) in the setphysics  function that creates that middle rect I had in the original image for testing, where the player CAN collide with it normally, but the weird thing about that especially is it’s not being added to the same group/hierarchy (or any at all), though it DOES work.  So my original thought that it was due to the layers/grouping was wrong, at least in this case.  

Only thing I can think is that, because the tile group is inserted the block group, and the block group is inserted in the section group, and the section group is inserted into the layer group in scene_gameplay, that all that insulation is somehow messing with the physics engine?  I’m not sure.  Maybe someone can offer some insight, I’m attaching the project here.

Edit - I tested adding the tile display group (un-inserted into the other groups) as a physics object and it is working and colliding.  However, the moment I add that tile display group to the block display group (a group inserted within a group) that does seem to be when the physics stops working with the player object.  Is this the way physics was meant to be?  Or is there some other issue that’s causing this to happen?

#14

Hey I saw your post, but I’ve been super busy all day.

I just ran it and reproduced the issue.

I’ll give it a look this weekend and see if something shakes out.

-Ed

#15

OK, I’ve looked at the code (briefly) and the news is not good.

  1. There is simply too much code for me to examine in any depth.  Sorry, but I have to be careful with my time.

(Typically I ask that folks make a micro-example demonstrating their issue, but in this case I can see you might not be able to do that easily.)

  1. I did look at your body code and a few other things.
  • I noticed you added bodies to groups.  While others may do this and it may work, I don’t see why you can’t add the bodies directly to the display objects.  Maybe I’m not understanding the structure of things, but that is a suggestion.
  • I didn’t see you offsetting any groups, but if you are, don’t.  At least don’t offset groups with objects in them that need to collide.  That won’t work and can’t be resolved.

  1. I strongly suggest you try to test your object creation code in stand-alone cases to verify it works and collisions work.  

  2. Consider refactoring or re-writing the project.  It looks like it needs some love, including consistent formatting, updates of old style modules, consolidation of common code into modules, etc.

Note: An old style module starts like this:

module(..., package.seeall);

These are terrible and should be updated to modern-style modules as the old ones are essentially big global bags of messiness.

Modern style is like this:

local mod = {} -- any name internal to the file will be fine function mod.exposed\_function\_1() ... function mod.exposed\_function\_2() ... ... function mod.exposed\_function\_N() ... return mod

So, while I wish I had been able to help you resolve this directly, there just isn’t any way I can in my limited time.  Sorry.

#16

It’s no problem, thanks for trying to take a look.  The thing is, though, what I wanted to do conceptually was have a kind of scrolling segments of ground/obstacles that worked with the physics for the player to walk on/jump over/fall into.  I figured the best way for this was to have one group that could represent any of those given states (hole/ground/wall), turn the physics bodies on/off depending if it’s the ground/obstacle or if it’s a hole, set the proper image visible and the rest invisible and all that.  Reason being, once these pass and are not visible on screen more, I could simply move them ahead and randomize/reset them instead of recreating a new object/loading new images every time, which seemed like it could be a problem if the level was moving too fast, or perhaps on older devices.  

If using display groups is as much of a problem as it’s sounding, though, it seems I’m going to have to go about it a different way.  Either way, thanks again, I do appreciate you taking the time to try.

#17

Tip: You can turn bodies on and off irrespective of what they are attached to.  Sot the block, unblock functionality you seek is doable.

I’m just saying (above) that I’ve never been a fan of adding bodies to groups.  If you can get it to work for you, then more power to you.