Subject: sqrt() function in the MOO server

From: Ryan Daum <[email-masked]>
Date: Fri, 7 Aug 1992 11:53:10 -0700

One thing I've added to my local LambdaMOO server (which is the version run by
GodNet) is a sqrt() function.

The reason for adding this was to increase speed when calculating the 3d
distance formulas we are working on here.

I'd like to see htis added as a standard functin.

In addition, considering the monthly updates of LambdaCore that we cannot
"patch" into our existing database, I'd like to suggest the following for
discussion:

	Some standard way of seperating "Core" from "database."

That is, have two seperate files -- one being the core database (i.e.
LambdaCore) and the other being the database file of objects that exist outside
of it.

Core database object #s  would differ slightly, so that they wouldn't interfere
with the number count.  Lets say we "reserve" the first two hundred objects or
so (make it a compile time option) for core database, and from #200 on would be
standard objects.

When a new core databas is created, it would contain a list of the differences
between the object numbers of it and the previous version.  So, all children of
$player on the old database would be recognized and CHparented to $player in
the new database, which would have been "patched" into that #0..#199 area.

Sounds far-fetched, but it really is a pain seeing how much nicer the latest
LambdaCore is *after* having built 50 objects on top of the old one.

---

From: Pavel Curtis <[email-masked]>
Date: Tue, 11 Aug 1992 17:36:30 -0700

> Date:	Fri, 7 Aug 1992 11:53:10 -0700
> From:	Ryan Daum <[email-masked]>

...

> LambdaCore) and the other being the database file of objects that exist
> outside of it.
> 
> Core database object #s would differ slightly, so that they wouldn't
> interfere with the number count.  Lets say we "reserve" the first two hundred
> objects or so (make it a compile time option) for core database, and from
> #200 on would be standard objects.
> 
> When a new core databas is created, it would contain a list of the
> differences between the object numbers of it and the previous version.  So,
> all children of $player on the old database would be recognized and
> CHparented to $player in the new database, which would have been "patched"
> into that #0..#199 area.
> 

I can certainly understand your frustration, but I'm not sure that I can see a
good way around the problem.  One difficulty with your idea is that it doesn't
allow for any local changes to the core, since they would be wiped out whenever
the next release of the core occurred.

An idea that I've kicked around for a while now is that it might be feasible to
write an integration tool that took three databases as input: your current
database, the version of the core from which it was built, and the latest
release of the core.  The tool interacts with the user, pointing out decisions
that must be made in merging the core changes into your database.  For things
(broadly construed) that are the same in both cores, it would assume that the
version in your database should be preserved.  For things that are the same in
your database and the old core, but different in the new core, it might presume
to use the new version.  For things different in all three, it would get help
from the user to figure out what to do with them.  There are a *lot* of nasty
details in even such a simple system, though; that's why I've neither written
such a thing or even considered anything more sophisticated.

	Pavel/Haakon