[locke]

Check out NiMUD at NiM5 Documentation Index

Lots of new features, scripts, the most powerful MUD codebase in existence!

[Zivilyn]

It come with Asbestos armor? Lol, kidding, welcome back again Locke. Did you want to list features and explain why it's the most powerful MUD codebase in existence?

[locke]

I have to admit it's still being worked on. There are some definite kinks. The bug I found today: if you hurt() in a script, destroying the target, the variable points to a bad part of memory when you next dereference it. Yay. Crashed the MUD hard. This will be fixed soon I hope.

I plan to implement only bug fixes in the hard code. I've noticed I've written a lot but not all of it functions as expected, so that's the only changes I will be making from here on out: making it do what it says it does and making it work as expected. Yes, I'm done adding features.

The latest updates not even available yet on SourceForge include fixes to the magic and spell system that I have put off for years. Today I added 6 (yes 6!!) spells, one creates an object, 3 are offensive and 2 create mobs. Once the kinks are ironed out I will be pumping out 100+ spells for an upcoming release demonstrating all of the features of NiMUD.

-------

The most advanced features of NiMUD currently are still amazing to use. I'm particularly fond of the "TRACE" feature which permits an immortal to "act out" the actions of a scripted actor in the game. Once in TRACE mode (by typing "trace" from within the script editor), everything you do is recorded and stored in the script.

The way I usually create one of these is by creating a new script and then adding the first line:

autowait (25);

This is a good pace for a script. I then exit the editor and type the 'trace' command to enter 'trace' (or 'tracing') mode.

When I'm done acting out the set of activities, I type 'trace' in the script editor one more time to exit this mode and it stops recording my actions.

I used this method to create the adventurer guide. I was able to walk for a great distance within the MUD and the adventurer makes it to his destination.

At the end of this script I wrap it up by adding these lines by hand:

do({:waves and heads back to the Inn.});
jump(5005);

At this point, I made sure all the settings were correct, created a couple accompanying scripts that help the player participate, and polished it off with a self-test.

I've made several interesting areas with this method and with other scripting features. There are even some room creating features I haven't used in a while that are pretty cool, like the programmable map-room feature.

------

Adding a spell is easy! First, create the spell, then create a script that will be the actions of the caster. I was able to add a creature summoning spell, an offensive spell and a spell that creates an ice sword all with this method. I've created several functions that incorperate the features of the components and gem magick systems.

