Jump to content




User Friendly Program combining several useful functions

turtle utility wireless

57 replies to this topic

#1 ChunLing

  • Members
  • 2,027 posts

Posted 11 October 2012 - 10:19 PM

I use ComputerCraft mainly as a way to have some useful robots around, rather than as a way to get all fancy building up a fully automated machine nation or anything like that. To that end, I made a program that combines a number of functions that I find pretty useful. The program is self-contained and should run on the basic API of ComputerCraft...I hope. So it should be ideal for new CC users to start getting some actual work out of their turtles right away.

Probably the best part of the program is the function based on the very flexible and useful replacement for go utility (which I refer to as "gox") by tele_iz_dva4a. This function accepts a string of commands encompassing most of the available turtle functions and allows loops and enumerated iterations, so it can do most of the things that novice users spend time programing to get some basic utility out of their turtles.

I've also included a function based on the nifty Satellite Builder by dustpuppy. Though this is a somewhat more specialized function, which just launches a four-node GPS array to the top of the map, it can be a real time saver for a new world (it also illustrates some of the principles of turtle/computer interaction that are of interest to those who want to eventually have an automated machine nation). It can be used to place multiple arrays and makes an effort to keep them consistent with each other (though success is spotty, sometimes the automatic GPS finding works and sometimes it doesn't). The function only overrides the user provided coordinates if it finds a valid GPS system in place, so if it doesn't work then nothing bad happens.

