38 replies to this topic

[Sangar]

Regarding startup script order, that's kind of up to you. The only reason LAMA isn't at 00_ per default is to allow scripts that do background stuff to start before it does (for example if you have a daemon script and run a daemon that sends the turtle's position via WLAN occasionally). Your program will just block until LAMA is initialized if it runs before LAMA's startup script (the API will automatically initialize itself the first time any function to it is called - besides set()).
So in short: if you don't know it probably doesn't matter.

As for JAM: that's totally intended, of course. Not. But: I have not continued working on it after I ran into a bug where CC deadlocks if a turtle moves next to a disk drive. Because of this JAM is practically unusable at the moment, since CC may just lock up your game at random. So I can't really recommend using it as it stands, anyway. If that CC bug ever gets fixed I might look into the issue you described. Until then I don't really see the point, sorry

[Firnagzen]

I see. So the multi-startup script is just there so that you can 'sideline' the actual startup behaviour.

And thanks for the info on JAM, I don't suppose you could edit the readme to note that it shouldn't be used?

EDIT: I suppose you've considered using a computer with an attached disk drive in place of just a disk drive? (I mean using the computer to activate the turtle, instead of the drive.)

[Sangar]

Yeah, I probably should add a note somewhere... I just didn't really expect people to actually use it.

Using a computer instead of a disk drive won't work. What's stored on the disk drive right now is the global state of the quarry: which jobs were already taken. So without that the turtles wouldn't know where to go. And no, I don't intend to fiddle around with some Data-via-Redstone-API to have the turtles store that info on a computer instead. And wireless is just too expensive to make it a requirement.

[Firnagzen]

Eh, fair enough.

[Ordinator]

Thanks again for the cool Api I did find something that would be very handy:

It would be nice if there were a way to call the lama api and have it gracefully shut down any buffered move/navigate commands it has pending.
I say this because I was building a rather complicated turtle and accidentally sent it very far away with no good way of stopping it. Even destroying it and putting it back down, it just resumes its journey of course.

I was going write a script that listens for wifi signal from another computer and then deletes the .lama-path-state file and restarts the turtle but it would be much less kludgey if my wifi listener function could just call some lama api to shut down nicely.

Just an idea.

[Sangar]

Do you mean when the turtle is already running, or when starting it up?
For the first, you can either use the helper program lama-conf set ... or call lama.set(...), which will completely reset the API's state (and lama.set() never triggers initialization).
For the second, yeah, I've been thinking about adding some kind of timeout in the initialization to allow aborting when the user presses a key or something. I'd probably add that to the startup script, so that the API itself never prints to the term.

Edit: I'm an idiot, for some reason I skipped the second paragraph. Interrupt it while moving? Hmmm... I'll have to think about that. We'll see.

[Ordinator]

Yes, interrupt a navigate() or moveto() that is still being executed. Probably not too simple to do cleanly and certainly not a sexy task. But handy and potentially pretty powerful.

I really think you've designed the startup behavior wonderfully as it is, silently and immediately resuming movement is very, very elegant. Adding a timeout before resume-ing a move might easily add timing issues with dependant programs, eg I may be assuming two neighboring turrles are working at the same speed or I may only wait so long for a wifi signal from this turtle. If you do go this route please, please add a way to turn it off too.
Anyway, just an idea.

[McLeopold]

Sangar, on 25 August 2013 - 11:04 AM, said:

For the second, yeah, I've been thinking about adding some kind of timeout in the initialization to allow aborting when the user presses a key or something. I'd probably add that to the startup script, so that the API itself never prints to the term.

I've added the same timeout to my resumeable scripts as well. I also had the thought that if the inventory of the turtle was blank or different when resuming, assume the turtle was broken and replaced and to abort the resume feature. Maybe even just do the timeout if it has a blank inventory.

[michthom]

Hi Sangar, thanks for the work so far - I just stumbled on LAMA while trying in vain to reimplement something similar.

In case it helps anyone else, I stumbled when trying to include LAMA in a resource pack e.g. to distribute with the programs that will require it: I foolishly copied the 'lama' minified version file into:

minecraft/resourcepacks/ResPackName/assets/computercraft/lua/rom/apis/lama

However when I tried that all I got was blank-screened turtles, that I was unable to restart with CTRL-R.
The approach that worked was to copy the lama-src version into that same location but renamed as just 'lama'.

Hmm. More complex than it first seemed, I'm struggling to get this to work consistently from within a resource pack, even with your 'bapil' API installed to get the path resolution.

Any advice/ideas?

Cheers
Mike

Edited by michthom, 31 December 2013 - 03:48 PM.

[michthom]

Thanks to Sangar for responding off the forum with the issue, and to those on the CC IRC channel, particularly AmandaC.
Between us we found that some of the environment checks in the API needed to be moved, and Sangar has now incorporated the changes in the GitHub repository, here:
https://github.com/fnuecke/lama

So if you want to distribute a program that requires LAMA as an API, you can now simply create a folder structure like this:

[Your-Minecraft-Folder]:
resourcepacks:
[Your-Resource-Pack-Name]:
assets:
computercraft:
lua:
rom:
apis:
turtle:
lama
help:
[Your-Program-Name]
programs:
[Your-Program-Name]
pack.mcmeta
pack.png

And once you're done testing, zip up the files under [Your-Resource-Pack-Name] (e.g. NOT including that directory/folder in the zip) and distribute that zip file for others to put in their resourcepacks folder, unmolested.

[joebodo]

Here's some code that I use for turtles that need GPS coordinates. I find it useful for the turtles running around my base that need to know where the refuel or drop off station is located. I removed all the error checking to help with readability.

Hopefully you find this helpful (and add GPS support )

function enableGPS()
  local ploc = _getGPS()
  if not ploc then
	return
  end
  -- store the offset for later use
  loc.gxOff = ploc.x
  loc.gyOff = ploc.y
  loc.gzOff = ploc.z
  while turtle.detect() do
	turtle.turnRight()
  end
  -- get second position in order to determine heading
  turtle.forward()
  local nloc = _getGPS()
  turtle.back()
  -- orient to east (alternatively, you could store the heading offset - but you will have to rotate the coordinates accordingly)
  if nloc.x < ploc.x then
	turtle.turnRight()
	turtle.turnRight()
  elseif nloc.y < ploc.y then
	turtle.turnRight()
  elseif nloc.y > ploc.y then
	turtle.turnLeft()
  end
  return ploc
end

function _getGPS()
  local c = {}
  c.x, c.z, c.y = gps.locate(10)
  if c.x then
	return c
  end
end

-- if going to coordinates that are absolute, then just adjust the relative coordinates
function gotoLocation(nloc)
  if nloc.gps then
	return goto(
	  nloc.x - loc.gxOff,
	  nloc.y - loc.gyOff,
	  nloc.z - loc.gzOff,
	  nloc.dir)
  else
	return goto(nloc.x, nloc.y, nloc.z, nloc.dir)
  end
end

BTW here's a good forum post on setting up the GPS hosts:
http://www.computerc...osition-system/

[Lyqyd]

That is not a good GPS tutorial. It swaps around the Y and Z axes for no good reason, which will completely foul things up if you aren't paying attention.

[joebodo]

Lyqyd, on 16 January 2014 - 10:20 AM, said:

That is not a good GPS tutorial. It swaps around the Y and Z axes for no good reason, which will completely foul things up if you aren't paying attention.

Y and Z are swapped as this is the normal method for using a coordinate system (outside of minecraft).

In analytic geometry, unknown or generic coordinates are often denoted by the letters x and y on the plane, and x, y, and z in
three-dimensional space.
-- http://en.wikipedia....ordinate_system

Having used the normal coordinate system for just about forever, I didn't realize it would be confusing (If i post more code, I'll either make it clear it's swapped or adjust it to minecraft's preference).

I provided this to hopefully give the OP some ideas - it is not provided as a tutorial (not sure how you came to that conclusion).

[Lyqyd]

The post is in the Tutorials section of the forums. In ballistics, +y is up.

[Oose]

This is a really well made API. I had never thought of using fuel to check if a turtle had completed a move or not. Lots of practical applications, thanks for making this.

[civilwargeeky]

Wow. I'm sorry to say I won't be using your api at this time, but thank you so much for all the research on turtle movements and persistence. All of this information will be really helpful to improve my quarry's session persistence. I would have never considered to use the turtle fuel as an indicator as to whether or not the turtle moved! That is really a novel idea that I think more people should know about.

[Manadar]

Thanks for this API. The waypoint system is very pleasant to work with.

I'm having a whole range of issues with using this API and I'm not sure if it's the server or the mod installations, or if others are having similar issues.

For several times now, I've had some turtles dead-lock themselves after a fresh installation. I would go ahead and run lama-installer, run my simple script (just lama.init, lama.set) and the turtle would ask me to "Invalid state. Please reinitialize the turtle's position." repeatedly. This often goes hand in hand with "Cannot set position while moving or refueling." when I would start my program for the first time, before performing any moves whatsoever. Removing the label from the turtle, taking and replacing the turtle, then doing a reinstall does not solve this.

When I attempted to investigate the issue further, I found additional errors such as when indexing nil in lama:712, and one other instance where nil was being indexed around line 400. But since the files are minified, it was hard to track the bug to the responsible line of code in GitHub. Sorry I could not be of further use here.

Finally, I'm not sure if this is intended behavior, when I would abrupt a running program abnormally, either via Ctrl+T or with a pickaxe, the turtle would merrily continue on its old path. If this is intended behavior, it would be nice if there was a way to stop this unwanted behavior in some way.

[LayZee]

Hi,

it seems that Lama does not work in ComputerCraft v1.63. Calling

lama.init

,

lama.set

, and

lama.forward

never yields.

Has anyone else experienced this problem?

[sjkeegs]

LayZee, on 22 June 2014 - 08:51 PM, said:

it seems that Lama does not work in ComputerCraft v1.63.

There is a lot of code in there that has not been updated for CC1.6. I'm not surprised that it's not working.