Building tools and doc files
wiz...@engin.umich.edu
I am of the opinion that tools like the roommaker are great for mass-
producing rooms (and I love using it...saves mucho time), but it can lead
to a LOT of poorly made rooms and new wizzes who don't know how to code.
I think new wizzes should have to code from scratch until promoted (even just
one level...say from 21 to 22). That way you will have people who know how
to code, but who can later use the quickie method.
As far as getting new wizzes to read the doc files...on Hero we simply
made all apprentice wizzes (post-doctoral students) read the /doc directory
and pass a 20 question test about it before they could become full-fledged
wizards :). I think that worked quite well.
--
"3 reasons why we can't make wiz in RL: ** Rich "Wichart" Chappell
1) We don't do enough killing. ** wiz...@warhol.art.umich.edu
2) There are too damn many quests! ** wic...@aal.itd.umich.edu
3) The god doesn't sign on anymore. ** rich_c...@ub.cc.umich.edu
Brandon Emerson
[stuff deleted]
> As far as getting new wizzes to read the doc files...on Hero we simply
>made all apprentice wizzes (post-doctoral students) read the /doc directory
>and pass a 20 question test about it before they could become full-fledged
^^^^^^^^^^^^^^^^
>wizards :). I think that worked quite well.
Hey! That's a DARN good idea there. I think I'll consider that. :)
BTW...I just want to stick in a few words here. This is kind of off
the subject of LPC and docs. I've noticed alot of people talking bad
about 2.4.5 and compatibility mode and what-not...and I'm a little
tired of it. There are people out there who practically re-wrote
a good percentage of their mudlib, and may NOT want to convert after
all that work. For those of you who has 3.0 driver/mudlib hey..I'm
happy for you! It's a very nice/secure mudlib indeed, but for those
of you who wrote (or re-designed) your own mudlib, I think it's better
off keeping it the way it is instead of going through the pain to
re-write it (again).
Soo..just enjoy what you got!
P.S. Hey! My first flame!! *strut*
-- -- ------ -- -- --- --- | Brandon Emerson (Decker)
##|_|##| ##( )#\ ##| |##| \##\/##/ | Asst. Administrator Unix Systems ETSU
## _ ##| ######/ ##\ /##| >##< | E-mail -> dec...@wizard.etsu.edu
##| |##| ##| \#####/ /##/\##\ | Cyberworld (192.43.199.33 3000)
Craig Richmond
>In article <TaB...@engin.umich.edu> wiz...@engin.umich.edu writes:
[irrelevant boring non-flame bits deleted :]
>the subject of LPC and docs. I've noticed alot of people talking bad
>about 2.4.5 and compatibility mode and what-not...and I'm a little
>tired of it. There are people out there who practically re-wrote
>a good percentage of their mudlib, and may NOT want to convert after
>all that work. For those of you who has 3.0 driver/mudlib hey..I'm
>happy for you! It's a very nice/secure mudlib indeed, but for those
>of you who wrote (or re-designed) your own mudlib, I think it's better
>off keeping it the way it is instead of going through the pain to
>re-write it (again).
>Soo..just enjoy what you got!
Well, I personally can't see why people are so against upgrading. People can
not use the excuse that their mudlib is too big, because Genesis have done it
and they must have been the largest LPMud, and if not, there are few others
bigger than them.
How long do you intend to use compatability mode? When LPMud 7.00.43 comes
out, will Lars have to include a -o<n> flag to give you compatability with
a specifiable version of lpmud? This is a short lived option. I fail to see
how it can be practical for Future versions (ie 4 and above) to remain
compatible with 2.4.5. So why not upgrade now and make it easier on yourself.
You can get rid of all those silly 2.4.5 preconceived notions about how objects
should be written etc.
Then again, maybe I'm just a little more enthusiastic about my hate of some of
the sillier bits in the distribution 2.4.5 mudlib :)
>P.S. Hey! My first flame!! *strut*
5.5/10
Craig Richmond
Darin Johnson
People that are in compatability mode aren't against upgrading. It's
just that upgrading is a lot of work and will require learning lots of
new concepts (which require looking at parser source to understand),
modifying almost all of the files in the mudlib (and if you have existing
wizard files...), and your mud will end up being closed down for long
periods of time - unless of course, you don't have a job and can work on
this all day long.
>People can
>not use the excuse that their mudlib is too big, because Genesis have done it
>and they must have been the largest LPMud, and if not, there are few others
>bigger than them.
Well, just how long was Genesis closed down? :-) :-)
>How long do you intend to use compatability mode?
Just until our new mudlib is finished. You expect us to close down to all
players while working on this? Writing mudlibs is not my job, so perhaps
a couple of hours a week gets spent on this. Of course, I'm not talking
about a pure non-compat mudlib - but one that supports the old style
destruct/move_player, etc (using simul_efun hacks). After that, then
I can expect wizards to convert their stuff over at a reasonable pace.
Of course, there is a lot to be said for the method used by a certain
unnamed mud which closes down periodically, purges all players/wizards, and
reopens in the future with a new mudlib and nary a compatibility problem :-)
If I were to open a NEW mud, I would use a new mudlib. But the whole
reason behind "compatability mode" is compatibility!
>Then again, maybe I'm just a little more enthusiastic about my hate of some of
>the sillier bits in the distribution 2.4.5 mudlib :)
Well, we don't run a distribution mudlib either :-)
--
Darin Johnson
djoh...@ucsd.edu
- Grad school - just say no.
Mud Admin
>BTW...I just want to stick in a few words here. This is kind of off
>the subject of LPC and docs. I've noticed alot of people talking bad
>about 2.4.5 and compatibility mode and what-not...and I'm a little
>tired of it. There are people out there who practically re-wrote
>a good percentage of their mudlib, and may NOT want to convert after
>all that work.
I am not disrespectful of those who run in COMPAT_MODE for the above
reasons. This is a quite valid line of reasoning. However, my point
of view is that no one should expect to have their cake and eat it too.
There is much kludginess involved with that particular #define, and
it seems that if your mud was working under a previous parser then maybe
you should keep that parser.
>For those of you who has 3.0 driver/mudlib hey..I'm
>happy for you! It's a very nice/secure mudlib indeed, but for those
>of you who wrote (or re-designed) your own mudlib, I think it's better
>off keeping it the way it is instead of going through the pain to
>re-write it (again).
>Soo..just enjoy what you got!
Certainly -- enjoy what you have...
>P.S. Hey! My first flame!! *strut*
This is a flame? It's not a real flame until someone gets accused of
being on their period...
Sulam (who is still trying to decipher that particular barb)
Gary R Mayer
>producing rooms (and I love using it...saves mucho time), but it can lead
>to a LOT of poorly made rooms and new wizzes who don't know how to code.
>I think new wizzes should have to code from scratch until promoted (even just
>one level...say from 21 to 22). That way you will have people who know how
>to code, but who can later use the quickie method.
Its understandable that you'd want new wizzes to learn to code but just
tossing them into free-for-all coding won't help; especially if they
have no coding experience whatsoever. Seeing the file structure created
by roommaker gives a base to start examining and getting used to. A
possible solution would be to let all new wizzs use the roommaker but
in order to open an area you would have to be of a higher level -- say 25.
To obtain 25th level, a small coding test would be required that would
test th basic knowledge without a roommaker -- inherit, add_actions,
heart_beat, set_hp, query_'s, etc. The above commands could be requested
through three files -- a room, a monster, and an object. This would also
allow a bit o room for freedom of imagination.
To prevent lower wizards from going code happy with the roommaker prior
to opening their castle, try setting a stricter file limit on their
directory if possible. (Not to sure bout this one as I have not been an
arch or god and know only a bit of LPC but I'd imagine its possible)
The DROW
Adam Beeman
I'm of the opinion, for this issue, that a well-made roommaker can be
very useful for mapping out large areas, and in some cases fairly creative
and complicated areas can be made with such tools.
However, if the roommaker doesn't produce nice, clean looking code, then
it's less likely that the wizard will learn much from it. Setting a disk
usage limit, in my experience, has been useful, as it encourages people
to be more innovative. A friend of mine once coded a quest that had
1000 rooms, but only about 20 or 30 small files for the entire thing.
He had a limit of 150k on that particular mud, and was able to pack some
pretty sophisticated stuff into that.
So yes, I'll use a roommaker, if it works better and faster, but in
my experience most roommakers produce messier code or don't have the
ability to add what I'd like to.
Buddha@TMI
#include <exits.h>
inherit "std/room"; void create(){set_short("a dark tunnel");set_long(
"You are in a cold dark tunnel.\nThere are rats scurrying everywhere and "+
"an eerie blue light "+GD("north")+"\nLoud screaming noises are coming from "+
GD("south")+".\n"); set_exits(({"/room/void","/room/heaven"}),({"south",
"north"})); }
Darin Johnson
>very useful for mapping out large areas, and in some cases fairly creative
>and complicated areas can be made with such tools.
Well, I just ran across an area (not on my mud) that would definately
have been improved if a roommaker *had* been used. The entire area
appeared to have the same room copied over and over, with only the
exit directions changed. At least with a standard roommaker, it is
trivial to change the descriptions slightly...
I don't mind (much) if my wizards make a skeleton from a roommapper, but
the area still has to pass by me before it gets opened up. Unfortunately
there are a lot of places where the sponsors and people in charge don't
care what is produced (ie, anything goes if it isn't buggy and doesn't
break the rules).
Chris Burrus
is is by writinga source file for the "Mudmaster" compiler to compile, and from
that, it can make all your rooms as detailed as you like... You can create
monsters and objects (i.e. weapons/armour/treasures) with a single line of
source code... It's also a macro assembler, not unlike a C compiler... with
the ability to #DVAR large amounts of repeditive text to a single word or
expression.. The world in which the computer constructs the 3d map can be
32,727x32,727x32,727, or 3.505246702^13 rooms in size. (I figured that OUGHT
to be enough for even the most picky administrators. ;) Also, another feature
is autoexit-mapping... (that's the purpose behind the lattice) All you do in
the source to declare a room is this:
#DROOM[<name of room>|<room x>|<room y>|<room z>|<short>|<long>|<EXITS>]
where <EXITS> is ACTUALLY N/S/E/W/U/D/NE/SE/NW/SW And yes, you could define
all of those exits, and as long as the computer could find rooms that they
led to, it would make an exit to that room. Well, anyone care to comment?
I'm looking for more suggestions for features for it... What do YOU think
would be handy?
--
=1PROUD/// Amiga can make your wildest dreams possible./ cbu...@lunatix.uucp =
=AMIGA/// Commodore just won't let it. -me /\______________________=
=DUDE/// ============================================: These opinions are mine=
=\\\/// There are those who believe the earth revolves\/ and you can't have =
Craig Richmond
>source code... It's also a macro assembler, not unlike a C compiler... with
>the ability to #DVAR large amounts of repeditive text to a single word or
This is going to be great for those horribly horribly repetitive mazes :)
>expression.. The world in which the computer constructs the 3d map can be
>32,727x32,727x32,727, or 3.505246702^13 rooms in size. (I figured that OUGHT
>to be enough for even the most picky administrators. ;) Also, another feature
>is autoexit-mapping... (that's the purpose behind the lattice) All you do in
>the source to declare a room is this:
>#DROOM[<name of room>|<room x>|<room y>|<room z>|<short>|<long>|<EXITS>]
Do you handle the concept of room size. One of the main problems is that
you want rooms on the inside of buildings to be a fraction of the size of
rooms out in the open. This bothered me until I decided it was futile to
try and make the map fit together like a jigsaw. I was just determined to
remove all the blantant silly bits like going north, followed by south and
not being where you started.
>where <EXITS> is ACTUALLY N/S/E/W/U/D/NE/SE/NW/SW And yes, you could define
Are they the only valid exits? Can you have enter building as an alias?
>led to, it would make an exit to that room. Well, anyone care to comment?
>I'm looking for more suggestions for features for it... What do YOU think
>would be handy?
How flexible is it? Will it require a total rewrite to handle a different
room.c (ie one with brains :), or is it easily configurable.