From: jacob@fy.chalmers.se (Jacob Hallen)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 27 Aug 92 03:29:21 GMT
Organization: Chalmers University of Technology, Physics Departement, Gothenburg

In this article I treat several subjects. There are no real flames.

I also have a couple of question for all mud admins:

A) If we ansified the gamedriver, would you be able to run it?
B) If the gamedriver was written in C++, would you be able to run it?
C) Are you using gcc?
D) What gamedriver are you using?

Please mail answers to jacob@fy.chalmers.se. Since I think all gamedriver
developers would be interested in what you have to say, I will summarise
to the net.

In article <UEKLEINF.92Aug25232049@queen.mcs.Drexel.edu> uekleinf@mcs.Drexel.edu (Erik Kleinfelder) writes:
>djohnson@cs.ucsd.edu (Darin Johnson) said:
>
>Darin> And again, if 3.1.2 is so HORRIBLY buggy as everyone says, why the
>Darin> hell is everyone hiding the bug fixes???
>
>     Now there is a damn good question!

Well, there is a damned good answer too. There are a select few sites that
belive in sharing for everyones good. The other ones think that this is
just an other ratrace and won't publish their findings (excluding the
ones that were just lucky that they managed to compile the GD, they have
nothing to publish). Since there no longer is one central site for GD
development, you should use this forum to tell people around the world
about the bugs and inefficiencies you have found in the different
GD versions. The active developers will be sure to gobble up anything
useful that is published.

On to the silly MudOS debate: I'm sure that the choice of name wasn't
due to a wish to gain fame. It was a neat marketing trick. By choosing
a serious-sounding name that was very different from the LPMud name,
they stand out in the crowd. It's the same with TMI, serious name,
lots of crome, do the publicity thing to get your act going. It's just
like IBM. The marketing gets the customers, the technical stuff isn't
all that special. They have a neat thing going and I think they deserve
our admiration.

On the silly 3.1.2 is good for us debate: The features of this GD version
were fixed about a year ago, and considering that LPMud as such is only
about 3 years old, there have been some rather sustantial developments
on the GD front, and more are certainly to be expected. The most
important one is that the role of the gamdriver has changed. It us now
considered a general platform for implementing multi-user environments
instead of a dedicated program for running chat/monsterbash games.
Concepts like wizard, room, monster, light and weigh have already moved
to the mudlib, and concepts like user, living and action may soon follow.
Gamedrivers are also becoming more OS like, implementing one single system
call for each operation that has to be carried out. Several different
sites are going in the same direction although they are taking different
routes.
I think the people who are running 3.1.2 in compat and non-compat mode should
take a look at the alternatives, because you get benefits that far outweigh
the effort needed to convert. Making a master object, a simul_efun object
and an object that all objects in the game need to inherit leave you with
very minor changes having to be done to the rest of the objects in the mud.
I know this to be true, because Kingdoms has done the conversion to the CD
gamedriver with only a minimal amount of friction. If you are lucky, we can
persuade them to publish the necessary code and their experiences of the
changeover. Using a modern GD has the most important advantage that there
are people working on improving it, and people who can hear your bug
reports, and act on them.

On the silly A is better than B debate: You should have hard facts to
support your opinion. If you don't, my conclusion is that your opinion
is based on the fact that you have a buddy in one camp or the other, or
that you don't like the indentation style of one or the other. My view is 
that the best one varies from day to day. A week of hard work will still
make tremendous improvements to all drivers that are around. There are
a couple of brave people out there who are working on something that
is truly better; a complete rewrite. That is where the future lies, not
in the cosmetic changes that we all are dealing in right now.

On the silly inheritance/shadow debate: You can accomplish very much the
same things with both features, but the situation determines which one
that is most suitable. Ease of understanding is one important parameter,
security an other, and robustness an other. There are still other mechanisms
that can be used to make clean and flexible interfaces, like call_others
to cenral objects and creative use of #include. The doctor orders a mix,
and not too much of each. Personally I use multiple inheritance for the
addition of permanent modification of the original object, and shadows for
short term modifications. Execing into wizard defined objects does not
fulfil my demands for game security, even if you have no write access
to key libraries from within the mud.

Can't we discuss HOW to improve things instead of this silliness? I have
thoughts on improving smalloc and I have a leak in sprinf that I will share
with you as soon as I have made some tests.


Jacob Hallen