I think I'm done for now. It turned out better than expected though, so I may eventually convert it into an RTS pathfinding system that handles multiple units efficiently.
Download: https://1drv.ms/u/s!Atq7cUIJ7uextFL_...aj0_3?e=xMv5ey
I think I'm done for now. It turned out better than expected though, so I may eventually convert it into an RTS pathfinding system that handles multiple units efficiently.
Download: https://1drv.ms/u/s!Atq7cUIJ7uextFL_...aj0_3?e=xMv5ey
Lovely, it does look really nice!
Thank you for the update.
Looking forward to the RTS pathfinding system MuddyMole.
Marv
Originally Posted by MuddyMole
I think I'm done for now. It turned out better than expected though, so I may eventually convert it into an RTS pathfinding system that handles multiple units efficiently.
Download: https://1drv.ms/u/s!Atq7cUIJ7uextFL_...aj0_3?e=xMv5ey
458 TGF to CTF 2.5+ Examples and games
http://www.castles-of-britain.com/mmf2examples.htm
Incredible exemple as usual!!!
You can add the feature if you click inside a polygon the charachter move to the closest point?
And another question, what's the diffrence beetwen this and the old exemple?
Btw, thanks for your great job!!!
Nope, there's no way to make it move to the nearest reachable point.
The previous version was based on polygons and vectors. All collision detection was done using pure maths, by calculating the intersection of line segments. That made it more complicated, both for me to create and for anyone to use.
This version does collision detection by scaling and rotating a detector object into the shape of a line connecting two nodes (or a node and the unit/target), and then just using Fusion's built-in collision detection (the "Object is overlapping backdrop" condition). It's a bit of a hack that people have been using for line-of-sight tests for years. That makes it much simpler, but probably also slower (I haven't benchmarked them).
Aside from that, there's not much difference - it's still the same A* algorithm, just implemented slightly differently. It's not supposed to be a replacement for the old version, or any kind of upgrade - just an experiment really.
I'm giving up on the multi-unit version. I discovered a fundamental flaw in my plan (it would only work for navigating on square grids), as well as what I think might be a bug in the way Fusion scopes instances. I guess it's probably easier to just check for groups of nearby units, and run the pathfinder once per group, and then have the whole group follow the same path.
@Muddymole, using the new features (or old ones even) it is in fact possible to go to the nearest node.
Here's a quick edit:
https://drive.google.com/file/d/17o-...ew?usp=sharing
Nice, but I don't think that's what ciaciosacchetti means. In the previous version, if you clicked inside an obstacle, it would find the closest point outside the obstacle that could be reached, which usually isn't at a node, but part way along a wall between two nodes. I can't see any practical way to do that using the new system, other than to copy that part from the previous system, or to use some kind of dirty hack (like shooting detectors out in all directions, and seeing which stops overlapping the obstacle first).
Exactly Muddy, anyway your old example is perfect for me, I was just curious to understand the differences between this and the old one!
Probably the easiest way would be to create a series of points along a spiral that radiates outwards from the mouse click, and check the collision mask at each point as you go, stopping when you find a point that doesn't overlap an obstacle. It's not going to be pixel-perfect, and it could get slow for large obstacles, but it might be good enough...
Or instead of a spiral, you could have nested loops to create concentric rings, but it's the same difference.
For example: https://1drv.ms/u/s!Atq7cUIJ7uextFNV...m_wzx?e=OwhJaR
what about a simulated ray trace between the clicked point and the object, and its intersection with the poly is the point? (closest to the target)
Posting Permissions
Reply With Quote