Top down movement

Hi all. I've been working on a little test to get a multi layered character to move around. The torso faces the mouse and the legs are supposed to move logically in relation to it. Problem I've hit all of a sudden (this is very messy and unfinished, be warned) is that the 'mouselook' that orientates the torso seems to just stop if the pointer is static. It works for a few seconds while you move around then after that, it only reorientates if you move the mouse. Something I've missed?

Any help would be appreciated. Also any suggestions on where to improve or make this more efficient would be massively appreciated.

Try leaving the mouse alone in one spot then using WASD to walk round it and eventually it stops rotating.

http://www.mediafire.com/?67qonmzz3p0ascc

Cheers

It seems to be a bug in anglediff - if the torso and the arrow ever have the same angle (I.E. the arrow, the torso, and the mouse are on the same line) the difference between them becomes 0 and gets stuck there.

As near as I can tell, your aim with those calculations is to make the player's torso turn to face the mouse more quickly at the beginning of its turn and then ease into place, right?

That's correct yeah, the torso never jumps directly to face the mouse pointer but smoothly rotates and then decelerates as it approaches the target angle

Here's a cap demonstrating a much cleaner and easier way to smoothly rotate a sprite towards the cursor.

http://dl.dropbox.com/u/9498285/smoothangle.cap

That's awesome! Much neater and more efficient, and it's solved my problem too

Thanks for the help! Any other suggestions or improvements would be great

Now to try and get my diagonal movement working :S Haha

I've applied this method to a basic kindof space ship type movements alike asteroids. I'm just wondering if there's a fix for this.

If you set the speed of turning to be relatively slow, the turn takes longer to face the pointer, obviously. Due to the speed at which you can move the mouse, it's possible to 'overtake' the 180 point and therefore shorten the turning distance. What this does is it creates a little jerk as it switches from rotating clockwise to anti-clockwise, or vice versa.

I'm wondering if there's a simple/efficient way to keep it rotating in the same direction once it's picked up momentum, as this little switch looks unnatural and it's really niggling me

Any ideas on this? It's frustrating me to the point of making me feel sick Every example online just doesn't apply! I'm trying to get it to decelerate before it begins the rotation in the opposite direction but all that maths just gets confusing :S

v92

http://www.mediafire.com/?b7o4gpovvpyyl95

It'll be a lot more complicated. It would involve ditching the entire rotate-towards-position action because it automatically chooses the shortest distance, and once you pass the 180 mark it will immediately reverse direction. Momentum would mean there would be carryover in the opposite of the desired direction for at least a few pixels.

You would have to calculate rotational acceleration and apply it manually with always set angle actions, letting positive values represent clockwise rotation and negatives for anticlockwise.

When the difference between the current and desired angles is between 90 and 180 degrees you would increase the acceleration towards the cursor, and when it's between 90 and 0 you would decrease it until it coasts to a stop at 0.

Since the only value we're modifying is acceleration, the slow turnaround would handle itself as the value nears and then coasts past zero. The tricky part is getting the system to understand which way to turn, especially when dealing with the 360 = 0 point.

Now that I look at it, the rotate-towards-position action will accept negative values. It might be possible to mess with this value to approximate the effect...

EDIT: Now that I look at it all written down, I think this code as written would cause it to simply rotate around the wrong way, because as soon as it passed 180 it would still take the shorter direction.

Thanks for the reply victrium

Yeah I started to figure out it'd take a lot more calculation - I did try this with the physics plugin before which worked to an extent, but was too unstable for me to be satisfied with :S Also, I'm avoiding using it now as those previous projects crash with the latest version of Construct.

It's easy to get this effect with WASD or cursor keys but so much more difficult when you have a target angle... I was hoping mouse control would feel a little bit more natural...

I've looked all over for examples and tutorials in other languages but had very little luck!

I think you could put a restriciton to rotating, put the angledifference as timer countdown before it is able to turn to other side, meaning it must slow down by decreasing angledifference before it can rotate to other side...

I have no idea how to use the timer stuff in Construct :S

I've been looking into some tutorials on the implementation of heat seeking behaviour... technically it's the same thing, the target is just the mouse. Plus it'll be great for enemy AI later on. Can't seem to get anywhere with it though

http://gpwiki.org/index.php/Heat_Seeker

Here's a way to eliminate the jerk in the movement by using a variable that keeps track of the total angle change and reducing the variable whenever the object angle is changed. Hope that helps.

req 0.99.92

http://dl.dropbox.com/u/5426011/examples/angaccum.cap

Exactly 110% what I wanted it to do. R0J0hound, I love you.

Here's a link to a picture of some cake for your trouble: Cake

Ah, 'Is Clockwise Of'... that's pretty much what I was lookin' for!

Might have found a bug here, or maybe I'm doing something wrong. Last night I attempted to merge rojohounds example into my original project, and it refused to work. Eventually I stripped it back so that mine was basically event for event identical to the example, even down to the event ordering. At that point it miraculously began to work. This is keeping in mind that in rojohounds example, the target is the mouse pointer and in mine, the target was a sprite X/Y which was placed at the location of the mouse in the Always event.

Anyways, I thought Construct was just having a bit of a funny turn and left it. I was experimenting just now seeing if I could get a target to move in a restricted circle around my ship. The cap I've posted doesnt work. However, if you change the references to 'Target.x' and 'Target.y' in the set target position line to instead be mouse coordinates mousex and mouse y, it works (not properly but that's because I only just started playing with this)

See if anyone else has a problem

http://www.mediafire.com/?5q5kn9dsxp3gb92

It would seem that there's some problem working out an angle between two objects, but it''s fine when using an object and the mouse?