Jump to content




[STABLE] MoveAPI - Reboot persist, coordinate tracking, smart movement

api turtle

15 replies to this topic

#1 Noiro

  • Members
  • 65 posts

Posted 08 August 2014 - 05:57 PM

Move API
v1.31

NOTICE: This API is now released as stable with exception to the travel() function still being experimental. All else should be fine.
So, what is MoveAPI? Well, moveAPI is a full toolset allowing you to easily navigate/move and get your turtle around the map as smoothly as possible with as little code as possible. It offers everything from simple dig replacements which automatically handle falling sand/gravel/gravity blocks, to advanced customization moveTo() of specific coordinates using relative or specific. Want to say, "Eh, go to these coordinates and if something gets in the way, break it or attack it until it's not and keep going till you get there", you can!

How to use: When you download the program, just os.loadAPI("apiName"). It should download and be named 'move', but if you choose to rename it, you will import under that name, instead. Any functions you want to call MUST START WITH turtle.functionName() (yes, vanilla turtle functions have been overwritten while move is loaded.)
One thing to note, MoveAPI is setup so if you plan to use any of the GPS/coordinate tracking features, ALL TURTLE MOVEMENT COMMANDS in your programs must use move. As long as all programs running on the turtle import move, coordinates should always persist properly. Just don't get into the shell and type "go forward 3" or whatever because on next load it will wipe your GPS data due to inaccuracy.

Random note: coordinates are reboot/chunkload persistent so as long as you have a program using move as startup, move will always know where it is at. If you pick it up and place it back down, be sure to delete move's config file in /api/moveLoc. If the turtle's fuel changes by more than 1 when off, he will auto-reset upon re-import of move (coords will overwrite and store as 0,0,0,"north"). If you plan to place autoexecuting turtles back down, ensure your program running move uses turtle.setCoords() accordingly. The only time you may get some corruption of your coordinates is in the event of a server crash, the server not saving block locations properly, and move saving, thus putting him however many blocks back the server failed to. This can't be fixed on my end so: Try not to crash your server :P

Downloads
Spoiler

Planned Features for 1.33
-Turn optimization (turns in fastest route)
-Cleaning up param input for travel and moveTo to accept GPS and a little more dynamic stuffs
-Adding turtle.back to overwrite list (woops)
-Notice: I will be deprecating the function turtle.turnToDir() and switching it out with turtle.turnTo(), new version will give you a chance to switch everything over. 1.34 will not support turtle.turnToDir()
-Additionally, I will be removing collision handling from the feature list. After a little more introspection, I don't feel it fits within the scope of this project. I may create a pathfinding API later on down the line but for now, I'd like to limit moveAPI to just the movements provided.


Changelogs
Spoiler

Documentation/How-To
Spoiler


Credits
-Sangar who I found out (85% into this project), had made something extremely similar for an older version. Sangar, I am borrowing your awesome idea to use fuel-level checks to compare for persistence. Thank you, much!
-Inari in IRC: Your help in various questions I had (I learned as I went) was greatly appreciated (and your massive code condensation help).
-Random IRC/forum people I poked regarding various aspects of stuff, mostly about how the heck Lua does function table overwrites

Edited by Noiro, 01 July 2015 - 01:13 PM.


#2 Cranium

    Ninja Scripter

  • Moderators
  • 4,031 posts
  • LocationLincoln, Nebraska

Posted 08 August 2014 - 07:06 PM

Looks good so far. Let us know when you have some code, and we can put this in the programs section.

#3 Noiro

  • Members
  • 65 posts

Posted 08 August 2014 - 07:23 PM

View PostCranium, on 08 August 2014 - 07:06 PM, said:

Looks good so far. Let us know when you have some code, and we can put this in the programs section.
Tbh, the code is like 90% there, just need to finish testing a few functions, but I'll release once I get them shined up.

#4 flaghacker

  • Members
  • 655 posts

Posted 08 August 2014 - 08:01 PM

I suggest returning the amount of blocks already travelled when any of the moment functions fail.

So this is 100% reboot persistent? Nice!

#5 Noiro

  • Members
  • 65 posts

Posted 08 August 2014 - 08:11 PM

View Postflaghacker, on 08 August 2014 - 08:01 PM, said:

I suggest returning the amount of blocks already travelled when any of the moment functions fail.

So this is 100% reboot persistent? Nice!
Well, I will preface that with: It's the program calling move's job to restart itself on reboot, not move. But if your program does restart and call move, move will have your coordinates.

As for turning around, I'm sure that shouldn't be too hard for you to implement in your own programs. :) I don't think that'd be a good idea as a default option as most wouldn't want that.

Edited by Signify, 08 August 2014 - 08:17 PM.


#6 Win7yes

  • Members
  • 110 posts

Posted 10 August 2014 - 03:49 PM

I think is
os.loadAPI("api Name")

and not
os.import("api Name")


#7 Noiro

  • Members
  • 65 posts

