Adding Physics Bodies To Sprites?

Million Tile Engine
#1

I’m trying to add a physics body to a Sprite in order to work with my Raycast/Field of View implementation; however as soon as I add a body like so:

[lua]

local setup = {
        kind = “sprite”,
        layer = mte.getSpriteLayer(1),
        locX = NewEntity.m_vLocPosition[1],
        locY = NewEntity.m_vLocPosition[2],
        levelWidth = 32,
        levelHeight = 32
    }
   
    mte.addSprite(NewEntity.image, setup)
    mte.physics.addBody(NewEntity.image, “kinematic”)

[/lua]

The character is stuck at 0,0 - if I remove the physics line then the character appears where he should be.

Dyson, is the functionality available in MTE or am I doing something completely wrong.

#2

I think I’ve run into this problem as well a few times. Try calling mte.update() between lines 10 and 11 of your code snippet. This should move the sprite into position before the physics API takes over. 

#3

Thank you sir - worked a treat.

#4

Spoke too soon :slight_smile:

After I change that - the characters appears where they should be, however they’re not responding to moveSpriteTo - if I remove the addBody line it all works flawlessly ?!?

#5

Hey Dyson - just a little more info.

I spent a few hours stepping through MTE last night and realised that the problem stems from the update function. More specifically the object.isBodyActive is continuously true, so beyond the first run through it’s never updating the object’s x/y property.

Even after stepping through the code, line-by-line, I can’t see where this property is changing from its initial nil value to true; so I was hoping you might be able to shed some light on it. If the addBody line is removed from above then the isBodyActive property is always nil ?!?

#6

OK, I feel slightly stupid - from what I can gather I can’t move the sprite around if it’s a physics object by modifying x/y values?

The thing is I only want physics for Raycasting/Field ofView and feel that a whole refactor to cater for moving objects around using physics is on the excessive side.

Damn!

However it doesn’t answer the whole issue over the isBodyActive property?!?

Edit

OK I feel even more stupid :slight_smile: So .isBodyActive is obviously a property of Corona physic objects and not MTE as I originally suspected.

If I stick object.isBodyActive = false in the :Execute method of my object’s FSM everything works peachy - pretty sure there will be problems further down the road, but at least the object is moving and he’s got a physics body attached :slight_smile:

#7

I’d be curious to know whether a non-active physics body can intercept rays. 

The Physics API and MTE’s movement functions don’t play particularly nice with each other at the moment when they’re both acting on the same object, but this is something I will definitely rectify in the next update, perhaps sooner if I can nail down a quick fix to tide things over.

EDIT

I’ve come up with a possible fix, if you’d like to try it. Open mte.lua and navigate to line 9428, which is in the update() function. You’ll see the following block of code:

local object = objects[key] local velX = object.deltaX[1] local velY = object.deltaY[1] local remainingVelX = abs(object.deltaX[1]) local remainingVelY = abs(object.deltaY[1]) local velXSign = 1 local velYSign = 1 if velX \< 0 then velXSign = -1 else velXSign = 1 end if velY \< 0 then velYSign = -1 else velYSign = 1 end while remainingVelX \> 0 or remainingVelY \> 0 do local vX local vY if remainingVelX \> blockScaleX / 5 then vX = blockScaleX / 5 remainingVelX = remainingVelX - blockScaleX / 5 else vX = remainingVelX remainingVelX = 0 end if remainingVelY \> blockScaleY / 5 then vY = blockScaleY / 5 remainingVelY = remainingVelY - blockScaleY / 5 else vY = remainingVelY remainingVelY = 0 end moveSprite(key, vX \* velXSign, vY \* velYSign) end table.remove(object.deltaX, 1) table.remove(object.deltaY, 1)

Comment it out and add this replacement block of code:

local object = objects[key] local velX = object.deltaX[1] local velY = object.deltaY[1] if object.bodyType then object.x = object.x + velX object.y = object.y + velY else local remainingVelX = abs(object.deltaX[1]) local remainingVelY = abs(object.deltaY[1]) local velXSign = 1 local velYSign = 1 if velX \< 0 then velXSign = -1 else velXSign = 1 end if velY \< 0 then velYSign = -1 else velYSign = 1 end while remainingVelX \> 0 or remainingVelY \> 0 do local vX local vY if remainingVelX \> blockScaleX / 5 then vX = blockScaleX / 5 remainingVelX = remainingVelX - blockScaleX / 5 else vX = remainingVelX remainingVelX = 0 end if remainingVelY \> blockScaleY / 5 then vY = blockScaleY / 5 remainingVelY = remainingVelY - blockScaleY / 5 else vY = remainingVelY remainingVelY = 0 end moveSprite(key, vX \* velXSign, vY \* velYSign) end end table.remove(object.deltaX, 1) table.remove(object.deltaY, 1)

This should hopefully allow the movement functions to operate normally without modification to your original code.

#8

Hi @dyson22,

Non-active (isBodyActive = false) physics bodies do not intercept raycasts. Just an FYI. :slight_smile:

