Changing bounce, friction, etc dynamically

[alfgago]

I’m doing a platformer game, and I want my character to slide or bounce more on certain terrain. Is there any way to change the bounce/friction property of a physical object once it’s created?
object.bounce = 1 doesn’t work

I want something like this:

bouncyGround:addEventListener(“preCollision”, onPreCollision)
local function onPreCollision( event )
if ( event.other.name== “character” ) then
event.other.bounce = 1
end
end

And then change it back to normal on postCollision, can this be done? or is there any other solution? [import]uid: 53195 topic_id: 33454 reply_id: 333454[/import]

[horacebury]

You can’t change the physical properties of an object during a collision, but set a timer for 1 millisecond and you can make it near enough. Here’s my function for modifying physical properties which can only be set at addBody() time:

[lua] – group is the dsiplay group/object to have a body applied to it
– you can pretty much ignore the warning if you call this func before adding a body to the group
function applyBody( group, params )
local isActive, vx, vy, rot = true, 0, 0, 0

if (group.getLinearVelocity) then
isActive, vx, vy, rot = group.isBodyActive, group:getLinearVelocity(), group.angularVelocity
end

physics.removeBody( group )

– the values here are from my code and are my defaults…
physics.addBody( group, {
bounce=params.bounce or .8,
friction=params.friction or 0,
density=params.density or .1,
radius=params.radius or 38,
filter=params.filter or {groupIndex=params.groupIndex or groupIndex}
} )

group.isBodyActive = params.isActive or isActive
group:setLinearVelocity( params.linearVelocityX or vx, params.linearVelocityY or vy )
group.angularVelocity = params.angularVelocity or rot
end[/lua]

Then call the function by passing in the names and values you want to set:

[lua] applyBody( someObj, { bounce=.1, linearDamping=2, angularDamping=8 } )[/lua] [import]uid: 8271 topic_id: 33454 reply_id: 132917[/import]

[bjsorrentino]

There actually is a solution now, at least for the “bounce” aspect. Read about it in my latest tutorial about “PhysicsContact”.

http://www.coronalabs.com/blog/2012/11/27/introducing-physics-event-contact/

This allows you to control the bounce property on a per-collision basis, without changing the core bounce property of either object.

As for the “friction” one, PhysicsContact allows that too, but I can’t figure out how it’s actually useful in practice. Since it doesn’t change the core friction of either object, it seems that you only get a momentary friction change. For your purpose, I would suggest maybe you apply an inverse “damping” to the character when you need to, and then revert the damping to normal after the character leaves the platform.

Hope this helps!
Brent

[import]uid: 200026 topic_id: 33454 reply_id: 132951[/import]

[alfgago]

Thank you both! I’ll try those solutions ^^ [import]uid: 53195 topic_id: 33454 reply_id: 132975[/import]

[horacebury]

Hi Brent,

First off, congratulations on your recent transfer

Second, the tutorial says that the majority of uses for Physics Contact will be in the preCollision event. My only beef with that is that it has such a massive overhead that simply using the preCollision listener is almost unusable in real world apps.

Would be great to get your take on that. Also, maybe some educating (of me) on how to apply the preCollision event to working code might not go amiss…

Matt. [import]uid: 8271 topic_id: 33454 reply_id: 132977[/import]

[horacebury]

You can’t change the physical properties of an object during a collision, but set a timer for 1 millisecond and you can make it near enough. Here’s my function for modifying physical properties which can only be set at addBody() time:

[lua] – group is the dsiplay group/object to have a body applied to it
– you can pretty much ignore the warning if you call this func before adding a body to the group
function applyBody( group, params )
local isActive, vx, vy, rot = true, 0, 0, 0

if (group.getLinearVelocity) then
isActive, vx, vy, rot = group.isBodyActive, group:getLinearVelocity(), group.angularVelocity
end

physics.removeBody( group )

– the values here are from my code and are my defaults…
physics.addBody( group, {
bounce=params.bounce or .8,
friction=params.friction or 0,
density=params.density or .1,
radius=params.radius or 38,
filter=params.filter or {groupIndex=params.groupIndex or groupIndex}
} )

group.isBodyActive = params.isActive or isActive
group:setLinearVelocity( params.linearVelocityX or vx, params.linearVelocityY or vy )
group.angularVelocity = params.angularVelocity or rot
end[/lua]

Then call the function by passing in the names and values you want to set:

[lua] applyBody( someObj, { bounce=.1, linearDamping=2, angularDamping=8 } )[/lua] [import]uid: 8271 topic_id: 33454 reply_id: 132917[/import]

[bjsorrentino]

There actually is a solution now, at least for the “bounce” aspect. Read about it in my latest tutorial about “PhysicsContact”.

