Real Time Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Relations, races and gods



Kjetil Torgrim Homme wrote:
> 
> [Mark Wedel]
> 
> >    The other way would be to extend the map object (map file header)
> >   to include more of this.  One possibility would be a 'region xxxx'
> >   field, with the details of the regions being defined elsewhere
> >   lib/regions
> 
> How about using the pathname?  I.e. /Navar/forest is in region Navar.
> 
> You could use the convention that the last capitalized component of
> the file name defines the region.
> E.g. /SantoDominion/portals/Navar/house/room1 is also in region Navar,
> if needed.

 That does require that all maps get put into the right subdirectories.  That
isn't a bad idea, but as of now, you get some maps arranged by user or other
mechanisms.

 Ideally, you probably want to do it in the individual objects structures, so if
you want to design a map with out of region characteristics (so and sos rare
import shop (which has treasurelists of another region, or maybe multiple
regions even)), you could do so.

 I don't really like the idea of relying on path names.  And having an entry in
the map header should be pretty easy to do - the only disadvantage of that is
that if you move the map to a new region, you need to update the map with the
new region (instead of it getting it automatically via pathname or whatever). 
But since you have to update the exits, that probably isn't a big deal.

  But I guess this really comes down to defaults - an easy way to have a map get
the regional characteristics without updating all the objects in the map.  And
with that, you could use several logics (use entries in object, if nothing
there, then use entry in map, if nothing there, then use pathname, etc.)
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]