[DGD] Re: mudlibs (kfuns/efuns)

[Serhat Sakarya]

Hello,

> *ponder* I don't quite see how this_player() is needed when there is a 
> this_user() kfun?  How is it different?

<not really useful>
Oh, I am sorry - let me explain: in most (some?) lpmuds, you've got two
things: this_interactive() and this_player(), the first one is sortof
similar to this_user(), but the second one can also be NPCs (Non Playable
Characters): objects within the game that act as a living thing. Usually,
these two are the same, but there may be cases where you force a monster
to do something and then that will be this_player(). Hhm.. maybe not the
clearest explanation I can give, but I think you'll get the idea ;-)
</not really useful>

> What sort of string related functions are you after?  I am also interested
> in why you feel they should be kfuns rather than efuns.  I generally only
> add kfuns if I think something can't be done as an efun.

The reason I want to use kfuns for specific applications (especially
string manipulation) is because I can use some crazy pointer magic in
C which I can't do in LPC - in fact, it would require some extra
effort on my part to make these functions in LPC rather than in C ;-)
Besides, I think that making 'standalone' functions as efficient as
possible is a good thing. It's the way I feel most comfortable with.

As I enjoy making kfuns, getting these from other places is not really
my main concern, but I do think it's a good idea to have a set of standard
solutions to certain problems that many (new) admin may be facing. For
instance, I could not find the strstr() function anywhere in DGD-1.1; 
this may not be the best of examples, but I am certain that many people
are interested in such functions. I would be willing to contribute some
of my kfuns and improve upon them with the help of comments/suggestions
from other people. 

Another thing: are you aware of any documentation on driver internals?
All of the things I know about driver internals are from studying the
source code.

> The first release is available (along with the first release of the mdbm
> package for interfacing with ndbm and gdbm databases) at
> http://www.enol.com/~asmith/drf/

Hehe, sounds interesting - I will take a look after the weekend. :-)

I am interested in making the mud have all sorts of interesting ports to
the 'outside world'. We are working on a system that will enable people
to read/post/write things via webpages (where authentication is required,
of course). We are using the net kfun package for this, which is really
neat, btw.

Well, I think this mailinglist could be of great use for discussions on
standards for certain optional (i.e. that don't come with the driver)
kfuns/efuns/patches. But, what I'd also like to see is discussion on how
to implement key elements of mudlibs such as access daemons, command
daemons, soul daemons, etc (or however you like to call them). I've
implemented all of these, but I'd like to know other people's approach
to these things. 

Regards,

Serhat Sakarya




List config page:  http://list.imaginary.com/mailman/listinfo/dgd