[[ Editor - This capture was graciously provided by Grumpy. I took the liberty
of editing his emotes so that the document read as third person singular to
match the others. I also cleaned up spurious characters in a few places. I
read the document through, so there is no chance meaning changed. I will leave
things alone rather than risk changing the meaning. These policies will apply
to the complete set. ]]

Descartes says: first off... I am going to set up a more organized schedule
for these classes as to subject and coder level
Descartes says: I will post that next week :)
Tunal looks at his surroundings.
Kalinash wonders what level he is...
Descartes says: for today, we will pick up with some of the details of room
coding.. we discussed an overview Wed
Drakken appears from the shadows.
Descartes says: everyone cd to /std

/std/:
  *9 Object.c       *1 daemon.c          obj/           *1 sign.c       
   1 Object.h        2 drink.c           oldliving/      7 storage.c    
     adt/            1 food.c        *15 oldliving.c     1 storage.h    
   7 armour.c        5 guild.c         5 pier.c            user/        
   4 barkeep.c         hm/             7 player.c      *26 user.c       
  *6 bboard.c          living/         1 player.h        7 vault.c      
   1 castle.c        9 living.c        2 poison.c       14 vendor.c     
  *1 clean_up.c      1 living.h        1 prop_logic.c      virtual/     
   1 clean_up.h     *1 money.c         1 quest_ob.c      6 weapon.c     
  *3 container.c     1 monster.c         room/        
   1 container.h     1 monster.h      *2 room.c       
A total of 160469 bytes in 34 files.  (8 directories)

Descartes says: now, as I explained in the previous class... the driver
calls the function create() whenever a room is first referenced
Tunal says: yeah, I know... I read your manual.
Tunal says: You should have everybody read your manual before they take a
class... :)
Grumpy says: i have yet to finish the intermediate actually...
Descartes says: almost everyone here has read it to some degree
Descartes says: except maybe carmen, who is a brand new creator
Descartes says: now, in create() you call all the functions you need to
call to initialize the room
Descartes says: if you look in the dir /d/Examples/room

/d/Examples/room/:
   1 search.c             1 simple.c             1 simple_search.c   
   1 search.txt           2 simple.txt           1 simple_search.txt 
A total of 9086 bytes in 6 files.  (0 directories)

Descartes says: type more simple.c once you are in that dir

--==** /d/Examples/room/simple.c **==--

#include <std.h>

inherit ROOM;

