How do I determine moving angle or save last position?

Hello guys! I have a problem which is driving me nuts....

I need to figure out a way to determine which direction / angle object is heading. I know several ways to achieve this but not the way I need it to work atm.

So the thing is, I DO NOT want to use behaviors on the object (so this counts out using bullet, 8 dir, physics... to determine angle of motion.) Object is moved just with *dt pixels... and this is how i need it to work on this project.

I can get value using: "angle(Sprite.LastX , Sprite.LastY , Sprite.X , Sprite.Y)"

Basically I have created instance variables to store sprite position on previous tick and compare that to current position. So this kind of works, BUT when object stops the value updates to 0. I am guessing it only does this for one tick, but it`s enough to render this unusable. (since I use this method for collision testing)

sample capx: https://dl.dropboxusercontent.com/u/137 ... otion.capx

Hope some one can help!

I can't view your CAPX because I still have the older C2 version but this should work if you just need to know the angle of any sprite without behavior or with behaviors.

https://www.dropbox.com/s/o0q09nybig47k ... .capx?dl=0

Thanks for your answers guys. lamar object angle won`t work since sprite can move other directions that it is facing...

99Instances2Go: Your solution is nice, its actually same principal that I am using on my actual project atm.. However the point why I am trying to figure out the actual direction object is facing is because I want to be able to go any direction (strafe etc) and always have the Collision Detector on the correct position. I should have implemented other directions to my example but I got lazy

So using several ImagePoints is my plan B, but since I intend to use similar collision detection for AI, I would like to have a very "clean" solution that won`t rely on inputs but rather to actual movement angle. I know I can work around this but I just want the cleanest implimentation..

Anyway thanks alot, any other suggestions?

First coming to mind. The character can move forward and backwards. Hence, 1 Collision Detector will not do. Need at least two. Character can have (depending on the map) a wall behind and a wall in front.

Now, if you gonna build an AI around this, i suppose we speak about multiple characters having multiple sensors. You got to move the sensors. You got to select the correct sensors. You got to test collision between many sensors and many objects.

Lets walk to this.

You got to move the sensors.

To place the sensors, the easy way is to use imagepoints (so we have allready the image points).

Now to keep them there, you can not use 'pin', that is a behavior. You dont wanna use behaviors.

So that will be placing the sensor every tick to its imagepoint.

Moving so many sensors around will have an impact on the performance.

To place it there, you need to select the sensor that goes with the right character.

You got to select the correct sensors.

The obvious way is using containers, else you land in a complicated 'pick based on instance variables' situation.

You got to test collision between many sensors and many objects.

Each character will have to react in a 'personal' way to wall. Still talking about an AI. It will get (i guess) a new direction depending on the position of the wall.

So you will have to test collision of each sensor to each wall.

That will result in a lot of collision testing. And if there is one thing to avoid (to keep performance), that is collision testing.

Conclusion.

All the moving around, all those events to select objects, all the collision checks .... when dealing with a lot of characters .... can not talk about a clean solution.

What i proposed (it is up to you witch way you go) .... is using already moving imageponts ... no pick problems .... no CPU demanding collision checks ...

Thanks for your answers guys. lamar object angle won`t work since sprite can move other directions that it is facing...

I am not following you?

Of course the object can move other directions but you said you wanted to determine what angle the object is "heading" and that event will give you the objects current angle for objects without behaviors. If you are using bullet or directions then you use those angles and a variable.

You "I need to figure out a way to determine which direction / angle object is heading"

99Instances2Go: Thank you for your answer, the thing is that all the objects are moving only one direction at the time, so they only need one collider (which has to be in the right direction) and this is what I am trying to achieve. I have this kind of system working on the grid based game and it`s very light solution. (it`s just harder to pull of with pixel perfect movement) I do not think performance is a real issue here. And its more precise than using imagepoints. Also container works great for picking, as you mentioned.

X = 16*cos (AngleOfMotion)+ Sprite.X

Y= 16*sin(AngleOfMotion)+ Sprite.Y

gives me the result i need for setting up the correct position for collider. Problem is that on collision the Sprite stops and my return value for "AngleOfMotion" glitches for 1 tick and messes up the collision testing. This is a problem I don`t have on grid based version.

Also the actual project is using FPS view with raycasts and if collision detection is not spot on, you will be able to see through walls etc.

lamar, sorry I was not precise enough.. What i need is the angle of motion, which in this case is not the same as the actual "heading" or the objectAngle. Also I am not using bullets etc for this, for several reasons.

lamar, sorry I was not precise enough.. What i need is the angle of motion, which in this case is not the same as the actual "heading" or the objectAngle. Also I am not using bullets etc for this, for several reasons.

OK when you do not use direction motion or bullet motion the angle will always be 0 unless you change it in the layout.

You need two variables and one to store the angle and one to change the angle of motion.

That gives you the angle and you can use the variable to set angle from other events

lamar, thanks.

I guess I am being kind of picky but I want to stay away of using "wait 0.1" etc. stuff, since I want really responsive and crisp implementation.

I am already using variables to store last position and using that to calculate the correct angle. That works pretty well too. I think I have to find some way to store the last position (just before collision) to prevent "angle of motion" updating to 0.

lamar, thanks.

I guess I am being kind of picky but I want to stay away of using "wait 0.1" etc. stuff, since I want really responsive and crisp implementation.

I am already using variables to store last position and using that to calculate the correct angle. That works pretty well too. I think I have to find some way to store the last position (just before collision) to prevent "angle of motion" updating to 0.

Well if you can click faster than 0.1 seconds you have some fast reactions lol!

You can remove those and they were put in for using tap and I forgot to take them out. Runs fine without them.

Anyway, what I gave you works and use it if you want or not. Have a good day!

Ok, I updated the example. https://dl.dropboxusercontent.com/u/137 ... n_ve2.capx

Now you can also strafe by holding ALT key. In example you can see that collision detector sprite is always on the correct position. (even if you hold ALT, Left Arrow, Forward Arrow at the same time)

So that is working great... Except when it matters, when the collision is detected.

SO the thing i need is a sure way to "save" the last position before collision to maintain the correct angle instead of it updating to 0.

Anyone have any ideas?

Using the last position to get the angle of motion isn't suitable in this case since from a stop the angle of motion will always just be 0. It needs to be moving for one frame to get a direction. However, notice that the angle of motion is connected to the object's angle and the input. So for example you could do this:

up arrow

--- angleOfMotion = sprite.angle

down arrow

--- angleOfMotion = sprite.angle+180

strave left

--- angleOfMotion = sprite.angle-90

strave left

--- angleOfMotion = sprite.angle+90

Damn... And I thought I had a good solution. Thank you R0J0hound and every one else for your suggestions. I think I will tinker around little bit more with the example provided by — Maybe try to implement some basic AI using that method.

Again, thank you all for your help

Gave it second though.

This what you actually want to do ?

https://www.dropbox.com/s/yc33l4u1d8e4f ... .capx?dl=0