You are magically teleported somewhere. /d/standard/square You are in Monument Square, once known as Krasna Square. The two main roads of Praxis intersect here, where all of Nightmare's people gather in joy and sorrow. The road running north and south is called Centre Path, while Boc La Road is the name of the road running east and west. A magnificent monument rises above the square. The sounds of a busy adventuring town are all about. There are four obvious exits: east, north, south, and west. Newbie Hawkwind the boy Grumpy the grand master rogue Enforcer Forlock Of Law Newbie Vishnu the boy Newbie Genesis the boy Descartes is a demon from hell... A wooden sign and monument are here. Genesis says: hmm... it's 7:15 let's learn. Descartes says: first thing, for those who have been to previous classes... do you have any questions? Grumpy looks at his surroundings. Descartes peers at Grumpy. Grumpy says: release_object()? Descartes says: err... what is that supposed to do? Genesis looks at his surroundings. Grumpy says: well from what i heard on the intercre the reverse of receive_object() You say: I've also a question when grumpy's done. Descartes says: oh... NM does not use any such thing Grumpy nods Grumpy says: i see Forlock says: that sounds like a simul_efun someone paranoid put in Grumpy says: okie that's fine then Forlock says: use init instead Descartes says: lfun actually Grumpy says: how? Descartes says: kinda like exit() on 2.4.5 Grumpy says: i want to remove an object from someone when they go out from the room Forlock says: Desc have you gone over init? Descartes says: no forlock... havben't *really*... just introduced it Forlock nods Grumpy says: i set up pre_exit and made the room no_teleport Forlock says: you'll find out then Grumpy :) You say: When inherit is used, what prototypes of functions are passed to the new object? Grumpy says: oh okay :) Descartes says: there likely should be something like receive_objects() for exits You say: Or perhapse a pre_exit func for teleporting? Descartes says: all and none really :) Forlock says: ya could do it with shadows Forlock grins Hawkwind says: what is pre_exit? Descartes kicks Forlock You tell Forlock: YOU could do it with shadows. We can't :) Hawkwind says: a function that gets called before someone exits the room? Forlock tells you: well none of us can, because they've been removed. That was a private joke between me and Desc. :) Descartes says: see... prototypes are not necessary to make a call to an inherited function Descartes at Hawkwind Descartes says: NM has it so you can set a pre exit function for a specific exit Descartes says: but not yet so you can have a function that always gets called Hawkwind says: cool You say: I was getting an error in my definition of the die function before I noticed it was rewritten and set_die added. Descartes nods Descartes says: well... You say: It seemed to know what the prototype for the die function was. Descartes says: since it was prototyped as something else... Descartes says: namely void die(object ob) Descartes says: and you had void die() Descartes says: it barfed Descartes says: any other questions before we start? Forlock says: prototyping = typecasting ? Kalinash smiles Forlock pokes Kalinash in the ribs Kalinash bows to Forlock Kalinash bows to Descartes Forlock looks at his surroundings. Hawkwind says: can you have a xterm save its buffer? Sparky says: how do I become a student? Kalinash says: How do I write to sockets? You say: Copies of this session are being saved. mail me if you can't read it from /doc/classes Forlock says: oh no we're logged Forlock pokes Descartes in the ribs Hawkwind says: thank you Sparky says: how do I become a student? Descartes says: prototyping means writing the function name, parameters, and return type at the top of a program Forlock says: yeah I've always heard it called typecasting, doesn't matter Descartes says: type casting, which is fake with MudOS LPC, is just a way of saying what type something is Descartes says: ie: Descartes says: prototype: Hawkwind says: typecasting is whtn you (datatype) var Descartes says: void die(object ob) Forlock says: ahh Forlock says: ok it is different Descartes says: typecasting: (like hawkwind said) Retrograde appears from the shadows. Descartes says: (string)this_player()->GetName() Ninja says: prototyping tells the system what a function WILL be before the actual function is defined. Descartes says: both are technically meaningless in MudOS LPC Forlock nods Descartes says: in LPC, type casting does NOTHING Descartes says: in some cases, it is still required Hawkwind says: that sucks Descartes says: but in general, it is good practice to cast call_other()'s (things like this_player()->GetKeyName()) Descartes says: prototypeing sorta does something Descartes says: you cannot have local function calls unless the function in question is prototyped Forlock looks at his surroundings. Grumpy says: uh...what was that? Grumpy looks at his surroundings. Forlock says: we'd better start Descartes says: ok... today we will discuss the way a room object works Descartes says: what I have been intending to do for 2 weeks now :) Grumpy smiles Descartes says: you should all "cd /std" Grumpy says: is this mudlib gonna have the new combat/stat system? Grumpy says: i mean this is the one meant to be implemented? Descartes says: ok /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: everyone at /std? Ninja nods Hawkwind nods Vishnu nods Nialson nods Grumpy says: yep Greyfax says: yes Hawkwind nods Genesis growls Descartes says: if you ls the dir, you will see room.c Descartes says: which is the object you always inherit for rooms (excepting door rooms and piers) Descartes says: in addition, you will see the sub-directory /std/room Descartes says: those of you who have had earlier classes know what room inherits Forlock says: those who haven't should more it and read the inherit lines ;) --==** /std/room.c **==-- // /std/room.c // from the Nightmare Mudlib // the room object // written by Descartes of Borg 17 june 1993 // ::create() added by Pallando (93-06-18) // ::create() changed to container::create() with calls to // items::create(), exits::create(), and senses::create() added // by Descartes 930619 // this_object()->setup(); removed from reset() by Pallando (93-06-20) // seteuid(getuid()) removed from create() by Pallando (93-06-23) // GetLong() changed not to give error if none set by Pallando 93-07-10 #include <std.h> #include <rooms.h> #include <move.h> inherit CONTAINER; inherit "/std/room/exits"; inherit "/std/room/items"; inherit "/std/room/senses"; private int reset_number; void reset(); void reinitiate(); void SetShort(string str); void SetLong(string str); string GetShort(); string GetLong(string str); string GetExtraLong(); int eventMove(mixed dest); int GetResetNumber(); void create() { container::create(); exits::create(); items::create(); senses::create(); reset_number = 0; reset(); call_out("reinitiate", 0); } void reset() { reset_number++; } void init() { exits::initiate(); senses::initiate(); } void SetShort(string str) { container::SetShort(str); } void SetLong(string str) { container::SetLong(str); } string GetShort() { return container::GetShort(); } string GetLong(string str) { string ret; object ob; if(str) return describe(str); else { if(query_night() && query("night long")) ret = query("night long"); else if(!query_night() && query("day long")) ret = query("day long"); else ret = container::GetLong(); } if( !ret ) ret = ""; if(GetExtraLong() != "") ret += GetExtraLong(); return ret; } string GetExtraLong() { object *inv; string ret, tmp; int i; ret = ""; i = sizeof(inv = all_inventory(this_object())); while(i--) if(tmp = (string)inv[i]->affect_environment()) ret += tmp; return ret; } void reinitiate() { object *inv; int i; i = sizeof(inv = all_inventory(this_object())); while(i--) { inv[i]->eventMove(ROOM_VOID); inv[i]->eventMove(this_object()); } } int GetResetNumber() { return reset_number; } int eventMove(mixed dest) { return MOVE_NOT_ALLOWED; } string *GetId() { return items::GetId(); } status id(string str) { return items::id(str); } varargs int receive_objects(object ob) { if(!ob) ob = previous_object(); if(ob == this_object()) return 0; return 1; } Descartes at Forlock Descartes says: namely, you will notice that room.c inherits 4 different files Hawkwind says: quite a bit of stuff from std/room Descartes says: to quickyl reveiw inheritance... inheritance allows an object to take on all of the characteristics of another object Grumpy chuckles politely Vishnu listens to Descartes Descartes says: okie... Descartes says: room inherits: container.c senses.c exits.c and items.c Descartes says: exits.c is an object that simply has exits Descartes says: items.c is an object which has items you can look at Hawkwind says: simular to the items array from 2.4.5? Descartes says: senses.c has sensory functionality... for objects which can have smells, sounds, and things to be searched Descartes says: similar, but very different too Descartes says: it is a mapping here Hawkwind says: much better format Descartes says: a room is an object which needs exits, needs items, and has sensory input to the user... so that is why it inherits what those files do Descartes says: in addition, it inherits container.c Descartes says: which allows it to contain other things Descartes says: continaer.c for those who remember, inherits Object.c, which inherits clean_up.c Grumpy nods Forlock says: as a little history, it used to be that absolutely any object could contain another, so people could go inside themsleves or go inside another person, have them go inside him and crash the MUD You say: I have a question if we get to vaults. Vishnu says: can you say something about what clean_up does? Forlock says: clean_up will basically clean out a room after a certain amount of time, destroying everything in it Descartes says: is wonderful! :) Sparky says: kinda like reset? Forlock says: Desc can get more specific Forlock says: I don't know what the exact times are Hawkwind says: what if someone leaves something in a room and comes back after it gets cleanred out? their item gone? Descartes says: well... Forlock nods Descartes says: clean_up.c is inherited directly or indirectly by every object on the mud Descartes says: if you more it, you will see it is a very smalle file --==** /std/clean_up.c **==-- /* /std/clean_up.c * from Foundation II * the central object of the entire mudlib * created by Descartes of Borg 940210 */ #include <move.h> #include "clean_up.h" static private int __NoClean; void create() { seteuid(getuid()); __NoClean = 0; } int clean_up() { object ob, env; object *inv; int i; if(__NoClean) return NEVER_AGAIN; if(!(ob = this_object()) || ob->query_auto_load()) return NEVER_AGAIN; if(userp(ob)) return NEVER_AGAIN; if(env = environment(ob)) { if((int)env->is_bag()) return TRY_AGAIN_LATER; if((int)env->GetProperty("storage room")) return TRY_AGAIN_LATER; } i = sizeof(inv = deep_inventory(ob)); if(sizeof(users() & inv)) return TRY_AGAIN_LATER; if(!env) { while(i--) inv[i]->eventDestruct(); if(ob) ob->eventDestruct(); if(ob) destruct(ob); return NEVER_AGAIN; } if(userp(env)) return TRY_AGAIN_LATER; return (int)env->clean_up(); } int eventMove(mixed dest) { return MOVE_NOT_ALLOWED; } int eventDestruct() { object env; object *inv; int i; if(env = environment(this_object())) { i = sizeof(inv = all_inventory(this_object())); while(i--) inv[i]->eventMove(env); } destruct(this_object()); return !(this_object()); } static void SetNoClean(int x) { __NoClean = x; } int GetNoClean() { return __NoClean; } Descartes says: it has clean_up() and eventMove() and nothing else I think Descartes says: eventMove() is what is called to move an object Descartes says: clean_up() is called by the driver every so often in an object which has not been touched in a long time Descartes says: normally, this is used to remove the object from the game and save memory Hawkwind says: is it a set ammount of time or random? Forlock says: set Sparky says: does cleanup affect object that are supposed to be in a room like a fishing pole? Greyfax says: this is what happens to idle players? Forlock shakes his head Forlock says: it could happen to linkdead players but they get moved Vishnu says: to void right? Descartes says: the time is set in the driver configuration file Hawkwind says: does it check for an interactive object in the room? Descartes says: clean_up() affects all objects Descartes says: no, something different happens to idle players :) Descartes says: ok... so you all understand what is basically happening as far as inheritance goes in rooms? Vishnu nods Sparky nods Greyfax says: yes A shadow nods Ninja nods Grumpy nods Descartes smiles Hawkwind nods Descartes says: previous classes discussed inheritance and the basic structure... you can ftp those if you like... they go into great detail Sparky says: where? Hawkwind says: so what does tonights class go into? Descartes says: so... you write a room Forlock says: rooms Hawkwind says: cool Descartes says: class will discuss what a room object does in detail Descartes says: back to room.c Descartes says: rooms, like every other object, have create() called in them when they are first created Descartes says: you can see that room.c itself has a create() function Descartes says: that function calls create() in all the objects it inherits... Hawkwind says: sets default information? Descartes says: sets its reset_number to 0 Descartes at Hawkwind Forlock nods Descartes says: calls reset() Hawkwind nods Greyfax pokes Ninja in the ribs Ninja looks at his surroundings. Descartes says: ok... back... Descartes gasps in Descartes says: so... as you can see... a lot is being done in room.c's create() Sparky looks at his surroundings. Grumpy nods Descartes says: so that is why you must call ::create() in any object which inherits room.c Forlock says: or you get me and 3000 mortals screaming at you for having a room with no exits Descartes smiles at Forlock Forlock ducks. Descartes says: since create() is called when the room is first referenced, this is your chance to set up initital values for the room Descartes says: to set up variavles, all variable initialization must be done before ::create() Descartes says: function calls after it Descartes says: void create() { Descartes says: __TestVariable = 1; Descartes says: ::create(); Descartes says: SetShort("short desc") Descartes says: etc Descartes says: } Forlock says: I'm watching Home Improvement now so I'll be quieter. Vishnu says: how can I control the order exits appear in? Forlock says: my guess would be to just put it in, in the order you want it to appear Descartes says: with NM 3.0+ you cannot control the order in which exits appear Descartes says: err... maybe you can... Vishnu says: i'm using 3.2 and they come out in different order Vishnu says: than I put them in Descartes says: it may be reverse order Forlock nods Descartes says: in that create(), of course you are setting up things like the exits Descartes says: the items which are in the room Descartes says: the searches, smells, sounds, etc Forlock says: I'm wrong, I don't think you can control the order Descartes says: once you call ::create() Descartes says: it does the stuff I described above... which includes calling reset() Descartes says: you can see that room.c itself has a reset() function Descartes says: all it does is increment the reset_number Descartes says: but since it exists, if you redefine reset(), you must call ::reset() Descartes says: reset() gets called ate creation time and every so often after creation... Descartes says: thus you use reset in the room to do things like put in monsters which get added every reset, close doors which got opened, etc Descartes says: do you all understand the difference between reset() and create()? Ninja nods Vishnu nods Grumpy nods Forlock says: it used to be MUCH harder, believe me Sparky says: how long between resets? Sparky understands Descartes says: again, that depends on a value you set in your driver configuration file Forlock says: I don't think we'll tell you how it's set for Nightmare :) Descartes at Forlock Forlock says: (nods) Ninja grins Sparky smiles Descartes says: simple rooms therefore just have a create() function Descartes says: more complex ones will have a reset() defined Descartes says: then there is init() which gets called any time an object ienters the room (a living object) Descartes says: when I enter a room, the function init() is called in that room Descartes says: forlock rid zellski Forlock says: huh? Descartes says: then when he logs in, promote him to level 1 frog :) Forlock says: uhh oh Forlock says: ok :) Ninja grins Grumpy chuckles politely Ninja says: that "Gnort's" buddy? Sparky smiles Descartes says: you can add commands to a player in init() Descartes says: using the add_action() efun Descartes says: as you can see, the files room.c inherits do just this... Descartes says: addin exit commands, "smell", "listen", and "search" Descartes says: hmm Descartes says: I have to go do something... Descartes says: read around the files in /std/room Descartes says: and room.c for the moment... it may be like 15 minutes to 1/2 hour... Descartes is gone from our reality. Forlock says: init() is called anytime anything in the environment of the object or the object itself changes Grumpy says: but it only works when they enter that room right? Forlock says: well if we're speaking in terms of rooms, yeah Forlock says: but init() can actually be in any object Forlock says: so like if I pick up an object here, init() is called Forlock says: or if I walk into the room with an object, init() is called Forlock says: init is called constantly :) Grumpy says: for that object? Forlock says: well init gets called on me in all those cases Forlock says: you can imagine the mess it used to make when you got guild powers by carrying objects ZellskI says: and if you are carrying anything living when you pick up an object, init is called in the object once for each such living object. Forlock says: if someone dropped one of those objects accidently (usually it was almost impossible) anyone who entered that room would get the actions Vishnu says: why does senses.c have initiate instead of init? Grumpy nods Grumpy says: how are guild objects set up now? Grumpy says: guild powers i mean Forlock says: well now very few actions are actually put on objects Forlock says: has Desc gone over the /cmds directory? Grumpy ponders Forlock looks at his surroundings. Grumpy says: i very much doubt it Forlock says: probably best to let him go over it, it concerns daemons and stuff Grumpy says: ah.. Forlock says: I can briefly though if you want ZellskI smiles brightly Grumpy shrugs Grumpy says: why not ? Grumpy smiles ZellskI says: it's got commands in it! Forlock says: well anytime you type in something a daemon is questioned Forlock says: to see if the command exists Forlock says: the daemon checks a certain directory Forlock says: and also checks to make sure you're allowed to use that command Forlock says: all a guild does is give you permission to use a certain number of commands Forlock says: back when Zellski and I were a couple newbies that kind of thing was impossible :) ZellskI says: more or less :) Sparky looks at his surroundings. Grumpy says: so say how would u bring up a guild? Grumpy says: put the powers in /cmds? Forlock says: I only gave you the brief version Grumpy :) Forlock says: yeah you could technically do it that way Grumpy says: what do most guilds do? Forlock says: I believe the commands are housed in the wizards directories Grumpy says: u make a cmd dir in ur own directory? Forlock says: you get a special thing in you, when you join the guild, that tells it where to look Forlock says: I believe so yes. Grumpy says: yea that UID Forlock says: but don't do it until after you've finished a domain ZellskI says: you must have fairly few guilds :) Forlock says: only 3 or 4, Nightmare uses classes Forlock says: we don't need many Forlock says: people join one guild and one class ZellskI says: oh yes, i remember.. Grumpy says: i was trying to give certain players powers while they were in a room ZellskI says: i didn't like the specifications. Forlock says: hmm...seems there is a /cmds/guild on Nighmare Forlock says: use init Grumpy Forlock says: probably done that way to control the number of guilds out there Grumpy says: and rather than having an array check if there name matched i figured it'd be easier to give an object or something like that Forlock says: if you only want them to have the powers while they are in the room, use init Grumpy says: how? any number of people can be in the room but should a player sit down etc they get the power Forlock says: ahh it's a command? Grumpy says: set of commands Forlock says: I mean to get the powers you have to type in a command, right? Grumpy nods Forlock says: well the way it used to be done is, yeah you'd give him an object Forlock says: I doubt that's still correct ZellskI says: init() { if (is_member(this_player())) perform_ad_actions(); } Grumpy says: is_member? what the hell is that? Forlock says: I don't write much code nowadays Forlock says: checks to see if something is in an array Grumpy says: ahhh Forlock says: correct? ZellskI says: Eh, yes. ZellskI says: It's known as structured programming I think :) ZellskI says: Use a mapping Forlock says: my old way would be easier Forlock says: but Lassondra and/or Desc would run you through ZellskI says: what was your old way? Grumpy chuckles politely Forlock says: just give the player an object when they sat Forlock shrugs Grumpy nods Grumpy says: that's what i thought of ZellskI says: then do the add_actions in the sit! Forlock says: that'd work even better ;) ZellskI says: init() { add_action("do_sit", "sit"); } do_sit() { write("You sit.\n"); add_a_lot_of_actions(); } Grumpy says: is there a remove_action Forlock nods Forlock says: I think it's remove_add_action though Grumpy says: ahh that's good :) [[Here I removed a long anecdotal discussion that the particulars might not have intended to be made public]] Forlock says: It's Descartes' class, I'm the teacher's assistant ZellskI falls down laughing ZellskI says: T.A. Forlock the Brave. Forlock grins Forlock says: I'm Al Borland ZellskI says: who? Frog shouts: Hey, where IS everyone? Forlock says: here Nialson says: Does the T.A. want to take a stab at a question from the class? Forlock says: sure ZellskI signs up as assistant T.A. Nialson says: Why are the door-exits put in a seperate object that inherits room instead of something that is inherited along with room like inherit STD_ROOM; inherit DOORS; ? ZellskI applauds ZellskI says: good question :) why? ZellskI pokes Forlock in the ribs Forlock says: hang on I'm still trying to understand the question ;) Forlock says: exits don't inherit room, room inherits exits Morjesta looks at her surroundings. ZellskI says: I think the question was, how come you get a package deal with doors'n'all when you inherit a room? Forlock says: why not? ZellskI says: oh.. not quite Forlock says: Nial please restate your question, I can't follow it :) ZellskI says: door object inherits room?? Forlock shakes his head Nialson says: I'm referring to /std/vaults.c Forlock says: room inherits door object Forlock says: that would be a pretty complicated door ;) Forlock says: ok, what about /std/vaults.c ? Nialson says: Why do we need to inherit a seperate object to add a door, wouldn't it be cleaner to add a door object? Forlock says: there isn't a /std/vaults.c Forlock says: add a door object to what? ZellskI says: doors have a long history of being the least clean things possible with the current way room-to-room travelling is done. Nialson says: Sorry /std/vault. ZellskI frowns Nialson says: If we want a door in a room we inherit a completely different object for the room. Why wasn't it arranged so that one always inherits room, and also inherits a door object when doors are added? ZellskI says: vault.c seems to be a room that defines code for handling doors, aa such it inherits the room file. Forlock says: because not all rooms use doors Forlock says: if I understand you right, doing it your way would use up a bit more memory Nialson says: Ahh, how so? ZellskI frowns ZellskI says: i really have no clue what you're asking.. Forlock says: are you asking why is it you have to inherit a seperate file for doors? Nialson says: I'm asking why the files were set up so that we inherit VAULT instead of inheriting 2 seperate objects like inherit STD_ROOM;inheritDOOR;, similar to the way room inherits several things. Forlock says: I don't know vault well enough to answer that, I think you'll do better to ask Descartes, sorry. Nialson says: it IS a bizzarre question. It would have made it easier when I wrote my monster cages. Forlock says: wait, you only snag vault if you want doors right? ZellskI says: Well, it is hard to imagine ever using a door without a room. Forlock grins Forlock says: I'd do it Zell Forlock says: are you saying you want to only inherit a door and not a room with it? Ninja says: a door without a room is a portal. Forlock says: a portal is a room with a door Forlock throws back his head and cackles with glee Forlock says: I can't believe we're having this conversation :) Forlock says: I can't see why you wouldn't want the door to come with a room Forlock says: unless you're part of Monty Python... ZellskI says: It sort of makes sense, but as it is, the door can rely on the room code always being there, which makes it a lot easier to write. Ninja says: portal from Azak's room seems random as to the room it leads to. Forlock says: yeah? Ninja says: ended up in treehouse once, rainbow serpent room once. Ninja says: Frog ain't going back a third time. :) Forlock says: you'd probably end up in my workroom Ninja bounces around Forlock says: you'd hear some government secret so I'd have to kill you Ninja says: er, I AM a governent secret. Forlock says: well I'm idling for a while to watch Home Improvement (again) Forlock says: two episodes tonight ;) Forlock looks at his surroundings. Forlock says: try asking Desc the same question, he'd probably be a bit more productive Ninja says: and i have 2 phone calls to return. Forlock wave to Ninja Ninja waves Ninja is gone from our reality. ZellskI smiles at Forlock ZellskI says: Damn, I'm hungry. Forlock says: eat a door ZellskI says: I'll eat some matzah, about as tasty.. Forlock grins Forlock says: I have a fortune cookie ZellskI says: oh...? ZellskI looks over Forlock Forlock says: it says Forlock says: "Your goal is just around the door" ZellskI looks at his surroundings. ZellskI falls down laughing Forlock says: lucky numbers: 666 ZellskI peers at Forlock. ZellskI says: really? Forlock nods Forlock says: I'm having a bad year ZellskI giggles