MUF Repository - Help

Current Directory: [root]/help

The purpose of this project is to provide a single location to act as an automated repository for MUF coders to store their work without having to maintain their own website, or go through the trouble of submitting new programs and code updates through someone else who maintains a site. Version control is enforced, as all older versions of a program will still be downloadable. It is an ongoing project that will continue to grow with time.

Once you have an account, you are free to add/update your programs in your account as you please. There is no limit on the number of programs you can add to your directory, but individual MUF files may not exceed 200k in size. If your program is bigger than that, consider breaking it into decent sized parts instead.

The idea is to facilitate the development and distribution of your own programs. When it comes to other people's code in the repository, you must follow the Program Ownership guidelines or face being removed from the project.

1. If you are the sole author of a program, you may freely submit your program to your directory and update it as you please.


2. If you are working on a program as a joint effort with one or more other coders, you must agree amongst yourselves in whose directory the program is to be maintained in. Don't go adding the same program to a bunch of different directories.


3. If you fix or update a program written by another author, you must turn your bug fixes/updates over to that author if that author is still actively maintaining their programs. Leave them p #mail on the MUCK or send them email if they have it in the header.


4. If the original author does not reply after two weeks, or the original author has made prior announcements to the effect that they are no longer maintaining that piece of code, or MUF code in general, then you may add the updated version of that program to your directory instead. Be sure to document that efforts were made to contact the original author before you added the program to your directory.


5. Programs that staff has selected as Public Domain are older programs that have been distributed for years without changes or updates even though there may be a name attached to them. If you find a program of yours in Public Domain and would prefer that they not be provided there, simply contact a member of the staff to have them removed.

1. Every program must contain a $author directive as the first line of code following the header.
   The $author directive may contain more than one author, but the first author in the list must match the name of the programmer submitting the program or update. This will be necessary for the MUCK update client/server support to be implemented in the near future.


2. Every program must contain a $version directive as the next line of code after the $author directive.
   The version number can be any valid integer or floating point value. The only requirement is that each version must go up in number from the prior version. In other words, if there is a version 3.7 of that program in your directory, the next version must be a number higher than 3.7. (3.71, 3.8, 4.0, etc. would all be valid). One can use $lib-version in place of $version if they would like, the updator will only look at whichever it encounters first.

Types are an indication of how the program is to be called most of the time while it is in the MUCK. There are no strict definitions of the types, though some good examples to follow have been provided. Below are some types staff recommends for consistency, though they are not going to be enforced at all. You can create your own types if you want. If you fail to include the .muf extension, it will be automatically added for you.

• aut = AUTOSTART programs. Programs thar are usually run when the MUCK starts and left alone afterwards.


• cmd = Programs that are normally run by @linking an action to them. Globals tend to fall into this category. (Page, say, etc.)


• con = Environment programs that are specific to the _connect/ propqueue. This type was used in the past for con-announce and a couple other programs, but really should be deprecated now. Use 'env' or 'que' instead.


• cron = Programs called from the cron_prog @tune.


• def = Programs that are definitions for other programs. These are really just 'libs' that contain only one function. The only two I'm aware of are 'def-pmatch' and 'def-sort', both of which are deprecated by prims now days.


• env = Environment programs. These tend to be called from propqueues. These may also be called 'que' in place of 'env'.


• gen = General use programs. These tend to be things that the general userbase interacts on a more local level. Things like games or MUF toys should be 'gen'.


• lib = Library programs. These are programs that are usually not called directly, but used frequently via the CALL prim by other MUF programs.


• mpi = Programs that are meant to be mostly called from the {muf:} MPI function should be this type.


• mud = MUF programs used to create MUD-like environments.


• muf = Programs that edit other MUF programs. A soft coded MUF editor, for example, and pretty much all of the repository-specific code fall into this type


• net = Network programs, such as the eventual ProtoNet code. Almost all programs that use MUF sockets could be placed in this category.


• sql = SQL specific programs.


• vehicle = Programs specific to working with vehicles. Distinguished only because there are so many that they form a type all by themselves.


• web = Programs called by the webserver, i.e., MUF-CGI.

Many programs will fit into more than one type, so it's generally a good idea to just pick the one that you think best describes the main use of the program.

It is important to keep in mind that once a version of your program is submitted, you will not be able to remove/edit it any further, but instead will be required to submit new versions with any other revisions you make. Therefore, it is important that you are careful during the submission process to follow all the steps correctly.
If, however, you make a particularly bad mistake in submitting a program or an upgrade, you may contact staff for assistence by leaving a p #mail with them indicating the problem you experienced. The staff response to almost any problem with program submissions will be to remove the version that you had the problem with, along with any change or version notes regarding it, giving you the chance to resubmit it cleanly.
You can update the various information fields without having to submit a new version, however. Simply use the Update Program form, and enter the new information you want for the Install Steps, Prerequisites, Platforms, or Description, and submit the update without putting anything in the Program Code field. This will update the information fields for your program without generating a new version of that program.

Each author will have their own personal BBoard board on the MUCK site. These will be available to be updated via the web (not implemented yet) for the reporting of bugs or feature requests for their programs. Alternatively, if you have an account on the MUCK, you can leave p #mail with the author.

• Programmer: Your account name (case insensitive)
• Password: Your password (case sensitive)
• Program Name: The name of the program. If using the New Program form, this will be the name of the new program added to your directory. If you are using the Update Program form, this name must match the name of a program already in your directory.
• Platforms Supported: Enter a list of platforms your MUF program should be able to run on. It doesn't need to be comprehensive, but it's good to be accurate. Platforms should be listed the way they show up in @version, though no format is enforced at this time.
• Program description or changelog: If using the New Program form, this field is the description of the program that will go at the top of that program's information page. If using the Update Form, and you include code in the Program Code field, then this box is for the change notes to indicate what is different from the version before. If you do not include code in the Program Code field, then this box can be used to update the description of the program.
• Prerequisites Field: This box is where you can put a list of things that the programmer will also require in order to compile or run your program. Things such as global _defs/, macros, and $included libraries should all be listed here. There is not a specific format required here, but you should probably put one requirement to a line for easier reading.
• Install Steps: This field is where you can put all the steps you want at the end of the install script. Lines such as '@set program=LINK_OK' or '@propset #0=dbref:_connect/prog:program', @registering the program, etc. They are reprinted, exactly as you enter them, at the end of the Install Script link for your program.
• Program Code: This field is where you paste in your program code exactly as it should be entered in the MUF compilier. When a user selects the View Code link on the program's page, they will be presented with exactly what you enter in this field.

To get an account, simply send an email to nakoruru08@hotmail.com with your desired user name. You will get an email back indicating that your account has been made and be given your password and where to log in to.

At this time, the MUF code running the repository is not available for distribution. I may or may not allow it to be downloaded in the future, but please don't ask for it. Questions about design and implementation of the repository are welcome by those interested in knowing how to program something like this, on the other hand.