Hey, there, since you confirmed the bug as a duplicate I've gotten here this fix.
Since I HATE PULL REQUESTS IT'S SO WEIRD, and there's like 12 branches...
here is all the code needed inside of projects/common/src/main/java/dan200/computercraft/shared/turtle/apis/TurtleAPI.java

/**
     * Read the rotation sensor value.
     * <p>
     * Returns a 4-bit register (0-15) that increments each time the turtle turns.
     *
     * @return The current rotation sensor value (0-15).
     * @cc.treturn number The rotation sensor value.
     * @cc.since 1.116.2
     */
    @LuaFunction
    public final int readRotationSensor() {
        return ((TurtleBrain) turtle).getRotationShaft();
    }

Here is all that is needed inside of projects/common/src/main/java/dan200/computercraft/shared/turtle/core/TurtleBrain.java

    private static final String NBT_ROTATION_SHAFT = "RotationShaft";
    private int rotationShaft = 0;

    //Read state
        rotationShaft = nbt.contains(NBT_ROTATION_SHAFT) ? nbt.getInt(NBT_ROTATION_SHAFT) : 0;
//Write state
        nbt.putInt(NBT_ROTATION_SHAFT, rotationShaft);

@Override
    public void setDirection(Direction dir) {
        owner.setDirection(dir);
        rotationShaft = (rotationShaft + 1) & 0xF;
    }

public int getRotationShaft() {
        return rotationShaft;
    }

Related: #788

I wonder how would look a review for this pull request xd

Why 0-15? Turtles can only face 4 directions.

rn I don't even understand what does this PR trying solve. Also the change of rotationShaft didn't even check if the direction actually changed or not.

Once ran in the java env we can consider this to be much safer than lua because it will save after the end of the tick.

But lua, lua may interrupt any time, example : on server reboot or simply a chunk deload reload.

With this we allow players to use turtles like they always wished without having to worry about a turtle (very impressive piece of technology) which can turn without registering, forcing players to place a block and read absolute direction and move only up and down until we know for sure what direction we are in and whether we are moving into a chunkloaded chunk or not. Moving and using gps is not much of a reliable choice because you'll be moving in an unknown direction, possibly an unloaded chunk.
It just possibly makes turtle reliable like we dreamed of.

rn I don't even understand what does this PR trying solve. Also the change of rotationShaft didn't even check if the direction actually changed or not.

I know we could tap inside the turn(left||right), if you prefer. I was thinking if another mod were to turn the turtle we would get a rotationshaft update, but perhaps we should verify that our direction changes that would prevent future conflicts.
Smth like
If(turtleDirection != newDir)
IncrementShaftSensor %16

I don't even understand what does this PR trying solve.

Chunk unload recovery for rotation. When unloaded, your code can stop at any point. It doesn't wait until a yield, it just instantly stops. If you are wanting to keep local information about where the turtle is without GPS, then you need to track each movement.

Unfortunately, this method of instantly stopping your code means you can end up in a state where you wrote to disk that you moved, but never actually did.

The current solution to this is to save both before and after a movement, while including the current fuel level. If you last saved before moving, but the fuel level is one below what you saved, you are safe in assuming that the turtle successfully moved, even though we didn't save that it finished moving.

Unfortunately, this does not work for turning, because it does not consume fuel. Currently, there is no way to determine if the turtle actually successfully turned, if it turned when the chunk unloaded.

This PR is aiming to fix that by adding a value that we can check from lua, like fuel. I'm just curious why it's 0-15 though.

And if a mod turn a turtle around we could increment by 2, making this modproof.

0 to 15 because it makes it a bit more complicated to track absolute rotations via this file, altough still easy, we can simply %4.

I guess 0 to 14 would be even better. But anyways, the goal is to track change not value. That is why it always goes up, "because the turtle's motor shaft never turns backwards", so that we have to write a rotation to file, then we can call a turnLeft(), then because of the shaft sensor, no matter when our program shuts down, we should have a way of reconstructing our current position. If we have a new rotation file but nochange in shaft sensor, we havent moved. If we have a new rotation file and the rotationshaftsensor isnt the same as the rotation in rotationOld then we have a successful rotation and we can copy the new rotation file into the old. If our rotationOld file is corrupt, (we verify it) it means we got shutdown mid overwrite and thus we can try copying new into old again ;)

0 to 15 because it makes it a bit more complicated to track absolute rotations via this file, altough still easy, we can simply %4.

Exactly, it's over-complication for over-complication's sake. It's just going to make it annoying to use.

If we have a new rotation file and the rotationshaftsensor isnt the same as the rotation in rotationOld then we have a successful rotation

If your goal is just to detect if movement succeeded, all you then need is a single value that flip-flops between two values upon completion of a movement.

And if a mod turn a turtle around we could increment by 2, making this modproof.

I am confused on your meaning here.

An aside

I'm curious, could we just add a compass to the turtle? Look at your phone, it has a compass built in via a magnetometer, why not allow turtles to just have a compass builtin?

However... Servo motors are extremely accurate to the degree. Extremely well built ones for industrial applications can do sub-to-the-nth-degree rotations in both directions. If we're playing this off the idea that it's some shaft that we're sensing the rotation of, why not just return the offset from placement (0-4), and possibly even allow the user to 'calibrate' it via another sensor (sets 0 to the current facing). I know it'd save me a lot of code writing handling turns myself in my code. Would not need a compass built in, but would give us the ability to still detect an offset facing.

Except that compasses do not work for the north in this game. Also, why bother bloating our hands for something that we all would assume to be basic turtle function.

By mod, I am talking mod compatibility, if a mod interacts with a turtle and commands it to setDirection..

How yeah you may say a servo shaft is very precise, but, you forgot we might be using a differential on that turtle's rotation apparatus, allowing the slippage to cause drift in the shaft.

All this is for a little challenge WHILE, not being a plan breaker.

The calls to sync our rotation only happen when the turtle reloads, so not during any loop or anything of the sort. It might increase turtle boot times a bit but that's all.
All we gotta do is write a well thought piece of code to get it working, exactly what this mod is about.

Without being a dead giveaway, it gives us what is expected from using theses turtles.

Except that compasses do not work for the north in this game.

How yeah you may say a servo shaft is very precise, but, you forgot we might be using a differential on that turtle's rotation apparatus, allowing the slippage to cause drift in the shaft.

This reads like I'm play-arguing with a 5 year old... "I shoot you, bang!" "But actually I was a robot and the bullets bounced off my metal armor!" Nothing constructive will come out of this, so I'm just going to yeet myself into bed and unsubscribe from this.

Except that compasses do not work for the north in this game.

Our mod implemented that.

Yeet yourself out because this suggestion to the mod maintainer is made for him to accept. As he said, he does not like turtles reading information out of thin air. Since we are commanding the turtle to turn, we would expect it to be a functionnal command for the turtles, that's all. The goal is only to fix turtle.turn, no matter the way.

And if you think handling 4 directions is hard, maybe you code like LAMA programmers did lol.. 1500 lines of code to track position on a turtle, 400 lines of comments ?

I reduced the concept to a few lines of code and it is working well for movement but not for rotations because of this very issue.

I will compile the code myself with my own fix to this problem if we cannot get to a fix, because this is what computercraft is about, it's just as much about coding your turtle that it is about coding your turtle. Wait, what ? Yeah you see, this rotation shaft really isn't much, but I remember when I was 12 and learned to code on computercraft, just knowing that turtles do not keep rotation would have stopped me from doing anything at all with them. If at least there was this LAMA2 library that were to work right, every, time.
Turtles are still going to be complicated to program right for your needs, but very much more reliable, that is the goal. The small in game patch we have to do will simply act as a skill barrier, a skill barrier we can surpass and get atop of. Progress does not come from nowhere, but I think placing an object and using a whole item slot to hold a torch would be very unconvenient, if not irritable. Using a built in compass wouldnt be very precise, just like in real life. Additionnaly, compasses in minecraft orient to spawn, indicating the north pole is in fact, 0,0. The north direction is seemingly not a real north. It'd be fun to have compasses that point to spawn for turtles tho, they would be almost useless, fun, maybe. With lodestones too !

Now the core of this mod, is programming, it's not a compass, it's to include programmable elements into minecraft, effectively propelling the possible into the much less finite than vanilla.

Basically, it just makes a lot of sense to calibrate the turtle once and that's it.

Now you like to get to insults, that's like right after the 5 y/o phase you know ?

Holdon, pole is not 0,0 , it seems it might be where the player first spawned... so we could know when a rotation succeeded then, and that would be good enough.
And by knowing the spawn center we could triangulate position from floats if we're up yo it.
Since we can already track moveup and move down we'd be good. Merci beaucoup, SVP

@fatboychummy

When unloaded, your code can stop at any point. It doesn't wait until a yield, it just instantly stops.

I don't think this is true. While @SquidDev has upgraded the lua vm to be able to interrupt programs at any point, this wasn't always the case and I don't think the behavior regarding chunk-unloading has changed. As far as I know, the program continues until the next yield, after which it is gracefully shut down (closing file handles (which also flushes) and such).

The current solution to this is to save both before and after a movement, while including the current fuel level. If you last saved before moving, but the fuel level is one below what you saved, you are safe in assuming that the turtle successfully moved, even though we didn't save that it finished moving.

Unfortunately, this does not work for turning, because it does not consume fuel. Currently, there is no way to determine if the turtle actually successfully turned, if it turned when the chunk unloaded.

Again - I'm pretty sure this isn't true. Turning always succeeds. So for turns you simply save that it happened to file before calling the turn function. So while the turn does sleep and the server can shut down during this sleep, the turn is always persisted at this point. This is how I've always dealt with this and it has never failed me.

This PR is aiming to fix that by adding a value that we can check from lua, like fuel. I'm just curious why it's 0-15 though.

Given @lostallmymoney did not take the 2 minutes it takes to figure out how pull requests work, I have the feeling that the code was vibe-coded and makes no sense.

On a positive note though: I have actually been working on solving persistence in userland on and off for 3 years now and I'm almost done. Will release it soon hopefully. I actually got a prototype running within an hour once I had the idea it just took a lot of time to make it easy to use, lower its memory footprint and figure out all the details.