FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Monster MUD?

 
Post new topic   Reply to topic     Forum Index -> Monster
View previous topic :: View next topic  
Author Message
rmt



Joined: 06 Apr 2008
Posts: 2
Location: Netherlands

PostPosted: Mon Apr 28, 2008 8:43 am    Post subject: Monster MUD? Reply with quote

I started my programming career with MUDs, and MudOS/LPmuds in particular, so I'm always interested in modern scripting languages which could be easily adapted to build a MUD. In the LPmud world, the driver handles networking and basic connection handling, but all the magic happens in the scripts themselves.

Some neat things about LPC, which I'd like to see replicated are:
* a virtual filesystem (Probably easy to do myself)
* be able to see the call stack and get information about each source file along the way (directories were commonly used to define the security context)
* the ability for a secure script to override any server function (simul efun in MudOS/LPC speak), and thus implement security in the scripting language itself, by having all other scripts calls to certain functions diverted to the secure script - I guess this can be done in D with an additional check. This and the point above allowed for fully script defined security models, which were quite cool. Smile
* limit cpu time for a function - since not all users were trusted, and people make mistakes, scripts should not be able to overload the environment.
* Although LPC didn't really have this, the ability to manage objects and memory usage is important, and allow for the orderly destruction of non-vital objects (eg. 100,000 bouncing balls should be destroyed before an instance of a user or a single instance of a book).
* some context associated with a call - such that you can map code triggered by user input to a particular user's network connection (eg. just call this_user() to get a user object). I haven't looked enough at Monster, to see whether this is possible.

Basically, I want a sandbox that I can let the kids play in without fear. Can Monster fill that role now, or in the future?

I'd love to get back into MUD programming in my spare time, and it would make for a fun project while learning D. Smile

Cheers, Rob
_________________
=rmt
Back to top
View user's profile Send private message MSN Messenger
nkorslund



Joined: 23 Oct 2007
Posts: 12

PostPosted: Tue Apr 29, 2008 2:30 pm    Post subject: Reply with quote

Hi. Thanks for the idea, this sounds interesting! I don't have much personal experience in the MUD world, but I think it's very possible that Monster can be used in that role. I can't say for certain without investigating the matter a little more first, though. The language is very much intended to be a sandbox, and is designed from the start to be a game modder's tool. It's still missing some key features though, so it is probably not quite ready yet in any case.

I'm not sure I completely understood the security model you describe or really how MUD scripting works. For example, how and by whom are the scripts inserted into the system? What kind of "bad things" do the security measures prevent?

I'd appreciate it if I could keep in touch with you about this, please drop me a mail a korslund@gmail.com.

I will check out some tutorials on LPC that I found - if you have any good links I'd appreciate it. I'm always interested in seeing what other game languages do and how I can learn from them.

Cheers, Nico
Back to top
View user's profile Send private message
rmt



Joined: 06 Apr 2008
Posts: 2
Location: Netherlands

PostPosted: Thu May 01, 2008 2:56 am    Post subject: Reply with quote

With LPmuds, the code is all stored on the filesystem, and each file is a class, which can (if designed for it) be instantiated. Most MUDs have players (who can't edit or call any code) and programmers (with varying degrees of access). Editing of code can be done from within the MUD's telnet sessions, and there are various tools to make the downloading/editing/uploading of code (and text in general) possible. LPmuds generally have no persistence, but state can be written to files by objects (it's common for a player to connect, and his entire inventory to be re-instantiated, restoring any state information if necessary). Static classes (files) also act a bit like objects, and a room is not really instantiated, it just is, and can be referred to by filename within the virtual filesystem (eg. as a programmer, I could use the MUD command "goto /home/rmt/home.c" to be transported to the room defined in home.c). The simplicity of it, combined with the social aspects of MUDs, makes for a fun way to learn programming. By convention, the normal way to instantiate an instance of an object is to call "clone /home/rmt/bouncingball.c" which would then create the object and place it in your inventory. You may then refer to it by name (as set in the constructor), and interact with it in the MUD environment like a user, or call methods on it as a programmer.

Obviously if you can have multiple people editing the code of the MUD, you either have to trust them completely, or have security measures in place so that they can only get access to that which they're permitted. A normal unprivileged programmer can only write to his home directory and the temporary directories. Code running from his home directory can only run with at most the privileges of the author. By default, all code runs without any special privileges, but they may be temporarily raised to the maximum level permitted for its location in the filesystem. I'm most familiar with the security model of the Lima Mudlib (Downloadable from http://www.mudos.org/ - it also has a lot of helpfiles included, which are enlightening), but in general most MudLibs use stack based security (http://www.dnd.utwente.nl/~krimud/Docs/NMAdmin/security.html) and the unguarded() function to raise privileges temporarily.

Bad things that could happen in the MUD include somebody creating an object called handcuffs that intercepts the user's commands and stops them from doing things, or initiating a network connection using the MUDs network stack and sending spam. You'd like to be able to be pretty broad about giving people limited programmer access, and just limit the privileged operations to those people you trust.

For a different take on MUDs, MOO's (MUD Object Oriented) such as LambdaMOO are persistent and treat objects and classes as one, and user Rmt has parent object $wizard (alias for an object number), who has parent object $user, who has parent object $object.. and a method/variable lookup involves dynamically searching each of these objects in turn for a matching method or variable.

I'll write you an email too, as I'd love to see the necessary features incorporated, and I'd be happy to be an evolving test case. Smile
_________________
=rmt
Back to top
View user's profile Send private message MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Monster All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group