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

["Mark Wedel" <mark@icp.siemens.com>]

On Jan 17,  5:02pm, Peter Mardahl wrote:
> Subject: CF: Advice requested on implementation of maps in crossfire
> 
> Hello,
> 
>   For random maps, I'd like to be able to link to human-defined
> maps, and have the human-defined maps lead back to the random maps.

 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?

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

 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?


> 
>   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?

>   The ugliness of this technique offends me, can anyone come up
> with something more elegant?

 My thought would be to add a special character in the slaying (other map
location) file in the random map.

 For example, if we are linking to a chapel, one random map may make the
exit something like

 /human/chapel%1

 And another may make that link

 /human/chapel%2

 Where the file is actaully just called /human/chapel.  The map code
has some hopefully minor changes to know to strip off anything beyond and
including the % for the actual map path.  Having, since the name is different,
the temp maps will then be different.

 So that works for the random map -> human map (one map, multiple links.)

 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.  

 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.

 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.



-- 

-- Mark Wedel
mark@pyramid.com
-
[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]