A Simple Prog Tutorial by Jherlen

Part One: A Simple, Easy, Prog

This one won’t be complicated at all. It’s just intended to get people familiar with the system on how to set progs and triggers.

Step One: Create the Prog Vnum

When you want to create a prog, you need to assign it a vnum, just like for a mob, object, or room. The prog vnum should be in your area to avoid load problems.

The command to create a prog vnum is: pedit create (vnum).

If you’ve exited the peditor for whatever reason and want to return to editing a prog that’s already been created, use the command: pedit (vnum).

To follow along with this tutorial and make a prog in your own area, just use vnums you’ve already been assigned.

Step Two: Name the Prog

You can name your prog to give a quick description of what it does. This helps you and the area checkers keep track of what prog vnums do what in your area.

The command to enter a prog’s description is: desc (description) while in pedit.

Step Three: Write the Code.

This is where a lot of people have been getting confused I think. The two major parts to a prog are the prog’s code, and the prog’s trigger. Think of the trigger as the action that sets off the prog. The prog’s code is the reaction you want the object/room/mob to have.

In this prog, lets say we want a mob to say “Stop talking to me!” when someone says “Hello” to it. We wouldn’t code anything to do with “Hello” in the prog’s code – the trigger handles that. All we want to do is tell the prog to react by making the mob say “Stop talking to me!”

To do that, we type code while in pedit. This brings us to the familiar description editor. Commands for progs are entered as if the mob was “typing” them itself. So to make a mob say “Stop talking to me!” all we would do would be to enter: say Stop talking to me! on a line. Since that’s all we want this prog to do, we then exit the editor.

That’s it for coding the prog. Simple, right?

Step Four: Set the Prog’s Trigger

Now we want to set our prog on a mob and test it out. To do this we add the prog to the mob, and set the trigger that will fire the prog. Remember, the trigger is the action that will set the prog off. There are many different triggers – you can look at the prog guide or type ? trigger in OLC to get a list.

Some triggers will need a “value” parameter set to further specify what fires the trigger. Remember, the trigger is the action that will fire the prog. If I want the prog to fire when someone says “Hello” to the mob, then we would use a speech trigger. “Hello” would be the value we add to the trigger. Speech is the TYPE of trigger, and Hello is the VALUE.

Another example, lets say we want a prog to fire when someone enters the room from the north. We would make the trigger a “greet” trigger for its TYPE (use the prog guide), and the VALUE for the trigger would be north.

To add a prog to a mob, the command is addprog (prog’s vnum) (trigger TYPE) (trigger VALUE) while editing the MOB you want the trigger added to. (You need to change from pedit to medit to add triggers.)

So, to add the prog and make it fire when someone says “Hello”, you’d type addprog (prog’s vnum) speech Hello

And that’s all their is to it! Four easy steps to writing the prog. To recap, here’s the commands you’d use to make the prog once again:

pedit create (vnum)
descr (prog description)
code
say Stop talking to me!
@
edit mob (vnum of mob you want to add the prog to)
addprog (prog’s vnum) speech Hello

What you have created for this mob is what is called a mprog (which stands for mob prog).  Other types include oprogs and rprogs (object progs and room progs respectively).  The only difference between the three is to whom the prog is attached to. 

Remember: THE PROG CODE IS THE REACTION TO THE TRIGGER. That’s the most important thing to know at this point.

Part Two: Oprogs and Rprogs

Oprogs and Rprogs work almost exactly the same as an mprog would. In fact, the only major difference with the procedure is how you add the progs. The commands for adding rprogs and oprogs are addprog and addprog, while in redit and oedit respectively.

The code writing step remains the same – you still use pedit to write the prog code itself. However, it’s best to keep in mind what kind of prog you’re writing and what you want to trigger it with. If you’re writing an rprog, for instance, commands like “say Hello” won’t work, because rooms can’t talk, and the commands are being “executed” by the room.

Rprogs and oprogs can still make use of other “special” prog functions however. An example of these is “prog mload” and “prog zecho”. I’ll paste an example of an rprog to demonstrate:

An Rprog triggered by the sunset (TRIG_SUNSET)

Desc:       Nighttime Firefly Load Prog
Vnum:       [2525]
Involved:   FALSE
Debug:      FALSE

Code:

prog zecho The forest trees begin to glow and twinkle with the light of fireflies.
prog mload 2582

When this prog is triggered, it first sends a zone echo (echo to the entire area) that talks about the fireflies coming out. It then calls “prog mload 2582”, which as you might expect loads mob 2582 into this room. Mob 2582 is a firefly, and so the prog’s effect has been to describe the fireflies coming out and create them.

A Mprog triggered by the sunrise (TRIG_SUNRISE)

Desc:       Daytime Firefly Purge Prog
Vnum:       [2526]
Involved:   FALSE
Debug:      FALSE

Code:

prog zecho The glow of the fireflies fades back into the forests as the sun creeps over the tree tops.
prog goto 3

 
Once again we use prog zecho to send the area a message that the fireflies are departing back into the forest. We then call “prog goto 3”, which will cause the fireflies to goto room 3 (which is the purge room).  The purge room is setup so that fairly frequently the mud will destroy all mobs and objects in that room.  (NOTE: A mob cannot purge itself, so when you want for something like that to happen that is the best way.)

