How do I determine moving angle or save last position?

Get help using Construct 2

Post » Tue Feb 14, 2017 12:38 pm

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!
B
30
S
7
G
4
Posts: 31
Reputation: 4,913

Post » Tue Feb 14, 2017 1:04 pm

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.

Image
Banned User
B
28
S
7
G
58
Posts: 1,229
Reputation: 34,825

Post » Tue Feb 14, 2017 1:12 pm

B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Tue Feb 14, 2017 1:26 pm

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?
B
30
S
7
G
4
Posts: 31
Reputation: 4,913

Post » Tue Feb 14, 2017 2:00 pm

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 ...
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Tue Feb 14, 2017 2:20 pm

Virpoja wrote: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"
Banned User
B
28
S
7
G
58
Posts: 1,229
Reputation: 34,825

Post » Tue Feb 14, 2017 2:33 pm

@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.
B
30
S
7
G
4
Posts: 31
Reputation: 4,913

Post » Tue Feb 14, 2017 2:37 pm

@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.
B
30
S
7
G
4
Posts: 31
Reputation: 4,913

Post » Tue Feb 14, 2017 3:12 pm

Virpoja wrote:@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.

Image

That gives you the angle and you can use the variable to set angle from other events
Banned User
B
28
S
7
G
58
Posts: 1,229
Reputation: 34,825

Post » Tue Feb 14, 2017 3:54 pm

@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.
B
30
S
7
G
4
Posts: 31
Reputation: 4,913

Next

Return to How do I....?

Who is online

Users browsing this forum: No registered users and 16 guests