Need some help with moving physics object to target

[Outcast]

I wonder if anyone has some experience with the Physics object and know how to make a physics objects move toward a target?

I have made an example where I have a physics object (a circle) and I can apply velocity in 4 different directions so the object moves, but I would like to make it so it always applies velocity in the angle of the target (the cross) so it moves toward it. Also I forgot how to set the collision on the object so it collides with the physics obstacle? (the gray rectangle) I think you should not use a regular overlap event if I remember correctly when it comes to physics?

Optimally I would like to make it so the circle always moves toward the target but can collide with the obstacle, though if it does collide with the obstacle it would be nice if it keeps pushing against the obstacle and have enough (or lack of) friction so it will glide along the obstacle toward the target instead. I think this will make sense in the mfa since I have placed the target so that if the object would apply some force toward the target it would hit the wall and then continue to glide toward the wall to the opening that finally lets it get to the target.

Anyone have more experience with this and the physics object that know how to make this happen?

[DaveC]

attached is probably the simplest way to do that. Set the move angle of your red ball to the "angle of a vector" being the targets x/y co-ordinates.

[Outcast]

attached is probably the simplest way to do that. Set the move angle of your red ball to the "angle of a vector" being the targets x/y co-ordinates.

Thank you that was smooth!

When it comes to collision with objects set to obstacles in the physics engine is using overlap and regular collision events the way to go?
I have a vague memory one should do it some other way when it comes to physics?

Or is it just that one should avoid using overlap events and instead use collision events? (seem to work)

[Outcast]

I have continued to edit the example so that the red balls now follow the target (x and y of mouse) and it is starting to actually become a quite nice method of enemies that hunt the players (something like zombies).

However I am trying to think of the best way to make the balls (enemies) detect if there is a wall blocking their way to the player. For example if you place the target just opposite a wall the enemies just push up straight toward the wall.

I am thinking if a good way for this would be to draw a line from the enemy to the player and if that line is overlapping an obstacle that means they need to course correct until there is a clear line again to the player.

I know I have seen/read that there should be some way to draw a line during runtime? I am pretty sure there is even a special name for such lines? What would be a good way to do it? Create a pixel square and somehow stretch its scale to a line or is there other methods to do it? I am pretty sure I have seen am example somewhere of this but I just can't remember. Anyone know?

[DaveC]

Try out this attached example.

Drawing a line is probably relatively efficient? There would be plenty of ways to optimize the attached. And plenty of ways to improve the AI.. for one, have a chase "cooldown" where if the enemy loses sight of the player, they still chase for 1-2 seconds before giving up. You could have the enemy stop and shoot if they're within a certain distance etc.

[Outcast]

Try out this attached example.

Drawing a line is probably relatively efficient? There would be plenty of ways to optimize the attached. And plenty of ways to improve the AI.. for one, have a chase "cooldown" where if the enemy loses sight of the player, they still chase for 1-2 seconds before giving up. You could have the enemy stop and shoot if they're within a certain distance etc.

Wow that is a really cool example! I have not dug into how it really works yet though, especially how the line is drawn Is it possible to explain the calculations in the drawing of the line event? I think it is event 29?

Set X scale: Sqr(( X( "Enemy" ) - X( "Player" ) ) pow 2 + ( Y( "Enemy" ) - Y( "Player" ) ) pow 2)

Set Angle: OAngle( "Enemy", X( "Player" ), Y( "Player" ) ) - 180

[NaitorStudios]

You actually don't need square root for this, you can use the distance expression from the object, basically that first part is setting the line scale to the distance between the two objects.
As for angle, it's finding the angle between the two, only thing different there is that it had to rotate it around because of the direction the object stretches to.

[NaitorStudios]

My internet is pretty awful right now, checked the file. Great example btw!
Just a few notes, it's terrible for performance to be scoping objects in multiple events...
That OAngle() also can be very innacurate at times, so I've replaced with atan2().
After some optimization, I've also added a collision to the "player", just so it looks nice hehe

[Outcast]

My internet is pretty awful right now, checked the file. Great example btw!
Just a few notes, it's terrible for performance to be scoping objects in multiple events...
That OAngle() also can be very innacurate at times, so I've replaced with atan2().
After some optimization, I've also added a collision to the "player", just so it looks nice hehe

Very nice!! About scoping and performance are you specifically speaking of the foreach loops in the Line of Sight group? I noticed it seems you reduced from 5 foreach to 1?

As for the actual calculations I am still trying to figure them out. Honestly I have not studied math in like 20 years so maybe that is the problem haha and I need to dust that off.. I have actually never used calculations with Scr, pow2 or this atan2. If someone want to dust that stuff off any suggestions on a good place? Honestly the very best way would probably be a code example if there exist any out there that demonstrate these in action and other expressions in a pedagogical way, but I doubt that exists?

Also regarding the line of sight with a line, would the same principle apply to a the more realistic and common cone shaped field of vision? Or that would have to be done in a completely different way since scaling a big cone would induce a lot more performance demand? I guess it would not be possible to draw two lines at an angle and then check everything in between? It seems like a very much more complex prospect?

I was thinking a bit also about other ways to reduce performance. One funny thing would perhaps be if the line of sight only checked like every 30-60 frames or so (that way the player could sneak past the field of view quickly if lucky) and the check would not be every frame (unless chasing) so that would save perfomance. Other things I thought about was if the enemies chase a ghost of the target and not the actual target so if the player turns a corner the last known location would be at that corner.

[MuddyMole]

For the cone of vision, you would use the exact same method, but before you check for line-of-sight, you would check the difference between the angle the enemy is facing, and the angle from the enemy to the player.
The angle from the enemy to the player is: ATan2( Y("enemy") - Y("Player"), X("Player") - X("Enemy") )
The absolute difference between two angles is: Abs(((AngleA - AngleB + 540) mod 360) - 180)

eg. If your enemy has a 90 degree cone of vision, you would test if the absolute difference is less than 45, meaning 45 degrees either side of centre.

If you're interested, I made a website mostly about maths for using with CF2.5 - klikology.lovestoblog.com (the hosting sevice InfinityFree is having problems, so it's down right now, but if you check back later it should start working).

I know it will spoil your visible debugging lines, but from a performance point of view, it is important that you only run the minimum number of tests - don't do the line-of-sight test if you already know the enemy is out of range. The order in which you do the tests also matters.

Make sure you do the line-of-sight test last, because it is computationally slow, and not necessary for those instances which are out of range or outside the cone of vision. I would do both those tests outside of the ForEach loop, and only run the ForEach loop for those instances that passed both (I would also reuse the Enemy_LOS object, instead of creating one per enemy).

Whether you do the distance or angle test first depends on a couple of things. The angle test is more computationally expensive, but if enemies have a narrow cone of vision, it could potentially mean that a lot more enemy instances will fail the test, meaning you can skip the distance check for them. On the other hand, if your map is very large or the enemies have a very short detection range, you would do the distance test first, because more enemy instances will fail that (meaning you can skip the angle test for them).