Posted 11 August 2014 - 01:53 AM

View PostWin7yes, on 10 August 2014 - 03:49 PM, said:

I think is
os.loadAPI("api Name")
and not
os.import("api Name")

Woops, thanks for catching that. I had a friend review the post and he was like, "Make sure you specify they have to import and use move.etc" So I kinda hastily threw that in there (though if you're going to be using an API, that should be common sense)

#8 Sovietshark

  • New Members
  • 1 posts

Posted 12 August 2014 - 06:19 AM

You should make a spin-off of this and make a nuking application. Input current co-ordinates of the turtle then the destination it needs to go to (mining and digging on the way) before it places a nuke and lights it off.

#9 Cranium

    Ninja Scripter

  • Moderators
  • 4,031 posts
  • LocationLincoln, Nebraska

Posted 12 August 2014 - 05:27 PM

Like I was saying in IRC, I think you can clean up the documentation of the goto() function.

You can specify that the main arguments are as such:
goto(x, y, z, dir)
and then while explaining how to use it, you can mention that instead of separate values, you can pass a table of those values to the funtion. This would be an actual usage example, such as:
local home = {0, 0, 0, "north"}
goto(home)
My recommendation is that instead of listing the available arguments as goto([coordinateTable or x], [y], [z], [dir], [x/y/z, x/y/z, x/y/z]), you'd just list them as what I suggested earlier.

#10 Noiro

  • Members
  • 65 posts

Posted 12 August 2014 - 11:43 PM

View PostSovietshark, on 12 August 2014 - 06:19 AM, said:

You should make a spin-off of this and make a nuking application. Input current co-ordinates of the turtle then the destination it needs to go to (mining and digging on the way) before it places a nuke and lights it off.
If you like, the program would be REEAAALLY easy to make....

os.importAPI("move")
turtle.travel(nukeLocation)
turtle.up()
turtle.placeDown()
rs.setOutput("bottom", true)
sleep(.1)
rs.setOutput("bottom", false)
turtle.travel(home)

Tbh, the turtle may not survive that depending on range of the nuke.

Update Status: Testing - 98.3%

-Basic movement functions - tested
-moveTo and fMoveTo - tested
-Reboot Persistence - tested
-travel() - Works for the most partish, don't super rely on it quite yet
-collisionHandling() - Turn that on if you really don't have any other obstacle avoidance available, will do its best

In other news, the beta is released! When you guys test collisionHandling or travel() (specifically), keep an eye out. Most of the core forward/fFoward stuff should be perfectly fine along with moveTo and fMoveTo, travel() has and likely always will be a little experimental. And I did basic collision handling because bored so...yeah. If you were one of the zealous ones to download the first couple minutes I uploaded, redownload...I forgot to turn debug off XD

Edited by Signify, 26 August 2014 - 01:14 AM.


#11 Cranium

    Ninja Scripter

  • Moderators
  • 4,031 posts
  • LocationLincoln, Nebraska

Posted 26 August 2014 - 01:38 AM

Moved to APIs on request.

#12 Noiro

  • Members
  • 65 posts

Posted 12 November 2014 - 12:15 PM

So....any feedback on this guys? Should I modify, keep it as-is, tips/tricks, suggestions?

Edited by Signify, 12 November 2014 - 12:15 PM.


#13 blackrabt

  • Members
  • 13 posts

Posted 07 March 2015 - 12:42 PM

I really like this. Currently using it to cut out a lot of coding of custom paths for some turtles in a storage retrieval system. Great work! Love to see it keep going if you have the time and interest.
If I might suggest something, another moveTo method that will try to complete a movement in one direction, but if it encounters an obstacle and is not supposed to break blocks, it tries to move in another axis toward the destination and then returns to the blocked axis after it has made progress. Does that make sense?

Also if it were possible to use an existing rednet GPS setup to input the initial coordinates that would save some work with turtles that are frequently moved. I suppose the built in GPS does not supply facing, but setCoords((gps.locate), "west") would still be nice.

Edited by blackrabt, 07 March 2015 - 12:44 PM.


#14 Krutoy242

  • Members
  • 3 posts

Posted 28 March 2015 - 07:50 AM

Cool functions and stable work! Also, i like the idea of restoring coordinates if 1 fuel was consumed.

But i cant understand, why saveData() called after turn function?
turtle.turnLeft = function()
--Turns turtle left once and changes dir
turnLeft()
if dir == "north" then dir = "west"
elseif dir == "south" then dir = "east"
elseif dir == "west" then dir = "south"
elseif dir == "east" then dir = "north"
end
saveData()
end
If server restarting during rotation in progress, isnt new coordinates will be unsaved?

Also, I found, that you not redefine turtle.back() function. If this will be called manually, turtle will be lost.

And, i found small mistake on 752 line:
elseif data[5] > (turtle.getFuelLevel()-1) or data[5] < turtle.getFuelLevel() then
You already cheked for == fuel() and == fuel()+1 , so right comparsion should be
elseif data[5] > (turtle.getFuelLevel()+1) or data[5] < turtle.getFuelLevel() then
And after this, next code after else is unreachable.

#15 Noiro

  • Members
  • 65 posts

Posted 22 May 2015 - 04:06 PM

View PostKrutoy242, on 28 March 2015 - 07:50 AM, said:

Cool functions and stable work! Also, i like the idea of restoring coordinates if 1 fuel was consumed.

But i cant understand, why saveData() called after turn function?
turtle.turnLeft = function()
--Turns turtle left once and changes dir
turnLeft()
if dir == "north" then dir = "west"
elseif dir == "south" then dir = "east"
elseif dir == "west" then dir = "south"
elseif dir == "east" then dir = "north"
end
saveData()
end
If server restarting during rotation in progress, isnt new coordinates will be unsaved?

Also, I found, that you not redefine turtle.back() function. If this will be called manually, turtle will be lost.

And, i found small mistake on 752 line:
elseif data[5] > (turtle.getFuelLevel()-1) or data[5] < turtle.getFuelLevel() then
You already cheked for == fuel() and == fuel()+1 , so right comparsion should be
elseif data[5] > (turtle.getFuelLevel()+1) or data[5] < turtle.getFuelLevel() then
And after this, next code after else is unreachable.

Thank you for looking it over. I am going to go back over and poke at some of the edits you mentioned. My only worry is that I'm uncertain on if the server reboots during a turn if the turn gets saved by CC the moment the turtle starts turning (in which case I should saveData() first, or if it will not save the state until it's finished so during a reboot, the turtle will go back to before it tried (my theory at the time)).