http://www.coronalabs.com/blog/2012/11/27/introducing-physics-event-contact/

This allows you to control the bounce property on a per-collision basis, without changing the core bounce property of either object.

As for the “friction” one, PhysicsContact allows that too, but I can’t figure out how it’s actually useful in practice. Since it doesn’t change the core friction of either object, it seems that you only get a momentary friction change. For your purpose, I would suggest maybe you apply an inverse “damping” to the character when you need to, and then revert the damping to normal after the character leaves the platform.

Hope this helps!
Brent

[import]uid: 200026 topic_id: 33454 reply_id: 132951[/import]

[alfgago]

Thank you both! I’ll try those solutions ^^ [import]uid: 53195 topic_id: 33454 reply_id: 132975[/import]

[horacebury]

Hi Brent,

First off, congratulations on your recent transfer

Second, the tutorial says that the majority of uses for Physics Contact will be in the preCollision event. My only beef with that is that it has such a massive overhead that simply using the preCollision listener is almost unusable in real world apps.

Would be great to get your take on that. Also, maybe some educating (of me) on how to apply the preCollision event to working code might not go amiss…

Matt. [import]uid: 8271 topic_id: 33454 reply_id: 132977[/import]

[bjsorrentino]

Hi Matt,

"First off, congratulations on your recent transfer
Thanks for the mention, I appreciate it!

As for the pre-collision event, I believe that it’s the “only way” to use PhysicsContact, at least in this scenario of one-sided platforms. No matter what, you have to tell Corona that a collision is about to occur, so it can effect the actual collision “contact” when it does occur. I don’t think there’s any way around that.

That being said, have you tried using local pre-collision handlers? I actually didn’t know this was possible until a couple days ago, but it is. I configured a local (as in, NOT Runtime) preC listener into the bouncing balls project that I linked to in my tutorial, and it works very nicely… and best of all, it doesn’t appear to be a “noisy” collision listener at all… in fact, it registers just one preC response on each collision, as should be expected.

I can share this code with you if you’d like; it’s very easy, and it uses local collision listeners which I absolutely prefer.

Brent
[import]uid: 200026 topic_id: 33454 reply_id: 133434[/import]

[horacebury]

Yes, please, that would be very useful.

Thanks,
Matt. [import]uid: 8271 topic_id: 33454 reply_id: 133449[/import]

[bjsorrentino]

Hi Matt,
I just realized that I already typed it out in one of my responses to the blog post. Take a look under my response to “sam3dus” here:
http://www.coronalabs.com/blog/2012/11/27/introducing-physics-event-contact/

And let me know your test results please. Somehow this just doesn’t seem to be as “noisy” as my previous testing with pre-collisions, but maybe I’m missing something and it really isn’t any more efficient than before.

Brent
[import]uid: 200026 topic_id: 33454 reply_id: 133500[/import]

[horacebury]

Thanks - I typically use that approach but I didn’t realise it was called a “local handler.” [import]uid: 8271 topic_id: 33454 reply_id: 133515[/import]

[bjsorrentino]

Hi Matt,

"First off, congratulations on your recent transfer
Thanks for the mention, I appreciate it!

As for the pre-collision event, I believe that it’s the “only way” to use PhysicsContact, at least in this scenario of one-sided platforms. No matter what, you have to tell Corona that a collision is about to occur, so it can effect the actual collision “contact” when it does occur. I don’t think there’s any way around that.

That being said, have you tried using local pre-collision handlers? I actually didn’t know this was possible until a couple days ago, but it is. I configured a local (as in, NOT Runtime) preC listener into the bouncing balls project that I linked to in my tutorial, and it works very nicely… and best of all, it doesn’t appear to be a “noisy” collision listener at all… in fact, it registers just one preC response on each collision, as should be expected.

I can share this code with you if you’d like; it’s very easy, and it uses local collision listeners which I absolutely prefer.

Brent
[import]uid: 200026 topic_id: 33454 reply_id: 133434[/import]

[horacebury]

Yes, please, that would be very useful.

Thanks,
Matt. [import]uid: 8271 topic_id: 33454 reply_id: 133449[/import]

[bjsorrentino]

Hi Matt,
I just realized that I already typed it out in one of my responses to the blog post. Take a look under my response to “sam3dus” here:
http://www.coronalabs.com/blog/2012/11/27/introducing-physics-event-contact/

And let me know your test results please. Somehow this just doesn’t seem to be as “noisy” as my previous testing with pre-collisions, but maybe I’m missing something and it really isn’t any more efficient than before.

Brent
[import]uid: 200026 topic_id: 33454 reply_id: 133500[/import]

[horacebury]

Thanks - I typically use that approach but I didn’t realise it was called a “local handler.” [import]uid: 8271 topic_id: 33454 reply_id: 133515[/import]