Need some help with moving physics object to target

[NaitorStudios]

I mean the condition that pairs the two objects by comparing their IDs, that's quite slow...
Of course Physics as well is slow in this case, but you should avoid having to rescope the objects multiple times.

As for math formulas, this has some good stuff:
https://clickstore.clickteam.com/math-and-loving-the-expression-editor

For LOS, no, a cone is a range, and you can't do a range without multiple rays, which would decrease performance even further...
You could perhaps use one ray and scan from one side of this imaginary cone to another tho...
As for the idea of checking everything in between two lines, that's another equation entirely, it wouldn't be able to know if there's a obstacle in the middle.
An array based LOS would be more efficient I think.

The ghost target to the last known position, that's good yes, I was doing it on my pathfinding example.

Edit: Ah, another thing, 325 is the max physics enemies you can have, so you may need to use a rudimentary movement for enemies out of sight to improve performance and limit to 325 on screen.

[DaveC]

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

hah! of course - great optimizations. Great use of sub-events, my aim is always to just make it work and be readable (to me at least) rather than go for optimization. I guess you have to do what you have to do if you want 325 enemies on screen �� but seeing those changes definitely makes me rethink the way I go about things.

[Outcast]

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).

Thanks for that link it works now and have started to read through!

[Outcast]

I mean the condition that pairs the two objects by comparing their IDs, that's quite slow...
Of course Physics as well is slow in this case, but you should avoid having to rescope the objects multiple times.

As for math formulas, this has some good stuff:
https://clickstore.clickteam.com/math-and-loving-the-expression-editor

For LOS, no, a cone is a range, and you can't do a range without multiple rays, which would decrease performance even further...
You could perhaps use one ray and scan from one side of this imaginary cone to another tho...
As for the idea of checking everything in between two lines, that's another equation entirely, it wouldn't be able to know if there's a obstacle in the middle.
An array based LOS would be more efficient I think.

The ghost target to the last known position, that's good yes, I was doing it on my pathfinding example.

Edit: Ah, another thing, 325 is the max physics enemies you can have, so you may need to use a rudimentary movement for enemies out of sight to improve performance and limit to 325 on screen.

Ah I see! Will check out that expression editor example also!

About performance I wonder how much one have to worry about it though on todays computers? Also is 325 really max physics enemies? I actually tried to make a variant of the example where there are a lot more enemies on screen (and you can duplicate them by pressing mouse) and it does not seem to be a cap for me?

Things really start to slow down a lot though after about 500 units on screen. I can actually go up to about 800 without too much impact on performance but I left the cap with max 1000 objects in the frame because if I go over 1000 it really starts to go to a crawl even on my very powerful computer. Would be interesting how performance is on other less powerful computers at around 500 units. (and at that point the whole screen is pretty much filled up so no real reason to go much higher)

Though I also suspect the collision events are the most demanding between the physics objects? Perhaps there would be things that could be done to also counteract them a bit like for example only checking for collision between enemies every other frame or so?

Also I notice there is some value in the actual Physics engine object that might be modified for performance? Maybe Position iterations? I am unsure what this does though exactly since I did change it from the value it has now (2) and 1 or 10 but did not see any difference?