Re: [CF-maps] fly_on but no_pass

[Mark W. <mw...@so...>]

 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.