Re: CF: ideas for next experiments

["Doug wilder" <doug_wilder@hotmail.com>]

>Mark Wedel wrote:
> >
> >  Objects that return are an interesting idea..  However, there >are 
>other complications.
> >
> >  Suppose you throw the hammer, and some other monster steps in  > behind 
>the path.
> > When it returns, that monster is now in the way.  Does it hit
> > that monster, or
> > bypass it?
> >
> >  Also, what happens if the player moves after he throws it?  I
> > guess the point I
> > am trying to make here is that I can see these boomerang type > objects 
>flying all
> > over the place.
>
>     I thought of that, and I think the simple approach is the
> > best.  Don't
> > make the boomerang weapons track their owner.  It just bounces
> > back where it came from, it's not a homing missile.  (Hmm... > homing 
>missile... arrows with specific targets (slaying field) > that use magic 
>missile code to steer themselves toward their
> > enemy if one is present.  And cursed arrows that
> > loop around and hit you in the back.)
>    Anyway, when the thrown object wrapper is created, it is given a
> > return strength equal to the maximum distance it will fly.  When
> > it hits something,
> >that return strength is added to the distance remaining, then set
> > to zero, and the direction is reversed.  If the owner isn't there
> > to catch it, it will just fly in a straight line until it lands
> > or hits something else.  If it hits something on the return trip,
> > its return strength is now zero, so it just falls the the ground.
>
>
> >  Just a note - you can not predict where the hammer will show up
> > in the players inventory.  One issue when the client/server split
> > happened is that  the order of the inventory (as both what the
> > client and server think it is) will not be
> > consistent (enforcing consistently would have made things more
> > difficult, as now when the player picked some up, the client
> > would have to say to insert it before the other object or > whatever).  
>One reason the mark command came around is
> > simply because of this - before some actions (like weapon > improvement 
>scrolls)would take the first weapon in the players
> > inventory.  If the player doesn't
> > know what the order of the inventory in, taking the top object
> > would not work well.
> >
> >  anyways, that is some history.  The main point I was making here
> > is that when the object returns, where the object will show up in
> > the players inventory can not easily be determined.  In theory, > you 
>could add some flags or whatever which says 'put this on > top', but I can 
>think of a few reasons that is not ideal.
>
>     Ah, but it doesn't matter where the item is listed in their inventory. 
>Throwing takes the first valid object it finds, and
>that means the one most recently picked up.  When the boomerang
>returns, even if it merges, it becomes the object most recently
>picked up.  Try it with some different objects, like throwing
>daggers, oranges, and a poleaxe.  If you keep picking them up after
>you throw them, they stay on top of the internal list, regardless of where 
>the client lists them.  That's the current legacy of the old 
>top-of-the-inventory code.
>


NICE - buy impractical in crossfire.  With the swarms of monsters in some of 
the dungeons trying to hit one particular one in a mess would be next to 
useless. second if you threw a boomerang or other throwing weapon and moved 
from the spot so it fell to the floor. Then caused a firetrap or even threw 
a fireball spell you would risk the chance ( a pretty hefty chance it is 
too) that your weapon would go up in smoke.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.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]