SkyTurtle [ComputerCraft framework and scripts]

[IBurn36360]

I have been working on some turtle code for a little while now, and would like to both put out the status of it and get some suggestions on what capabilities I should have for the framework as a whole. It is less designed to be a script to do a lot of jobs more than a set of various commands and functions designed to allow anyone to make their own scripts without the monotonous coding to write your own handling for everything in =P.


Contributors:

mrswisstobi - Some great bug finds =)



Capabilities:

- World Destructive movement (100%)
- World Safe movement (100%)
- Inventory Management (90%), missing Enderchest handlers for input of items in scripts as of this post
- Fuel Handling (100%)
- Rednet Handling (100%)
- Turtle Location handling (100%), I will go into detail about this later on when it is closer to a full release
- Redstone persistence handler(90%-ish), Should be pretty much done, just need to look through and write the array builder for the cache
- Debug Output (100%), Terminal and Rednet
- Drop-Off cababillities (100%), needs some cleaning up and some of the higher up code for it to path to the drop-off point
- Pathing algorithm and engine (5%), all commands done, needs to logic and the function written
- Turtle Remote Control (100%), Subset of rednet handler
- Caching and resuming of coded functions (100%), each function needs to implement this, but thats to the functions, this handler is done
- Enderchest handling (80%), Almost done
- Block distance Calculation (100%), functions need to implement their own handlers for algorithmic movement, but the basic and default stuff is done
- Terminal input and output (60%-ish), should work, but the terminal kinda freezes on load and stays that way, need to re-write the coroutines a bit
- Turtle Net (100%), A script and subroutine that allows turtles to act as mobile GPS hosts to each other. Takes much of the GPS code an modifies it (don't change what isn't broken)
- Advanced Quarry(80%), algorithm is mostly done, needs some finishing and testing
- Tunneler (5%), commands are done for movement, this needs to get coded
- Flattening Area (5%), commands done for movement, this needs to get coded (Yes, this is inspired by Guude)
- Road Builder (5%) Same as above
- Room builder (5%), not coded yet
- Logger (5%), not coded yet

Code:
Main (1/21/13)
Globals (1/21/13)
Move (1/29/13)
Location (1/29/13)
Rednet (1/29/13)
Cache (1/21/13)
Redstone (1/21/13)
Control (1/21/13)
Inventory (1/21/13)
Debug (1/21/13)
Fuel (1/21/13)
Enderchest (1/21/13)
AdvQuarry (1/21/13)

Feel free to comment and give me some feedback on what capabilities to code in =)

- Anthony "IBurn36360" Diaz

EDIT: fixed link

 

[IBurn36360]

Function Documentation:

Movement:
-moveForward(), moveUp(), moveDown(): World destructive movement. These actions will destroy any and all blocks in the respective directions in order to complete the action commanded. Is able to raid chests and attack mobs in order to complete the action in any and all directions, accounts for gravitational blocks like sand and gravel. These actions will always update the GPS location of the turtle respective to its heading and the action. Action return success[bool] on their ability to move.

-safeForward(), safeUp(), safeDown(): World safe movement code. Attempts to move the urtle in the specified direction. Updates the GPS location on success and can return false for success. Can attack mobs when turtleCanAttack is true.

Turning:
-turnRight(), turnLeft(): Turning code. Updates the turtleFacing upon completion.

Inventory Handler:
- checkTakenInventory(): Does a check for the taken slots in the inventory. Returns an int of the number of taken slots and an ordered array of ints representing the slots taken.

-checkFreeInventory(): Does a check of the free slots in the inventory. Returns an int of the number of free slots and an ordered array of ints representing the slots taken.

Drop-off Handler:
-dropOffAll(): Drops all items in the inventory off, ignoring fuel.

-dropOffLFA(): Drops off all items leaving anything that can be used as fuel for the turtle. Once all non-fuel items are cleared, the fuel is located to the end of the inventory.

-dropOffLSF(): Drop off all items ignoring the first slot of fuel. Once all other items are cleared, the slot of fuel is located to the end of the inventory.

Refuel Handler:
-dummyRefuel(): A refuel that consumes all fuel in a slot and breaks to retain any other fuel in the turtle.

-economicalRefuel(): Consumes a single fuel in a slot and breaks to preserve as much fuel as possible in the turtle.

-selectiveRefuel(): Consumes a set number of fuel in a slot, will not consume fuel if there are not enough items in a slot to refuel. A better version of this is coming in the next build.

 

[SilvasRuin]

...so you're making the equivalent to a code engine? I might actually dabble in Turtles thanks to this.

 

[IBurn36360]

UPDATE:

- The world destructive movement code now returns its success. This should allow the function to safely fail for the script running.
- Many of the bugfixes found thanks to mrswisstobi (mainly missing variable requirements in functions and general derping all over the place)

Updated link to the code in the OP, will document exact changes once I have the OP done

Changes:
+ Line added
- Line Removed
! Line edited
* Line moved

function moveUp(actionDelay)
...
...
[348] + if (turtle.up()) then
[349] * turtle.up()
[350] * updateGPSUp()
[351] + success = true
[352] + else
[353] + success = false
[354] + end
[355] +
[356] + return success
 
 
function moveForward(actionDelay)
...
...
[378] + if (turtle.forward()) then
[379] * turtle.forward()
[380] * updateGPS(turtleFacing)
[381] + success = true
[382] + else
[383] + success = false
[384] + end
[385] +
[386] + return success
 
 
function moveDown(actionDelay)
...
...
[408] + if (turtle.down()) then
[409] * turtle.down()
[410] * updateGPSDown()
[411] + success = true
[412] + else
[413] + success = false
[414] + end
[415] +
[416] + return success

 

[IBurn36360]

UPDATE: Changes and additions all over the board. Redstone input and output handlers put in, making the turtle able to set and keep outputs from load to reload as soon as I write the array builder. Currently sets and changes redstone on move or update . Always clears on turning as of now, that will change.

- World destructive movement code now returns weather or not it was able to dig a block. That should allow us to count when we dig and makes the turtle able to perform a check for a block dig.
- Redstone input and output handling added, documentation for it will come at a later date.
- A quick converter to check for a color as a string and convert it to an int.
- A few efficiency clean ups
- Temp vars added to the function array to cause it not to crash on load
- Enderchest handlers almost done, Refuel and dropoff are done, including failsafes for cases where the block is not able to be placed properly.
- Refuel now takes a new variable for the enderchest handler: defaultRefuelTake[int]. This will be used in a new refuel level and is defined in the startup script.
- Startup (Never posted) is getting completely re-written to allow turtles to self-update should an update be available. Configurable in the startup script itself and will not go through if the turtle had a task to perform.
- Some junk code stripped out, mainly functions and checks that had not been written in yet.

As always, feel free to give feedback on what you want the turtle code to be able to do for the future. This update will not receive line-by-line documentation due to the sheer amount of changes and additions in the update. The redstone implementation is a little over 100 lines as is. Startup will be available once I get the logic for the update check done and make sure that it runs without errors.

Redstone Handlers

----------------------------------
-- Redstone  and input handling --
----------------------------------
 
-- Go through our sides and clear out outputs based on what persistance level we have
function RSPersist(Sides, redstoneState, redstonePersistanceLevel)
  if (redstonePersistanceLevel == 0) then
    for i = 1, 6, 1 do
      redstone.setOutput(Sides[i], false) -- Set all redstone outputs to false, this is default
      redstone.setBundledOutput(Sides[i], 0) -- Do this for bundled output as well
    end
    debugString = "All redstone and bundled cable outputs cleared"
    debugLevel = 3
    debugTerminal(debugString, debugLevel)
  elseif (redstonePersistanceLevel == 1) then -- Keep bundled output
    for i = 1, 6, 1 do
      redstone.setOutput(Sides[i], false)
    end
    debugString = "All redstone outputs cleared"
    debugLevel = 3
    debugTerminal(debugString, debugLevel)   
  elseif (redstonePersistanceLevel == 2) then -- Keep side output
    for i = 1, 6, 1 do
      redstone.setBundledOutput(Sides[i], false)
    end
    debugString = "All bundled cable outputs cleared"
    debugLevel = 3
    debugTerminal(debugString, debugLevel)     
  elseif (redstonePersistanceLevel == 3) then -- Keep both outputs
    debugString = "No Redstone outputs cleared"
    debugLevel = 3
    debugTerminal(debugString, debugLevel)       
  else -- Someone called a persistance level we don't have
    debugString = "Redstone persistance level not valid. Level: "..redstonePersistanceLevel
    debugLevel = 1
    debugTerminal(debugString, debugLevel)       
  end
end
 
-- A bypass to clear all redstone output, called when turning
function RSClearAll(Sides)
  for i = 1, 6, 1 do
      redstone.setOutput(Sides[i], false)
      redstone.setBundledOutput(Sides[i], 0)
  end
end
 
-- Grab the inputs we have connected to the turtle (bundled and standard)
function RSGetInputNormal(Sides)
  RSNormalInput = {}
 
  for i = 1, 6, 1 do
    if (redstone.getInput(Side[i])) then
      RSNormalInput.insert(i, (redstone.getInput(Side[i])))
    end
  end
 
  return RSNormalInput
end
 
-- Grab the Bundled input, will return an int representing the combined binary value of all colors active
function RSGetInputBundled(Sides)
  RSBundledInput = {}
 
  for i = 1, 6, 1 do
    if (redstone.getBundledInput(Sides[i]) ~= 0) then
      RSBundledInput.insert(i, redstone.getBundledInput(Sides[i]))
    end
  end
 
  return RSBundledInput
end
 
-- A function to test a specific side for a specific color input
function RSGetBundledColorInput(Sides, inputSide, RSColor)
  if (type(RSColor) == "string") then
    RSColorToBit(RSColor)
  end
 
  RSTemp = redstone.getBundledInput(Side[inputSide]))
 
  if (if bit.band(RSColor, RSTemp)) then -- This should satisfy a simple color check on a side
    RSIsOn = true
  else
    RSIsOn = false
  end
 
  return RSIsOn
