What exactly is happening down here? Do you create an array with all these "objects" in it or are all these objects becoming arrays?
"node" becomes an array. The rest of the variables (direction, curnode, etc) don't get set to anything, the Lua VM just notes them down as variables that're to be treated as
local to the script.
If you did this:
local var1, var2 = {}, "cow"
… then var1 would get set to point to a new table, and var2 would get set to the string "cow". If you supply less data than you do variables, the extra variables remain set to nil.
Could you explain how you use the two-dimensional arrays?
based on the comment I know what the function does, but I cannot find your specification of the array node.
What does 1,2,3 refer to?
-- Returns true if the turtle is at the specified node.
local function atNode(tnode) return (x == node[tnode][1] and y == node[tnode][2] and z == node[tnode][3]) end
"node" starts out as an empty table, and gets filled with values as the turtle explores. On boot, it adds a node referring to its starting position (line 337 - and if there's a GPS handy, it'll bug the user for the co-ords it should travel to, and those go in the node table as a second entry on line 317). Every time the turtle finds an intersection it throws that in the table too (around line 226).
Each node is defined according to my previous post (though there's an additional "explore" table assigned to them as well). node[whateverNode][1] is the x co-ord of "whateverNode". node[whateverNode][2] is the y co-ord, and node[whateverNode][3] is z.
Thus if the variables x, y and z (which track the turtle's current position) match the co-ords of a given node, then the turtle must be at that node.
(Note that I treat z as "distance from the bottom of the world", as that's the convention I'm familiar with from most other games, but I only do it internally - MineCraft itself uses y for this value, and so the turtle expects any co-ords it
receives (from eg a GPS) to match that convention.)
based on what you said earlier: saving "linkedNodeX". What kind of objects are they? Also nodes (and thus arrays?)? How did you initialize the whole set of nodes?
Well, the linkedNode values attached to each node are simply numbers indicating the index of each node the turtle can travel to from the node it's at.
Here's an example of a manually-built node table I gave to a older turtle that helped manage a base for me:
local node = {{241,422,58, 2,3}, -- 1, barrel central.
{244,422,57, 1,3,4}, -- 2, processed resource dropoff.
{244,419,57, 1,2}, -- 3, machine central.
{242,430,57, 2}} -- 4, chopper programming point.
When the turtle is at node 1 ("barrel central"), it knows that the linked nodes are 2 and 3. Say it runs its pathfinding code with the aim of getting from node 1 to node 4 (the spot for placing new turtles to act as wood choppers - which is a long story in itself). It can't just try to go directly from 1 to 4, because enough blocks are in the way that it'll get stuck on a wall or something.
So instead, it sees that node 1 has clear access to nodes 2 and 3. It checks the position of each of those nodes, and notices that only node 2 is linked to node 4. So now it has a path - it will travel from node 1 to node 2, then from node 2 to node 4.
Node 3 also links to node 2, so in theory the turtle could also go 1 - 3 - 2 - 4. However, it's bright enough to know that 1 - 2 - 4 involves traveling a shorter distance, and so that's what it goes with.
In the case of the pathfinding turtle, whenever a new node is discovered, that node is automatically "linked" to the node that the turtle started exploring from to get to that new node (and the starting node is likewise linked to the new one). If, while exploring, the turtle stumbles across a pre-explored node, then much the same thing happens. This goes on until all the directions the turtle can travel from each node have been crossed off as "explored".
Whenever the turtle hits a dead end, it checks the node list to see which other nodes still have directions available to explore in. The next node to check might be quite far away, requiring a lot of turns to get to -
that's when the pathfinding code kicks in, allowing the turtle to navigate through the nodes that've already been explored back to the next one that needs checking.
Bear in mind that nodes don't have to be right next to each other. If the turtle moves into a space and finds that the only directions it can travel are either forward or backward, then it doesn't register that space as a junction but instead keeps going.
It's a little more complex than that (sometimes the turtle doesn't bother to save points as nodes, and sometimes it deletes nodes - this is done to keep the node table free of dead-ends that don't go anywhere), but that's the general gist of it:
while true do
if not at an unexplored node,
pathfind to an unexplored node using your A* code.
end
explore in one direction from the node you're at.
(mark that direction as explored for that node.)
(add the new node you find to the node table, link it to the one you explored from)
if at the destination,
finish the script
end
prune any dead-end nodes from the table
end
For now, I advise concentrating on building around that loop, leaving the node-pruning thing until very last (assuming you bother with it at all - I didn't bother to do it properly myself). Don't worry too much about what the rest of my script is doing. That way lies madness.
