14 Feb, 2009, boblinski wrote in the 1st comment:
Votes: 0
http://gt.webvis.net/emforest.txt

Can anyone help me in what to do to get this area implemented onto QuickMud..

Thanks in advance.
14 Feb, 2009, JohnnyStarr wrote in the 2nd comment:
Votes: 0
The format is simliar, but not quite there.
QuickMud (if you have a stock version) just uses stock ROM files.
If you inlcude this file and try to run it, what error messages do you get in your log?
Have you tried?
Whenever formatting an area file i do my best to compare it to the format guidelines.
Try looking in the (doc) folder and looking into the HOWTOs of area building.
Compare it to your file, make changes as best you can and then try to run it.

Anytime you add a new area file you will probably get bugs due to bad "vnums", this will be
refferences to other area files room vnums or objects or mobs that are refferenced but not included in your mud.

As a rule of thumb, i try to "encapsulate" all objects rooms and mobs in my area files if possible. This creates a more "modular" approach.

Hope this was at all helpful.
15 Feb, 2009, Skol wrote in the 3rd comment:
Votes: 0
Same here on encapsulation, I even coded it into the OLC so that builders didn't take mobs/objects from other areas and mess up things if the load order changes.

The area looked more like a Merc area #AREA instead of #AREADATA, try comparing it side-by-side to a regular ROM area and matching up KEY's.
15 Feb, 2009, David Haley wrote in the 4th comment:
Votes: 0
I've always found it silly that every area has to recreate its own iron long swords, its own wooden chairs and tables, and so on and so forth. Having a centralized catalog of objects like that not only reduces duplicated work, but in doing so it also makes it far easier to manage the world's equipment.
15 Feb, 2009, Sharmair wrote in the 5th comment:
Votes: 0
DavidHaley said:
I've always found it silly that every area has to recreate its own iron long swords, its own wooden chairs and tables, and so on and so forth. Having a centralized catalog of objects like that not only reduces duplicated work, but in doing so it also makes it far easier to manage the world's equipment.

Agreed. If you are going to release an area it might make sense to have it self contained, but if you are
managing a MUD world as a whole, it makes a lot more sense (at least if you want a good world IMHO) to
have some consistency in objects and mobs.

The load order should not really matter (room exits don't seem to have a problem in any codebase I am
aware of). In the code I work with, object and mob references do not cause bugs on load, but will bug
if they don't exist on reset. And of course room exits to nonexistent rooms are removed. I also have
developed a relative relocatable vnum syntax for use for vnum references in area files (and on the MUD),
but that is really another issue.
15 Feb, 2009, Skol wrote in the 6th comment:
Votes: 0
DavidHaley said:
I've always found it silly that every area has to recreate its own iron long swords, its own wooden chairs and tables, and so on and so forth. Having a centralized catalog of objects like that not only reduces duplicated work, but in doing so it also makes it far easier to manage the world's equipment.


No kidding!
I've considered making a stock 'equipment.are' file that has all of the 'standard' equipment like that, and allowing those to be reset everywhere. (Then simply have the objects include 'area' in structure so that identify/lore can note where it was made).

Fully makes me wish the game was level-less though. I guess that's one of the issues between a 24/7 computer game vs a game ran by a human who can say 'um, no you can't give the +12 longsword from your hero character to your new level 1 character… heh.
0.0/6