[DGD] Saving to disk

[Raymond Jennings]

Also, regarding syncronization.

Objects being automatically received from an external source turned into a
major pain in the rear over on Skotos, with people complaining of verbs and
objects being overwritten.

If this is the sort of synchronization I think it is, you'd definitely want
to make sure that the devs of the receiving mud can opt out of any changes
they wish to reject.


On Tue, Apr 16, 2013 at 9:53 PM, Raymond Jennings <shentino at gmail.com>wrote:

> This marshalling of objects between a network of servers deserves a
> mention of Geir Hansen's thesis:
>
> http://geir-hansen.com/distributedworld.pdf
>
>
>
> On Tue, Apr 16, 2013 at 9:33 PM, Jared Maddox <absinthdraco at gmail.com>wrote:
>
>> > Date: Tue, 16 Apr 2013 07:37:16 -0500
>> > From: Blain <blain20 at gmail.com>
>> > To: All about DGD and Hydra <dgd at dworkin.nl>
>> > Subject: Re: [DGD] DGD
>> > Message-ID:
>> >       <CAD2jvh7EsA_NMiygT2kR=TFK=
>> T1Demdj5dbr8JQOjNuwd48EYQ at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Thanks, Felix.
>> >
>> > I'm currently trying to install everything I need to compile DGD on my
>> > Droid tablet.  So far I've paid for "c4droid" and installed the GCC
>> addon.
>> > I had to force HOST=DARWIN (My OS string is undefined because the uname
>> > command is missing or otherwise inaccessible).  Then it barfs trying to
>> > find yacc.  I've searched Google Play for yacc or bison, but to no
>> avail.
>> > I e-mailed the author of c4droid to see if he had any knowkedge of there
>> > being a droid-compatible yacc/bison.  If I get this thing working, I
>> will
>> > e-mail the list of the steps I took to get DGD on the Droid OS and I'll
>> > also recommend some programs for coding on the tablet below.
>> >
>>
>> Word of warning. If you actually run DGD on your Droid then you'll
>> want to put it's swap file (and preferably everything else it uses) on
>> an SD card, so that you can swap it out. NAND (including the Flash
>> used inside tablets & smartphones) has a much lower maximium number of
>> data writes before you start getting bad sectors/blocks. Better to act
>> ahead of time by always keeping this stuff on replacable media.
>>
>>
>> > Date: Tue, 16 Apr 2013 10:01:06 -0500
>> > From: Blain <blain20 at gmail.com>
>> > To: All about DGD and Hydra <dgd at dworkin.nl>
>> > Subject: [DGD] Saving to disk
>> > Message-ID:
>> >       <CAD2jvh6RCcm9X=
>> u4cTVRX62Tc27aYkTrJm0hRW2tsUcY_BFVZQ at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>>
>> > For starters, users should not be ever-present in the game.  In a
>> standard
>> > LPMUD/MudOS game, a user is represented by a .o file.  This makes sense.
>> > This also means that the user connection can and should be destructed on
>> > logout.  The body, if separate can also be saved to a .o file and
>> > destructed.  Other players and NPC's don't usually need to interact
>> with an
>> > offline player in most MUD designs.  If a designer really wanted to,
>> they
>> > could redirect private messages (usually called 'tells') to an internal
>> > mail system or a cache waiting for the player to return.  Also, I don't
>> > think an environment object should be trying to load a player's body
>> when
>> > that player isn't on.  Of course, there are ways which this can handled
>> > appropriately in most any persistence scheme.
>> >
>>
>> Outside of certain conditions, I think that it's probably better to
>> keep the primary copy of the user & their body in the swap file.
>> Still, there are exceptions:
>> 1) If you've got a multi-server system then body objects need to be
>> able to move from server to server, and swap files don't really help
>> with that.
>> 2) If you've got too many users, you'll simply need to marshall them
>> out to non-swap when they logout.
>>
>> I also think it makes sense to move "long-inactive" players out to
>> non-swap for archival purposes (after all, you might want to restore
>> that info for some reason later on).
>>
>> The real question is "is there any real reason for me to move this?".
>> I think that in most cases, the answer is no.
>>
>> > Persistence seems to be a great way to keep the Game going without
>> skipping
>> > a beat, but players can choose not to be logged in, and so they should
>> not
>> > quite be included in the persistence of the Game.
>>
>> So "teleport" them to a "login zone". If there's several "reentry
>> points" for them in the area where they were, then they could even
>> choose between them.
>>
>> > The object will also recursively save its inventory
>> > and compile the data mappings received into a string variable, and it
>> will
>> > reconstruct its inventory using that string upon reconstruction.
>>
>> Having played around with implementing a C object database, I have a
>> note to make. For internal data, simply translating down to strings is
>> fine, but for objects that other objects can interact with (let's say
>> a sword object), I think you should do it a little differently.
>> Firstly, create an object to represent the save file. Every object
>> that will be stored inside (body objects, shoe objects, etc.) will
>> request an id. They will then be asked for their "self string", or
>> whatever you'd like to call it. When they return that self-string,
>> instead of containing sub-strings that describe other objects, they'll
>> contain a stringified form of the id of the other object. So, a
>> mapping would get it's string form embedded directly into that of it's
>> owner, as (I assume) would an LWO, but a clone would get it's id
>> stored instead.
>>
>> The reason why you want to do it like this is to prevent the
>> possibility of link-recursion in a relatively simple and fast way.
>>
>> If the object being saved refers to objects that aren't being saved,
>> then an id obviously wouldn't be enough (after all, what do you do if
>> it gets reissued?). In that case, I'd recommend a combination of
>> timestamp and id issued at time of creation (and for multi-server
>> setups, the server of origin). This can come up if, e.g., you decide
>> that players who logout while in a certain room will appear in that
>> room when they return. Obviously you can't store the room with them if
>> it's publicly accessible, so you need some other method. The same
>> thing could come up if there's an object which for whichever reason
>> isn't allowed to leave the game (let's say it's a remote controller
>> for a teleporter in a dungeon, or a hologram in a StarTrek-style
>> holodeck), but the player is carrying. They'll want to still be
>> carrying it (or at least close to it) when they log back in, but other
>> players will presumably need it too. So you store it's id, log out the
>> player, move the remote somewhere reasonable (e.g. the burrow of a
>> packrat), and treat it as the player's restore location when they
>> return... even if it's moved, or is in the hands of another player.
>>
>>
>> > Date: Tue, 16 Apr 2013 14:10:39 -0500
>> > From: Blain <blain20 at gmail.com>
>> > To: All about DGD and Hydra <dgd at dworkin.nl>
>> > Subject: [DGD] Saving to disk
>> > Message-ID:
>> >       <CAD2jvh5TLKfND0b=csthVr+6jaem6Eyh76=
>> oXncwS1JamOri2Q at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > On Tue, Apr 16, 2013 at 10:51 AM, Noah Gibbs <noah_gibbs at yahoo.com>
>> wrote:
>>
>> >> You're right about areas -- being able to write, import and export
>> areas
>> > requires some kind of disk format.
>> >
>> > Especially when I plan to have two different servers running, a Dev
>> server
>> > for creation of the game, and a Live server for players to play on.
>>  Areas
>> > have to be copied from one to the other.
>> >
>>
>> Something you might consider is having a "synchronize" or
>> "import/export" system for devs. You could connect the two systems
>> together with either outgoing sockets, or an external "cross-connect"
>> program. This might require the occasional addition of an "install
>> script" or "unmarshall script", but that could be compiled & run at
>> the destination from source. Serializing doesn't always have to target
>> the disk.
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>
>