No Subject

["Mark Wedel" <>]

________=22Re=3A_CF=3A_Multi-square_exits_=28was_Re=3A_CF_scorn_maps=29=22?=
 =?iso-8859-1?Q?_=28Jan_12=2C__5=3A27pm=29?=
References: <> 
	<> 
	<> 
	<>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: =?iso-8859-1?Q?Rapha=EBl_Quinet_?= >,
 Crossfire Mailing List <>
Subject: Re: CF: Multi-square exits (was Re: CF scorn maps)
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.19901121610.ZM9293.eng.pyramid.com"


--PART-BOUNDARY=.19901121610.ZM9293.eng.pyramid.com
Content-Description: Text
Content-Type: text/plain ; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Zm-Decoding-Hint: mimencode -q -u 

On Jan 12,  5:27pm, Rapha=EBl Quinet wrote:

> Suggestion: make multi-square exits point by default to "destination +
> offset from head" or something like that.  There could be a flag in the=

> archetype that would be used to decide if this mechanism should be used=

> instead of the old mechanism (all squares point to the same destination=
).
> The latter is probably desirable for houses and shops, which are also
> multi-square exits.

 This would probably work out OK.

>
> If this is integrated now and documented, then hopefully this will not
> get unpredictable results when objects are redone.  ;-)

 If only stuff with the new flag works that way, it shouldn't cause any
problems.

>
> If I am not mistaken, it should be enough to add this feature in the
> editor, right?

 Better to do it in the server.  It is conceivable that sometime in the f=
uture,
when multipart objects are saved, it will just save the head and not all =
the
parts.


-- =


-- Mark Wedel


--PART-BOUNDARY=.19901121610.ZM9293.eng.pyramid.com--

-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]