[MUD-Dev] Room Generation

[Eli Stevens]

----- Original Message -----
From: "Nathanael Dermyer" <NDermyer at HNTB.com>
Sent: Friday, January 19, 2001 10:22 AM


> On the mud I admin on (an LP Mud, running aamylars 03.02.01 at 128, on a
> tw lib) we have a "virtual" room system where you feed a compiler a
> file containing a map, a list of what the symbols in the map mean, and
> the appropriate code to create the files.  When the area initializes,
> it builds virtual rooms (meaning no actual file exists on the disk,
> only in memory).  The problem here, is when the map is large (meaning
> bigger than say, 15x15) the virtual compiler blows the max_eval.
>
> The max_eval is not the problem.  I don't like virtual areas.  Plus
> the areas I typically create only have several similar rooms, so
> virtual areas are actually kinda worthless to me.  What I'm wondering
> is if anyone has some sort of mechanism (perl script, C program, VB,
> whatever) that will accept some sort of map file and a list that
> defines what each map symbol means, and spews out individual room
> files.

[Sample snipped]

Perhaps instead of trying to convert the raw map/symbol files to room
files, you could write a function to move the in-memory room to a file.
This would save you having to parse the map file, figure out "if line 4 has
an 'X' in column 7, which rooms need to be linked," etc.  All of that can
be taken care of by the virtual area code you already have.

Instead, if you can take the in-memory room and write it to disk, it should
be fairly straight forward.  The main challenge would be to make sure that
you get the text format of the room right.  Once you get that, just have it
loop over all the virtual area rooms that you want to convert after they
have been loaded into memory...  That may not be trivial, but it should be
a lot easier to code.  :)  (Is this clear?  I cannot tell if I am stating
my idea well or not.  If not, I can try and explain in more detail... :)

> Has anyone done anything sort of like this?  I'm in the middle of a C
> book, so perhaps by the time I finish I'll know enough to kludge
> something out that works how I need it to.  I'd rather have something
> *now*, though, being the impatient type!

Somehow I suspect that both the unusual nature of the problem and the
implementation details of your particular flavor of area files would limit
the usefulness of anyone else's code.  Unless your virtual areas are a
standard feature...?  I am unfamiliar with LP mud internals, much less
specific driver/libs.  :)

--
> Eli Stevens <wickedgrey at wickedgrey.com> wrote:
> > What am I doing?  I'm typing to an empty computer.
> I don't understand...
'Cause there is a dead man on the other end of this email.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev