NiM5 comes with a script interpreter. A major bug was fixed in the script interpreter which causes memory leaks on servers running versions of the code before 2004. There are two noticable engineering questions left with the current interpreter:

1) The design of the language

The language could use the following structural improvements:

a) switch() statement (minor addition, with some functional limitations)
currently, switch() statements would be limited by max # of params
for a function, which I believe is 6, so 5 cases
b) trigger: clause
for automatic %astr% comparisons with strings for commands,
the easiest implementation would look something like this:

{disarm}:
settimer(self);
{arm}:
close(self);

or this say trigger:
{keyword}:
do({'response});

c) less-strict literals {,}
d) loose-functioning goto() statements
there are some odd restrictions using goto() and if()
e) intelligent object-manipulation and referencing features
me.variable, which includes object-structure links
so that settimer(1) would appear as %me.timer%=1;
(or appears as self.variable)

2) Precompilation of scripts

It would drastically improve performance if the scripts were precompiled in some way. Currently, no pre-compilation occurs but could occur to increase performance of the server. 4000+ scripts running at the same time can yield some performance lag. Scripts do not have even performance: most function at a single level, but lengthening the wait() state is a great way to improve performance when running multiple
scripts. Aside from extreme scripts (examples below) most solutions are not performance heavy.

Examples of "Extreme Scripts"

Scramble
Aggression-like scripts
Scripts that generate a lot of new memory quickly without
destroying it (producers/dispensers)

There are over 200 functions in the current implementation. Functions can be implemented with simple code hooks, and the language itself
could be easily ported to other software such as Envy, Smaug, Diku,
Merc or ROM.

If you want to talk about your scripting language, how about some information on the actual grammar, semantics, implementation design, etc? There's really no point in spamming the forum with a bunch of function prototypes. It doesn't tell anyone anything.

This code, a function of NiMScripts, demonstrates two important syntactic features and one very important interpretive constraint.

Otherwise, the other features demonstrated are looping with goto() and label() as well as if-clause

IMPORTANT NOTE: YOU MUST USE BRACES to delineate a section of code is imperative and should be used whenever seperating code blocks.

ADDENDUM: BRACES VERSUS BRACKETS

You can use Brackets [ and ] in place of braces, if you don't want to think about how much your braces hurt. This is fine, just don't mix braces and brackets-- this is like crossing the streams in Ghostbusters -- a definite no-no.

Scripts Versus The World File
-------------------------------
Tricks and Tips

Use duplicate mobs to fake changes.. use duplicate areas to fake major changes -- create group adventures with the use of moveall() --

Take a close look at the scripts in the area files and how they are arranged. The scripts are like books on a shelf -- or dominos -- each script or set of scripts functions together as a single unit. You may want to cut and paste from an external editor when making these things, and watch for the upward spam limit -- I've lost work this way.

To make a ferryman, for instance, you may need several dummy rooms. Start thinking of the MUD as a whole unit of manipulated databases -- create the workings behind the black curtain, for now you truly are
an empowered wizard.

Spellcrafting
-------------

Scripts can be used to make spells. Either using the event queue or incorperating scripts into your magick system. In its raw form, NiMUD produces a spell system that manipulates two spectrums of spells -- mixed reagent magic and mana-based spell craft with a combination of both player mana and object-based mana (gems).

The mix() and reagents() functions provide an overview of the inner workings of this system, and offer a great start for folks wanting to use
this system.

do_oload has been modified to produce components, so you can test the system.

It's taking a while to make this, I know, but I just haven't had the energy I had in the past.

Event queues
------------

You can now add scripts to the event queue, tied to the "owner" of the event. This is useful for spellcasting and "triggering" other scripts
using the event() function.

See events.c

Script Awards 2003
------------------

Included in the area files are a series of scripts, to give you an idea of what "works" (since many aren't functioning properly) I've included this listing. I wrote all of these. User submissions welcome.
locke@mugs.net