Re: Scripting System..

From: George Greer (
Date: 12/12/02

[ Yes, this is late. ]

On Mon, 2 Dec 2002, Patrick Dughi wrote:

>> 'use Safe' stuffs all variables into a separate namespace too.  Have a
>> separate namespace for each player and the system itself.
>        I reread the info for this, it does indeed have seperate
>namespaces, so long as you keep track of the individual 'safe' objects you

One per player, plus one for the system (optional).  The MUD could run
system script (administrator-approved code-equivalents) without protection
if necessary.  Depends on how paranoid you want to be.

>There are still many, many problems with this; you'd still have/want to
>fork the processes off since there's no way to insure that any given
>process wouldn't take an undue amount of time.  That is, the only type of
>time sharing perl is capable of is via process control
>(alarm/suspending/etc - and some of these are not reentrant.  I see
>difficulties in restoring state and the location of the execution pointer.

There'd be only one extra process, for players.  If the player's script
process died or got stuck it'd only delay their scripts.  These would be
like custom prompts and macros so nothing important to the game itself.

>        I still think the flexibility of perl will make it far too
>difficult to account for even a reasonable number of the points of
>failure.  Upping the complexity of the system by using thread/process
>controls which are OS-dependant or using additional external
>programs/shells like rlimit makes it even worse.

It'd be a pipe.  What kind of pipe (Unix/TCP/UDP) isn't important.  Other
than that it's standard child fork/wait operations for the system that
CircleMUD already must do.

>        I am curious though, what you have envisioned... before I get too
>dragged down in the details, what do you envision a perl script actually
>looking like/doing?

Goal is to be able to write special procedures in it, but the inital go at
it would be for simple conditionals, printing, and actions.  Sort of like a
built-in TinyFugue, MCL, Tintin, or zMud.

>        Would there be a general set of structures generated and passed
>into the perl function to descibe the players, rooms, mobs, objs and their
>important relationships, or would this be accessable directly from the
>embedded perl via some... uh.. magic?

The structures themselves would not be exported.  The Perl code would call
into C interface code that'd send requests over the pipe (for players) to
request changes.

>        Also, a sidenote; using the perl that comes with cygwin for
>windows ends up being (depending on what you're doing) around 8-80x slower
>than a compiled from source version on a linux machine.  Use activestate
>if you have to use windows.  It's still slower than the linux, but there's
>not such a wide descrepancy when you perform network operations.

I'd expect somebody to find a way to use VisualBASIC scripts there.  Won't
be me.

George Greer

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT