New method for turtle API - direction.

I tried to search for it and didn't find such a suggestion. I feel one simple method added to the turtle API would greatly improve it. It should return the turtle's current direction (where is it facing: north, south, east or west).

This could be made to altering the turnLeft and turnRight function.

Denied by Dan200.
Use some peripheral instead or setup a GPS network.

GPS, yeah, that or tracking your every turn.

It is important to note that gps can't directly give you the direction, and that could be where it is added, but I guess it's still a no.

Unless you have a source for that denial, don't post.

You can simply move forward one and check to see which direction you moved, i.e.:

x1,y1,z1 = gps.locate(2,true)
turtle.forward()
if x1 then --there is a GPS system
	   x2,_,z2 = gps.locate(2)
	   x2,z2 = x2-x1,z2-z1
end

x2,z2 now contain which axis you moved on and which direction.

There is also at least one peripheral mod that lets you craft a compass turtle…I may think it's not very useful but the option is there.

If you really want it - there is compass turtle peripheral.

Otherwise, it's trivial to set up two alternate right and left functions that remember how many times your turtle turned so you can always get the direction. Only problem might be that this system would be relative to turtle's first direction when you placed it down.

The problem is that CC does not keep its state, so after quiting MC and starting it again all programs restart. If a program left a turtle in some weird position while quiting MC, this turtle may do some unplanned things after MC starts again (I use autostart with my turtles).

And it's not always possible to move a turtle… Not to mention that I have to setup a gps network to have a workaround for something that would not bother me if CC was keeping it's state and would continue programs :)/>/>

Thanks for the tip about the compass peripheral - I'm gonna look into it.

Edit: Not that useful, I'm afraid. I need every kind of turtle to be able to tell direction, not just one specific kind.

CrazyCatLady, on 22 October 2012 - 08:13 PM said:

The problem is that CC does not keep its state, so after quiting MC and starting it again all programs restart. If a program left a turtle in some weird position while quiting MC, this turtle may do some unplanned things after MC starts again (I use autostart with my turtles).

And it's not always possible to move a turtle… Not to mention that I have to setup a gps network to have a workaround for something that would not bother me if CC was keeping it's state and would continue programs :)/>/>

Thanks for the tip about the compass peripheral - I'm gonna look into it.

Edit: Not that useful, I'm afraid. I need every kind of turtle to be able to tell direction, not just one specific kind.

Then save the direction to disk whenever you rotate. However I'll see if we can add it.

Persistence will be coming to CC eventually.

It's not that simple. Sometimes chunk is unloaded in between saving and rotating. For example, I save new direction to disk and then rotate. However, chunk unloads right before rotating meaning that my turtle thinks he rotated but he did not.

It might seem like a slim chance but this happens quite frequently for me. Not so with rotating, but with moving (save coordinates and then move). That is why none of my moving-related turtles are autostarted.

AFAIK nearly every turtle can be combined with compass peripheral?

matejdro, on 22 October 2012 - 08:55 PM said:

It's not that simple. Sometimes chunk is unloaded in between saving and rotating. For example, I save new direction to disk and then rotate. However, chunk unloads right before rotating meaning that my turtle thinks he rotated but he did not.

It might seem like a slim chance but this happens quite frequently for me. Not so with rotating, but with moving (save coordinates and then move). That is why none of my moving-related turtles are autostarted.

AFAIK nearly every turtle can be combined with compass peripheral?

Then only save after it has moved?

Then turtle moves and after move it saves. But again chunk might unload after moving but before saving.

matejdro, on 22 October 2012 - 09:22 PM said:

Then turtle moves and after move it saves. But again chunk might unload after moving but before saving.

Possible but less likely. One easier way to be sure is to queue the turtle movement using turtle.native.turnLeft().

Turtle.native?

matejdro, on 22 October 2012 - 10:08 PM said:

Turtle.native?

Yep - calls the functions without waiting for a response (although you could handle the success or failure event yourself). I agree it isn't ideal though and I'll look into it.

I'd rather have persistence done sooner than distract you from working on it. I've been able to get all the saving and stuff I need, but persistence would still be nice.

Sounds interesting. But how do you know when turtle moved and if moved successfully?

just saving after instead of before eliminated the vast majority of failures when I tested this in turtlex. Saving before, any unload while it was running a program was almost always off by the last move or turn that was unfinished, while saving after very rarely had any issue. Of course, very rarely is not never, but it beats the hell out of almost always.

I'm actually saving it after. But I still get issues quite regularly (especially with areas that are frequently loaded and unloaded).

Saving the Lua state seems extremely hard and resource intensive. But what do I know, besides an extremely short web search?
If instead one saved part of the state, e.g. the turtle.native queue, or in general peripheral's requests queue's, one would guarantee that peripheral calls would be executed. Then again I'm theorizing on incomplete information about how CC works internally. Just my two bits.

CoolisTheName007, on 09 December 2012 - 07:41 AM said:

…If instead one saved part of the state, e.g. the turtle.native queue…

It already does.

Cloudy, on 09 December 2012 - 07:56 AM said:

snip

How is then that people were complaining about saving future position, calling turtle.forward and then chunk unload causing unsync between save and real position? Which is the same as calling turtle.native.forward(), if there's an unload.

CoolisTheName007, on 09 December 2012 - 08:08 AM said:

Cloudy, on 09 December 2012 - 07:56 AM said:

snip

How is then that people were complaining about saving future position, calling turtle.forward and then chunk unload causing unsync between save and real position? Which is the same as calling turtle.native.forward(), if there's an unload.

I'm not sure of the behaviour if it is in the middle of moving and then the server shuts down. Perhaps it will have moved, perhaps it won't - I'm leaning towards the former.

Cloudy, on 09 December 2012 - 08:09 AM said:

snip

By server shutdown, I assume we refer to an ordered shutdown, not a hurricane-was-in-a-hurry shutdown?
If it's uncertain if the turtle has moved, then the only logical alternative to get the right coords after chunk load is that:
-There is an output queue that only gets events in case of movement success;
-This queue is resumed and events are queued to the respective computers;
-The computer catches the events;
This happens right after the chunk loads, so I'm not certain event queues work like this.

If this is not the case, then there is no safe way to keep the position saved.

As I'm sure I said before - when persistence comes, this shouldn't be a problem, since everything about the computer will be persisted. I'm not going to have this argument again for the umpteenth time.

Cloudy, on 09 December 2012 - 08:35 AM said:

snip

Sorry, assumed you had given up total persistence.

Snip.
Dammit, there was another page. :/