Can you do turtles with a small dot-indicator of position? That'd be amazing. For normal CC output, I'd focus on colors, monitor, and term api's before working about peripherals.

blackrabt, on 07 March 2015 - 12:42 PM, said:

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. />

Lyqyd, on 16 June 2015 - 12:26 AM, said:

So it's fair to assume if someone performs a peripheral.wrap() and starts using it as a terminal, it WILL be a monitor of some kind under all circumstances? My goal with the API is not to bind to a specific side so one computer can run across however many monitors/terminals they want. Do displays have some kind of identifier like functions do? does the pointer to the monitor return an id of some kind I can use as an index in a table and store a value telling me how to deal with it?

I was considering hijacking the peripheral.wrap() function, adding a "Add this to my own table", then continueing on with its normal operation, though I'm sure that's probably the more hacky way to do it.

Edit: Ok, I went through Touchpoint line by line and I see how you did it. Blargh. You did it with the OOP route by just assigning the pointer of the side via each screen or buttonscreen object. I was hoping my API would let them bounce between different terminals of their own accord and if they said they wanted a button there, I'd put a button there, but now I can sorta see how that'd be difficult to manage if I was going to give them that much freedom but the API would still be expected to manage input from them.

My question on touchpoint though, line 99 and line 108, it looks like run 'runs' handleEvent though you seem to want users using your api to call button:run(), it looks like handleEvent is the one actually returning all the variables and I don't see run returning anything that handleEvent unpacks and returns. Where is it going and how is run returning the values? (better yet, I'm not exactly sure WHAT values it's returning though you gave p1-p5) as possible returns.

valithor, on 15 June 2015 - 11:26 PM, said:

While that makes sense and thank you for the if term.native() == term.current(), but my thing is that I may not be able to check the peripheral.wrap(side). Well, the goal is that I'm wanting to make an API that includes buttons and input and it'd be nice to know if I'm working with a computer or a monitor so though my code that'd be pasting visuals to the monitor wouldn't matter much, how I accept input would. I guess worst case, I can loop through all the sides of a computer (up, down, left, right, top, back) right? and check a) if it's a periph and if it matches, but that still wouldn't answer if it's a monitor or not. What if it's an openblocks setup for glasses? Or would I have to loop around, look at each periph, and compare to what I'm looking at and if true, handle each case accordingly? That...is going to be annoying. Can you wrap a monitor in FRONT of the computer? And if the search was performed by a turtle, would peripheral.getType("front") throw any areas? If I recall, there are sides turtles can't wrap that computers can.

So, I guess my first question is, which api does print() belong to exactly? Is it just default lua? If you are in a terminal and use print and the text you pass in is greater than the width of that terminal (let's assume you have two windows side by side and the 'terminal' is the left window), will print wrap to the next line of the window or will it run over into the window beside it?

My second question is regarding terminals themselves. Since they can be different objects, is there a way I can tell the difference between say a window object, a native terminal object, and a monitor? I would assume that type(term.current()) would return table instead of "window" or "monitor". If they do return "window" or "monitor", how would I make code that'd let me give custom objects I create their own names for when returning a type() as well?

What are you guys using for navigation? If you'd like, you have permission to use my moveAPI for keeping track of coordinates and movements from one place to another.
If you intend to utilize GPS functionality as well, my turtle.setCoords() function will soon be receiving an update so that it can take the GPS.locate's output as a valid parameter. So you'd get something to the effect of turtle.setCoords(gps.locate(), "west") or whatever. Tbh, he shouldn't need to have his loc set all that often unless he gets picked up, move does a pretty handy job of keeping track of it through reboots/crashes/whatever. I was actually considering starting a project like this myself and i kind wouldn't mind getting involved in helping develop. My only hangup is that I've never used Git seriously in my life. xD

I noticed on the github that you were also looking for an updater. I do have one I've been working on but it's probably not as fancy as you're looking for. Basically it runs off of a masterfile stored...somewhere, that you can edit and assigns every program a version number. If the version number is newer than the version on the machine, it will automatically download and update it when update gets run. Feel free to poke me if you'd be interested, I built it for a custom launcher I'm building that just keeps all my utilities in order and set up.

Krutoy242, on 28 March 2015 - 07:50 AM, said:

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.

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

I want to add my API to it, but the register throws a cannot connect. I know it's still a WIP, but give me a shout when it's running.

Not sure if you're the kind to code your own stuff (I am), but if you need help or get stuck, feel free to review my code here for reference or ask me. I've got both moveTo (the exact functionName, haha), and collisionHandling (though that was kinda thrown together). As for doing persistence across reboots/restarts, here's a hint: Save the locations with fuel level before and after the move. If fuel is one less than the one saved, the move finished but position wasn't saved, check the direction being faced and account/update it. If it differs by more than one, they pulled shenanigans in between restarts and direction/Loc is all wrong, in that case, wipe it.

flaghacker, on 14 August 2014 - 08:06 PM, said:

If you're making a local backup, why wouldn't it be:

local oldForward = turtle.forward
turtle.forward = function()
  -- logic, loops, bla bla bla
  oldForward()
end

But even if I overwrite those, since this is happening within an API, wouldn't the program still executing my api still have to reference them as api.turtle.function() ?

Cranium, on 14 August 2014 - 07:57 PM, said:

So in my API, I could literally say:
turtle.forward = myForward?

Or would I have to:

holderFunction = turtle.forward
turtle.forward = myforward

function myforward() 
  holderFunction()
end

Cranium, on 14 August 2014 - 07:48 PM, said:

While that may work for executing programs from the shell, what about when programming? I want to overwrite turtle.forward(), since putting it in the root directory would not automatically load the API as turtle, how exactly would I do this? Could I replace go and refuel without spamming their root with a ton of replacements? Or would I have to have the api named turtle and somehow replace their startup script so it automatically loads 'turtle' overwriting the previous one? Since it is an API, I can't use shell.getRunningProgram() to get it's name, rename it to turtle only the fly, move it to the root directory, then load it.

And if I loaded turtle over the current one, does that mean I'd have to provide ALL of the turtle functions or would it just overwrite the ones I've got and when it couldn't find it from mine, it'd look elsewhere after that?

Let's saying I want to make an API which enhances movement functions and I want to overwrite the default forward() with my forward(). How would I do this? Does the program need to move itself somewhere? When someone uses go or forward in the shell outside of a program, is there a way I can overwrite those as well? What stores them and how can I save to it?

Sovietshark, on 12 August 2014 - 06:19 AM, said:

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

Win7yes, on 10 August 2014 - 03:49 PM, said:

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)

flaghacker, on 08 August 2014 - 08:01 PM, said:

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.

Cranium, on 08 August 2014 - 07:06 PM, said:

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.

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

Downloads

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

Documentation/How-To


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