Save lua state with game saves.

The most frustrating issue i have is that the lua state isn't saved when the game is saved. this hurts the turtles more then the computers. yes i can write my programs to save there state to a file every time i process, but this increases perf and seems to break the illusion of persitance.

I believe dan looked into this - there apparently seems to be no way to get the Lua state using LuaJ - however I'll mention it to dan next time I speak to him.

Can turtle have some event when world saves/shutdown ?
So program has a chance to save some vital info in the right moment, not after each action.

This would be technically possible. The shutdown code is run asynchronously anyway, so it could wait a bit.

The same would be quite nice to have for computers as well: a function (probably in the OS API) that registers a callback that's invoked just before the chunk containing the computer unloads.

Event for chunk unload too. Or else unloaded turtle would be unable to save anything.

something done in this direction? I'm really in need to get some informations to let a program be persisten on chunk unloading and server shutdown….

This would be very useful, even if an event was called such as "will_shutdown" or something.

This is, I believe, something that the developers are working toward.

Let's hope! It would bring finally Computercraft programming to a whole other level!

i like the idea of an event before shutdown

The time/effort spent adding an event (and resuming the computers again rather than shutting them down) would be better spent working on saving the Lua state, I would imagine. Especially so since it would be made useless by the change to state-saving.

No event before shutdown. How many more times must we say no to that?

Cloudy, on 20 March 2013 - 03:59 AM said:

No event before shutdown. How many more times must we say no to that?

You just add it to the "things not to ask" post.

Sebra, on 05 April 2012 - 08:27 PM said:

So program has a chance to save some vital info in the right moment, not after each action.

Whats wrong with saving after each action?

Performance? Let's say we have a bunch of turtles making a hole (yeah, I'm talking about my Turtle Swarm). Each time turtle moves, it should
1) Open a file
2) Write the data onto a hard drive (Real hard drive)
3) Close the file.

I'm not sure if server would like that, especially when 64 turtles do that each second. May be I'm wrong, though.

Actually, would that work? is there a chance that world would shutdown before the file closes?

PonyKuu, on 21 March 2013 - 04:56 PM said:

Actually, would that work? is there a chance that world would shutdown before the file closes?

Very small odds of it happening. but not impossible.

When there are a lot of turtles running, chances are not as small I think… Especially when you
1) Move the turtle
2) Update its coordinates
3) Save the data

PonyKuu, on 21 March 2013 - 08:09 PM said:

When there are a lot of turtles running, chances are not as small I think… Especially when you

that is irrelevant. they aren't all moving and running their code at once, they all run individually, thats why the computers and turtles need to yield, so the next can run… the chances of having the server shutdown or the chunk unload in the exact millisecond before the file is saved is small… again, not impossible, just small…

As far as I understand, that yielding can increase the chance that something bad happens between the turtle's movement and file updating, am I right?
I mean…

- turtle 1 moves
- turtle 13 does something
- turtle 2 does something else
- turtle 32 does other stuff
- Server shuts down before turtle 1 had a chance to save its state

PonyKuu, on 21 March 2013 - 08:38 PM said:

As far as I understand, that yielding can increase the chance that something bad happens between the turtle's movement and file updating, am I right?
I mean…

- turtle 1 moves
- turtle 13 does something
- turtle 2 does something else
- turtle 32 does other stuff
- Server shuts down before turtle 1 had a chance to save its state

yeh so in that case, save before moving.

- turtle 1 changes its pos in file and then moves
- turtle 13 does something
- turtle 2 does something else
- turtle 32 does other stuff
- Server shuts down

1) Record your intention to move in the file, and the direction you are moving in.
<– if interrupted here, coordinates are valid and turtle hasn't moved
2) Request the turtle to move with turtle.native.
<– if interrupted here, the turtle will fire a success or failure event after it restarts, and coordinates are wrong if it succeeded.
3) Wait 0.05 (or 0.1?) seconds for a failure event. If you get one, go to step 6
<– if interrupted here, the turtle will fire a success event after it restarts, and coordinates are wrong if it succeeded.
4) Update your coordinates. Record the fact that you haven't received a success event yet.
<– if interrupted here, the turtle will fire a success event after it restarts, and coordinates are valid.
5) Wait for a success event.
<– if interrupted here, the turtle will not fire an event after it restarts, and coordinates are valid.
6) Reset the file.


When loading:

if file has "intention to move" flag then
  if file has "updated coordinates but didn't receive success event" flag then:
	wait for success event, failure event or one second
	if failure event then
	   crash - something screwed up
	end
  else
	wait for success event, failure event or one second
	if timed out then
	   crash - something screwed up
	end
	if success event then
	  update coordinates with direction of movement
	end
  end
end

Btw, that's three file writes per block moved.

TheOriginalBIT, on 21 March 2013 - 08:44 PM said:

- turtle 1 changes its pos in file and then moves

Are you sure that turtle wouldn't yield between those things?

PonyKuu, on 21 March 2013 - 08:49 PM said:

Are you sure that turtle wouldn't yield between those things?

Positive.

Things that yield

sleep
os.pullEvent
os.pullEventRaw
turtle api, NOT turtle.native
… I feel like there is another one I'm forgetting but cannot remember at this time…

if you don't believe me run this code

while true do local h = fs.open('this', 'w') h.write('this') h.close() end

it will error with the 'too long without yielding' after ~10 seconds.

Oh, Immibis… That's cool, but a bit… complicated. And I have no Idea what turtle.native is… Wiki doesn't have such page. Is it a some sort of low-level turtle function?

yes turtle.native is the low level. its what actually tells the Java to move the turtle and such.
the turtle api adds this over the native

local function waitForResponse( _id )
  local event, responseID, success
  while event ~= "turtle_response" or responseID ~= _id do
	event, responseID, success = os.pullEvent( "turtle_response" )
  end
  return success
end


local function wrap( _sCommand )
  return function( ... )
	local id = native[_sCommand]( ... )
	if id == -1 then
	  return false
	end
	return waitForResponse( id )
  end
end


for k,v in pairs( native ) do
  if type( k ) == "string" and type( v ) == "function" then
	if turtle[k] == nil then
	  turtle[k] = wrap( k )
	end
  end
end

wiki doesn't have the page because they don't want you to know about the natives :P/> (there is more than just turtle.native, like term.native)

Oh, I see. Thank you for the explanation and stuff.
But all that doesn't mean that Lua state saving on chunk/world reload is a bad idea. ^_^/>'

It's already planned, it's just not easy, given the current state of things.

And for what I saw in the decompiled sources, they already started work on this (not sure since which version). I don't know if it's even working, but there's some work done to use native lua libraries and the pluto library (used to save the lua state).

(Sorry if it was a secret :P/>)