Brent

#9

Thanks Brent! I was hoping that would be the case, else raycasting on individual map layers when others are present would become troublesome.

#10

I think I have the same issue with the latest version of MTE. If I add physics body to my sprite then movespriteto does not work, I have tried the code you have posted and the sprites do move but not in the places they should

#11

In what way are they not moving to the places they should, exactly? Are they offset a small distance from where you’d intended to send them, or are they way off, or are they moving in an erratic fashion? More details would be useful here as I’m definitely trying to stamp out these incompatibilities for the next update.

#12

Well they are a small distance away from where I expected but also sometimes acting strange and zig zagging and skipping waypoints 

#13

If you could email your project to me I would appreciate it. This way I can see exactly what you’re talking about and look into incorporating fixes into the next update.

#14

Thanks I have emailed you

#15

I think I’ve run into this problem as well a few times. Try calling mte.update() between lines 10 and 11 of your code snippet. This should move the sprite into position before the physics API takes over. 

#16

Thank you sir - worked a treat.

#17

Spoke too soon :slight_smile:

After I change that - the characters appears where they should be, however they’re not responding to moveSpriteTo - if I remove the addBody line it all works flawlessly ?!?

#18

Hey Dyson - just a little more info.

I spent a few hours stepping through MTE last night and realised that the problem stems from the update function. More specifically the object.isBodyActive is continuously true, so beyond the first run through it’s never updating the object’s x/y property.

Even after stepping through the code, line-by-line, I can’t see where this property is changing from its initial nil value to true; so I was hoping you might be able to shed some light on it. If the addBody line is removed from above then the isBodyActive property is always nil ?!?

#19

OK, I feel slightly stupid - from what I can gather I can’t move the sprite around if it’s a physics object by modifying x/y values?

The thing is I only want physics for Raycasting/Field ofView and feel that a whole refactor to cater for moving objects around using physics is on the excessive side.

Damn!

However it doesn’t answer the whole issue over the isBodyActive property?!?

Edit

OK I feel even more stupid :slight_smile: So .isBodyActive is obviously a property of Corona physic objects and not MTE as I originally suspected.

If I stick object.isBodyActive = false in the :Execute method of my object’s FSM everything works peachy - pretty sure there will be problems further down the road, but at least the object is moving and he’s got a physics body attached :slight_smile:

#20

I’d be curious to know whether a non-active physics body can intercept rays. 

The Physics API and MTE’s movement functions don’t play particularly nice with each other at the moment when they’re both acting on the same object, but this is something I will definitely rectify in the next update, perhaps sooner if I can nail down a quick fix to tide things over.

EDIT

I’ve come up with a possible fix, if you’d like to try it. Open mte.lua and navigate to line 9428, which is in the update() function. You’ll see the following block of code:

local object = objects[key] local velX = object.deltaX[1] local velY = object.deltaY[1] local remainingVelX = abs(object.deltaX[1]) local remainingVelY = abs(object.deltaY[1]) local velXSign = 1 local velYSign = 1 if velX \< 0 then velXSign = -1 else velXSign = 1 end if velY \< 0 then velYSign = -1 else velYSign = 1 end while remainingVelX \> 0 or remainingVelY \> 0 do local vX local vY if remainingVelX \> blockScaleX / 5 then vX = blockScaleX / 5 remainingVelX = remainingVelX - blockScaleX / 5 else vX = remainingVelX remainingVelX = 0 end if remainingVelY \> blockScaleY / 5 then vY = blockScaleY / 5 remainingVelY = remainingVelY - blockScaleY / 5 else vY = remainingVelY remainingVelY = 0 end moveSprite(key, vX \* velXSign, vY \* velYSign) end table.remove(object.deltaX, 1) table.remove(object.deltaY, 1)

Comment it out and add this replacement block of code:

local object = objects[key] local velX = object.deltaX[1] local velY = object.deltaY[1] if object.bodyType then object.x = object.x + velX object.y = object.y + velY else local remainingVelX = abs(object.deltaX[1]) local remainingVelY = abs(object.deltaY[1]) local velXSign = 1 local velYSign = 1 if velX \< 0 then velXSign = -1 else velXSign = 1 end if velY \< 0 then velYSign = -1 else velYSign = 1 end while remainingVelX \> 0 or remainingVelY \> 0 do local vX local vY if remainingVelX \> blockScaleX / 5 then vX = blockScaleX / 5 remainingVelX = remainingVelX - blockScaleX / 5 else vX = remainingVelX remainingVelX = 0 end if remainingVelY \> blockScaleY / 5 then vY = blockScaleY / 5 remainingVelY = remainingVelY - blockScaleY / 5 else vY = remainingVelY remainingVelY = 0 end moveSprite(key, vX \* velXSign, vY \* velYSign) end end table.remove(object.deltaX, 1) table.remove(object.deltaY, 1)

This should hopefully allow the movement functions to operate normally without modification to your original code.