[DGD] Where did all the players go?

[Raymond Jennings]

*instant drool*

I've been working about that with Kotaka, but so far I'm primitive.
Basically what I have in mind for mine is a nested hierarchy of
coordinate systems based on the traditional object containment
hierarchy, with coordinate system transformations as you rise and sink
through the hierarchy from one object to another.

As you might expect, doing a containment trace to find the lowest
common container as a coordinate system root of sorts is a key part of
this operation.

On Tue, Dec 12, 2017 at 1:53 AM, Blain <blain20 at gmail.com> wrote:
> I guess we can also contribute various stock mudlibs.  I've been working on
> a bare bones lib that offers a lot of utility in a small package.
>
> I think it should be based on the kernel, but should have a System wrapper
> around the kernel, perhaps.  Or a combined version where all code outside
> the kernel can be very customized.  It could have a lot of ifdefs to turn
> features on and off, like many of the MudOS distros I used to tinker with.
> I have been implementing various LPMUD-esque things in my bare lib, such as
> reset/clean_up, heartbeat, etc.  A fully functional object database with
> fill automatic upgrade capability is also a must.  These things can be in a
> kernel, possibly, and not specific to any one mudlib distro.
>
> I'm also working on a scalable 3D coordinate map system which can handle a
> medieval/fantasy flat earth as well as a vast, expansive space game with
> planets.
>
> On Dec 12, 2017 3:45 AM, "Blain" <blain20 at gmail.com> wrote:
>
>> apt-get install kernel-dworkin
>>
>> On Dec 12, 2017 3:41 AM, "Felix A. Croes" <felix at dworkin.nl> wrote:
>>
>>> bart at wotf.org wrote:
>>>
>>> >[...]
>>> > As you mention, keeping the mudlib uptodate this way is more difficult
>>> because
>>> > of user changes to that lib. I tried to do a few things to reduce this
>>> issue:
>>> >
>>> > - Make things 'pluggable', ie: Gurbalib's safun setup allowed for
>>> adding and
>>> > overriding afuns in a way that should not conflict with updates to the
>>> lib
>>> > (this is no longer the case in the current version)
>>> > - Strictly dividing the lib in a 'kernel', 'lib' and 'user' part. Only
>>> touch
>>> > the 'user' part (which included the safun dir)? You should be fine.
>>> > - Modified the 'lib' part? This should still be relatively easy, but
>>> requires
>>> > work for merging changes
>>> > - Modified the 'kernel' part? You are on your own.
>>>
>>> This dovetails with my own experience.  I came to the conclusion that you
>>> need a kind of package manager for inside the persistent mud, and that the
>>> OS-level package manager can only mess things up; that is another reason
>>> for desiring the isolation of a container.
>>>
>>> What a persistent mud needs goes further than a traditional package
>>> manager,
>>> because of runtime upgrading.  I have not yet settled on any particular
>>> solution.
>>>
>>>
>>> > This worked somewhat, but, people find enough reason to modify the lib
>>> part to
>>> > still make this a lot of work for both the maintainer of the core
>>> > distribution, and the users. Additionally, it also meant a fair bit of
>>> extra
>>> > work to ensure lib upgrades always worked, or in cases where that was
>>> not
>>> > possible, at least ensure they pointed at the proper way to upgrade
>>> (requiring
>>> > specific inbetween versions for migrating data).
>>> >
>>> > At any rate, keeping a mudlib distribution uptodate and facilitating
>>> in-place
>>> > upgrades of muds using it is a pretty big challenge due to data
>>> conversion and
>>> > having to provide ways to upgrade user data, even when people do not
>>> modify
>>> > the core lib.
>>> >
>>> > Part of the issue here is this being a somewhat unusual approach for
>>> most
>>> > people. Understanding the in-place recompilation of code is already a
>>> bit of a
>>> > challenge, doing proper data conversion seems a bridge too far until
>>> people
>>> > gained significant experience with the system.
>>>
>>> This is true even for non-mud database professionals.  Mention runtime
>>> upgrading, and they will insist that bringing the database down for
>>> maintenance is a better solution.  Mention hotbooting, and eyes start
>>> to glaze over.
>>>
>>> Regards,
>>> Felix Croes
>>> ____________________________________________
>>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd