[MUD-Dev] Time travel and Logging

[JC Lawrence]

Somewhere I missed the message that Lambert is replying to.  I'll
reply to both below.

On Sun, 28 Dec 1997 02:44:24 PST8PDT 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

> On 27 Dec 97 at 15:48, Ola Fosheim Grøstad wrote:
>> coder at ibm.net wrote: 

>>> As mentioned earlier I log everything.  Be careful of that word
>>> "log".  This does not mean that I create text files which record
>>> past doings, but that I log DB activity amd the event sequences
>>> such that any prior point in time for that BD can be created
>>> __exactly__ as it was then, with the addition that that point in
>>> time can be rolled forward thru time such that __exactly__ the
>>> same things as ahppened back then, now happen again.


> I would doubt his logs are human readable, no?  The interesting
> potential side-effect of backwards time travel does pose some
> technical problems.  For instance, the observing object originally
> took no part in the original events.  The replay mechanism would
> have to account for this and add the observing object to all the
> local event chains.  

I used to do this.  It was an incredible bandwidth sucker to handle
the extra data load that I had to preserve to be able to regenerate
all that.  Now I merely record the IO for an object, and the state
changes for that object (actually IO is now a state change for me, so
that's cheap).  The result is that time watchers will only be able to
see what the object they are watching "thru" saw.  If that object
never got the IO, then neither will they.

> I wonder how or whether perception of the character would be
> translated into the viewing object.  For instance, would a character
> notice a hidden/invisible character that he hadn't noticed when he
> passed through a location a few days earlier?  Or would he, by
> observing as a third party, generate a new chance to detect this or
> see it automatically?

He'd only notice it if the object he is watching thru did.  Thus
perception is filtered by the watched-thru object, not the watcher.
This is a side-effect of the bandwidth reduction I mentioned above.

<sigh>

I ___*really*___ hated to have to yank that code out.  It was ever so
gorgeous.


> I would also assume
> that the replay engine(s) would be a separate state machine of it's
> own separate from the 'real' mud and that time travel events
> wouldn't be logged.

Correct.  The fact of the time travel would be, but not the IO generated. 

>>> Want to see exactly what happened on Main St yesterday at 16:03?
>>> Just go to that location on Main St, walk back thru time to 16:05,
>>> and then resume normal time flow.  You'll see everything that
>>> happened there, exactly as it happened, exactly as if you had been
>>> standing there at the time (except that you won't be affected by
>>> anything).
>> 
>> Ok, but on what level is this observation done?

You occupy the viewpoint of an object that was in that location at
that time.  You see what it saw.

>> I split concepts into at least 3 levels:
>> 
>> - World level 
>> - Room level ("field of view" if the system doesn't involve rooms) 
>> - Avatar level

Depending on the object taken for the viewpoint object in the time
watch, all three can be used for time watching.  

>> For instance, is it possible to observe actions that take place on
>> the avatar level? ("you feel hungry" etc)

Yes.  
 
> That's interesting.  I would guess that events that are
> "internalized" or avatar events would not be observable by a third
> party time traveller.  Whose avatar events would they be observing
> in any event?  I suppose 'tell' (the traditional implementation) as
> well as person to person telepathy would also be unobservable to the
> typical time traveler.

Actually, uhh, no.  You would be able to see all the SAYs and TELLs
both generated by and received by the viewpoint object, as well as
other internally received text.

Note: None of this is fixed in stone.  I've had to cut yet more
corners recently to try and save yet more bandwidth, so some details
may change.

But, the neat thing is that I have a nice background story for all the
limitations:

  Life observes.

  Life records.

  Occupy life and you can see what it saw.

  Occupy an inanimate, and you can only go where it goes.

Not quite haiku, but what else do you expect when buried in a really
nasty recursive bug on a generic rules testing engine I'm writing in
python?  <shudder>  I still have no idea where its going wrong.

Aside: I'm becomqing increasingly impressed with Python
(www.python.org).  Its impressively elegant for a very small OO
language.

See:  

  http://www-acs.ucsd.edu/~jstrout/python/poo/index.html

for an implementation of MOO in Python, using Python as the internal
programming language, I'm beginning to think that python would make a
rather decent internal language for a MUD, with all the advantages of
an external, standardly defined, documented, multiple commercially
published books on it (incl O'Reilly (not a terribly good book I'm
afraid)) etc etc yada yada language brings with it.

--
J C Lawrence                               Internet: claw at null.net
                                           Internet: coder at ibm.net
----------(*)                        Internet: jc.lawrence at sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...