OGR - Saturday, November 18, 2000, 12:01 PM
-----------------------------------------------------------------------

*Post-Class Note #1: My original intention for this class was to clone the Armoire for each person that attended the class, so that they could get the output, examine the attributes and do their own modifications to them. This was particularly important for the puppet output section discussed later. Given that those that showed up were there only to listen and log, not to participate, this method was not put into practice. Perhaps in a future class.

*Post-Class Note #2: For the purposes of this log, I will show the commands I typed before the output statements. Commands will be prefaced with >> to designate their difference from says and poses, and from the code's output*

Moses says "Okay, this is the third installment in the +wear series of classes. The point of this class is going to be discussing debugging and documentation of code. The class is being logged for posting to the webpage, so if you don't want comments of your in the log, speak now."

Moses says "In previous classes, the goal was to approach the coding of a full system, from start to finish."

Moses says "This process, of debugging and documenting, is essentially the last stage. It ties up all the loose ends of what you have been working on, and endeavours to make your system intelligible to the average user."

Moses points to the Armoire. "THis is the object that was used in the last class for demonstration purposes. I put a fair amount of code on here, and it is all untested code. This was done deliberately."

Moses also notes, as far as procedure goes, you can interrupt me at any point. I'm pedantic, wordy, and write big paragraphs when explaining things. Please, feel free to stop me if I gloss over something you need/want to know.

Moses says "A note about the object here, the Armoire. There are two different methods for doing things on this object. Two different 'styles' of coding, if you want to look at it that way. I did one method that relies heavily on functions to do the work of the +wear system, and one method that uses commands to do the work."

Moses says "Those attributes named fn-* are the ones for the function-dependent system, and those attributes named do-* are for the commands style."

Moses says "cmd-wear1 is the main command for the first style, and cmd-wear2 isthe command for the latter."

Moses says "Would either of you like me to give a brief summary of what the system does, which directions the code goes, etc? Or would you rather I plunge into the debugging?"

Moses drops a pin. (bowling)

***Class Note: Five full minutes of silence at this point.

Moses checks pulses.

Noltar dives to catch it, smashing his hand but prevents any sound from occuring.

Moses whews. :)

Noltar says "Sorry, I was expecting a larger crowd and just wanted to listen, RPing elsemu*"

Noltar says "What was the system intended to do?"

Moses ahhs, understanding. yes, I wanted a larger crowd too, but my crappy second box died, so I didn't get to have it at the regular time.//The system provides a multidescer for your character, giving two 'sections' of your desc that you can mix and match.

Noltar says "Ahh. What I know of as a +wardrobe system. :)"

Moses nods. +wear, multidescer, wardrobe, clothes chest...I've seen about eleven different varieties.

Noltar grins

Noltar says "May I ask why limit it to just 2 sections?"

Moses says "For the purposes of this class."

Moses says "It was easier to explain and demonstrate with just two sections."

Moses would normally recommend at least 3, with 5 being my preference.

Moses says "The two sections we outlined here were a 'base' section, that was intended to contain your general physical appearance at the time. And a 'clothes' section, that..surprisingly, would contain a description of your clothing."

Moses says "We decided to give the system the capability to list, add, delete, clear, preview, and put-on your different description elements."

Moses says "We broke it down into two commands. +wear/list and a larger command setup as +wear/* *"

Moses says "So, what I'm going to do now is enter in a few temporary desc elements, into the Armoire's system, and then test each of the commands, using these temp elements."

Moses is also going to use the 'putting in' of the temp elements as a method of testing both commands.

Moses says "So, the format for adding is +wear/newbase <name>=<text> or +wear/newclothes <name>=<text>."

Moses will use the function-dependent command to add a new base description, and the command-dependent +wear command to put in some new clothes descriptions.

>>+wear1/newbase base2=This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency.

I'm sorry. You must specify either base or clothes for a new description element.

Moses says "So, I typed: +wear1/newbase base2=This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency.

And I got the error message: I'm sorry. You must specify either base or clothes for a new description element." Moses says "So, this is a bug, right off. In this situation, what I am going to do now is try to put it in using the +wear2 command, which is the command-dependent style of coding."

>>+wear2/newbase base2=This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency.

I'm sorry. That isn't a valid command.

Moses says "And, then I realize what I'm doing wrong. It should be new-base or new-clothes. I forgot to put the hyphen in. Pitfall of not having worked extensively with this code for two weeks."

>>+wear1/new-base base2=This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency.

Your new base description, named 'base2' is set as:
This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency.

>>+wear/list

=-----------------------------------+Wear-----------------------------------=
Basic Descriptions:
BASE1 BASE2
Clothes Descriptions:

Type '+wear/preview <type>=<name> to see one of these.

Noltar nods as he reads everything :)

Moses says "Okay, so when I went back and typed it as +wear1/new-base base2=<text>, it worked fine, and added the description. It showed me the evaluated version of what I had typed, which is important if you are trying to embed ansi or formatting characters(%R,%t,%b) in your text."

Noltar nods

Noltar says "This is just a personal system right, not a global +wear command for mushwide use?"

Moses says "For the purposes of this class, it is only a personal system, with some global issues addressed."

Moses says "But, designed for personal use, yes."

>>+wear2/preview base=base2

I'm sorry. That isn't a valid command.

Moses says "Okay, now that I have put the base desc in, ideally we like to go back and test the preview option, just to see how our code works, in retrieving the individual elements for display. We want to make sure it parses the attribute name correctly, is looking in the right place, and will display what you want it to."

Moses says "As came up in the last class, I forgot to code in a preview option for the +wear2 command, which is the command-dependent version. So, in the debugging process, this functionality would have to be added in order to have a fully-working system. However, I did code it into the +wear1 version of the system(the function-dependent one), and so I'll use that to test, rather than doing the code for the preview option of +wear2 now."

>>+wear1/preview base=base2

Your 'base' named 'base2' appears as:
This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency.

Moses says "So, by typing: +wear1/preview base=base2, the system properly retrieved the data. Yay code."

Moses notes, that in his experience, and in the experience of some of the more advanced coders he knows, rarely does something work right the first time.

Moses says "Because of the nature of mushcode, there is inevitably a parentheses mismatched, a missing bracket, a typo in a function name..."

Moses says "Something."

Moses says "One of my common errors in coding is typo'ing the word 'ifelse'...it usually comes out 'iflese'."

Moses says "Plus, when you get into deeply nested functions, it becomes very difficult to keep track of all of your parentheses/bracket pairings."

Moses says "Quick anecdotal case in point...I was recently working on recoding the +ambassadors/all and +ch/list commands for here. I was using the same structure of code for generating both sets of lists, as they are similar styles of list. I wound up with nested functions with about ten pairs of parentheses and four sets of brackets."

Moses says "It got ugly. quickly. :)"

Moses says "Back to +wear."

Moses says "To test the command, I will now add a couple new clothes descriptions, using both commands."

>>+wear1/new-clothes clothes1=This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

Your new clothes description, named 'clothes1' is set as:
This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

>>+wear/list

>>+wear2/new-clothes clothes2=This is a test of the clothes adding command, using the command-dependent system. It should work identically to the code used for adding a new base description, in either system, but as a coder you can never take things for granted.

**Post-Class Note: No output resulted from this command.

>>+wear/list

=-----------------------------------+Wear-----------------------------------=
Basic Descriptions:
BASE1 BASE2
Clothes Descriptions:
CLOTHES1 CLOTHES2
Type '+wear/preview = to see one of these.

Moses says "Okay, so I found another bug. When I added a new clothes description using the +wear2 command, the attribute was added, but I got no confirmation message. This is the better of the worst-case scenarios of bugs. The worst is the 'silent death'. It does nothing, and gives you no output, and you have to go into the trace output of the code to see where it is dying."

Moses says "A tip I will give you folk, both here and reading the log, when you get a silent death. Set the object that has the code on it puppet, and see what error message is returned to the object when it does the code routine. This will often point out where the problem is and prevent you having to do a trace routine on your code."

Moses says "Objects get error messages just the same as you do. If you tried to do @pemit me=flipper(1,2) It would tell you that there is no function named flipper. If you have code that tries to @pemit %#=flipper(1,2)...the object is going to get the same error message."

Moses says "So, using the puppet flag is beneficial in the bug-chasing process."

Moses says "Now, the thing I have to do is to first, analyze the existing code to find where in the code the notification is supposed to occur. I will check for typoes, and bracket/parentheses errors. Because I know this has happened in the command-dependent version, I will also be checking for curly braces."

Moses says "So, the command-dependent style uses the attribute do-new to set a new description. So, I'll look there first."

Armoire's do-new attribute:
DO-NEW:@switch u(fn-typeok,%1)=0,{@pemit %0=[v(msg-bad-type)] for your new description.},{&%1-[u(fn-space2tilde,%2)] me=%3;@pemit %#=Your new '%1', named '%2' is set as:%R[s(%3)]}

>>+wear1/preview clothes=clothes2

Your 'clothes' named 'clothes2' appears as:
This is a test of the clothes adding command, using the command-dependent system. It should work identically to the code used for adding a new base description, in either system, but as a coder you can never take things for granted.

Moses says "I know the attribute was set, because I can preview the description."

Moses tries to use the preview code to test the existence of attributes, rather than just examining for the attr in question.

Moses says "As I look at it right now, I can't see a reason why I wouldn't get the pemit for adding a new description."

Moses says "So, I will try the puppet method."

>>@set Armoire=puppet
Armoire is now listening.
Set.

>>+wear2/new-clothes clothes3=This is a test of the clothes adding command, using the command-dependent system. It should work identically to the code used for adding a new base description, in either system, but as a coder you can never take things for granted.

Armoire> Triggered.
Armoire> Set.
Armoire> Your new 'clothes', named 'clothes3' is set as:
This is a test of the clothes adding command, using the command-dependent system. It should work identically to the code used for adding a new base description, in either system, but as a coder you can never take things for granted.

Moses says "Okay, and now I see why I didn't get the output. The structure of the command triggers the subsequent command attributes. In this case, +wear2 subsequently triggers the &do-new attribute to set the new description. So, in do-new, I instructed the code to @pemit to %#."

Moses says "Because the object itself triggered the code, the object is %#"

Moses says "Okay, if this was PennMUSH, I could @edit do-new to have %# replaced with %@."

Noltar says "Sorry I'm not interacting... added an admin argument to my list ;)"

Moses says "%@ in Penn puts the caller's dbref number in. Initially the same as %#, it changes in this instance if something like a ufun or an @tr is called."

Moses chuckles and comforts. I love those.

Noltar says "The worst that can happen is I get removed, no big deal :P"

Moses hehs.

Moses says "Because this is Tiny2.2 here, I know that in order to get the message displayed properly, I need to edit the code and pass another parameter to the do-new function. The fourth parameter will be the caller's dbref, in this case %#. In do-new, this will be %4, but it will allow the player to get the proper message."

>>ex armoire/cmd-wear2

CMD-WEAR2:$+wear2/* *:@switch gt(words(%1,=),1)=1,{@switch %0[setq(0,first(%1,=))][setq(1,rest(%1,=))]=new-*,{@tr me/do-new=%#,[after(%0,-)],%q0,%q1},del*,{@tr me/do-delete=%#,%q0,%q1},put*,{@tr me/do-wear=%#,%q0,%q1},{@pemit %#=I'm sorry. That isn't a valid command.}},0,{@switch %0=clear,{@tr me/do-clear=%#,%1},{@pemit %#=I'm sorry. That isn't a valid command.}},{@pemit %#=Boing. Code Error. Please report it to [name(owner(me))].}

Moses hmms. Interesting.

Moses heehees at himself.

Moses says "When I look further at cmd-wear2, I see that I already did pass %# in I just forgot to use it properly."

Moses says "So, it's just a matter of a simple @edit on do-new, to replace %# with %0"

>>@edit armoire/do-new=%#,%0

Set - DO-NEW: @switch u(fn-typeok,%1)=0,{@pemit %0=[v(msg-bad-type)] for your new description.},{&%1-[u(fn-space2tilde,%2)] me=%3;@pemit %0=Your new '%1', named '%2' is set as:%R[s(%3)]}

Moses nods. Now, it's edited, and I will test it by adding yet another description. Repetitive, but it insures that it's right.

>>+wear2/new-clothes clothes4=This is a test of the clothes adding command, using the command-dependent system. It should work identically to the code used for adding a new base description, in either system, but as a coder you can never take things for granted.

Armoire> Triggered.
Armoire> Set.
Your new 'clothes', named 'clothes4' is set as:
This is a test of the clothes adding command, using the command-dependent system. It should work identically to the code used for adding a new base description, in either system, but as a coder you can never take things for granted.

>>@set armoire=!puppet

Armoire is no longer listening.
Cleared.

Moses nods. Success.

Moses says "Now, we have four clothing descriptions on our list, and it's definitely time to test the delete functionality."

>>+wear1/delete clothes=clothes4

Your 'clothes' named 'clothes4' has been deleted.

>>+wear/list

=-----------------------------------+Wear-----------------------------------=
Basic Descriptions:
BASE1 BASE2
Clothes Descriptions:
CLOTHES1 CLOTHES2 CLOTHES3
Type '+wear/preview [type]=[name] to see one of these.

>>+wear2/delete clothes=clothes3

Your 'clothes' named 'clothes3' has been deleted.

>>+wear/list

=-----------------------------------+Wear-----------------------------------=
Basic Descriptions:
BASE1 BASE2
Clothes Descriptions:
CLOTHES1 CLOTHES2
Type '+wear/preview [type]=[name] to see one of these.

Moses says "Okay, so I deleted the last two that I had set in the clothes section, using each command. Both responded with the proper output and both deleted the attributes."

Moses says "Yay, again."

Moses says "For the purposes of the class and for testing the ability of the code to put the elements into your desc, I'm going to use the description of the object, rather than mucking about with my own character's description."

Moses says "The way the code was set up to accomodate multi-section desc was to have it evaluate an attribute named player-desc, which read the descriptions of the currently set base and clothes descriptions."

Armoire's player-desc:
PLAYER-DESC:[u(base-[u(current-base)])]%b[u(clothes-[u(current-clothes)])]

Moses says "So, the player's description would be read off of the object, rather than attributes stored on themselves. The player would @desc themselves with [u(<dbref of object>/player-desc)]"

Moses says "Because they own the object, they would have privileges on reading, and there would be no issue in that regard."

Moses says "So, I'm just going to @desc the armoire to read [u(player-desc)]"

Moses says "Which will accomplish the same thing."

>>@desc armoire=[u(player-desc)]

Set.

>>l armoire

Armoire(#1353V$)

>>+wear1/puton clothes=clothes1

[switch(u(fn-typeok,clothes),0,I'm sorry. You must specify either base or clothes to put on.,You have put on your 'clothes' named 'clothes1'.

>>l armoire

Armoire(#1353V$) This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

Moses says "So, to test the puton functionality, I used +wear1 first, and got [switch(u(fn-typeok,clothes),0,I'm sorry. You must specify either base or clothes to put on.,You have put on your 'clothes' named 'clothes1'."

Moses says "Which tells me I have a parenthetical error. It treated the beginning of the switch as plain text, meaning it wasn't encapsulated in proper )] characters"

Moses examines the fn-new ufun on the object.

Moses says "Er, not fn-new...fn-wear, I believe it is called."

>>ex armoire/fn-wear
No matching attributes found.

Moses checks.

>>@pemit me=lattr(armoire/fn*)

FN-SHOWNAME FN-TILDE2SPACE FN-SPACE2TILDE FN-NOTCLEAR FN-CLEAR FN-NEW FN-TYPEOK FN-DEL FN-PUTON FN-PREVIEW

Moses was logical. Go figure. fn-puton

>>ex armoire/fn-puton

FN-PUTON:[switch(u(fn-typeok,%0),0,[v(msg-bad-type)] to put on.,[switch(lattr(me/%0-[setr(1,u(fn-space2tilde,%1))]),,[u(msg-no-attr,%0,%1)],[set(me,current-%0:%q1)]You have put on your '%0' named '%1'.)]

Moses says "and sure enough, I have a nested switch that I didn't close properly."

>>@edit armoire/fn-puton=$,)]

Set - FN-PUTON: [switch(u(fn-typeok,%0),0,[v(msg-bad-type)] to put on.,[switch(lattr(me/%0-[setr(1,u(fn-space2tilde,%1))]),,[u(msg-no-attr,%0,%1)],[set(me,current-%0:%q1)]You have put on your '%0' named '%1'.)])]

>>+wear1/puton clothes=clothes1

You have put on your 'clothes' named 'clothes1'.

Moses says "So, I did: @edit armoire/fn-puton=$,)]"

Moses says "And, that closed off the outside switch, and it worked fine."

>>l armoire

Armoire(#1353V$)
This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

>>+wear1/preview clothes=clothes1

Your 'clothes' named 'clothes1' appears as:
This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

Moses says "If you look at the armoire, you will see a test description in there. Which, when I did a +wear/preview to test, is the proper text from the proper attribute."

Moses says "Now, I will add a base description, to ensure that it is going to read both of them. For this, I will use the +wear2, the command-dependent version."

>>+wear2/puton base=base2

You put on your 'base' named 'base2'.

>>l armoire
Armoire(#1353V$)
This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency. This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

Moses says "And, voila. It replied with the proper message."

>>+wear1/clear base

**Post-Class Note: This command produced no output.

>>l armoire

Armoire(#1353V$)
This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

Moses says "Now, to test, I tried the clear command, and it succeeded silently. I didn't get the output I wanted. So, I check the fn-clear attribute."

>>ex armoire/fn-clear

FN-CLEAR:[switch(u(fn-typeok,%0),0,[v(msg-bad-type)] to clear.,[set(me,current-%0:)]Your [lcstr(%0)] has been cleared.)]

Moses says "And, at the outset, it isn't clear to me why it didn't work. So, I go to the puppet method."

>>@set armoire=puppet

Armoire is now listening.
Set.

Noltar nods

Moses says "I will put the element back into the desc."

>>+wear1/puton base=base2

You have put on your 'base' named 'base2'.

>>l armoire

Armoire(#1353Vp$)
This is a test basic description. This should be entitled 'base2', and I am going to make it at least two lines long to make it a worthwhile segment of a description. Smaller bits of text could be used for this, but some length should be used, for consistency. This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

>>+wear1/clear base

*Post-Class Note: Again, no output to me, the player. And, no output to the object, as a result of the puppet flag being set. In essence, nothing. Bad Thing(TM)

>>l armoire

Armoire(#1353Vp$)
This is a test of the clothes adding command. It should work identically to the code used for adding a new base description, but as a coder you can never take things for granted.

Moses says "And this is really interesting. Because now it succeeds REALLY silently. In essence, it doesn't produce any message at all."

Moses says "At this point, I would go to the trace method, and find out why it isn't producing any output, and track it down, beat it into submission, and go on with my bug-testing process. But, since we only have about a half hour left, I want to discuss the documentation process of your system."

**Post-class note: After the class, I did go into the trace of the output, and discovered the problem. I had set two defaults in the switch in cmd-wear1. Here is the code:
CMD-WEAR1:$+wear1/* *:@pemit %#=[switch(gt(words(%1,=),1),1,[setq(0,first(%1,=))][setq(1,rest(%1,=))][u(fn-notclear,%0,%q0,%q1)],[u(fn-clear,%1)],Boing. Code Error. Please report it to [name(owner(me))].)]

As you can see, I did not specify a '0' case for the switch to test against. gt() returns either 0 or 1. The code succeeded silently because the ufun was called, but the switch did not know which message to display and therefore displayed neither. When I went in and added a '0' test case in the switch(), it worked fine.**

Moses says "You can see that the bug-chasing process is tedious, time-consuming, but all important. As well, you have to get creative. You have to find ways to break your code."

Noltar nods

Moses says "In previous classes, I have discussed the simple fact that you have to assume that people are not going to type in what you wanted them to."

Noltar grins

Moses says "So, you have to deliberately put in bad input. In this class, I have used 'good' input, meaning I have used the system the way it was designed to be used."

Moses says "In a Real-World situation, something I was coding for usage, I would work hard to put in bad output, and test the error messages."

Noltar nods

Moses says "At the beginning, I entered the wrong format for the command...which produced an error message. this was an example of that, even if unintentional."

Moses says "So, we are assuming that our code is as bug-free as we can get it. I advise getting a friend to try and break your code before you put it globally, or make it available for many people to use personally. But, with those steps having gone by, you want to write your documentation for the code."

Moses says "This is probably the most important part of the process, really. What is the point of having miraculous code, code that does things no one could have coded, code that does things so efficiently and marvelously, but code that has no way to instruct players on how to use it?"

Moses says "Unix without man pages, Photoshop without tutorials, SimCity without instructions."

Moses says "All essentially useless, despite however neatthey may be."

Moses says "When writing help files for your code, you have to take into account the fact that the person reading these has never used your code before, most likely."

Noltar nods

Moses says "Even if they have used eleven different multidescers before in their mu*ing career, they have never used this one. They can't have, because we just coded it. So, we have to write the files with the first-time user in mind, and still give enough information on the advanced functionality(if any) to those users that are growing familiar with the system."

Moses says "Now, in the setup of this code, there are essentially three 'types' of commands. There is +wear/list, which will output a listing to the player of the names of the descriptive elements they have defined for themselves. +wear/clear <base|clothes> will clear that portion of their description, without erasing the attribute. And finally, +wear/<switch> <base|clothes>=<text>"

Moses says "It is important to note in writing the help file that the +wear/clear and the +wear/delete will have to be strenuously separated. People get scared that when they take something out of their description that it is then gone forever."

Moses says "As well, when you have parts of your commands that can accept variable input, you should take care to display that this is a special part of the command. As I did earlier with putting <>'s around optional or variable arguments."

Moses says "Other options are ansi, different surrounding characters, or listing each possible variation."

Moses says "Of those three, I would only recommend trying different characters. Not everyone is setup for ansi. Not everyone likes ansi. So, it's better to code help files for the lowest common denominator."

Moses says "As well, listing each possible permutation of arguments is...time consuming, laborious and spammy."

Moses says "For this system, you can probably condense the help files into two or at most, three sections."

Moses says "And, it's probably best to code separate commands for each one. wear help, wear help2, etc."

Moses says "The commands themselves are simple pemits, with lots of formatting characters in them. If this were a global system, you'd do the same thing, but write them in as +help files."

Moses suggests listing each successive command or command-type with %R%t formatting.

>>"For example: +wear/<switch> <base|clothes|name>=<text> - The main +wear command, where <switch> is one of the following:%R%tnew-clothes - Adds a new clothes description. Specify the name you want this element to have, and then fill in the text.%R%tnew-base - Adds a new base description. Specify the name you want this elemnt to have, and then fill in the text.%R%tdelete - Specify base or clothes, and then give the name of the element you want to delete in the <text> portion of the command. Careful, this erases the description permanently.%R%tpreview - specify base or clothes, and then the name of the element you wish to preview in the <text> portion.%R%tputon - Please specify base or clothes, and then the name of the element you wish to put on in the <text> portion of the command.

Moses says "For example: +wear/<switch> <base|clothes|name>=<text> - The main +wear command, where <switch> is one of the following:

new-clothes - Adds a new clothes description. Specify the name you want this element to have, and then fill in the text.
new-base - Adds a new base description. Specify the name you want this elemnt to have, and then fill in the text.
delete - Specify base or clothes, and then give the name of the element you want to delete in the <text> portion of the command. Careful, this erases the description permanently.
preview - specify base or clothes, and then the name of the element you wish to preview in the <text> portion.
puton - Please specify base or clothes, and then the name of the element you wish to put on in the <text> portion of the command."

Moses says "Spammy, but when put into a help file, takes up about a screen."

Moses says "Never have your help files over about 20 lines each, if you can help it."

Moses says "But, I hope that gives some example of how you would write a basic set of documentation."

Moses says "You'll notice in there that I have two typoes. If at all humanly possible, avoid typoes in your documentation. The quality of your help files is going to determine whether someone wants to use your code."

Moses says "Again, having great code is worthless if no one wants to use it."

Hercules has disconnected.

Moses says "And, if people find sloppy help files, they're likely to not expect much of your code."

Moses says "And, there's ten minutes left, so if you have any questions Noltar, I'll be happy to field them."

Noltar says "Not really. I just came to listen really :P"

Moses nods. Well, I appreciate your coming, even if interactivity was at a low.

Moses says "On that note, I'm turning the log off."