Re: Saving the lua state

["Ales Mlakar" <jazzbre@...>]

I agree that this has nothing to do with Lua, since all saving game stuff
should be done from the C/C++ side of the game not from Lua. You're using
Lua just to script things so all acctual variables and stuff is in your C
code anyway. I don't see why you want to do this in Lua though, really. If
your C/C++ code architecture is solid, for example derived classes with
virtual Save & Load functions, this should be a pretty straight foward
thing. And you don't need to save information about what Lua is doing since
I think you must do your script functions like Once-per-loop called anyway
like:

function    DoAI(object) -- object is a C++ class

    if  object->Target
       object->DoWhatYouNeedToDoAndStuff()
    ..and so on
end;

This really doesnt have anything to do with Lua.

Ales Mlakar
----- Original Message -----
From: Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>
To: Multiple recipients of list <lua-l@tecgraf.puc-rio.br>
Sent: Friday, July 28, 2000 10:08 PM
Subject: RE: Saving the lua state


> >From lua-l@tecgraf.puc-rio.br  Fri Jul 28 16:32:06 2000
> >From: Falko Poiker <fpoiker@relic.com>
>
> >Cool.  Save.lua has pretty much everything I need.
>
> save.lua is meant only as an example, really.
> You should adapt it to your uses, but it does show how to save a table and
> global variables so that their values are restored when the file is loaded
> later.
>
> >What part of lua's design makes it "designed for" saving stuff?
>
> Not for saving per se, but for allowing applications to easily read values
of
> its "control variables".
> This is what we called "configuration" in the SEMISH'94 paper that
described
> Lua 1.1. See http://www.tecgraf.puc-rio.br/lua/semish94.html .
> In such configuration files, there no need for control flow, but there is
> a need for data structuring, hence tables.
> So, support for configuration was one of design goals of Lua.
> Of course, once you have this support, you have support for saving state,
> because all you have to do is write a file that can be read later.
>
> >In this simplistic example, I demonstrate something I haven't been
> >able to achieve with lua yet, that is blocking functions.  Is
> >there a way to do this?
>
> No. You have to write your application in a different way, probably using
> threads and the new multi-state API of Lua 4.0.
>
> >According to the
> >lua reference doc, you can only read an entire file, a string
> >or a buffer, but since lua 4.0 is reentrant, there's no saying
> >you can't read a file line by line.  Does this make sense?  Is
> >line reading (through a buffer maybe?) possible for lua?
>
> You can only load *complete* chunks.
> You can load it line by line, but only if the lines make sense as a whole.
> That's what the sample interpreter lua.c does.
> In particular, you cannot load the body of a function line by line, sorry.
> Again, it seems to me that you need multithreading.
>
> >At any rate, the reason I wanted to save the lua state innards
> >(using the second form mentioned above) is because the player
> >may want to save his game while his soldier is "moving to"
> >his target.  Lua would then be in the middle of reading a file,
> >possibly needing a save of the innards of the lua state.
>
> Like I said, it seems to me that this is mainly a question about the
> *architecture* of your game and has not much to do with Lua.
> But I'm not a game expert. Perhaps other people in this list can help
here.
> --lhf
>