[Fixed as of 1.76pr2][1.73][SMP/SSP]Moving (or attempting to move) turtle does not update redstone.

VERSION:
1.73 (Confirmed to happen in beta 1.74pr20)
DESCRIPTION:
If turtle is attempting to move into next block and failing it will not update adjacent redstone wire even if it should be powering it.
EXPECTED RESULT:
Turtle moving forward to give redstone power to wire under it as it stands/moves over it.
REPRODUCTION STEPS:
CASE 1: Stands over wire situation. If turtle is not attempting to move into next(blocket) block it would update correctly.

1. PLace a turtle and in front of it one level lower place redstone wire. Place a block 2 blocks in front of turtle to prevent it from moving forward.
2. Make turtle emit redstone signal from bottom
3. run code:

   
   						while true do
   						  turtle.forward()
   						end

4. Turtle will move over redstone but will not update it state.
5. Cause wire to block update and see that it should have been powered after all.

CASE 2: In case of move over redstone simply make turtle emit from bottom and make it move over some redstone. Said redstone will not be powered when turtle passes over it.

SCREENSHOT/VIDEO:
Screenshots are for Case 1.
1. Turtle at point 2 of Steps

2. Turtle at step 4

3. Turtle at step 5 (redstone [or block] update caused by adding piece of wire )


In screenshot there are other mods but i have confirmed it on clean CC install and on clean beta install as well.

Sorry for self bump but can anyone confirm its a bug or is its working as intended and i am just crazy?

It seems to me that the turtles are simply not causing a block update when it moves. You should be able to confirm this theory if you are able to put any block where you put the additional redstone and it updates then.

Cranium, on 11 June 2015 - 04:22 PM said:

It seems to me that the turtles are simply not causing a block update when it moves. You should be able to confirm this theory if you are able to put any block where you put the additional redstone and it updates then.

Yes Block update causes redstone dust to light up as it should be. Now question is should turtles be causing block updates? If yes that is bug right?

Well, moving certainly SHOULD do that, but it doesn't it seems. I'm wondering if that's something that can be queued by ComputerCraft?

This thread comes to mind, where turtles certainly seemed to trigger updates.

Reckon I'll do some tests of me own later.

After some retesting right now i am even more confused. From my testing it appears as if turtle yelds due to use of coorutine.yeald() it will cause block update but if it attempt to make another movement using turtle api (no matter if that movement works or fails) there will be no block update.

So in example made in screen-shots turtle is constantly banging its head on block in front of it using turtle api and not causing turtle update.

Edit: Tested in latest beta. Same thing happens.

After performing some tests of my own, I would say that the problem is that when the turtle attempts to move forward, it first disables the redstone output to the tile under it, then doesn't bother to re-enable it (by triggering another block update there) if it finds out that it can't complete the operation. Because redstone updates only occur every couple of server ticks and your turtle is coded to constantly attempt to move, you never see the redstone turn on at all.

Does that match your observations?

Edit:

No, the above's wrong. But I reckon it's along the right track.

What I reckon's happening is that the turtle first goes forward, then before redstone can update and figure out that the signal's on, it turns it off again in order to move forward again. But it doesn't move forward again, because there's a block there.

So although the turtle ends up providing a signal to the redstone under it, the redstone updated when it was off, and no further block updates occur because the turtle isn't moving any more…

So why does the redstone come on as soon as the turtle stops attempting to move forward? Well, I reckon that's because the turtle is triggering block updates around it when the script ends!

Try this script to see what I mean; pressing a key to "stop moving" won't light the redstone, but pressing a key after that to "exit the script" will!:

rs.setOutput("bottom",true)

print("Press any key to stop moving")

parallel.waitForAny(
	function()
		while true do turtle.forward() end
	end,
	
	function()
		os.pullEvent("char")
	end
)

print("Press any key to end")
os.pullEvent("char")

Edit 2:

Erg, that's not it either. Just doing this in the Lua console also fails:

turtle.forward() os.pullEvent("char")

… so the failed movement attempts have nothing to do with it. Ditto if you add extra os.pullEvent("char")'s to the line. No redstone update until the whole line resolves, even though the turtle successfully went forward and never failed a movement attempt.

It's like, the first time the turtle moves over redstone, it won't trigger a redstone update until the next successful movement (including turning), or until the script ends. Why that would matter, I dunno, but that's how it's acting.

Edit many:

It's term.setCursorBlink() that triggers the update. When the script ends, or when the Lua console command completes, blinking is enabled and the redstone state beneath the turtle corrects itself.

This is probably because that same function toggles the animation that plays on the front of regular computer blocks. Turtles don't play that animation, but odds are some of that same code is triggering.

So, in a nutshell, when a turtle emitting a signal beneath itself first moves over redstone, it won't trigger the needed block update to light that redstone (or it might, but not at the correct time). Making the turtle move again or calling some other block-update-triggering function (such as term.setCursorBlink()) seems to correct things.

Resolved as of 1.76pr2

Taking Wojbie's word that this is fixed. Closing