Re: CF: Advice requested on implementation of maps in crossfire

[Peter Mardahl <peterm@langmuir.EECS.Berkeley.EDU>]

> On Jan 17,  5:02pm, Peter Mardahl wrote:
> > Subject: CF: Advice requested on implementation of maps in crossfire
> 
>  I'm guessing hypothetically you are wanting to do something like.
> 
>  town -> random map -> treasure chamber

>  And you want the treasure chamber to lead back to the random map that
> has already been created and not make a new random map?

Yes, exactly.

>  I haven't looked the code right now, but how does the random map stuff
> deal with the town -> random map?

Right now, you need to modify an exit so that it has a /! in the slaying
field, indicating "make a random map" and some parameters in the 
msg field of the exit, to define styles.

>  Obviously if I enter the random map it gets created.  However, suppose
> I leave the random map to sell some stuff off and then go back to the
> random map?  Does a new one get created, or does it already know about
> the existing one?

It stays, I think, so long as the server keeps maps alive.  I'm not
really sure of this part.  I've just used (or possibly MISUSED) 
the library's map handling routines as much as possible.  I say possibly
misused because Raphael Quinet has reported problems--which I haven't
observed on my own machines.

> >   Can anyone suggest anything which isn't an ugly hack, for doing
> > this?
> > 
> >   This is my idea of an ugly hack:
> > 
> >   1)  Copy the human-defined map to some new name.  (Allows the
> > re-use of human maps in several random maps, like re-use of some
> > small chapels, little shops, etc.)
> 
>  So it sounds like you want to use the same human generated map in
> multiple random maps but have them unique?

Yup.  Like for example, a mini-temple where characters could go to
heal up, etc.

>  Now the reverse is a bit more difficult.  If we know that the human map
> will never be loaded prior to the random map that calls it being created,
> that may not be too hard (if that is not the case, then things get pretty
> complicated, as how do we know what random map to go back to).
> 
>  But lets assume that is the case - the random map that calls the static
> map will be called first.  Then the map load function (or some portion)
> can see the % in the field and know that the static map needs to be updated.
> IF we are loading the original static map from disk, we go through and
> update the appropriate exits.  When this static map is swapped out as
> a temp map, are exits are OK.
> 
>  For updating the exits, we can probably examing the coordinates around
> whre the exit from the random map to the static map goes (ie, the 9 spaces) -
> and use those exits.  

My thought was to have static maps not have an exit back at all, but rather
have a sensible start_x start_y.  My idea was to load the static map, rename it,
and insert an exit back to the random map at start_x and start_y.

>  I don't think we want to copy - I know some people want/like to mount the
> maps stuff on a read only partition, so trying to copy may not work.  Trying
> to update the stuff we need when loaded seems to make more sense.

Perhaps it would be sufficient just to change the map path, to /tmp/random,
or something.

>  The static/human made maps will obviously need to be custom designed for
> use with random maps.  If we want to do

>  random map 1 <-> static map <-> random map 2
> 
>  That gets more difficult, as you probably want random map 2 to
> follow some of the file from random map 1.
> 
>  I wonder if it might be better to expanded the random map generator to
> incorporate pre made map segments.

Oh, I'm working on that now, but I was going to have these little sub-maps
included at random.  I see what you're saying though, I could re-used this
code to simply create a level, and then overwrite it--But I'd need to know
the dimensions of the human defined map, so I'd have to load it.
If I need to load it I may as well put an exit in it, it'd be simpler.
Alternately, these dimensions could be given, but I'd rather Keep It Simple,
for the person making random maps.

PeterM
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]