I am planning to pick this back up again and poke a couple extra things. I've had a lot going on in life recently so been busy, but with a new modpack I'm building and wanting to get my WorldEater program perfected (which uses move), I will be going back over some of the code. I was not even aware turtle.back() was even a thing. :o

Edited by Signify, 22 May 2015 - 04:07 PM.


#16 Noiro

  • Members
  • 65 posts

Posted 01 July 2015 - 01:22 PM

View Postblackrabt, on 07 March 2015 - 12:42 PM, said:

I really like this. Currently using it to cut out a lot of coding of custom paths for some turtles in a storage retrieval system. Great work! Love to see it keep going if you have the time and interest.
If I might suggest something, another moveTo method that will try to complete a movement in one direction, but if it encounters an obstacle and is not supposed to break blocks, it tries to move in another axis toward the destination and then returns to the blocked axis after it has made progress. Does that make sense?

Also if it were possible to use an existing rednet GPS setup to input the initial coordinates that would save some work with turtles that are frequently moved. I suppose the built in GPS does not supply facing, but setCoords((gps.locate), "west") would still be nice.
In 1.34, I am changing up a little bit of code that handles how you input parameters into the navigation stuff. You should be able to pass a GPS location in as you specified. In 1.3.4, if you use turtle.setCoords(gps.locate()) and don't specify a facing, he will assume whatever direction he has as his facing is the right one. So if you pick him up and he's facing south and put him down, make sure he's facing south. Or just specify and ensure you put him down facing that dir. Essentially how the new parameters will work is that if you include a table in the parameters, it will assume any numbers in the table as coordinates and assign them in the order it gets them (first number it gets will be X, whether it is in a table or not), so if you wanted to you could:

xTable = {354}
turtle.moveTo(xTable, "y", "x", "south", "z", 13, 5)

That would say: "Go to coordinates: x:354, y:-13, z: 5, face south when you get there, then travel along the y axis first, then x, then z." Order will no longer matter in terms of where you place the variables, but order DOES matter relative to numbers and x,y,z axis order. In your case:
originalPos = gps.locate()
--Insert code to go do a thing
turtle.moveTo(originalPos, "east")
print("Hey, I'm back!")

Would work just fine. Though if I"m totally honest, I'm being a bit selfish in that half the reason I even am adding this is so you can pull stuff like:

--Locations
home = {0,0,0,"north","z","x","y"}
exitHome1 = {5,0,-6,"east","x","z","y"}
exitHome2 = {5,3,-6,"east","y","z","x"}
friendHouse = {-306,55,1522, "south"}

function goHome()
  turtle.moveTo(exitHome2)
  turtle.moveTo(exitHome1)
  turtle.moveTo(home)
end

function leaveHome()
  turtle.moveTo(exitHome1)
  turtle.moveTo(exitHome2)
end

--Here's the fun part
leaveHome()
turtle.travel(friendHouse)
--Insert code to fill his house with water (I'm a bad person)
goHome()

See how this code works? It essentially allows you to build locations and then make functions that essentially generate paths so the turtle can get around without hitting things. He enters into exit2 (which is likely the turtle entranceway), then moves down into exit1 (which is where he'll then go into his 'home' position), then go to home, this way, along with axis specifications, you have full control over how he gets where. :)/&gt;

Edited by Noiro, 01 July 2015 - 07:15 PM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users