Question about Loops and Nested Loops

That's a complex piece of code if you've just started using Fusion (welcome!)
cool!

If I got it correctly, I think it can be vastly simplified:

Please login to see this attachment.

though if you have specific questions on nested loops,
foreach loops, or other mechanics, let us know

Quote

The loop will sometimes cause certain tiles to not have a direction (ie pointing to a node). I'll try to work with it but if you have a quick fix off the top of your head I'd love to hear it.

You mean in the latest example above?
I think the only tile not having a "correct" direction should be the "target" itself, because it would point to itself
but on the other hand - which would be the correct direction to point for this tile?
You could make an animation with "no direction", like a single center dot without line
(if this can be of any use for your application of course X))

Quote

Previously I used 4 "scanners" but your change only uses 1 and is placed on the tile rather than all around it. Why is that and how does that work so much better?

The example doesn't use scanners at all, since you were already storing the "distance" value in tiles,
I've simply cycled through all tiles (with the foreach loop), finding the one with lower distance value,
and then placing the green tile as a "target" on top of that (this object could be avoided entirely)

...though, reading your latest post, I'm not sure the example does what you were aiming to do XD
as I'm not sure I understood what you are willing to do:

Quote

this program is supposed to cause each node to point to the one around it with the lowest distance value

you mean that each "node" (grey tile) should look to the one around it with lowest value in the whole neighborhood (same "cluster" of 100 tiles)
or only among the 8 adjacent ones.. which the example doesn't do and I think you probably need if you're making a pathfinding algorithm!

Btw, if you are interested in Pathfinding and willing to look at other "precooked" solutions,
there's the Pathfinding extension, and a number of Fusion-made implementations (including Please login to see this link. >:) which is cross-platform) you could look into.

Otherwise, I could modify the example above to do so, without detectors (assuming you'll work with a strict "grid")
but the better (fastest) way to do this is probably using an array

Hey I'm interested in your pathfinding algorithm that you're working on. A couple years ago I created an A* pathfinding algorithm by scratch and it was pretty fun. This is the first time I'm looking into goal-based vector pathfinding. I know Schrodinger also made his own custom pathfinding algorithm as well in Fusion. I haven't looked at the file yet since I'm at work now, maybe I'll take a look at it later.

Instead of creating four actives in the cardinal directions when testing for the distance, why not just use one detector and position in four times around the node you're checking using another nested loop. Or better yet, record your distance values in an array that's linked to the grid on your level then just compare the data values from the array using offset X and Y array cells? Just food for thought. When I created my system I used a list to record each node and each line had a bunch of data separated by commas. I used string delimiters to parse the data.

Another pathfinding example that was pretty good was Sketchy's example from the Daily Click. You can check that one out here: Please login to see this link.

I'm sure other people on this forum can tell me how to improve and optimize my system, but it was definitely fun figuring it out!

I made a video showcasing it if you wanna check it out.

Please login to see this media element.

Does that mean you have to loop through every possible tile in your game to update its distance value relative to the goal? Sounds intensive and it would take awhile to check all of them, maybe a few seconds at most even with the nested loops. I guess it also depends on how big the area is and how big your tiles will be. Maybe you can restrict the search area to lower the requirement, as long as you know it doesn't hinder the search process. As long as I'm not misunderstanding the video.

Interesting video, the effect looks very cool also,
though - off top of my head, so I may be more easily mistaken XD -
it doesn't seem to be very different from non-vector-field pathfinding?

The first step is what most pathfinding algorithms actually do (calculating the distance -steps- of each cell from the "target" position)
the second step is avoided (drawing the vector field)
but once you have step one, it would be highly unefficient (as Sumo says) calculating vector directions to each adjacent cell
and generally unuseful, as you can simply calculate those vectors for the single objects lying in the field whenever you need to poll those
(like, obejct at cell 33,12 wants to move, and so polls for vectors around cell 33,12, reading grid values got on step 1)

can't see how drawing all the vector field can grant better performances :o
unless you use a very large number of objects going pathfind and constantly moving (swarms or particles, like in the video)
then doing the math on the grid *could* maybe be more efficient than picking single objects of the swarm
(always speaking of Fusion --- in other languages probably not?)
and probably in all languages, when the swarm is larger than the number of cells in the grid XD

EDIT
had the audio turned off on first seconds of the video - ok, so it is what the guy says, it is useful for a very large number of objects.
However, if this is your goal, with similar figures, I'm sorry this may be not possible to do with Fusion,
you'll very likely have problems when in the order of few hundreds of objects
don't know if these figures can suit your needs?

Quote

you should divide the map into smaller "sections" containing a certain number of tiles

this would surely help, for the vector field, but handling a very big number of objects will be a problem nonetheless

Sorry, I said "drawing" but I meant "calculating", that would be anyway a performance hit.

The array is likely your best bet,
sorry for the question: do you plan to allow multiplayer on this game?

If not, you can avoid recalculating the first step for each zombie, making for just one pathfinding call (reading all cells from target position) for all the zombies whenever their target is the same
(but that could also be done with multiple players by calculating N different path maps for N different players)
this is something some pathfinding engines do to lower calculations (my widget does it i.e.)
so calculating 100 paths to a single target counts much less than calculating 100 paths to 100 different targets

Another idea, when you have a grid of distances (step 1)
you can simply do something like this (assuming the grid is stored in array where Z=2 is the dimension for the vector field):

for each zombie
value at (zombieXY/gridsize - Z=1) > 0 (the vector is calculated)
>>> zombie looks at vector direction

for each zombie
value at (zombieXY/gridsize - Z=1) = 0 (the vector is NOT calculated)
>>> start loop "calculate vector field" (for this cell)
>>> zombie looks at vector direction

so following zombies will inherit the calculated vector
but you wouldn't calculate unnecessary cells
(hardly your zombies will cover the whole play area?)

You can also see this awesome example by SolarB, that I think implements a similar solution to increase performances with swarms:
Please login to see this link.

Having a "sheer number" of objects isn't generally possible in Fusion without hitting some performance walls
it's likely you'll end up with some headaches with this ..
but will surely be an interesting challenge

EDIT
wrote this after seeing you need 250 units - then I think you can have that!
More so I think calculating the whole vector field would be less efficient than choosing one of the options above
let us know what you end up doing and how performance goes, your project looks interesting! ;D