# Softcode

Softcode is the domain of using softcode functions and softcode commands provided by the server's hardcode for building or globals commands. Input from players may match exit names, global commands written in softcode, or built-in softcode commands provided by the server itself.

Softcode is stored in attributes on objects like other data, and is interpreted through various mechanisms by the parser. It is not compiled or stored/installed into the game's directory on the host, as is sometimes the case with MUD codebases.

Additional complications for softcode are the various permissions, locks, and configuration options which affect who can do what and how far away. Also, it is useful to have a firm grasp on the behavior of the command queue and semaphores.

## Contents

## Example

Someone asks you to write a command to calculate the square root of a given number. With the following, we create a separate object called *MyCode*, and then set an attribute on it called *SQRT.CMD*.

`@create MyCode``&sqrt.cmd MyCode=$sqrt *:@pemit %#=The square root of %0 is [sqrt(%0)].`

The name of the attribute is arbitrary, but attribute name appears after the ampersand. The name of the object comes next followed by the equal sign and the attribute value. The value of the attribute is also arbitrary. The server will simply save the value for you until you specifically delete it or @destroy the MyCode object. Since we are softcoding a new command, there is a specific format in order for the server to recognize the attribute value as a $-command.

$-Commands always start with a *$* in the first position. This is a requirement. Between the *$* and the *:*, is the pattern of the command. In this case, the command is *sqrt **. The *** will match any characters which following *sqrt *. This first wildcard becomes argument *%0*.

The @pemit command takes a message and a destination. In this case, the *%#* refers to the object who ran the command (i.e., the enactor. We do this so that anyone and everyone can run the command at the same time, and all the answers go the right player.

The message is evaluated, and as you might expect by now, there are rules for that. Substitutions are performed first. Snippets of softcode functions are usually placed between square brackets, but depending on the circumstances, this is not always necessary. Sqrt() takes one argument.

With this, you can now do the following:

`sqrt 2``The square root of 2 is 1.4142135623730951.`

This seems like exactly what you were asked to do, but there are problems. Look at this:

`sqrt -10``The square root of -10 is Ind.`

And, this:

`sqrt ABC``The square root of ABC is 0.`

Further work is potentially needed to validate user input and do something reasonable.

This square root exercise is useful because it offers the opportunity to demonstrate exactly what softcode is most of the time. It also demonstrates the ambiguous lingo that is sometimes necessary. You have created a square root *command*, and yet square root is a mathematical function defined over the range of real numbers greater than or equal to zero.

Sqrt() is also a built-in softcode function provided by the hardcode for use by the softcode. What is the mechanism that it used to provide this? It's provided by a C++ function in the hardcode called fun_sqrt(). Even though it looks the same as a softcode function, we are now at a level below where softcode lives.

Inside fun_sqrt(), there are code to convert C strings to doubles and back, certain protections against attempting to take a square root of a negative number for platforms which do not support IEEE floating-point numbers. This hardcode function inside TinyMUX calls a C/C++ Standard Math Library function called sqrt() strangely. This C++ function opens up yet another level of square-rootness. On a Unix system you can use *man 3 sqrt* to get the details.

Finally, on Intel x86 and compatible platforms, the sqrt() library function probably uses a FSQRT instruction. This lowest level is called hardware. The Standard C/C++ Math Library is above that. The TinyMUX hardcode is above that. The SQRT() softcode function is an interface above that that the hardcode provides and softcode uses.

## Softcode Packages / Respositories

Much of the softcode used on a game is generally written by the developers of that game for their use. However, there is a big call in the community for reusable softcode (globals packages, chargen/skills systems, dice rolling code, multidescers, etc). There are some websites that provide archives of such code, although it is hit or miss what you'll find.

Additionally, several softcode packages that implement either a specific system or a group of common commands are available. Here are some examples:

### SGP globals

One of the most commonly available and used prefab 'globals' packages is the SGP globals package (SGP stands for the Sandbox Globals Project). This package includes common softcode commands such as +who and +where, includes 'places' code, and various others.

### Myrddin's Bulletin Board System

The most common softcode package ever, Myrddin's Bulletin Board borders on the ubiquitous. Many games that use alternate bboards have interfaces that mimic or duplicate the commands from this bboard package.

### Anomaly Jobs

Anomaly Jobs is a task management system that is gaining in popularity.