Orbiting rotation around player

hey fellow developers,

I have a joystick that controls the movement & direction of my player but I was just wondering if I can have my player pick up a weapon from the ground. I was just wondering if I can have the weapon stick to the side of the player at all times now follow his rotation, position and everything kind of like this example

/ - \
| 0 |
\ - /

0 = player
/ - \ | = all sides of the gun orbiting/ revolving player 

Hi @jazzarssoul,

Are you using physics? If so, you could make the gun another physics object and weld it to the player with a weld joint.

Otherwise, you make the gun the same (canvas) size as the player, and use a Runtime listener to sync its position/rotation to the player as he moves around.

Brent

Hey Brent I attempted all kinds of physics joints on the 2 objects but all deemed not very suitable… Using the weld joint sparked all kinds of funky movement… Any chance you can provide an example of proper usage? cause I’m sensing one of the parameters I don’t quite understand is the anchorX and Y variables…

I sense that having the runtime listener will cause for a lot of confusion with multiple enemies capable of picking up weapons

Hi @jazzarssoul,

The anchor point should be in content (world) coordinates. That means, you need to determine the anchor point relative to the enemy’s current location and rotation. Fortunately, you can use the “localToContent” API for this.

http://docs.coronalabs.com/api/type/DisplayObject/localToContent.html

So, let’s say you want the gun to be in the “right arm” of the enemy, at like x=50, y=0 relative to the enemy’s center point (so, the gun is offset to the right 50 pixels from its center). You’d just code this:

[lua]

local tx,ty = enemy:localToContent( 50,0 )

[/lua]

This will give you the exact world content points, no matter where the enemy is located or how it’s rotated (any of the 360 degrees). Use those values to attach the gun to the enemy using a weld joint. You’ll probably need to do this after you rotate the gun to the same angle as the enemy, so the gun is oriented properly.

Brent

an update to our little problem…

built a test application for your suggestion with localToContent, works perfectly however… Implementing this into our current application what we’re working towards proves a little more difficult… I will attach an image that has the caption “what is happening” & “what should be happening” and this potentially could explain our problem a little more clearer.

as you can see from the images. with the first image this is what is happening: he can be anywhere on the level and be only shooting from that point.

the second image: all I’ve done is moved to the point of where he’s shooting from just so you can get perspective of what we want to happen

third image: showing the top left edge of our screen showing you what I think could be the issue behind local content to the global view? (I have no idea what I’m saying here)

I’m afraid I don’t understand the issue, or how this “border” is changing anything. The gun looks positioned properly to me…

Hey Brent the idea behind the pictures was showing current footage of the game.

The first image you see is the player is holding the gun and shooting down-right. the player is facing the right direction just fine but the source from where the bullet is getting created is in perspective a few metres above the player and to the right abit.

The second image is how we want the guy to be shooting (I’ve just moved to the source of shooting)

The third image is just showing how the source is coming from middle of the screen when you align the level to the top left (0,0) origin of the screen

What I should also point out is removing the gun from the view allows for the player to hold the weapon… leaving the bullets in the view means they shoot from that source in image 1. if we remove the bullets from the view they come from the gun just fine but have no interaction with other objects like enemies on screen because I suspect they are no longer in the same compatible view for collision to occur anymore…

this is all new to me, I have no idea what is happening. It just appears that localToContent has bound the weapon to the player. which is one step closer to our solution than what we figured out. thanks :slight_smile:

Hi @jazzarssoul,

Are you using physics? If so, you could make the gun another physics object and weld it to the player with a weld joint.

Otherwise, you make the gun the same (canvas) size as the player, and use a Runtime listener to sync its position/rotation to the player as he moves around.

Brent

Hey Brent I attempted all kinds of physics joints on the 2 objects but all deemed not very suitable… Using the weld joint sparked all kinds of funky movement… Any chance you can provide an example of proper usage? cause I’m sensing one of the parameters I don’t quite understand is the anchorX and Y variables…

I sense that having the runtime listener will cause for a lot of confusion with multiple enemies capable of picking up weapons

Hi @jazzarssoul,

The anchor point should be in content (world) coordinates. That means, you need to determine the anchor point relative to the enemy’s current location and rotation. Fortunately, you can use the “localToContent” API for this.

http://docs.coronalabs.com/api/type/DisplayObject/localToContent.html

So, let’s say you want the gun to be in the “right arm” of the enemy, at like x=50, y=0 relative to the enemy’s center point (so, the gun is offset to the right 50 pixels from its center). You’d just code this:

[lua]

local tx,ty = enemy:localToContent( 50,0 )

[/lua]

This will give you the exact world content points, no matter where the enemy is located or how it’s rotated (any of the 360 degrees). Use those values to attach the gun to the enemy using a weld joint. You’ll probably need to do this after you rotate the gun to the same angle as the enemy, so the gun is oriented properly.

Brent

an update to our little problem…

built a test application for your suggestion with localToContent, works perfectly however… Implementing this into our current application what we’re working towards proves a little more difficult… I will attach an image that has the caption “what is happening” & “what should be happening” and this potentially could explain our problem a little more clearer.

as you can see from the images. with the first image this is what is happening: he can be anywhere on the level and be only shooting from that point.

the second image: all I’ve done is moved to the point of where he’s shooting from just so you can get perspective of what we want to happen

third image: showing the top left edge of our screen showing you what I think could be the issue behind local content to the global view? (I have no idea what I’m saying here)

I’m afraid I don’t understand the issue, or how this “border” is changing anything. The gun looks positioned properly to me…

Hey Brent the idea behind the pictures was showing current footage of the game.

The first image you see is the player is holding the gun and shooting down-right. the player is facing the right direction just fine but the source from where the bullet is getting created is in perspective a few metres above the player and to the right abit.

The second image is how we want the guy to be shooting (I’ve just moved to the source of shooting)

The third image is just showing how the source is coming from middle of the screen when you align the level to the top left (0,0) origin of the screen

What I should also point out is removing the gun from the view allows for the player to hold the weapon… leaving the bullets in the view means they shoot from that source in image 1. if we remove the bullets from the view they come from the gun just fine but have no interaction with other objects like enemies on screen because I suspect they are no longer in the same compatible view for collision to occur anymore…

this is all new to me, I have no idea what is happening. It just appears that localToContent has bound the weapon to the player. which is one step closer to our solution than what we figured out. thanks :slight_smile: