[crossfire] Server map redo: movement types

[Mark Wedel]

  This mail describes my current proposal on changing the movement types.  Some 
areas are open for discussion.

Basic change: Allow more extensible movement types, as well as blocking of 
specific movement types.

All fields below use a bitmask to represent value, similar to how the attacktype 
works.  These would be defined like:

MOVE_WALK	0x1
MOVE_FLY	0x2
MOVE_SWIM	0x4
etc

move_type: This is a bitmask that represents all the movement types the object 
is capable of.  There is a clear analogous value right now - default is 
basically move_walk, and if creature is flying, that would be same as MOVE_FLY. 
  However, this is a bitmask that represents available movement types of object, 
so serveral values could be set.

move_block:  Represents what movement types are unable to pass this space. 
Similar to no_pass (which will likely remain for backward compatible reasons and 
not allow anyting to pass).

  The code to handle this would basically be:

if ((space->move_block & op->move_type) == op->move_type) space is blocked

  Thus, a space has to block all movement types player is capable of (otherwise, 
it can be assumed object is smart enough to do what is needed to move to new 
space).  Eg, if you can fly, you fly over the obstacle if that is all that is 
blocking.

  Note however for the player to fly over, they need to have equipped an object 
tht lets them fly (unless it is a native ability), as at least as players go, 
may not be as useful.

  Question: Do we want to print messages and/or add support of messages that 
give some clue as to possiblity to move but player lacks ability.  Eg, player 
trys to walk into water and gets message 'you lack the abilility to swim' or 
something, and a player tht does have swimming but tries to swim into deep water 
maybe gets a message like 'you can't swim in the deep water - it is too rough' 
or something?

move_on/move_off:  Analogous to the walk/fly_on/off flags.  Basically, if you 
have movement type and move onto a space, walk on function is called, if move 
off, walk off function is called.

  I'm mixed what to do for multiple move types.  If a player has both fly and 
walk movement types, what should happen when he walks on a trap door?  Nothing 
at all?  Or activated?  What about when he walks on a teleporter/shop map - same 
question?

  I'm thinking the logic should be like the block code above - players generally 
avoid the hazards.  In the case of shop mats/teleporters, players could manually 
apply them.  Perhaps keep the enforcement of 'can't be flying to pick stuff up', 
so players could always put those nifty items on top of traps to try and lure 
the players.

move_slow: Like move_block, bitmask that represents slower movement of that 
type.  Walking though jungle should be pretty slow, and flying over it shouldn't 
slow one down much.  right now, the actual penalty is same for all movement 
types, so not sure if there is a need desire to be able to specify different 
move penalties (10% if flying, 60% of walking, etc).

  Loading/saving details:
On saves, I'd expect all these values get saved as the name above and bitmask 
mentioned.

However, for loading, I'm thinking of allowing more general naming, so instead 
of having to do:
move_on 7

You could do
walk_on 1
fly_on 1
swim_on 1

  And the loader takes care of setting up the bitmask.  I mostly see this as a 
convenience for archetype writers - using fill names is much easier than having 
to look up bitmask, convert, etc (ok, with just a few values, not hard, but 
still).  I'm not concerned about saves, as the editor should be able to nicify 
this is necessary.

  This also has the advantage of keeping that backwards compatilibity.  Some new 
ones would be added like walk_move, fly_move, fly_slow, etc (basic idea is to 
keep the names consistent so parsing is easier).