end
 
-- Set functions
function RSSetNormalOutput(Sides, outputSide, Sides, RSOutputState)
  redstone.setOutput(Sides[outputSide], RSOutputState)
end
 
function RSSetBundledOutput(Sides, outputSide, RSOutputState, RSColor)
  if (type(RSColor) == "string") then
    RSColorToBit(RSColor)
  end
 
  if (RSOutputState) then
    redstone.setBundledOutput(Sides[outputSide], colors.combine(redstone.getBundledOutput(Sides[outputSide]), RSColor))
  else
    redstone.setBundledOutput(Sides[outputSide], colors.subtract(redstone.getBundledOutput(Sides[outputSide]), RSColor))
  end
end
 
-- Decypher our color as a bitwise interger
function RSColorToBit(RSColor, colors)
  temp = colors[RSColor]
  RSColor = temp
 
  return RSColor
end

 

[fearlessdragon]

hey do you need any help?

 

[MrSwisstobi]

Cool iBurn..
We talked about that already, you remember me?
.. i still have a lot of time and would love to help you

 

[IBurn36360]

Anyone and everyone is free to post any and all code revisions as long as they make sense in the code and/or are fixes or additions. I am not above receiving help from anyone, just post it up =P

 

[MrSwisstobi]

Cool, i might help you then

btw, is the link at #1 the latest one? or is there somewhere an updated version?

 

[Vilmos]

This is excellent. I had previously done some turtle coding but I found it tedious since there was no good framework. I may have to give it another go! Shame I'm currently working in the magic pack, looks like I'll also look at changing packs and keeping the world!

One step closer to my wolfpack...err turtlepack?

 

[MrSwisstobi]

hehe .. if you understand LUA, you can do a lot with turtles.. but ya, its much easier once you have a nice 'master' API like that [DOUBLEPOST=1358284971][/DOUBLEPOST]Typing Error @ #2, Line7

Attempts to move the urtle in the specified direction.

Turtle

 

[IBurn36360]

The OP is the first post updated when I push an update to the code. The link might not work correctly, in which case I show the link as text as well.

 

[NightKev]

Your edit says "fixed link" but I think you may have actually broken it more.

 

[MrSwisstobi]

Your edit says "fixed link" but I think you may have actually broken it more.

.. i wanted to point that out as well, but once i tried to put in the correct link, it made the same thing to me...
thats a forum bug

 

[IBurn36360]

Yeah, that's why I have the link as a text element. I need to see why that's breaking to see if I can fix it (WISIWIM editors are a little too idiot proofed in most cases). If not, oh well.

 

[NightKev]

Well, you can set the editor to be text-only (in the top right of the text editor is a couple of "A"s, click that to toggle it to be "BBCode editor" mode and that changes the textarea into plaintext).

 

[IBurn36360]

UPDATE: I am going to spend some time compartmentalizing the modules so that people can go in and edit them easier. While this is being done, I will most likely not be merging changes. I only expect this to take a day at most (Trying to find a good way of compartmentalizing it), so it shouldn't affect anyone's additions and changes to the framework. As of now, I have the modules planned to be separated by functionality, IE: Movement and turning, Rednet, Fuel, Inventory, etc...

With that change, it should be far easier to read and understand the functions. Note that this will not change ANY of the calls in the framework, so anything you have written will remain functional if you have anything implemented. See you after it is finished o/

 

[MrSwisstobi]

Ok cool...

- Room builder (5%), not coded yet
Could be done with the advQuarry function + checking if walls exitst/fill them.

- Flattening Area (5%), not coded yet
Could also be done with the AdvQuarry function + replacing the floor maybe?

- Tunneler (5%), not coded yet
As big as you want? or a fix size? .. like a sideways-quarry + placing torches?
• torch slot
• check if length%<torch distance> == 0 then place <torch slot>

- Logger (5%), not coded yet
replant and bonemeal tree? only chop down a tree? ..
only 1*1*x tree's or 2*2*x (huge jungle) as well?
• template slot with 1 log
• check if compared to block above then chop, else go down

.. if you want the correct code, i could help you, that are just some ideas

 

[slay_mithos]

I can help you a bit with the logging system.

It is not fully complete, but at least it can cut down and replant trees, and I tried to use not to much fuel, but I do have some moves that could be removed.

If you wanted, you could build upon this base, or you could go to the computercraft forum and pick one of the many logger programs that are out there too.
http://pastebin.com/quFtMd8n

 

[MrSwisstobi]

I can help you a bit with the logging system.

It is not fully complete, but at least it can cut down and replant trees, and I tried to use not to much fuel, but I do have some moves that could be removed.

If you wanted, you could build upon this base, or you could go to the computercraft forum and pick one of the many logger programs that are out there too.
http://pastebin.com/quFtMd8n

doesnt look too bad, im going to read trough it once i got a little bit more time