Developer Primer

From LSWiki

This page is documentation for new developers. If you edit this page please try to keep it to a minimum. Insofar as is possible it should not be overwhelming. These are the bare essentials needed to do two main things: (1) get comfortable as a developer--there are a lot of new commands and possibilities that should be learned right at the start, and (2) to get up and running development-wise, i.e. to start looking at examples of code and manipulating ones own objects. Advice on thematic/conceptual considerations, specific coding dos-and-don'ts, rules and expected behavior--all that should go elsewhere.

Some of this material may be old hat for those who have past experience with command line interfaces, FTP, or coding. If you haven't, going through this material may take some time. Please be patient. If you remain active-minded, all of this will become far less mysterious the more you dev, I promise.

Contents 1 A Few Necessities 2 The File Structure and the Command Line 3 Other Commands 4 FTP 5 Coding 6 Further Reading

A Few Necessities

• First and foremost, the developer channel is "dev".

• If you get zapped by a dev--a likely fate for new developers--or whatever, just "heal me" to heal yourself.

• To move yourself somewhere quiet, "goto" a person, preferably a dev in a non-player room. E.g. "goto chaos".

• There are several commands that let you review changes to the MUD that are important and that you get in the habit of using immediately. These are "change", "promotions", and "privs". You should probably

set alias since to change since;promotions since;privs since

and be in the habit of doing that at least once per login. (The first time you do this you will probably be spammed, as it will give you the entire changelog; don't feel obligated to read through it all.) You can also use these commands with other arguments, such as "change 1" to see the most recent change ("help change" for the full range of possibilities).

With that being said, its time to familiar yourself with the structural backbone of Lost Souls.

The File Structure and the Command Line

If you're familiar with command line interfaces (CLIs), this will be old hat. If not, it may take some getting used to. This document will at least assume you are familiar with directory trees, i.e. that you know at least what the various components of "C:\windows\system" designate. If you don't and you can't figure it out, then, I'm sorry to say, you just need to learn more about computers in general before you start coding for Lost Souls.

• Your home directory--where you can directly upload and download files from via FTP (see below)--is /w/devname. So for me, Twilight, my home directory would be /w/twilight.

• The cd command stands for "change directory", and is used to navigate from one folder to another. When used by itself, without any other arguments, it moves you to your home directory. "cd .." will move up one directory and is used to predicate relative movement within a file structure (e.g. "cd ../etc" will move you from "/w/twilight/Hanoma/dmn" to /w/twilight/Hanoma/etc"). "cd /" will move to the root directory and is used to predicate absolute movement (e.g. "cd /w/twilight/Hanoma/etc" will move you there no matter where you are).

• ls lists the contents of a directory. By default it lists them in a little table consisting of only file names in various colors (what the colors designate will become apparent to you over time). "ls" also takes arguments to display hidden files, or to display files in a verbose format that indicates their size and when they were last modified. "help ls" for more.

• pwd stands for "print working directory", and will print the directory that you are currently in. This is useful if you don't remember where you are and don't want to get a file listing, either because its too long (like /obj/magic/rings) or uninformative (like a project daemon directory, which mostly look the same).

• cp and mv respectively copy and move files. To rename a file you use mv within a directory ("mv workroom.c workroom.c.old" renames the former file to the latter).

• rm deletes files. The files will be moved to /tmp/.removed/ for a short time, or until they are ovewritten by you deleting a file with an identical name. Note in this regard that deleting a file is actually less hazardous than overwriting one with a bad "cp" or "mv" command. Try not to do that, it sucks.

• If you have the privileges to write in a directory, you can use mkdir to make a new directory.

• Last but certainly not least, more will display the contents of a file.

Try moving around some, seeing what files are there, and reading some files. Don't worry if you don't understand them. "cd /pub/fun" might be an entertaining place to start. Also, within your home directory, trying making and removing some directories, copying them, etc. If you have any files there, move them around some too. If you don't, try it after you've read the FTP section and put some there.

After you've mastered this you should be fairly well-equipped to traverse any *NIX CLI, so rejoice.

Other Commands

There are a huge number of commands available to you as a developer. First there are more settings than there were when you were a player, type "help set" and "help show" to see them. Particularly useful is "help set notify". I'd recommend turning most or all of your notifications on. Also useful is "help start crashing". I'd "start crashing on all" for starters. (Many developers also "start being unlisted on all" as well.) You should "switch omniscience" until it's on, so you don't have to identify people and items. Also: "people" is much more informative than "who".

There is also the useful "show administrative commands" file. Each of those commands has a help file for it. Don't worry if you don't understand what many of them do; just skim through it occasionally, and as you develop more and more, you'll learn the various commands.

FTP

clients, info

Coding

objects, evals, man

Further Reading

After you get familiar with being a developer and what possibilities are open to you, you should read "man developers". Reading it beforehand will probably just be confusing, but it contains the rules and guidelines and behaviors expected of you as a developer.

While you will learn coding primarily by example, there are some very bad examples of code out there, and it can be hard to tell what is what. To innoculate yourself from the worst aspects of this, read "man style" for our standard coding styles. Some of this may be hard to understand at first, so you'll probably want to check back after you've learned some more code.

You should familiarize yourself with some of the log files in /txt/log. Also note that you can use the "log" command to return the tail end of any file in that directory. For example, "log lpmud.log" will return the newest portion of the error log. This is a particularly useful logfile, as is the "Eval" log.

Another very important thing you'll need to learn how to use is the "grep" command. In its simplest cases, the ones you'll use most frequently, grep is fairly easy, so get started reading the help files on it and using it to find simple patterns in documents.