void create() {
    ::create();
    set_properties( ([ "light" : 2, "indoors" : 1 ]) );
    set_short("a plain shack");
    set_long(
      "Floorboards and walls made of long rotting wood are the "
      "only features of an otherwise barren shack.  The only "
      "entrance is an opening to the south where a door once "
      "used to be.  Time and the environment must have taken "
      "it away."
    );
    set_smell("default", "Mildew fills your lungs, nearly making you
sick.");
    set_listen("default", "The floorboards creak under you as you walk.");
    set_smell("mildew", "That really makes you sick!");
    set_listen(({ "floorboards", "floorboard" }),
      "Old and unhappy with your presence, they are crying out");
    set_items( ([
      ({ "floorboard", "floorboards" }) : 
        "Be careful where you walk, they are rotting through in places.",
      ({ "entrance", "opening" }) :
        "A doorway with no door that leads out into the woods.",
      "woods" : "The great woods which surround the shack.",
      "door" : "What door?", "shack" : "An old, abandoned shack." ]) );
    set_exits( ([ "south" : "/domains/Examples/room/search" ]) );
}

Descartes says: everything in that file happens in create()
Descartes says: the first thing done in create() is to call ::create()
Descartes says: as I explained in previous classes... ::create() is simply
a call to create() in the inherited room.c file
Drakken says: like create() { create(); ?
Descartes says: ::create() must come before you do calls to functions in
room.c
Magius says: void create() {            ::create();
Descartes says: but after you initialize any variables you have
Descartes says: for example...
Descartes says: I have a global variable called __IsDirty
Descartes says: whenever say a player does something to mess up the room,
it gets set to 1
Tunal says: Oh, I get it! So that's the flag to set if create() is
triggered
Descartes says: whenever the room is clean, the variable is 0
Carmen says: so if someone leaves something in the room, it's set to 1....?
Descartes says: it is no where in any example... I am just making this
up...
Descartes says: this is an example, non-existent room I am talking about
Descartes says: hmm... let me start again...
Tunal says: I mean if it is 1, then when the cycle is going to check if it
needs to reset the room, then it resets it if it is 1 but not if it is 0
since everything's still in place
Descartes says: say you were giving a player a command to conjure up an
item into the room
Descartes says: actually... better yet...
Descartes says: you simply have a wandering monster
Descartes says: so you have a variable which you set = to the wandering
monster
Descartes says: call the variable __Monster
Descartes says: if you look at /std/room.c and read the code for create()
Descartes says: you see that it calls create() in all the objects it
inherits, then calls reset()
Descartes says: you want to set up initial values for any variable before
reset() is first called
Descartes says: so the initial value for your variables must be set before
you call ::create()
Descartes says: problem here is we have several very different levels of
people now :(
Descartes says: but... create() in all the other inherited objects must be
called before you can call functions they define
Dumrats says: what levels are here?
Descartes says: so ::create() must be called *before* you call any
pre-defined functions
Descartes says: so you do this:
Descartes says: void create() {
Descartes says:     my_setup_stuff
Descartes says:     ::create();
Descartes says:     regular_setup_stuff
Descartes says: }
Tunal says: gotcha. But what does ::create(); do?
Descartes says: ::create() calls create() in the inherited room.c object
Tunal says: Okay, so it calls the inherited object's create() function?
Descartes says: room.c defines its own create() function and need to be
called
Descartes says: right
Descartes says: when you write your own, you are *redefining* that create()
Descartes says: so you need to make sure you call the old create()
Drakken says: do we have an directory here where we can test some stuff?
Magius says: like in room.c it inherits from CONTAINER?
Descartes says: yep magius :)
Tunal says: so that all the vars defined in the inherited variable are set,
too
Tunal looks at his surroundings.
Carmen says: so it give the new room a few basic attributes and you can go
from there.....
Tunal says: Yeah! I think...
Descartes says: right... you all basically seem to have it
Descartes says: notice in /d/Examples/room/simple.c
Drakken looks at his surroundings.
Descartes says: it just does ::create() then calls the system functions,
since it has nothing to do itself
Magius says: the system functions like set_properties are in the the
included files correct?
Descartes says: first thing after ::create() is set_properties()
Descartes says: in the inherited files
Magius says: then what do you use the included files for?
Descartes says: set_properties() is defined in Object.c
Descartes says: room.c inherits container.c which inherits Object.c
Magius says: ahhhh...cascade effect
Tunal says: Okay, and Object.c is basically what every object inherits?
Descartes says: the include file defines ROOM as "/std/room"
Magius says: okay.....
Descartes says: every game object, yes :)
Tunal says: and then there's like monster.c or living.c that defines a
living thing, and then player.c which inherits living.c?
Tunal says: and so on for other things
Descartes says: in Object.'right tunal
Magius says: and every room inherits the container stuff too
Descartes says: set_properties() is used to set basic properties for any
object, that is why it is in Object.c
Descartes says: you pass to set_properties() a data type called a mapping
Descartes says: in this case, it comes in the form:
Descartes says: ([ "property name" : value, "property name" : value ])
Descartes says: example:
Descartes says: ([ "light" : 2, "indoors" : 1 ])
Carmen says: are there other properties which can be set like that?
Tunal says: yeah!
Descartes says: so the value of the property "light" is 2, and the
property "indoors" is 1
Cantaloupe says: does light need a property?
Tunal says: but what does the light property matter?
Descartes says: there are lots of properties actually... I think many of
them are listed on Nightmare in /doc/build/etc/properties
Tunal says: It's not like there's graphics or anything to show the shading
Descartes says: it is how well illuminated the room object is
Magius says: it determines what you can see in certain lighting situations
Descartes says: no, but different lighting is displayed through what you
can see
Tunal says: I thought it would be that as long as it's over 0, you could
see and if it was 0 then you couldn't see and needed a light source like a
torch
Cantaloupe says: so what are the um.....what is the range?
Descartes says: indoors 1 means that the room is indoors
Descartes says: indoors 0 means it is outdoors :)
Tunal says: so you can have different descriptions for different levels of
light?
Cantaloupe says: does indoors mean it isn't affected by time?
Descartes says: light? no specific range... meaningful from -6 to 6
Descartes says: indoors means just that, that the room is indoors and not
outdoors :)
Cantaloupe says: wow. =)~~~~~~~
Drakken says: 6 is very bright :)
Grumpy says: u can't look at the sky while indoors
Descartes says: now, this will vary based on the version of the Nightmare
Mudlib your mud uses
Grumpy says: plus i'm willing to bet when the weather stuff is done indoors
will have significance
Descartes says: older versions of the Nightmare mudlib use set_property()
Descartes says: which requires you to set a property one at a time
Descartes smiles at Grumpy
Grumpy says: i was right!
Grumpy grins
Descartes says: after set_properties(), you call set_short()
Tunal says: to set the short desc
Tunal says: and then set_long() to set the long desc?
Descartes says: right
Descartes says: the short desc is seen by players in brief mode
Descartes says: set_short() can accept either a string which is the
description... or a function which would be a function to call every time
you want to get a short desc
Descartes says: in this case, the short desc is a string
Descartes says: more on function in a sec
Tunal says: Now I have a big question -- is your mudlib interpreted by the
MUD driver or compiled in C?
Descartes says: interpreted by the mud driver
Descartes says: set_long() handles the long description people see when in
verbose mode
Descartes says: type "more here"
Descartes says: see set_long() here?
Descartes says: it uses a function instead of a string
Tunal says: it points to the function square_long
Descartes says: functions are in the form (: obj, str :)
Magius says: does it call up a text file?
Descartes says: where object is an object
Descartes says: if no object is mentioned, the object is assumed to be this
object()
Descartes says: so whenever something tries to get the long description for
this room....
Tunal says: so there's a separate .c file for each room!
Descartes says: right tunal
Descartes says: it calls square_long() in that room object
Descartes says: and uses the string it returns
Descartes says: that way you can have a description which varies from
moment to moment rather than one that is always the same
Tunal says: so you mean the def of square_long is 'string square_long'
Dumrats looks at his surroundings.
Tunal says: so is square_long a procedure, an object, or a method?
Tunal looks at his surroundings.
Tunal says: er... a function, object, or method
Descartes says: string square_long() {
Descartes says: err, in LPC, it is called a function
Tunal says: (sorry, I'm used to Pascal)
Descartes nods
Cantaloupe says: a function is just s thing that makes something happen,
yes?
Grumpy says: u could call it a procedure
Descartes nods
Descartes does not know Pascal
Grumpy smiles
Tunal says: Oops, I thought you would since you mentioned it in your manual
Grumpy says: functions are both pascal procedures and functions
Tunal says: Yup.
Descartes says: err... I know bits and pieces of it
Grumpy says: depends on what u want from it..if it's a void function it's a
procedure
Grumpy says: if it's a function returning a variable then it's most probably a
function
Tunal says: I guess everyone here except Desc knows Pascal
Tunal grins
A shadow says: nope
A shadow says: i don't know much of any computer language
Tunal says: that's okay
Tunal says: I know bits & pieces of C
Descartes says: so at any rate... that is how room defining goes
A shadow says: its occurred to me this is a very bad place to be
experimenting with emotes... sorry
Descartes blushes
Descartes says: I need to structure this better for coding ability :)
Descartes says: but code some rooms, and look at the functions in
/std/room.c and the files it inherits
Grumpy says: nope this was good enuff :)
Descartes says: and then you should come up with some good questions :)
Descartes says: mail me here on Nightmare
Magius says: I plan on it..........
Descartes says: err here or on Nightmare
Cantaloupe says: i'll take you up on it
Tunal says: is there anywhere that we can test our rooms?
Descartes says: good luck!@
Descartes says: not here, no
Cantaloupe says: aren't we on nightmare?
Tunal says: hmmm... Where can I get the nightmare lib?
Descartes says: we are on Nightmare IV
Descartes says: Nightmare mudlib is available via ftp at nightmare.connected.com
Descartes says: in pub/mud/MudOS/mudlibs
Magius says: give me a little time and I may open mine up for a
while.........d
Tunal says: Hey, where is this machine located anyways?
Descartes says: Seattle