This worked perfectly in the prototyping phase. But as soon as my levels became larger and had more game objects(enemies walking around, moving platforms, pickups etc) The player sometimes fall through platforms while walking on them. I could share my player script but its 940 lines long! I tried running debug and it seam the y normal randomly flips to 90 degrees(horizontal arrow). I tried printing the normal while the player is on the platforms but it always reads (0,1,0) which is what its suppose to be so im a bit confused.
I also checked the game project setting and tried increasing the Max Collisions and Max Contacts without any luck. I’m not sure what to try next. Is it some kind of memory leak issue maybe?
The normal.y sometimes flips horizontally which causes the fall but the point was it didnt happen before. As if the physics accuracy took a hit after adding so much go’s to the levels.
Honestly I don’t think I’ve ever found a really great solution for this. You can try making your player’s collision rounded or beveled on the bottom. You can try to make checks to ignore these contacts, with some sort of threshold, or have vertical contacts override horizontal ones . . .
Actually I think the only reliable way to deal with this is to rely on raycasts instead of contact point responses.
Using Rounded collision seams to do the trick but now the player is twitching each time I pass between 2 platform tiles i.e trying to switch to his fall state then back to running state. Ill try the adjust the normal and see what happens.
Box2D is sometimes a bit funny when two vertices from separate fixtures are put on top of each other, which I suppose is causing this issue in the first place?
If so, could one solution be to optimise the tile > fixture conversion happening behind the scenes?
I checked his y velocity as well as his current command from the player.
his states are state_normal with sub-states [stand, stand_shooting, run, run_shooting, jump, jump_shooting, fall, fall_shooting]
and state_rocket with sub-state [flying, flying_shooting]
and state_dead
if his velocity.y > 0 then he’s in the jump state, less than 0 then fall state. if he’s currently firing a weapon with those cases true then set state to its shooting variants etc
@chevgc were you able to get this to work? I use a sphere which works to a degree, but I also get issues with the incorrect collisions triggering (probably caused by the invisible seams in Box2D where two tiles meet).
Collision Object components don’t have a position themselves. The collision shapes on the collision object have positions and sizes, but unfortunately there’s no way to get these at runtime. You will have to hard-code those. I also suggest you start the raycasts slightly inside the shape, instead of from exactly at the corners (have a variable ‘overlap’ parameter), since they have to start outside any colliding object to detect it.
You can probably get away with fewer rays than that too. The issue with inside/overlapping edges is generally only a problem for the ground, since gravity is constantly forcing the player into it.
Thanks @ross.grams, that’s a bummer! I’m used to Gideros, another Lua SDK, where all variables are always available (as well as the entire Box2D API), so I’m trying to wrap my head around Defold’s way of doing things. Not a fan of hard coded vars, because it makes collaboration with artists harder.
Objects tend to get stuck to the sides of walls too, so it’s probably best to use one system determining collisions, for consistency.
