March 2000
- Portal Matthew Mihaly
- randomly dropped connections Matthew Mihaly
- randomly dropped connections cg@ami-cg.GraySage.Edmonton.AB.CA
- randomly dropped connections Ben Greear
- randomly dropped connections J C Lawrence
- randomly dropped connections adam@treyarch.com
- randomly dropped connections Kevin Littlejohn
- Mud Network Setup Jon A. Lambert
- Mud Network Setup adam@treyarch.com
- Mud Network Setup J C Lawrence
- Mud Network Setup David Bennett
- Mud Network Setup Todd McKimmey
- Mud Network Setup David Bennett
- Mud Network Setup J C Lawrence
- Mud Network Setup adam@treyarch.com
- Mud Network Setup Jon A. Lambert
- Mud Network Setup J C Lawrence
- Mud Network Setup Emil Eifrem
- Mud Network Setup Dominic J. Eidson
- Mud Network Setup Emil Eifrem
- Mud Network Setup Eli Stevens {Grey}
- Mud Network Setup Todd McKimmey
- Mud Network Setup adam@treyarch.com
- Mud Network Setup cg@ami-cg.GraySage.Edmonton.AB.CA
- Mud Network Setup Steve Boleware
- Mud Network Setup Joe Andrieu
- Mud Network Setup John Bertoglio
- (fwd) MU* hiasb@cc.gatech.edstory? claw@kanga.nu
- (fwd) MU* hiasb@cc.gatech.edstory? cg@ami-cg.GraySage.Edmonton.AB.CA
- (fwd) MU* hiasb@cc.gatech.edstory? Ola Fosheim Grøstad
- (fwd) MU* hiasb@cc.gatech.edstory? adam@treyarch.com
- (fwd) MU* hiasb@cc.gatech.edstory? 송재경
- Processor Usage Christopher Kohnert
- Processor Usage J C Lawrence
- Processor Usage Dominic J. Eidson
- Processor Usage Ben Greear
- MUD-Dev digest, Vol 1 #298 - 11 msgs Dr. Cat
- MUD timeline Koster, Raph
- MUD timeline cg@ami-cg.GraySage.Edmonton.AB.CA
- MUD timeline Jon Leonard
- MUD timeline Richard Woolcock
- MUD timeline J C Lawrence
- MUD timeline Kristen L. Koster
- MUD timeline Kristen L. Koster
- MUD timeline Lovecraft
- MUD timeline Koster, Raph
- MUD timeline AR Schleicher
- MUD timeline Matthew Mihaly
- MUD timeline Matthew Mihaly
- MUD timeline Koster, Raph
- MUD timeline Dundee
- MUD timeline Darrin Hyrup
- MUD timeline Koster, Raph
- MUD timeline Moreland, John
- MUD timeline Darrin Hyrup
- MUD timeline jkerr@htech.withoutthisstuff.com
- MUD timeline __Deric___@yahoo.com
- MUD timeline Darrin Hyrup
- MUD timeline Erik Jarvi
- MUD timeline Travis Casey
- MUD timeline Jon A. Lambert
- MUD timeline Travis Casey
- MUD timeline Jon A. Lambert
- MUD timeline Travis Casey
- MUD timeline Bruce
- MUD timeline Daniel A. Koepke
- MUD timeline cg@ami-cg.GraySage.Edmonton.AB.CA
- MUD timeline Dr Richard A. Bartle
- MUD timeline Koster, Raph
- MUD timeline Hans-Henrik Staerfeldt
- MUD timeline Koster, Raph
- MUD timeline Hans-Henrik Staerfeldt
- MUD timeline Sellers, Michael
- MUD timeline Jon Whitehouse
- MUD timeline Derek Snider
- MUD timeline J C Lawrence
- MUD timeline Sellers, Michael
- MUD timeline Matthew Mihaly
- MUD timeline J C Lawrence
- MUD timeline Ryan Palacio
- Mud Timeline Darrell Michaud
- Mud Timeline Klimon, Ian
- Mud Timeline Matt Mihaly
- ADMIN: Ooops, damn... J C Lawrence
- FW: MUD timeline Daniel James
- MUD timeline F. Randall Farmer
- MUD-Dev digest, Vol 1 #298 - 11 msgs Koster, Raph
- Skotos Website Up Christopher Allen
- CGDC dinner J C Lawrence
- CGDC dinner Joe Andrieu
- CGDC dinner J C Lawrence
- CGDC dinner J C Lawrence
- CGDC dinner Joe Andrieu
- CGDC dinner Koster, Raph
- CGDC dinner Bruce
- CGDC dinner J C Lawrence
- CGDC dinner Derek Snider
- CGDC dinner Ryan Palacio
- CGDC dinner Koster, Raph
- CGDC dinner Sellers, Michael
- CGDC dinner Derek Snider
- CGDC dinner Joel Dillon
- CGDC dinner J C Lawrence
- CGDC dinner Emil Eifrem
- CGDC dinner Richard Ross
- CGDC dinner J C Lawrence
- CGDC dinner Wes Connell
- CGDC dinner Suess123@aol.com
- CGDC dinner Joel Dillon
- ADMIN: Posting delays J C Lawrence
- javascript Ola Fosheim Grøstad
- javascript cg@ami-cg.GraySage.Edmonton.AB.CA
- javascript Ola Fosheim Grøstad
- javascript Laurel Fan
- javascript Ola Fosheim Grøstad
- javascript Bruce
- javascript Ola Fosheim Grøstad
- javascript Bruce
- MUD-Dev digest, Vol 1 #302 - 6 msgs Dr. Cat
- Admin: Corrections, data loss, and interruptions in service. J C Lawrence
- Raph's collection of MUD design Laws Greg Underwood
- Raph's collection of MUD design Laws Wes Connell
- Raph's collection of MUD design Laws Kristen L. Koster
- Raph's collection of MUD design Laws Greg Underwood
- Raph's collection of MUD design Laws Caliban Tiresias Darklock
- Raph's collection of MUD design Laws David Bennett
- Raph's collection of MUD design Laws J C Lawrence
- (OT) Admin: Library memberships J C Lawrence
- Open Source Online Gaming Aaron Mitchell
- Open Source Online Gaming Koster, Raph
- Open Source Online Gaming Bryce Harrington
- Open Source Online Gaming Bruce
- Open Source Online Gaming J C Lawrence
- Open Source Online Gaming Bryce Harrington
- Open Source Online Gaming Ryan
- Open Source Online Gaming Erik Jarvi
- Open Source Online Gaming Derek Snider
- Open Source Online Gaming Aaron Mitchell
- GDC Dinner Matthew Mihaly
- GDC Dinner Justin Rogers
- ADMIN: looking for work? J C Lawrence
- [OT] Sound in games Erik Jarvi
- [OT] Sound in games Koster, Raph
- politics J C Lawrence
- Have openings Gary Whitten
- HTML as a MUD client . . . was javascript John Bertoglio
- ADMIN: Kanga.Nu will be moving (again) J C Lawrence
- ADMIN: Lost mail? J C Lawrence
- better usage through mechanics [from: CGDC dinner] Lovecraft
- better usage through mechanics [from: CGDC dinner] John Bertoglio
- better usage through mechanics [from: CGDC dinner] Joel Kelso
- better usage through mechanics [from: CGDC dinner] adam@treyarch.com
- better usage through mechanics [from: CGDC dinner] Ola Fosheim Grøstad
- Dynamic Load Balancing Kevin Scott London
- Open Source Environments (was: Open Source Online Gaming) scott guzman
- Open Source Environments (was: Open Source Online Gaming) Nathan F Yospe
- Fw: [RRE]MediaMOO birthday Celebration, March 20th 2000!!! Bruce
- Open Source Environments scott guzman
- MudDev FAQ part 1 Marian Griffith
- MudDev FAQ part 1 Todd McKimmey
- MudDev FAQ part 1 Marian Griffith
- MUD Dev FAQ part 1 Marian Griffith
- MudDev FAQ part II Marian Griffith
- Questions about the MudDev FAQ Marian Griffith
- Open Gaming? J C Lawrence
- Open Source Environments / MacOS X J C Lawrence
- Open Source Environments / MacOS X Chris Jacobson
- Star Wars gmud? Nathan F Yospe
- better usage through mechanics [from: CGDC dinner] J C Lawrence
- [CODE] unique items J. Coleman
- [CODE] unique items Draymoor
- [CODE] unique items cg@ami-cg.GraySage.Edmonton.AB.CA
- [CODE] unique items Matthew Mihaly
- [CODE] unique items Quzah
- [CODE] unique items J. Coleman
- [CODE] unique items Ben Greear
- [CODE] unique items Kevin Scott London
- [CODE] unique items Lord Ashon
- [CODE] unique items Marc Bowden
- [CODE] unique items J C Lawrence
- Kanga.Nu has a new IP J C Lawrence
- Licensing and Clauses Chris Jacobson
- The Meta list is now open and active. J C Lawrence
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? Par Winzell
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? Phillip Lenhardt
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? Phillip Lenhardt
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Object and class heirarchies -- are they really nec essary? Koster, Raph
- Object and class heirarchies -- are they really nec essary? Nathan F Yospe
- Object and class heirarchies -- are they really necessary? Draymoor
- Object and class heirarchies -- are they really necessary? scott guzman
- Object and class heirarchies -- are they really necessary? Chris Jones
- Object and class heirarchies -- are they really necessary? Dr Richard A. Bartle
- Object and class heirarchies -- are they really necessary? Lazarus
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Object and class heirarchies -- are they really necessary? Phillip Lenhardt
- Object and class heirarchies -- are they really necessary? cg@ami-cg.GraySage.Edmonton.AB.CA
- Object and class heirarchies -- are they really necessary? Brandon J. Rickman
- Object and class heirarchies -- are they really necessary? Marian Griffith
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Object and class heirarchies -- are they really nec essary? Brian Ashburn
- Object and class heirarchies -- are they really necessary? Par Winzell
- Object and class heirarchies -- are they really necessary? J C Lawrence
- Object and class heirarchies -- are they really necessary? adam@treyarch.com
- Object and class heirarchies -- are they really necessary? Kevin Littlejohn
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Matthew Mihaly
- Gamasutra: Online Justice Systems Draymoor
- Gamasutra: Online Justice Systems Vijay Weasel Prabhakar
- Gamasutra: Online Justice Systems J C Lawrence
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems adam@treyarch.com
- Gamasutra: Online Justice Systems Dundee
- Gamasutra: Online Justice Systems David Bennett
- Gamasutra: Online Justice Systems Wes Connell
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Fred Clift
- Gamasutra: Online Justice Systems Ola Fosheim Grøstad
- Gamasutra: Online Justice Systems Draymoor
- Gamasutra: Online Justice Systems Ananda Dawnsinger
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Todd McKimmey
- Gamasutra: Online Justice Systems AR Schleicher
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Wes Connell
- Gamasutra: Online Justice Systems Sayeed
- Gamasutra: Online Justice Systems Koster, Raph
- Gamasutra: Online Justice Systems Ola Fosheim Grøstad
- (fwd) mud.design.ideas Nathan Fenenga Yospe
- Command interface for Coordinate based world WriterDL@aol.com
- Command interface for Coordinate based world Draymoor
- Command interface for Coordinate based world adam@treyarch.com
- Command interface for Coordinate based world Nathan F Yospe
- Command interface for Coordinate based world Vijay Weasel Prabhakar
- Command interface for Coordinate based world Jeremy Noetzelman
- Command interface for Coordinate based world Laurel Fan
- Command interface for Coordinate based world Lovecraft
- ADMIN: Moving house and posting delays J C Lawrence
- MUD-Dev digest, Vol 1 #18 - 17 msgs Dr. Cat
- Embedding C/C++ Draymoor
- Embedding C/C++ Justin Rogers
- Embedding C/C++ J C Lawrence
- multiplaying Tess Lowe
- multiplaying Lovecraft
- multiplaying Wes Connell
- Online Justice Systems scott guzman
- Online Justice Systems Matthew Mihaly
- Online Justice Systems J C Lawrence
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Wes Connell
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Wes Connell
- Trouble Makers or Regular Citizens Marc Bowden
- Trouble Makers or Regular Citizens adam@treyarch.com
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Jon Lambert
- Trouble Makers or Regular Citizens Rasdan
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Par Winzell
- Trouble Makers or Regular Citizens Todd McKimmey
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Todd McKimmey
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Dan Shiovitz
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Chris Jones
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Dundee
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Zak Jarvis
- Trouble Makers or Regular Citizens Todd McKimmey
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Fred Clift
- Trouble Makers or Regular Citizens Gunnar Kreitz
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Justin Rogers
- Trouble Makers or Regular Citizens Ananda Dawnsinger
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Kevin Scott London
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Marc Bowden
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Jon A. Lambert
- Trouble Makers or Regular Citizens adam@treyarch.com
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Jon A. Lambert
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Par Winzell
- Trouble Makers or Regular Citizens Jon Lambert
- Trouble Makers or Regular Citizens Kristen L. Koster
- Trouble Makers or Regular Citizens Tess Lowe
- Trouble Makers or Regular Citizens Jon Lambert
- Trouble Makers or Regular Citizens Tess Lowe
- Trouble Makers or Regular Citizens Ola Fosheim Grøstad
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Joe Andrieu
- Trouble Makers or Regular Citizens Chris Lloyd
- Trouble Makers or Regular Citizens David Bennett
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Chris Lloyd
- Trouble Makers or Regular Citizens Ola Fosheim Grøstad
- Trouble Makers or Regular Citizens Koster, Raph
- Trouble Makers or Regular Citizens Matthew Mihaly
- Trouble Makers or Regular Citizens Zak Jarvis
- Trouble Makers or Regular Citizens J C Lawrence
- Trouble Makers or Regular Citizens Zak Jarvis
- Trouble Makers or Regular Citizens Par Winzell
- Online Justice Systems (response to J C) J C Lawrence
- Online Justice Systems (response to J C) scott guzman
- Meta: Questions about the MudDev FAQ Jon A. Lambert
- RE:Troublemakers and their M.O. Aaron Leslie
- RE:Troublemakers and their M.O. Baldur Norddahl
- RE:Troublemakers and their M.O. Chris Jacobson
- RE:Troublemakers and their M.O. Lovecraft
- RE:Troublemakers and their M.O. Tess Lowe
- RE:Troublemakers and their M.O. Kevin Scott London
- RE:Troublemakers and their M.O. Sellers, Michael
- RE:Troublemakers and their M.O. Kevin Scott London
- Object and class hierarchies -- are they really necessary? Christopher Allen
- ScryMUD 2.0.11 released. Ben Greear
- ADMIN: Spam filters and being unsubscribed J C Lawrence
- World and History Creation Ling
- characters per account Matthew Mihaly
- characters per account F. Randall Farmer
- characters per account Jeff Freeman
- characters per account Sellers, Michael
- characters per account LexaH@aol.com
- characters per account Jeff Freeman
- characters per account Matthew Mihaly
- characters per account AR Schleicher
- characters per account Matthew Mihaly
- characters per account AR Schleicher
- characters per account John Bertoglio
- characters per account Sayeed
- characters per account Matthew Mihaly
- characters per account Sayeed
- characters per account Brian Green
- characters per account Timothy Dang
- characters per account F. Randall Farmer
- characters per account Paul Schwanz - Enterprise Services
- characters per account Kristen L. Koster
- characters per account Paul Schwanz - Enterprise Services
- characters per account Ola Fosheim Grøstad
- characters per account Timothy Dang
- characters per account Paul Schwanz - Enterprise Services
- characters per account Darren Henderson
- characters per account adam@treyarch.com
- characters per account Jon Lambert
- characters per account Darren Henderson
- characters per account J C Lawrence
- characters per account Zak Jarvis
- Richard Garriot's 'X' project Matthew Mihaly
- Richard Garriot's 'X' project Sellers, Michael
- Richard Garriot's 'X' project skeptack
- Richard Garriot's 'X' project skeptack
- Richard Garriot's 'X' project AR Schleicher
- Richard Garriot's 'X' project Jeff Freeman
- Richard Garriot's 'X' project Brian Green
- Debugging techniques adam@treyarch.com
On Tue, 28 Mar 2000, Marian Griffith wrote:
> On Tue 28 Mar, Kevin Littlejohn wrote:
> > It is _very_ handy for being able to change the world physics without
> > restarts - introduce new concepts (like weight, size, etc) on-line, tinker
> > with them, remove them again, without actually disturbing
> > players/builders/visitors.
>
> I do not understand why this would be so important. Why not simply
> restart the mud after you made some extensive changes? Every other
> mud that I have played had, at some point in time, a test game up,
> that was used for new ideas. If they worked out they were incorpo-
> rated in the actual game, if not, they were discarded. Seems much
> more sensible to me to do things that way.
It depends on the goals of the server. Many of the folks here are interested
in making the ultimate "virtual sandbox", and this sort of incredible
flexibility is a primary goal of such an endeavor. This also leads
towards a kind of mud that *I* would definitely play: nearly infinite
possibilities with free-user programming, but unlike most existing muds
of this sort, the mechanics of the world are actually very well defined.
User programming, then, becomes a matter of twiddling those mechanics, rather
than writing routines which simulate, through well-written text, whatever
it is that the user wants to achieve. As far as I know, there are no
running muds that achieve this. (Please correct me if I'm wrong!)
Now, if you're more interested in just making a good 'traditional' mud
and focusing on your game-level features, yeah - doing the above is WAY
more work than you need bother with. I, for one, do all my development
on my desktop machine, and then when I have features that I'm ready to roll
into the server, rsync to the mud machine, recompile, and reboot. (Thanks
to modern technology, a complete rebuild of my server takes about 15 seconds,
and it boots in about 3, on a mediocre K6-3/400.) Certainly players don't mind
the reboots; in a way, it generates excitement when I come on and say, "alright
folks, reboot time..." because they know it means new features are coming
online. Secondly, and much more importantly, it allows me to run a debugger on
my development version without interrupting the play of the main system. (I
suppose someone is going to chime in here and say, "Well, if you would just
quit writing code with bugs in it...")
Which allows me to segue, perhaps not so smoothly, into this topic (and hence
the subject change):
- What techniques do listmembers use for debugging their servers?
This actually covers three levels, of course: code, scripting, and data.
The bottom level is code. I assume that the core of most currently
running servers is C or C++. I generally use DDD at home (*love* that
undo/redo) and text-mode gdb remotely. Generally I try to avoid debugging
the main server and just use core dumps to check the cause of the occasional
crash that occurs. If I notice that a certain character is bugged, I just
copy their player file over to my desktop machine and load them up there
to debug it. There have been, however, several occasions where there were
bugs in the socket code which were *only* triggered by players typing certain
commands at a certain speed. (In some cases, they were things that were
impossible for me to duplicate locally, because they required a little bit
of net lag to show up.) In this case I haven't been ashamed to attach a
debugger to the running server and check it out. If you're quick enough
at your breakpoints, people will just chalk the lost time up to lag. :)
The middle level is scripting. The huge amount of time I spend supporting
scripting languages in my professional work (Revenant, Die by the Sword,
and Draconus all make heavy use of scripting) make me not want to bother
with it in my spare time. I know that scripting is very popular among
listmembers, so I'm sure that someone will chime in here about the 'fun'
of writing your own in-game debugger. (Note that I'm considering the
term 'scripting' to be inclusive of any special game language, which includes
byte-code compiled languages or even LPC.)
The top level is data. My first experience with area creation was for diku
(SillyMUD to be exact), and it took me about five seconds to realize that the
data-debugging tools were totally inadequate. I suppose there's two levels
here: one is actually aquiring the data (text files, an external editor, or
OLC) and the second is "tuning" the data, or making sure that everything works
the way you expected it to.
I use pure text files for my server, as I find them fast and easy to create,
and better yet, don't require supporting an editor or OLC. (They also work
quite well under revison control.) My error reporting is still quite limited:
it only lists the line number, the file, and prints the line itself.
Eventually it would be nice to point out the actual problem (like,
'unrecognized flag' or 'syntax error'), but due to the file format I use I
find it quite easy to determine the problem.
In fact, as it turns out, the difficulties I had with writing my first
diku area were not so much a lack of good debugging tools, but a problem
with the format being too obscure. Mostly it's just rows of numbers, and
it's easy to forget which goes where or forget certain values.
I think I've shown examples of my file format before; it looks like this:
name = "longsword"
material = iron
weight = 5.2 kg
sharpness = good
quality = average
etc. In almost all cases, the only "debugging" I have to do is fixing a
few mispellings.
This is particular true for rooms; on that diku area I spent at least four
hours trying to get all the rooms to match up properly (due to typos in
my to_room field). Although I have a to_room field, I generally line up
the rooms by assigning them an x, y, z value, and then the server figures
out which rooms link up where. Using this method I can write a complete
area and it will usually work properly the very first time I run it.
So I suppose you could say that I avoid data-entry-debugging altogether,
due to a file format that is simple enough that errors are rare and
are obvious and easy to fix when they do occur. This wouldn't work for
just any server; I could easily envision a heavier simulation where the
data is quite simply very complex, and more intensive debugging tools are
necessary, and possibly creating it this way (in a text file) would be
out of the question.
The second area of data debugging is making sure that you got what you wanted
in the game. Again, I try to make all the fields no-brainers. On servers
where you enter numeric values that are in "mud units" that the builder
is just expected to be familiar with, swords that weigh as much as a house
are a common problem. Fields which use measurements (weights, volumes,
distances, times...) are entered using whatever real world units the
builder wishes (for weight I support pounds, kilograms, ounzes, and grams)
and are then converted to my internal unit (which happens to be grams).
Even then, there's still debugging that must be done. In this respect I
think that stock diku actually offers a lot of good tools; you can load
up the object, stat it, and then give it to one of your creatures and see
if they can use it in the way you expect. (typical data debugging: "Oops!
That club is *way* too heavy for the troll chief to wield effectively.
I guess I'll bump up is strength and then lower the weight of the club.")
One possible tool that might be nice here is an evaluate function that does
some manual checking on an object to see what it's obvious uses and problems
are. For example:
% load my.new.sword
You load the object 'my new sword'.
% builder-evaluate sword
Running builder evaluation on 'my new sword'.
Its quality score is computed at 2507, rating it in the top 23% of weapons.
It is a bit too heavy for most mortals to wield.
Its value (35000 gp) seems to be too low for its quality (sc: 2507).
The skill(s) it requires restrict it to use by: warriors paladins rangers
This item will be easy to repair and it is not expected that players will
ever find it breaking on them.
[etc]
Now, one could say that, as long as one is writing code to detect common
problems with items, one could also turn that code into a correction.
For example, as long as we have a good method to compute the value of an
item, why allow builders to specify at all? As a builder, my answer would
be "special cases"; so perhaps, by default, the server will compute a value,
but the builder code override it if they chose. Perhaps the worst example
is ungetable items, a common problem on muds that require a "take" flag on
items. Obviously the easy fix here is to change the flag to be "no_take",
but even so the server should definitely warn the builder and make sure that
that is what they wanted.
Other debugging techniques? Muds with free user programming should be
particularly concerned with this issue.
Adam - Lord British gone Geoffrey A. MacDougall