if ( reagents( mana, reglist ), { goto({cast}); }, { goto({failed} } );
<- tests to see if the caster has everything they need
mix(mana, reglist);
<- casts the actual spell, consuming the reagents

and

if ( gem({f|w|e|a},20), { goto({cast}); }, { goto({failed}); } );

where gem consumes any available mana stored in magic gems

Example: Water-elemental Spell Summons Water Spirit

if ( gem({water},{75}),
 { goto ({cast});
 },
 { goto ({failed});
 } );

label(failed);
echo({me},{You don't have enough water mana.});
goto({end});

label(cast);
do({:concentrates for a moment.});
wait({20});
do({:conjures the spirit of water to aid in battle.});
breed(self(),27);

label(end);

[Zivilyn]

The trace() sounds great actually Locke. Reminds me of Applescript with 'record new script' then you just do whatever and hit stop when it's done.

[locke]

I released a new version today with new production notes and many fixes enabling the spell system to work with gem magicks. A future version will include the 'natural magic' which takes advantage of hundreds of spell components to create a realistic alchemy.

Download at my website, below:

[locke]

Does this function read memory it shouldn't?

/*
 * Cuts a sentence like "You arrives through the hole to the surface."
 * to be "You arrive through the hole."
 */
char *cut_to( char *p ) {
  static char buf[MSL];
  char *t=buf;
  char *o=p;
  boolean found=FALSE;

  while ( *o != '\0' && (found= *o != 't' && *(o+1) != 'o' && *(o+2) != ' ') ) ) {
    *t=*o; t++;
    o++;
    if ( o=' ' ) { *t=' '; t++; }
    o=skip_spaces(o);
    if ( *o == 't' && *(o+1) == 'o' && *(o+2) == ' ' ) { found=true; break; }
  }

  if ( found ) {
    t='.'; t++; t='\0';
    return buf;
  }
  else return p;
}

[scandum]

Yes. It's the o+2

You could try this:

  while (*o)
  {
    if (!strcmp(o, "to "))
    {
      break;
    }
    *t++ = *o++;

    if (*o == ' ')
    {
      *t++ = ' ';
    }
    o = skip_spaces(o);
  }
  if (*o)
  {
    *t++ = '.';
    *t++ ='\0';
    return buf;
  }
  else
  {
    return p;
  }
}

[locke]

The o+2 would not be called if o+1 is checked against '\0', thus:

/*
 * Cuts a sentence or phrase with "the hole to the surface."
 * to be "the hole."
 */
char *cut_to( char *p ) {
  static char buf[MSL];
  char *t=buf;
  char *o=p;
  bool found=FALSE;

  while ( *o != '\0' && (found=(*o!='t' && *(o+1)!='o' && *(o+1) != '\0' && *(o+2)!=' ')) ) {
    *t=*o; t++;
    o++;
    if ( *o==' ' ) { *t=' '; t++; o++; }
    o=skip_spaces(o);
    if ( *o == 't' && *(o+1) == 'o' && *(o+2) == ' ' ) { found=true; break; }
  }

  if ( found ) {
    *t='.'; t++; *t='\0';
    return buf;
  }
  else return p;
}

[scandum]

Hrm.

It may not read invalid memory that way, but it still reads like a hack job.

[locke]

It's always a hack-job, Scandum. My method is elegant.

[Fizban]

Originally Posted by locke It's always a hack-job, Scandum. My method is elegant.

I find Scandum's method to be more elegant, as well as more "proper". As for the scripts, the trace feature is indeed neat, but the syntax screams "coder" whereas I think in-game scripting should be more builder orientated. If you need a coder to make all the scripts then the benefit of the system is largely negated in my eyes. If you need a coder to do the scripts it's just as easy for them to write them in C.

[locke]

The reason you write a scripting language is not to make it easier, but to make it more powerful. A logical scripted language is capable of a higher degree of variation than without it, plus the headache of dealing with "C" code, timed events, etc, must be formalized somehow.

I think my language could use 1 or 2 changes, but overall it has greatly enhanced the experience and provided far more possibilities for spells, for instance, or area traversal, as well as the "random encounters" aspect of the game --

[Fizban]

Originally Posted by locke The reason you write a scripting language is not to make it easier, but to make it more powerful. A logical scripted language is capable of a higher degree of variation than without it, plus the headache of dealing with "C" code, timed events, etc, must be formalized somehow. I think my language could use 1 or 2 changes, but overall it has greatly enhanced the experience and provided far more possibilities for spells, for instance, or area traversal, as well as the "random encounters" aspect of the game --

That's not really true. The benefit of the scripting language in a MUD is largely to reduce the workload of the coder by allowing the builders to create the scripts in their zone themselves. Builders are not known to be coders as such the language should ideally be easy enough to use to allow non-programmers to be able to use it to at least a minor extent.

[locke]

Actually, Fizban, it's very difficult to argue that considering I have personally written every single NIMScript to date and thus have plenty of evidence to the contrary. I would not say it's less work.

Index of /nimscripts

The things the scripts allow are multiple ways of 'getting to' the things that were once basic MUD features, but they can involve event-based activities. Also, they provide rudimentary logic and random variation.

In fact, it merely moves the "spec_fun", C hardcode world to soft code, decreasing overall reliability and increasing performance requirements (albeit slight).

Yes, in part, to open it up, but not really: many scripters don't have the extensive background necessary to undertake doing it on their own, and thus need training and guidance which I also provide. So, while it has yielded better gaming rewards, it has not really been less work at all.

The one place where it really pays off is when you want to create many variations on one theme. For instance, let's say you had a generic fireball script and you wanted to make many different strengths of fireballs as separate spells, that would be fairly easy to do. Maybe you just think of it as an offensive spell like fireball, then you can make a bunch of fireball like spells with different timed emotes and different potencies very quickly.

Another example is the Pirates part of The Isles. It is fairly easy to create 5 similar adventuring ships based on the first ship. You can just make one ship perfectly, and then use it as a template to make the other 4 ship adventures, swapping in and out different parts to make them different (such as the captain's name, the ship's name, or the types of random encounters and their chance of happening).

[Fizban]

Originally Posted by locke Actually, Fizban, it's very difficult to argue that considering I have personally written every single NIMScript to date and thus have plenty of evidence to the contrary. I would not say it's less work. Index of /nimscripts The things the scripts allow are multiple ways of 'getting to' the things that were once basic MUD features, but they can involve event-based activities. Also, they provide rudimentary logic and random variation. In fact, it merely moves the "spec_fun", C hardcode world to soft code, decreasing overall reliability and increasing performance requirements (albeit slight). Yes, in part, to open it up, but not really: many scripters don't have the extensive background necessary to undertake doing it on their own, and thus need training and guidance which I also provide. So, while it has yielded better gaming rewards, it has not really been less work at all. The one place where it really pays off is when you want to create many variations on one theme. For instance, let's say you had a generic fireball script and you wanted to make many different strengths of fireballs as separate spells, that would be fairly easy to do. Maybe you just think of it as an offensive spell like fireball, then you can make a bunch of fireball like spells with different timed emotes and different potencies very quickly. Another example is the Pirates part of The Isles. It is fairly easy to create 5 similar adventuring ships based on the first ship. You can just make one ship perfectly, and then use it as a template to make the other 4 ship adventures, swapping in and out different parts to make them different (such as the captain's name, the ship's name, or the types of random encounters and their chance of happening).

I wasn't saying they can't save the builder time as well, I was just stating that ideally, at least in my eyes (ie. I'm not saying your opinion is wrong, just simply that it's coming from a different perspective) , a scripting language embedded into a MUD should have simple enough syntax for the majority of the MUD's staff to be able to use it to save the absolute largest amount of time. That way more people can share the workload and builder's can write the scriptsfor their own zones when making the zones instead of having to think up scripts and then request that a coder write them for them. DG Scripts can most likely do 95%+ ofthe things your NIMSCript (I said most likely) but it has syntax which is friendlier to non-coders who would quite likely be intimidated by the syntax used in the NIMScript. I certainly do agree that how powerful and flexible a language is matters, I just disagree on it being the only thing that matters.

[locke]

Originally Posted by Fizban I wasn't saying they can't save the builder time as well, I was just stating that ideally, at least in my eyes (ie. I'm not saying your opinion is wrong, just simply that it's coming from a different perspective) , a scripting language embedded into a MUD should have simple enough syntax for the majority of the MUD's staff to be able to use it to save the absolute largest amount of time. That way more people can share the workload and builder's can write the scriptsfor their own zones when making the zones instead of having to think up scripts and then request that a coder write them for them. DG Scripts can most likely do 95%+ ofthe things your NIMSCript (I said most likely) but it has syntax which is friendlier to non-coders who would quite likely be intimidated by the syntax used in the NIMScript. I certainly do agree that how powerful and flexible a language is matters, I just disagree on it being the only thing that matters.

From what I can see, DG scripts can't do the things NIMScripts do, because DG scripts aren't written this way at all. NiMScripts aren't exactly in their best form, but they offer far more logic power than DG scripts. DG scripts seem to be a bit more specific in how they handle events, where NIMScripts are more general and have wider applicability. Plus, a newly added sub-language called "Building Scripts" is unlike anything available on a MUD before this release on 03/09/2009.


Game Statistics
---------------
Highest ranking player: Ponnet
Played the longest: Ponnet with 11 hours, 108 logins
Most diverse skillset: Ponnet with 62 skills
Most powerful mage: Ponnet with 13 spells
Most experienced: Ponnet with 126495 points

Strongest: Fizban with 27 strength
Smartest: Ponnet with 30 intelligence
Wisest: Ponnet with 30 wisdom
Nimblest: Ona with 25 dexterity
Toughest: Ponnet with 30 constitution

Nicest: Ponnet with 112390 karma
Meanest: Kileem with -2178 karma

[Fizban]

Originally Posted by locke From what I can see, DG scripts can't do the things NIMScripts do, because DG scripts aren't written this way at all. NiMScripts aren't exactly in their best form, but they offer far more logic power than DG scripts. DG scripts seem to be a bit more specific in how they handle events, where NIMScripts are more general and have wider applicability. Plus, a newly added sub-language called "Building Scripts" is unlike anything available on a MUD before this release on 03/09/2009. Game Statistics --------------- Highest ranking player: Ponnet Played the longest: Ponnet with 11 hours, 108 logins Most diverse skillset: Ponnet with 62 skills Most powerful mage: Ponnet with 13 spells Most experienced: Ponnet with 126495 points Strongest: Fizban with 27 strength Smartest: Ponnet with 30 intelligence Wisest: Ponnet with 30 wisdom Nimblest: Ona with 25 dexterity Toughest: Ponnet with 30 constitution Nicest: Ponnet with 112390 karma Meanest: Kileem with -2178 karma

I could easily, very easily in fact make that Game Statistics Page (exception for that most diverse skillset line, it could be done, but not necessarily easily, that would actually be a pain) with just DG Scripts. I'm not exactly sure what all NIMScripts can do but if you can list a few things they can do (5-10) I can list which DG can and can't feasibly do.

[locke]

The Game Statistics had nothing to do with NiMScripts. In fact, it isn't possible to do that in NiMScripts without specific functions -- I was just sharing that you made a high score.



NiMScripts can:

-Appear on a prop, actor or scene, a player or be called as a spell or inside another script
-Be called in response to the following game events: SAY, "GIVEN"/"GETS", COMBAT ROUND START, ACTOR DEATH/OBJECT DESTROY, ACTOR BIRTH/OBJECT LOAD/ROOM RESET, SOMEONE ENTERS A SCENE, SOMEONE EXITS A SCENE, A COMMAND IS TYPED IN PROXIMITY TO ACTOR/SCENE/PROP, EACH TICK, EACH PULSE.
-Be installed by another script on an entity instance or player
-Be triggered by another script that has the owner as target
-Generate an updated display using an ASCII graphics renderer which includes line, circle, button etc
-Generate MXP and MSP
-Dispense objects, breed hirelings
-Be fed a special script type called a "Builder Script" which it uses to generate customized dynamically allocated areas
-Utilize special functions to be called as a SPELL

[Fizban]

The Game Statistics had nothing to do with NiMScripts. In fact, it isn't possible to do that in NiMScripts without specific functions -- I was just sharing that you made a high score.

DG I thought it only listed online players but realized this isn't the case, so DGcan not actually do this either, it could generate those stats among people currently online, but can not read from pfiles.

NiMScripts can:

-Appear on a prop, actor or scene, a player or be called as a spell or inside another script

DG Can be attached to rooms, objects, mobs, or players as of tbaMUD 3.58, the player part is a relatively new addition though

-Be called in response to the following game events: SAY, "GIVEN"/"GETS", COMBAT ROUND START, ACTOR DEATH/OBJECT DESTROY, ACTOR BIRTH/OBJECT LOAD/ROOM RESET, SOMEONE ENTERS A SCENE, SOMEONE EXITS A SCENE, A COMMAND IS TYPED IN PROXIMITY TO ACTOR/SCENE/PROP, EACH TICK, EACH PULSE.

Object scripts can be triggered when the object is picked up, dropped, given to another player, randomly every 13 seconds, a set amount of time after the object is loaded, when a specific command is typed by someone holding the item, with it in their inventory, or in the room with it (you can also decide in which of those stats a specific trigger will fire), when it is worn, or removed, or loaded, when a spell is cast upon it, when a player/mob leaves the room it is in, when it is opened/closed/locked/unlocked or when it is eaten.

Mobile/Player scripts can be triggered randomly every 13 seconds, when a specific command is typed by a player/mob in the same room, when a specific phrase is spoken, when a specific message is sent by act() to the room the mob is in (emotes/socials), when the mob dies, when a player enters or leaves the room with the mob, when the mob itself enters a room, when the mob is given an item, when it is fighting, when it's hp reaches a certain amount of its max, when it is given gold, when it is loaded, when a spell is cast upon it, when it sees a player who it has previously fought, when a door or container in the room with the mob is opened/closed/picked/locked, at a set time of day.

Room scripts can be triggered randomly every 13 seconds, by a specific command, by a specific phrase spoken, by a zone reset, by a player/mob entering the room, by an object being dropped in the room, by a spell being cast in the room, by someone leaving the room, by someone open/close/lock/unlocking something in the room, and at a specific time of day.

-Be installed by another script on an entity instance or player

DG Can do this.

-Be triggered by another script that has the owner as target

DG can't quite do this, but it can pass variables from one script on an entity to another script on the same entity

-Generate an updated display using an ASCII graphics renderer which includes line, circle, button etc

DG can not do this.
-Generate MXP and MSP

DG can not do this either.
-Dispense objects, breed hirelings

DG can do this
-Be fed a special script type called a "Builder Script" which it uses to generate customized dynamically allocated areas

DG can not do this, though exits can be created and removed via DG, but rooms can not be made, so DG can change the shape of an existing zone.

-Utilize special functions to be called as a SPELL

DG can do this by attaching a command script to the player

[locke]

NiMScripts can:

-Be called in response to the following game events: SAY, "GIVEN"/"GETS", COMBAT ROUND START, ACTOR DEATH/OBJECT DESTROY, ACTOR BIRTH/OBJECT LOAD/ROOM RESET, SOMEONE ENTERS A SCENE, SOMEONE EXITS A SCENE, A COMMAND IS TYPED IN PROXIMITY TO ACTOR/SCENE/PROP, EACH TICK, EACH PULSE.

DG Object scripts can be triggered when the object is picked up, dropped, given to another player, randomly every 13 seconds, a set amount of time after the object is loaded, when a specific command is typed by someone holding the item, with it in their inventory, or in the room with it (you can also decide in which of those stats a specific trigger will fire), when it is worn, or removed, or loaded, when a spell is cast upon it, when a player/mob leaves the room it is in, when it is opened/closed/locked/unlocked or when it is eaten.

---> NIMScripts command functions do not replace existing mud commands by default, a special call to "return(1)" alerts the MUD that it should not continue looking for other commands (command syntax properly entered, so stop here) -- if this is not used, the command executes and then the mud continues to the next command. So, in effect, you can override or augment standard commands like 'wear', 'lock', 'drop', 'get' etc by adding a command like this to a "prop" (similar to Diku "object") .. this can be done for rooms, objects or mobiles (actors,props,scenes) and therefore NiMUD can do all of the things listed as possible in DG scripts. Adding script_update() calls to the source in places listed above is also possible, but I have as yet to find a need for many of those.

-Generate an updated display using an ASCII graphics renderer which includes line, circle, button etc

DG can not do this.

---> NIMScripts interfaces with "NAGE", the NiMUD ASCII Graphics Engine. The "NAGE" functions are then tied into NiMScript functions. Since NAGE is modular, you could easily extract its functionality from NiMUD and wire it into DG Scripts, with the required attribution of course.

-Generate MXP and MSP

DG can not do this either.

---> It's probably the addition of only a few functions.

-Be fed a special script type called a "Builder Script" which it uses to generate customized dynamically allocated areas

DG can not do this, though exits can be created and removed via DG, but rooms can not be made, so DG can change the shape of an existing zone.

---> NiMScript have functions dig() and undig() to do this. In the build() processor, though, scripts can be written which generate player-owned facilities, complete with actors, props, scenes, cues and scripts. One early use of these scripts is a player castle which, when deployed, comes complete with random encounters.

-Utilize special functions to be called as a SPELL

DG can do this by attaching a command script to the player

---> NiMScripts must be written in a special way (utilizing magic-specific functions for mana drain and checks for special alchemical supplies or spell components), and are attached to spell objects edited in the "SPEDIT" (spell editor) which sets basic information about the spell (level, name, attached scripts).

You can also write skills using SKEDIT, and then check against them in a script function (as well as tie them to practitioners).

Advanced debugging features: a full screen live debugger, plus other script-related notifications using "NOTIFY" provide information about the script during execution.

[Fizban]

NIMScripts command functions do not replace existing mud commands by default, a special call to "return(1)" alerts the MUD that it should not continue looking for other commands (command syntax properly entered, so stop here) -- if this is not used, the command executes and then the mud continues to the next command. So, in effect, you can override or augment standard commands like 'wear', 'lock', 'drop', 'get' etc by adding a command like this to a "prop" (similar to Diku "object")

DG can do this as well. DG overrides the actual mudcommand by default, but can be set not to.

A few examples below:

Name: 'Look',
Trigger Intended Assignment: Rooms
Trigger Type: Command , Numeric Arg: 100, Arg list: look
Commands:
if !%arg%
  %send% %actor% Alas, it is too dark to see anything.
end

That script fires if they type look with no argument, ie. to look at the room. They would get that message in place of seeing the room as would usually occur.

Name: 'Look',
Trigger Intended Assignment: Rooms
Trigger Type: Command , Numeric Arg: 100, Arg list: *
Commands:
if %cmd.mudcommand% == look && !%arg%
  %send% %actor% Alas, it is too dark to see anything.
else
  return 0
end

This script is the same as the one before except it triggers when anything is typed by players in the room. (arg list of * does this). It then checks what they typed against the command interpreter and if it would be interpreted as 'look' the "if %cmd.mudcommand% == look" part of the first if check is true. As such this one fires when they type l, lo, loo, or look if all of those would make them look if the script wasn't there. The return 0 in the else tells the script to pass the players input to the MUD as if the script wasn't there so that it doesn't interfere with commands other than 'look'.

Name: 'Look',
Trigger Intended Assignment: Rooms
Trigger Type: Command , Numeric Arg: 100, Arg list: *
Commands:
return 0
if %cmd.mudcommand% == look && !%arg%
  %send% %actor% You notice a movement out of the corner of your eye.
end

This one sends the message in addition to showing them the room as usual due to the return 0 at the top passing the input to the command interpreter in addition to anything the script is doing.

Note: I'm not trying to one up NIMSCript, I'm really mostly comparing because it piques my interest as well, to the best of my knowledge DG was what I'd always considered to be, by far, the most advanced scripting used in any DIKU derived codebase that wasn't just an existing language embedded into the MUD. (ie, I'm not comparing it non mud-specific languages like lua which can be embedded.)

[locke]

Name: 'Look',
Trigger Intended Assignment: Rooms
Trigger Type: Command , Numeric Arg: 100, Arg list: *
Commands:
return 0
if %cmd.mudcommand% == look && !%arg%
  %send% %actor% You notice a movement out of the corner of your eye.
end

This one sends the message in addition to showing them the room as usual due to the return 0 at the top passing the input to the command interpreter in addition to anything the script is doing.

Note: I'm not trying to one up NIMSCript, I'm really mostly comparing because it piques my interest as well, to the best of my knowledge DG was what I'd always considered to be, by far, the most advanced scripting used in any DIKU derived codebase that wasn't just an existing language embedded into the MUD. (ie, I'm not comparing it non mud-specific languages like lua which can be embedded.)[/quote]


Is it mere coincidence that both languages use %variable% syntax? Probably not. NiMScripts have been made available as early as December 1993, so it's likely that parts of NiM's interpreter ended up as DG Scripts.

Here's an example of the mining script:

Vnum:  [ 3506]  Name:  [mine]
Type:  [    0]         [COMMAND (When a command is typed.)]
Script:
if ( pre(%astr%,{mine}), { goto({mine}) }, { goto({end}); } );
label(mine);
 return(1);
 %minehere% is(sector(here()),4);
 if ( %minehere%, {}, { goto({nothere}); } );
 if ( skill(%actor%,{mining},{0}), { goto({success}); }, { goto({fail}); } );

label(success);
 echo(%actor%,{You throw the pick against earth.});
 oecho(%actor%,{%name% throws a pick against the earth and a few bits of debris scatter around.});
 wait(20);
 echo(%actor%,{You rummage through the debris and pick up anything of value.});
 if ( check(10),  { goto({gem}); } );
 if ( check(35), { goto({gold}); } );
 echo(%actor%, {You find nothing useful in the debris.});
 goto({end});

label(gold);
 dispense(%actor%,{17040});
 echo(%actor%,{You find a hunk of gold!});
 goto({end});

label(gem);
 dispense(%actor%,{50});
 echo(%actor%,{You find a gem!});
 goto({end});

label(nothere);
 echo(%actor%,{You cannot mine here.});
 goto({end});

label(fail);
 echo(%actor%,{You miss and nearly strike your foot!});
 goto({end});

label(end);

MUSHes are still easier to write code for, somewhat, because all objects in a MUSH are essentiall the same type. The split between actor/prop/scene is difficult to manage from the hardcode side because of the multiple types distinction on entities. It would probably take a week to fix this, with a lot of unknown consequences.

Here is an example of the script used to manage a pirate ship adventure:

Vnum:  [ 6211]  Name:  [aelmon-shipmate]
Type:  [    1]         [EACH_PULSE (Each pulse.)]
Script:
label(start);
%state% {pending};
if ( not(random(0,20)), {goto(boarding);});
if ( not(random(0,20)), {goto(fishing);});
if ( not(random(0,20)), {goto(storm);});
if ( not(random(0,20)), {goto(return)});
wait(6);

label(boarding);
%state% {boarding};
wait(101);
do({shout Merchant ship, ahoy!  All hands on deck!});
reset(6215);
reset(6216);
reset(6217);
wait(30);
dig(6210,{east},6215);
do({shout Plank is lowered, board the enemy ship!});
wait(1002);
do({shout all aboard the Aelmon, we set sail soon!});
wait(103);
do({shout Plank is raised, anchor's away!});
undig(6210,{east});
wait(100);
goto(start);

label(fishing);
%state% {fishing};
wait(10);
do({:baits his hook.});
wait(10);
do({:fishes over the side.});
wait(random(50,150));
do({:catches a fish and reels it in!});
do({at 20 oload 6209});
wait(10);
do({drop fish});
wait(10);
if(random(0,1),{goto(start);},{goto(fishing);});

label(return);
%state% {returning};
wait(40);
do({shout Land ho! Starboard!});
wait(15);
recho(6210,{The ship floats safely into the Marina.});
recho(6211,{The ship floats safely into the Marina.});
recho(6212,{The ship floats safely into the Marina.});
recho(6213,{The ship floats safely into the Marina.});
wait(20);
do({shout Drop anchor!});
wait(30);
do({shout We have returned to port!});
moveall(6211,6200,{look});
moveall(6212,6200,{look});
moveall(6213,6200,{look});
moveall(6210,6200,{look});
goto(start);

label(landfall);
wait(10);
do({shout Storm!});
wait(50);
recho(6210,{Wind buffets the ship; you hear the mast break!});
recho(6211,{Wind buffets the ship; you hear the mast break!});
recho(6212,{Wind buffets the ship; you hear the mast break!});
recho(6213,{Wind buffets the ship; you hear the mast break!});
wait(50);
do({shout All hands abandon ship!});
recho(6210,{The boat begins to capsize!});
recho(6211,{The boat begins to capsize!});
recho(6212,{The boat begins to capsize!});
recho(6213,{The boat begins to capsize!});
wait(50);
do({shout Abandon ship!});
moveall(6210,6218,{look});
moveall(6211,6218,{look});
moveall(6212,6218,{look});
moveall(6213,6218,{look});
wait(100);

label(storm);
%state% {storm};
if ( cmp(weather(),3),
     { goto(landfall); } );
if ( cmp(weather(),2),
     {  do({shout Batten down the hatches!  Lower the misenmast!});
        wait(100);  } );
goto(start);

The adventure begins when the player boards the ship. The player is then subject to the changes in the ship's state as set by the above script on a shipmate actor. The script digs an exit to a merchant vessel area with aggressive mobs during one of its random events. In another case, the player is transported to a lifeboat during a storm because the ship has wrecked. Several ancillary scripts are used: one to transport the player to the vessel Aelmon in the first place, another to manage the adventure from inside the Aelmon, and a script for effect during combat on the neighboring vessel, and a fourth script to handle the storm event once the player has been placed on the life boat.

[KaVir]

Originally Posted by locke Is it mere coincidence that both languages use %variable% syntax? Probably not. NiMScripts have been made available as early as 1995, so it's likely that parts of NiM's interpreter ended up as DG Scripts.

DG Scripts come from Death's Gate MUD, which was written from 1993 to 1994, and therefore predates NiMScripts. However NiMUD is based on Merc 2.2 (released in October 1993), which comes with a modified version of the scripting system developed by Worlds of Carnage in 1992, so it could be that they were both inspired by the same system. This would make sense, as Worlds of Carnage was the first Diku with embedded scripting. Did you remove the scripting system from Merc 2.2 before adding your own, or did you modify it into the NiMScripts?

I'm not sure if it's really a "revolutionary new OLC and scripting" if it's been around for 14 years though....

[Fizban]

Originally Posted by KaVir DG Scripts come from Death's Gate MUD, which was written from 1993 to 1994, and therefore predates NiMScripts. However NiMUD is based on Merc 2.2 (released in October 1993), which comes with a modified version of the scripting system developed by Worlds of Carnage in 1992, so it could be that they were both inspired by the same system. This would make sense, as Worlds of Carnage was the first Diku with embedded scripting. Did you remove the scripting system from Merc 2.2 before adding your own, or did you modify it into the NiMScripts? I'm not sure if it's really a "revolutionary new OLC and scripting" if it's been around for 14 years though....

The World's of Carnage inspiration is a possibility I suppose, but Death's Gate was a CircleMUD and not a Merc derivative.



And Locke, do not let me catch you editing Wikipedia again to add this:

DG Scripts is based on the idea of the 'trigger' - a small program (script) which is called (run) as a consequence of a certain action, much like the earlier NiMScripts which shipped with NiMUD.

It has been removed, and if said false information is added back I will be very annoyed. I suppose I can't prove it's you, but here's the revision information from wikipedia of it being added less than two weeks ago:

This is an old revision of this page, as edited by 98.111.199.226 (talk) at 17:36, 4 March 2009. It may differ significantly from the current revision.

I'd bet money that 98.111.199.226 is your current IP or was as of two weeks ago. EDIT: (I traced the IP, it's in Pennsylvania, anyone know if that is where Locke lives?)
In fact do me a larger favor. Stop editing any and all MUD related wikipedia pages to make references to NiMUD. NiMUD's page was deleted some time ago due to being voted to be of little consequence, relatively unknown, and to have few MUDs running it. Since then you seem to have tried editing almost every other DIKU codebase's page in existence to add mention of NiMUD to it. Why do you bother? I'm guessing vanity, and that hopefully if it is mentioned on enough other pages you will have an easier time making the claim that it is of enough consequence to deserve its own page once again. Frankly I don't care for the reason, I do not want to see NiMUD referenced as being an inspiration for CircleMUD or DG Scripts when it was pre-dated by both.

[locke]

Originally Posted by KaVir DG Scripts come from Death's Gate MUD, which was written from 1993 to 1994, and therefore predates NiMScripts. However NiMUD is based on Merc 2.2 (released in October 1993), which comes with a modified version of the scripting system developed by Worlds of Carnage in 1992, so it could be that they were both inspired by the same system. This would make sense, as Worlds of Carnage was the first Diku with embedded scripting. Did you remove the scripting system from Merc 2.2 before adding your own, or did you modify it into the NiMScripts? I'm not sure if it's really a "revolutionary new OLC and scripting" if it's been around for 14 years though....

Well, early versions of The Isles had the original interpreter. Those versions were released in late 1993. I didn't have an account at any ISPs or Universities at the time, so I used Don Jone's account, and several others. Later, I fixed a major memory leak which made the language usable in 1996. I took a hiatus from coding in late 1997 which lasted until 2000. I then took another break until 2003. In 2003 I fixed a long time issue which opened the language up to a stable base of functions. It took three days to find it.

At the time the only other system available for Merc and that I was aware of aside from MUSHcode was MobProgs.

I based the %-% variable method from MS-DOS Batch File language. Since I was at the time developing The Isles using the DJGPP Compiler, and it seemed like something easy to implement. I've since then learned a lot more about programming and my experience has become quite vast. I can see where I could write a better language in retrospect, but don't really see a reason to because writing the software is not profitable for me. I'm also displeased with its illegal sale by Owen Emlen, so my days in MUD development are pretty numbered.

Considering many of the advanced features were only recently programmed, and since this thread proves its superior feature set, I would say "revolutionary" and "new" are fine adjectives. Additional evidence to back this up is in the 80 or so downloads since January, proving the software is still a cult classic.

Fizban,
As for your unfounded claims versus me on Wikipedia, you might want to consider that I have an avid fanbase, many of which do actively use other websites and it is very possible that discussions on my MUD may have lead to others erroneously making claims on other websites.

Regards,
Locke

[locke]

Originally Posted by Fizban The World's of Carnage inspiration is a possibility I suppose, but Death's Gate was a CircleMUD and not a Merc derivative. I'd bet money that 98.111.199.226 is your current IP or was as of two weeks ago. EDIT: (I traced the IP, it's in Pennsylvania, anyone know if that is where Locke lives?) In fact do me a larger favor. Stop editing any and all MUD related wikipedia pages to make references to NiMUD. NiMUD's page was deleted some time ago due to being voted to be of little consequence, relatively unknown, and to have few MUDs running it. Since then you seem to have tried editing almost every other DIKU codebase's page in existence to add mention of NiMUD to it. Why do you bother? I'm guessing vanity, and that hopefully if it is mentioned on enough other pages you will have an easier time making the claim that it is of enough consequence to deserve its own page once again. Frankly I don't care for the reason, I do not want to see NiMUD referenced as being an inspiration for CircleMUD or DG Scripts when it was pre-dated by both.

Actually, it's because you're obscuring the truth and lying about my software, along with many others, who share a group delusion. You think you're "defending the truth", but you're really "ganging up on the truthsayer".

These letters prove the circulation of NiMUD as early as October. I had already uploaded this information to several MUD archival sites, including wuarchive, and other defunct FTP directories services.

Bull**** your way out of believing it all you want, but I speak the truth when I talk about the 3Q-4Q of 1993.


NIMUD. - rec.games.mud.diku | Google Groups
CthulhuMUD (kuh-tool-loo) - rec.games.mud.diku | Google Groups <- October, at least 1 month after it was released to several FTP sites and announced privately on MUD bboards such as at Hidden Worlds MU*

[Fizban]

Originally Posted by locke Actually, it's because you're obscuring the truth and lying about my software.

I'm making no claims about your software. I stated DG was not in anyway derived from it, but I didn't state that yours was derived from DG either. I did though in fact state that I would appreciate you keeping the DG Scripts Wikipedia Page free of all references to NIMScript. As to whether or not you actually made the change yourself I can't prove as I do not know your IP nor where you live. What I do know is that whoever made the changes does live in Pennsylvania. I also know that Thomas Arp aka. Welcor wrote most of the DG Scripts language and that it was not derived from NIMScripts. I also know that KaVir has deleted references to NiMud in the past from the GodWars Wikipedia Page so that whoever is adding references to NiMUD to one of the pages is likely the same person who has added them to all of them in the past. I also know the change was added to the DG Scripts page just shy of two weeks ago which was around the same time that you recently began posting on TMC again.

Summary for those with tl;dr syndrome: I make no claims about the history of NiMScript, but I will vehemently deny any claim that DG is a derivative of said language as I have never heard of NiMScript till recently and have worked with Thomas Arp on TBA for five years and know that 99%+ of what is today known as DG Scripts was written by him or was in the initial release by the DG Staff when they released it. (ie. he coded the majority of the differenced between what it was then and is today, not that he coded the initial language that was used on Death's Gate)

[locke]

How CthulhuMUD became NiMUD aka The Isles, see r.g.m.d links in this thread.

[locke]

Originally Posted by Fizban I'm making no claims about your software. I stated DG was not in anyway derived from it, but I didn't state that yours was derived from DG either. I did though in fact state that I would appreciate you keeping the DG Scripts Wikipedia Page free of all references to NIMScript. As to whether or not you actually made the change yourself I can't prove as I do not know your IP nor where you live. What I do know is that whoever made the changes does live in Pennsylvania. I also know that Thomas Arp aka. Welcor wrote most of the DG Scripts language and that it was not derived from NIMScripts. I also know that KaVir has deleted references to NiMud in the past from the GodWars Wikipedia Page so that whoever is adding references to NiMUD to one of the pages is likely the same person who has added them to all of them in the past. I also know the change was added to the DG Scripts page just shy of two weeks ago which was around the same time that you recently began posting on TMC again. Summary for those with tl;dr syndrome: I make no claims about the history of NiMScript, but I will vehemently deny any claim that DG is a derivative of said language as I have never heard of NiMScript till recently and have worked with Thomas Arp on TBA for five years and know that 99%+ of what is today known as DG Scripts was written by him or was in the initial release by the DG Staff when they released it. (ie. he coded the majority of the differenced between what it was then and is today, not that he coded the initial language that was used on Death's Gate)

I would say the languages are not similar aside from the use of %<somevar>%, and possibly function calls which look like LPC anyway. I only recently named them NIMScripts (2003) -- before that they were referred to as "NiMUD's scripting language" or "NIM script interpreter". It's been a part of The Isles since 1994, but I wanted to wait to release it and now that some time has passed it is time to! I believe I even wrote a "how to" guide a few years back on installing them in other DIKUs. It's no easy chore though.

[KaVir]

Originally Posted by locke The Isles - rec.games.mud.diku | Google Groups <- The Isles first emerges, July 30, 1993

That post is dated 31 July 1994. As I mentioned previously, Merc 2.2 (which TheIsles is based on) wasn't released until October 1993.