Sorry for the uninformative title, it was the simplest and quickest I could come up with at this time of day/night.

After posting here about better elevators I decided I'd make them and have been at it since then - lots of fun figuring things out, etc.
However I've hit a snag that I'd rather get help with than try to figure out by making things up til it seems to work. I'm not very knowledgeable about tables; I don't know how to use them except for adding things to them and calling things in them.

Preamble aside this is what I'm trying to do. My intent should be pretty clear to anyone who takes a look at the script.
So, I'm trying to find the closest node to self (this node). My guess was that the best way to do this was to create a table with all the nodes in it (which is probably more efficient in general and should probably done for actors affected by this too) and use that to compare every value and figure out which is closest. Unfortunately I'm not very knowledgeable or comfortable with tables so I don't really know how to do that. You can see my attempt on line 28. As I said what I want to achieve is finding the closest node above, below, to the left of and to the right of self. This would then be compared with the distance values to determine if the node is close enough that it counts as attached for the purposes of waypoints and removing movator effects.


Also, to anyone clever, if they can come up with a way to get waypoint actors to be able to have more advanced direction movement that'd be great. For one, I'm not sure how I would get C shapes to work, which'd be the basis of pretty much anything more advanced. For an example of what I mean there, getting something like this to work:

Here the only passage leads in the opposite direction of the waypoint, what I have can't handle that at all and the only idea I can come up with is setting up four new movement modes for any node with only one node next to it. The modes would then keep the actor going in the direction it's moving until can change movement direction by 90 degrees. All in all I'd love to not have to do that


Anyway, here's the rte (ignore the sprites ripped from unitec and mappack). Feel free to mess around with it if you want or make something far better based loosely off it, though if you do that some credit would be nice.
The script and object that you should use is MovatorHub since the other ones have outdated scripts attached and are just for testing (hence the names). That said, the 5X one (and larger sizes that are yet to come) will actually be used once this is working.

Alright, to find the closest object to self, you'd have something like this:

And the closest object in your table would be "self.target".

Now, if you're trying to find the closest node in a specific direction, it depends on exactly what node is considered closer to a direction than another, how distance compares to angle, etc. A little more complicated.

On pathfinding, you could create grid that represents a certain rectangular space on the scene, check what spots are "open" enough for an actor to fit through, and flood-fill the space with numbers that increase as they get further from the target.



Then, you trace a line starting from your actor or w/e and move to the closest adjacent number until you hit the destination.



And that should form a path for whatever you're doing.

Thanks a lot for the help with tables, I guess I was trying to make things more complicated than they needed to be by trying to figure out how to compare every value in the table with every other one. Maybe I shouldn't try to figure things out at 6 in the morning.

As for the movement, thanks for the idea, sort of a Dijkstra's algorithm thing but a lot less complex. The main problem with that that I can see is prioritizing which node would be closest. It'd have to be one of the ones next to self or else it wouldn't matter because the movator isn't supposed to work with gaps. That would, I think, make things a lot easier than flood filling the whole grid since I'd only have to account for some directions. Then I'd either have arbitrarily say up is most important, then down, etc. or have the priorities shifting based on waypoint direction. The latter would probably be the only way to get it to work unless I combined Dijkstra's algorithm with what I have now and used the former for the complex parts. That said, the more I think about it (I've rewritten parts of this a couple times now) the more I think it'd be a very good idea and a lot better than my current way of moving actors if I can figure it out.

Again, thanks for all the help.
_____________________________________

Bump Edit:
So this doesn't work, nor does the more standard check you'd do for thing in MovableMan.Stuff. Although trying to figure out why it doesn't work has made me a lot less unhappy with tables I still haven't been able to really figure the problem out, much less solve the it. Instead I've just dumped it all in the MovableMan.Particles loop for now but I'd still like to know what's wrong.
Note that this was done using almost exactly your script to test it when it didn't work. I also tried a ton of variations based on what I could find in the lua scripting subforum. I also want to add that I will be quite upset at myself if this is due to some stupid error on my part.
Script:

Well, first off, you probably don't want to be updating the table every frame, rather, you should only update it when the node initially spawns.

Also, in the piece of code where you're trying to add the nodes to the table:

That's a really messy way of adding an item to a table when you could just have:

If I'm not mistaken/misunderstanding you the problem with updating the local table only when the node spawns is that any nodes placed afterwards won't go in the table. If you mean only updating it when any node initially spawns, not just self, then that makes sense. But I'm not sure what the best way to determine whether a node spawned would be (maybe a global variable that switches to true briefly then goes back to false after a few miliseconds). On the other hand maybe changing everything to one global table and adding self to that table upon spawn then only searching within that table would be more efficient than what I'm doing currently. (Edit: Went with the global variable).
Either way I plan to try to improve resource usage, right now the node stuff isn't too bad but the gigantic MovableMan.Actors loop lags hard when there are a a bunch of nodes and a bunch of actors, I might try to table actors within nodes as well.
On the note of optimization, would using boxes instead of distances to see if an actor is within a movator's area of make it more or less resource heavy?

And thanks, that fixes it. I figured it wasn't the best method of adding to the table but since it seemed to be more or less working I left it alone instead of trying to find out the proper way of doing it. Wouldn't have guessed that laziness was breaking things.