[CF-Devel] suggestion for flying

[Todd Mitchell]

Hi,
I have been thinking a lot about the suggestions from Mark Wedel about
no_pass and flying posted in the map mail list (below), and I have been
mulling over how much milage you could get from implementing a few different
pass conditions for map objects.  First off it really improves the value of
ranged combat, you can put in moats, broken bridges to jump over, fire over
obstacles, really use windows to good advantage by putting archers in
them... you could use this to fake elevation too (really make use of those
elevation arch walls).  This would add a lot to multiplayer maps since
characters would be able to deploy themselves to their mutual advantage (you
take the archers on the left, I'll go for the door...).  A pile of smaller
baddies with ranged attacks would be more effective, since you couldn't just
wade into them unless you could fly, and it would be more reasonable than
putting them in a room with a too-little door.  It would give flying spells
a lot more usage (jumping as well).  You would get a lot more maps where the
full-on charge would not be a good option and that is a good thing.  It
would probably break a bunch of maps however, but I don't think it would be
hard to fix them.
This same strategy could also be used for other pass conditions like a
no_phase_pass for a phase spell or giving ghosts the ability to pass certain
walls (or a ring of ghost walking perhaps).   You would certainly want to
add other pass conditons at the same time rather than work it over twice.

******************************************
FROM: Mark WedelDATE: 03/19/2002 19:55:54
SUBJECT: RE:  [CF-maps] fly_on but no_pass
 Best I know, there is no way to directly what you want to do.

no_pass applies to both flying and walking creatures, and ignores the fly_on
and
walk_on (and off) flags.

 What the walk_on, etc, flags do is control if the object that has them
automatically get applied when the event happens.  This is how the automatic
exits work - they have walk_on and fly_on.

 Similarly, this is how player movers that control one aspect would work -
you
would set the walk_on but not the fly_on.

 the walk/fly_off flags say that the space should be re-examined when the
player
leaves it.  This is mostly used for buttons (so they can see if they should
still be depressed or not).

 Now it makes a lot of sense to have a no_walk_pass and no_fly_pass - There
are
lots of things that something should be able to fly over but not walk over
(water, acid pits, etc).  In theory, I guess you should be able to walk into
those and then instantly die (drown, dissolved, etc), but that would be a
bit
unfriendly.

 It should be noted that many objects have the fly attribute - eg, most
spells
and missile weapons.  Thus, if you create a moat which things can fly over,
you
have to be careful because if there are monsters on the far side and they
don't
have range weapons, the player could kill them off quite safely.  OTOH, this
is
no worse than big monsters trapped in small rooms.

 If I was to do this, I would internally rename the no_pass to no_walk_pass
and
create a new flag called no_fly_pass.  Put the appropriate loader/saver
support
in.  If when loading a map with just the old no_pass flag, you set/clear
both of
those values appropriate.  Update all the references to FLAG_NO_PASS as
appropriate (looks to be about 30 of them), evaluating each one to see if it
should be FLAG_NO_WALK_PASS or the FLAG_NO_FLY_PASS - certainly some new
case is
needed in the actual move logic to check the objects status wrt what the
space
allows.  This would probably necessitate changing the P_NO_PASS flags in a
similar fashion.

 All of that isn't very hard - takes some work, and is a bit time consuming.
The hardest part is monster logic - right now, I'm pretty sure that some of
the
'can the monster hit the player' looks at the no pass attributes - this
would
need to get redone a bit - just because the monster may not be able to have
a
path to move to the player, it may certainly have a path to fire a
weapon/spell
at the player.