[Prev][Index][Thread]

# Re: your mail

- Date: Wed, 26 Feb 1997 15:49:24 PST
- From:
- CC: moo-cows@parc.xerox.com
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=us-ascii
- Organization: Unorganized
- References: <Pine.LNX.3.95.970226155744.1163A-100000@redbeard>

    > My question is, will I be better off scrapping the work I've done so far
    > and loading up the new DB, or are there any big changes?  Also, I'm
    I was in a similar situation, I've been working on a new MOO since mid-Jan but
    wanted to upgrade to the new Core. Although it took a bit of work, I managed
    to basicly port everything from my Dec95-based DB into a fresh new Core.
    Although there is 1 more object in the new core, if you recycle Mr Spell
    (which is tricky in itself, but doable), and then use #32 for whatever your
    #94 in the old DB was (for me it was Guest1), then all the objects after that
    case have exactly the same numbers, and you just @dump them over (modify @dump
    to @chown and @move them, and you can almost exactly duplicate your old DB).
    If you've mucked around with Core code a lot, that needs re-doing, but most of
    numerous changes to the Core are relatively minor, so it's not too big a
    problem. I whipped up a simple system which allows one MOO-server/DB to
    @compare objects in it to those in another (which hasta run a simple 'Compare
    Daemon' using listen()/:do_login_command). Then I could run my old DB, a
    generic Dec95 DB, and my new DB simultaneously, and look at what things I'd
    changed and what things in the core had changed. It ended up only taking me
    about 3 days to get everything transfer, and everything seems to be working
    fine now.
    If you want I could send you a copy of the code I used, and/or a list of
    changes between the Dec95 and Feb cores.

    > running under Linux kernel 2.0.27 on a DX4-120/16 megs/16 meg swap
    > partition.  Aside from needing more RAM (Like maybe 32 to 64 megs) would
    > this be sufficient for a MOO that has maybe 15 players logged in at once,
    > that includes a combat system (forked tasks like combat make hella lag)?
    > I've found that the only time I ever get any lag with Linux, regardless of
    > how many or how big of tasks I'm running, is when it has to fetch and
    > retrieve pages from swap.  Just for a point of reference..
    I'd think that machine would be fine, up to a DB size of maybe 20 MB, assuming
    you stick ~40+ MB RAM in it. If you write forked-tasks (especailly NPCs can be
    a bit CPU hit) efficiently, you could prob'ly get away with somewhat more.
    In my experience, much more critical is your network connection. 1 or 2
    seconds server lag doesn't matter much if you're getting 6-8 seconds network
    lag. This doesn't nessecarily depend on the bandwidth to your machine (you can
    get a long way on a 28.8 modem) as much as your ISP/network provider having
    reliable, non-overworked connections.

    --
                                      -Chris^`~'*.,_,.*'~`^P$iON-
    -----BEGIN GEEK CODE BLOCK-----
    Version: 3.12
    GCS/CM/IT/M/S d-- s+: a15 C++++$ UL+ P L-- E? W++(+++) N+ o? K? w++++@
    O--- M-- V- PS++ PE- Y+ PGP- t+ 5++ X+ R+ tv+ b++ DI+++ D+
    G++ e* h! r y-
    ------END GEEK CODE BLOCK------

References:

- Re: your mail

- From: redbeard*NOJUNKEMAIL* <redbeard@cdc.net>

- Prev: Re: your mail
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index