I also included a couple of functions that I find useful, such as a simple bone-meal based wheat farmer (to use up all the bones you aren't feeding to dogs), a gravel sifter (in case you want to turn a hundreds of blocks of gravel into flint rather than using it to make paths that collapse when their underlayment gets removed), and a basic remote control function.

I now have a user guide for clfn in the spoiler below.
Spoiler

The program can be considered more of a starting point, if you want to build on it. The code is in the following spoiler, check the bottom of this post for the pastebin links.
Spoiler
Hopefully this is easy to use and works with the basic ComputerCraft API. Let me know if it doesn't work. For those seeking to understand the logic about certain parts of the program, just ask. I didn't really comment it all that well and the code is designed to be easy for me to understand rather than for others.

On the other hand, if you spot areas where the functionality (not just the notation style) of the code can be improved, please share.

Oh, I should include the program for controlling a turtle remotely. It isn't strictly necessary (you can just send the commands by rednet in lua mode), but it could be helpful.
Spoiler
The Remote Controller code is unfinished basic, it works but I was hoping to use it with CCinput only I never got the remote working, so it may be a little odd in some details, it also doesn't currently allow separate control of multiple turtles though the turtle function would support this (you can have synchronized control of multiple turtles, which might be fun but not very useful).

User/customization guide for rctrl, also substantially applicable to rcpda:
Spoiler

The code has been updated and now provides the ability for the remote control terminal to send entered strings, and the remote turtle will now accept loadstring commands (Shift+s to enter text send, send "loadstring", when the turtle gets the command you'll be prompted to "send lua code chunk"). If the text is not valid lua code then you'll get back the error message, but if you send syntactically valid lua code that produces an error then the remote control function will terminate. The functions "rcvfl" and "srvfl" have also been added, so that you can remotely write/read files on the turtle (or on a disk in a drive next to the turtle).

The code has been updated again and now supports passing a numeric variable to the turtle API commands. This means that you can now use turtle.select(n) by sendind "select n" (where n is the number of the slot to select). The turtle also responds to all turtle commands by reporting the function result (if any). The "loadstring" command has been replaced by "ldstrng" (to avoid confusion in the code). I think there were also some other minor improvements, but don't remember what they are.

Fixed inability to remote terminate remote control.

Early versions of clfn and rctrl posted on pastebin. Newer versions are in development, later in the thread. These will be posted to pastebin after some more development and testing.

Newest versions of clfn and rctrl now posted. There is also a version of rctrl that utilizes the CCPortable pda, named rcpda. The newest version of clfn is designed to work with rnhst, in development in the Programs forum (specifically, the Launch GPS Array functionality now launches an array of rnhst nodes rather than standard gps nodes). If you cannot (or just don't wish to) install rnhst in rom, then a copy has to be on the turtle that places the array (this is also useful because turtles can be used as temporary rnhst nodes themselves). The copy on the turtle will be copied to the disk and thence to the computers in the array.

Mad props to Ralnick for patient testing of bugged versions, the latest bugfix/update is up.

Experimental rcpda with menu for easy access to rnhst options, and now the ability to use up/down and PgUp/PgDn keys to revisit previous inputs (and returns) when sending text. Feedback always welcome. Another new version of clfn, this one adds a chst command that places a block from slot 16 and attempts to dump the rest of the inventory into it. It can be used with gox as "C". Bugfix/update for clfn (bugs discovered while reading the code to create the user guide, none found in "chst"/"C"), new updates for latest rcpda and rctrl.

Further development will require separation into an api and other parts, and thus clfn will no longer be an integrated, standalone program. Therefore, this will probably be the final update for the standalone clfn, barring the discovery of any further bugs, which I shan't be doing because I'll be using an api based collection of programs I'm developing.

Edited by ChunLing, 18 November 2012 - 11:09 PM.


#2 ChunLing

  • Members
  • 2,027 posts

Posted 12 October 2012 - 05:28 PM

I'm continuing to update these programs so if anyone is interested in seeing newer versions (with things like command line parameter support, remote loadstring() use, and file receive/serve), then let me know.

#3 ChunLing

  • Members
  • 2,027 posts

Posted 13 October 2012 - 05:19 PM

I've put the latest version in the first post. With the addition of command line parameter support and the file functions, you can make it so that the turtle will always enter remote control mode on startup ( the command should be shell.run("clfn",1,"password"), there is room for a third parameter that will set the ID of the remote controller, so that there is no chance of the turtle being hacked in SMP). Or you can store a description of the contents of the turtle so that you know what you're placing remotely.

I've also added the "gox" command, so you can send a string of commands/loops, but using this remotely isn't recommended unless you are very familiar with the usage (cause it's easy to write a string that means "go far away until you run out of fuel" or something like that). The new commands "gox", "rcvfl", and "srvfl" as well as the use of "loadstring" are all accessed by using Shift+s, since they all require additional rednet string input.

#4 ChunLing

  • Members
  • 2,027 posts

Posted 15 October 2012 - 08:50 PM

Another update. Some new functionality to better support a (theoretical) program that controlled a turtle automatically. Could also be useful for those wanting feedback on their turtle through the provided control program.

#5 ChunLing

  • Members
  • 2,027 posts

Posted 16 October 2012 - 08:57 PM

Crap, I broke the termination code when I improved the turtle command code. Why nobody tell me that? I say to tell me things like that. You not tell me things like that, you maybe not deserve fixed version.
Fixed version edited into initial post.

#6 Ralnick

  • New Members
  • 32 posts
  • Locationthe lighter side of Hell -- South Dakota

Posted 17 October 2012 - 01:59 AM

no I am not following you. (maybe)

but cool code.. I will give it a try.. and let you know if I can break it.

#7 ChunLing

  • Members
  • 2,027 posts

Posted 17 October 2012 - 02:12 AM

I'm so happy that someone replied that I don't care about not knowing what I said that couldn't be followed.

#8 Ralnick

  • New Members
  • 32 posts
  • Locationthe lighter side of Hell -- South Dakota

Posted 17 October 2012 - 02:18 AM

View PostChunLing, on 17 October 2012 - 02:12 AM, said:

about not knowing what I said that couldn't be followed.
sorry it was ment to be a joke.

#9 Ralnick

  • New Members
  • 32 posts
  • Locationthe lighter side of Hell -- South Dakota

Posted 17 October 2012 - 11:26 PM

working great, I like the "gox" commands.. (nice work to the original programmer tele_iz_dva4a ) updated the refuel function (just needed a space)

Spoiler

to

Spoiler


All in all ... really nice work..

can you tell me how to install the remote, still not sure on this one...

thanks

#10 ChunLing

  • Members
  • 2,027 posts

Posted 17 October 2012 - 11:49 PM

The remote control code currently runs from the controlling computer and simply packages a number of the activating rednet commands to be sent by key/presses on the numeric/direction keys (you can still send a general command by pushing Shift+S).

If you mean the remote from CCInput, sadly I haven't been able to get that to work on my system. I'm currently working with the CCPortable PDA, which needs an operating system that I haven't written. But the pda_key event can be supported by adding in a couple of lines after the "key" event handler, like so:
repeat
    cldt[4],cldt[5],cldt[6] = os.pullEvent()
    if cldt[4] == "key" and rcmdlst[cldt[5]] then rednet.broadcast(rcmdlst[cldt[5]])
        if cldt[5] == 45 then cldt[3] = true end
    elseif cldt[4] == "pda_key" and rcmdlst[cldt[6]] then rednet.broadcast(rcmdlst[cldt[6]])
        if cldt[6] == 45 then cldt[3] = true end
    elseif cldt[4] == "rednet_message" then print(cldt[5]..": "..cldt[6])
        if cldt[6]:find("^send") then rednet.send(cldt[5],io.read()) end
    elseif cldt[5] == "S" then write("Enter message") rednet.broadcast(io.read()) end
until cldt[3]


#11 Ralnick

  • New Members
  • 32 posts
  • Locationthe lighter side of Hell -- South Dakota

Posted 18 October 2012 - 01:39 AM

Sweet.

let me ask you this.

you already have a remote control set up using the CC computer is it possible to use that same program with a new item block kind of like (as an example) the powercraft mod for the "weasel". If you are holding or have in your action bar the activartion crystal you can control the weasel.


in this idea, you enter the password for the turtle that you want to control and as long as the PDA is in your action bar you can control it with the number keys.

anyway thanks for the hard work.

#12 ChunLing

  • Members
  • 2,027 posts

Posted 18 October 2012 - 04:00 AM

Well, the CCPortable PDA requires that you have it selected and "open" to send pda_key and pda_char events back to the computer that has the receiver. So just having it in your action bar won't work with that mod. I believe that the CCInput mod also requires that you have the remote selected and turned on, not just have it in your action bar.

Of course, rumblings are that in an upcoming version of ComputerCraft there will be a PDA item that will have the ability to run simple programs and send/receive rednet (but will not be able to interface with peripherals or redstone as the current "desktop" computers do). Such an item should be able to run the control program directly to control the turtle without the need for modification.

But until them I'm working on making it so that the CCPortable PDA can act as a complete interface for a computer. It's a bit slow going, though. The PDA currently has little functional support, so it's kinda starting from scratch.

#13 Ralnick

  • New Members
  • 32 posts
  • Locationthe lighter side of Hell -- South Dakota

Posted 19 October 2012 - 12:25 AM

is there a way to add more commands to this?

for example adding: 7 - run "program name"

#14 ChunLing

  • Members
  • 2,027 posts

Posted 19 October 2012 - 01:17 AM

Yes. First add the new function to the table rctfncs in the clfn program on the turtle. For something that ran another program, the function would look like:
runfl = function()
    trply("send file path/name")
    repeat cldt[2], cldt[3] = rednet.receive() until cldt[2] == cldt.rcID
    shell.run("..cldt[3]..")
end,
THIS CODE NOT TESTED, but I think it will work.

Then you add the name of the function to the table rcmdlst at the start of the rctrl program on the control terminal.
[8] = "runfl"
8 is the key code value for the "7" key. Then, when you press 7, the rctrl program sends the message "runfl".

To test out a function, try using the "ldstrng" command. This prompts the turtle to accept a lua code string and attempt to run it. You can access the text sending function by pressing Shift+S in the rctrl program, this prompts you to enter a text string to send to the turtle. If you send "ldstrng", the turtle will reply with "send lua code chunk" and you can then type in a function for it to execute. This functionality allows you to command the turtle to do pretty much anything it can be programmed to do, but it's a bit unwieldy and dangerous. Using it to test a potential new function before adding it to clfn is a good use, though.

Be aware that the virtual environment created by loadstring doesn't have access to any of the existing data/code loaded by clfn, so you can't do things like call rctfncs.gox and have it work. Also, while loadstring can recover from a string that doesn't parse as lua code, a syntactically correct string can then throw an error that will terminate clfn.

#15 ChunLing

  • Members
  • 2,027 posts

Posted 19 October 2012 - 01:24 AM

On another note, I've managed to put together a version of the control program that uses a PDA (from [MC 1.2.5 / CC 1.4.1] CCPortable - And not even overpowerd) for the input/feedback. But it's kinda ugly and clunky at this point. It's nice to be able to get the feedback and do text string entry remotely, but man, ugly code ahead:

I'm still experimenting with whether there is a way to make it so that the PDA reconnects remotely after a logout/login event, so far looks like no. But this does seem to work. You need a CCPortable receiver attached to your control terminal, and a PDA. Use the PDA on the receiver to attach it. I posted a simple testing program in the CCPortable thread that lets you get a feel for how the PDA functions, if you haven't used it before.

Oops, gotta hide that ugly code. Help making that work better will be appreciated, but not expected. Cause it's pretty ugly.

Latest versions are linked in the top post. (Why did I post so many versions?)

Edited by ChunLing, 24 October 2012 - 11:43 PM.


#16 Ralnick

  • New Members
  • 32 posts
  • Locationthe lighter side of Hell -- South Dakota

Posted 19 October 2012 - 10:34 AM

ok so I got the "CCPortable" (NICE work G3R4RD. ) installed and have a receiver and PDA connected, I am guessing your program needs to be ran from the PC itself. or does it go to the Turtle. I want to control?


i installed the "test" program form CCPortable. tried to run it.. gives error --- pdatest:38: attempt to index ? (a nil value)

i installed the program from here.. pdaremote (I called it that for ease of use). it works for the most part. but I might not have things in the right area. tells me I pressed a button says the test loop is active.. but if I am reading the code correctly.. (i am lua ignorant). it should allow access to turtle. for movement and the like.

let me know if I can help... (remember I am LUA ignorant)

PS: would it be possible to get this on pastebin (so i don't have to reload game every time) ?

#17 ChunLing

  • Members
  • 2,027 posts

Posted 19 October 2012 - 05:26 PM

Sorry, the rcpda program is something of a Frankenstein. If the test loop is working, then you need to press Shift+X to exit the test mode. Then you should receive a prompt to enter the password for the turtle. This will loop until a turtle responds with "password accepted", after which you should be in control of that turtle.

The code on the peripherals forum did work but wasn't throughly bug tested. Looking at it, I can only guess what went wrong. I should go ahead and post a revision.

By the way, if you change the names of the programs, you need to change the names of their shell.run references. On line 58 of the rcpda program, it has "strtfl.writeLine("shell.run("rcpda",""..pdat.chnl.."")") strtfl.close()" This saves the restart information for the program so that the program will autorun on startup. You can change "rcpda" to the new program name, or just delete that line (along with the preceding line which opens the startup file for writing). The corresponding line in clfn is at line 111 (in the latest version of the code) "hndl.writeLine("shell.run("clfn",1,""..cldt[1].."")") hndl.close()". It is not recommended to delete this as it properly allows an activated turtle to restart after a game/chunk save/load or other reboot event.

I didn't want to pastebin until I had something that worked on other computers, but I suppose it is time for an initial beta. I'll post a link once I have it posted.

#18 ChunLing

  • Members
  • 2,027 posts

Posted 19 October 2012 - 06:30 PM

Okay, current versions of clfn and rctrl posted on pastebin. These programs are considered provisionally ready for initial beta release. Feedback on errors/bugs/usability is still needed.

The suggestion for a "run program" function will have to wait on tighter division between global and local scopes for some of the data, as the global data usage in clfn currently may conflict with other programs running correctly.

#19 Ralnick

  • New Members
  • 32 posts
  • Locationthe lighter side of Hell -- South Dakota

Posted 19 October 2012 - 08:18 PM

i have to be doing something wrong here, I have rcpda clfn and rctrl all installed on a command PC and a turtle.

i used rcpda got the test loop tested -- shift X -- for control and it asked for confirmation Password I enter it via PDA and it says entered then returns to enter text -- waiting for the password -- screenshot

I look on the turtle. and it is saying input from PDAEnter confirmation password for remote turtle control
input form PDA screenshot

no where does it allow a password to be entered or confirmed via turtle access.

pda and turtle are talking just not getting the option to enter info from turtleOS

please let me know if I am doing something wrong.

#20 ChunLing

  • Members
  • 2,027 posts

Posted 19 October 2012 - 11:22 PM

Did you start clfn on the turtle, put it in remote mode, and give it a password? The turtle needs to be in remote control mode, waiting for a password. Otherwise the password send on the rctrl and rcpda programs never gets the password accepted message back. You can start the turtle in remote mode with a given password by using "clfn 1 password" from the command line.

I should probably rewrite those, eventually I'll want to support selective control of multiple turtles, and the password loop only really allows the program to work with a single turtle at a time.

Yeah, I took a close look at your second screen. You're running rcpda on the turtle, with it positioned on top of a receiver block. That won't work, you need a control terminal setup (like where you would have run rctrl before, but with the pda receiver added), and that communicates with the PDA and interprets the PDA input as rednet commands for the turtle. You can't use the PDA directly on the turtle because once the turtle moves, it won't be next to the receiver anymore and you'll lose input capability.

Edited by ChunLing, 19 October 2012 - 11:28 PM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users