That’s about it. These progs are still very simple, but they should demonstrate the differences between mob and obj/room progs, namely that you can’t use commands like “say” or “emote” when the prog isn’t attached to a mob.

Once again, the prog guide makes a great reference if you’re trying to find out how to make the progs do something. If you’re having trouble finding something or are confused, just ask me, I’ll be glad to help.

Part Three: If/Endif/Else and $n Usage

This is where progs start to look more like code. I’ll try and explain this as best I can. A good thing to remember is that when coding, the code parts will always work the same way, so cut-and-pasting is a good tactic. If someone’s made a prog that does one thing, and you want one that does the same thing or something similar, just copy the code and change what’s checked or what’s printed.

Lets examine this prog for a changer mob.
The prog’s trigger is set as give_money.
Quote 

if level $n == 55
 say You gave me $+ $s coins for a value of $# silver
else
 emote kicks @n in the face.
 say Hahaha I keep your money!
 prog abort
endif

This is nothing more than the simple hello prog from Part 1, with some extra stuff added on top of that.

Lets examine the prog line by line. The first line reads: if level $n == 55.

if level means we will be checking something’s level. The next part, “$n” tells us who or what’s level to check. The $-references refer to people, objects, and rooms that are used by the prog. These will be different for each trigger type, since each trigger has different conditions. So, to find out what “$n” will refer to in a give_money trigger, we CONSULT THE PROG GUIDE (do I emphasize that enough?). I go to give_money in the triggers section, and look at the “values” part. It tells me…

Values:   $n – The person giving money
          $s – “gold”/”silver” for the type of coin dropped
          $# – The value (in silver) of the amount given
          $+ – The number of coins given

Aha! Now we know what “$n” is – the person giving the mob money. if level $n must be checking that person’s level! But now we run into a problem again. The whole line reads if $n level == 55. What’s == mean?

The short answer is, think of “==” as just “=” for the basis of progs. The syntax is “==” because in code, “==” and “=” mean two different things. In code, “==” is a logic check to see if two things are equal, and “=” MAKES two things equal. Prog syntax doesn’t use the “=” operator, but for familiarity to coders Wyare made the operator to check if two things are equal “==” anyways. Again, though, just read the “==” sign as “are these two things equal?”

So, going back to the first line, if level $n == 55, we can now translate this line from prog-speak to people speak as “Does the person giving money’s level equal 55?” Or, “Is the person giving money an immortal?”

The line immediately following this line is:  say You gave me $+ $s coins for a value of $# silver. This may look awkward, but since we checked the prog guide and know what the values of the $-symbols are, we can make sense of the line too. The mob is going to tell us how many coins of what type we gave them, and then tell us their value in silver.

After this, the next line is simply: else. Okay… else what? What does the else mean?

Whenever you see an “else”, look for an “if” above it. Elses and Ifs are tied directly together. Think of it this way: an “else” handles everything an “if” didn’t handle. In this case, that means anytime $n’s level is NOT 55, the stuff under the “else” is going to be run instead of the stuff under the “if”.

In fact you’ll notice the lines under the if and else are slightly indented, while the if and else are not. This is done so that it’s easier to tell what is covered by the if, what is covered by the else, and where they both end.

An if/else block is terminated by the endif statement that you can see at the very end of the prog. “Endif” tells the code that every line after it should not be affected by the condition that it corresponds to. Lets say that at the very end of this prog, after the endif, we had another line that said emote sneezes.. Since the emote comes after the endif, it is not part of the condition checked by the if statement and will occur regardless of whether the condition was true or not. The mob would sneeze whether the level was 55 or not. Since the if block has already been terminated, the code outside it will always run.

When the code sees an “if” statement, the first thing it’s going to do is evaluate whether the condition is true or not. If it IS true, the code will run everything under the if statement, until it hits an “else” or an “endif”. If it is NOT true, the code will look for an “else” first, and run what’s under that if it exists. If there is no “else”, then the code will pick up on the first line after it finds an “endif”.

Public Service Announcement: ALWAYS TERMINATE YOUR IFS/ELSES WITH ENDIF. ALWAYS. IT IS ALWAYS ALWAYS NEEDED.

Now that we know (hopefully) what the if/else stuff is about, we know almost everything that we need to know to decipher this prog and write ones like it. If the person’s level is not 55, the mob will kick them in the face. You’ll notice the exact command is emote kicks @n in the face.. Why @n, not $n? The difference is basically a matter of usage. You’ll notice the new “emote” command uses “@” to refer to someone’s name, so @n would be the name of $n. The letters or symbols used to refer to something in a prog will always stay the same though, so @n and $n still both point to the person giving money.

The only other thing we don’t know yet is prog abort. What’s that do? The simple explanation is that it will stop the flow of the MUD code outside the prog in some situations. To see exactly what (if anything) prog abort will do, consult the……… PROG GUIDE. I won’t quote it again here, but for give_money triggers, prog abort will stop the mob from giving any money back if the mob is a changer.

We now can read, understand, and decipher this prog completely. We see the if level $n == 55 and know that if the person is an IMP, the mob will tell them stuff about the money it was given. Otherwise (else) it will say its taking your money and kick you in the face. Then prog abort is called, and the mob, even though it’s a changer, doesn’t give any money back like it would for an IMP. Ha ha, suckers.

Next time: else ifs, more complicated condition checks, and prog debug!