[crossfire] Server map redo: movement types

[Mark Wedel]

Nicolas Weeger wrote:
>>
     
     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
     
     >
     
     
     >
     
     
     >
     
      Sounds like a great proposal.
     
     >
     
      I'd tweak it slightly, having MOVE_FLY_LOW and MOVE_FLY_HIGH:
     
     >
     
      first is your regular levitation, flying over jungle and water
     
     >
     
      maybe, second is flying over high mountains.
     
     >
     
      Let's not forget also MOVE_CROUCH :)
     
     
  How do we differentiate those, or maybe the question is what has 'move_fly_high'?

  Do we map everything that has flying right now to move_fly_low?  spells and 
whatnot?


>
     
     
     >
     
      I'd say yes, we should warn player, directly or not (ie "you
     
     >
     
      hate water, don't want to drown" => hint hint: learn to swim!).
     
     >
     
      It could be nice to also either have the player automatically
     
     >
     
      fly over an obstacle (for instance), or get a message
     
     >
     
      (something like "the wall is too high to walk on" => hint
     
     >
     
      hint: try flying! :p). This way players won't need to always
     
     >
     
      fly or have to try all solutions to get over walls.
     
     
  My thought on how to handle this is look at the msg field of the object - if a 
player is unable to move onto the space, look for the object preventing him and 
print the message.  Thus, they can all be customized in objects, not the code.

>
     
     
     >
     
     
     >>
     
       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'd say handle as it is now. Player is assumed to walk, unless
     
     >
     
      using levitation spell/skill/item.
     
     >
     
      This then means dragons should be able to levitate (skill) and
     
     >
     
      cast spells, of course (not sure it's possible).
     
     
  But current method doesn't work well in the new mode.

  I consider it completely reasonable that a player may have multiple move types 
set.  It may be he has to use a skill or object to get the flying, but if we use 
the same logic we do for objects, these abilities would OR with his basic 
(archetypal) movement type, this giving him several.

  And for things like swimming, this may be needed for it to work at all 
sensibly - if you have both MOVE_WALK | MOVE_SWIM, things just work fine - you 
move into the water and start swimming, and move out of hte water and start walking.

  To mimic existing code, there'd basically need to be special logic - if 
move_type & MOVE_FLY, move_type = MOVE_FLY, eg, strip out any other move types 
the object has.


>
     
     
     >
     
     
     >
     
      It could be interesting to do, but maybe too complex.
     
     >
     
      But it could be fun, imagine a big jungle and a small path you
     
     >
     
      can follow to go faster - alas, monsters lurk around!
     
     
  The slow penalties is an object attribute, so you can set up the paths.

  What I was talking about was different penalties based on move type.  If we 
take that jungle example, it has move_slow MOVE_WALK.  It may be reasonable to 
say that you can't fly as fast also, so should have move_slow MOVE_FLY | 
MOVE_WALK - the problem is that either mode of transport would get the same 
movement penalty.

  Actually, perhaps one way to handle this is multiple objects - the movement 
penalty itself probably doesn't have to be stored in the object (or could be 
stored in an array).  So you could have something like:

object move_fly_penalty
move_slow MOVE_FLYING
move_penalty ..
end

  and put that along with the jungle.


>
     
      I'm thinking of tweaking the collect.pl script to accept names
     
     >
     
      instead of values for flags. So instead of having "attacktype
     
     >
     
      5940423" you'd have "attacktype fire cold poison". The
     
     >
     
      collect.pl changes that to correct numerical value.
     
     >
     
      This way the loader doesn't have to handle those gory details,
     
     >
     
      no performance hit :)
     
     
  Doing that for attacktype certainly makes sense.

  I'm not concerned about performance hit vs doing it in collect - after all, 
archetypes are only loaded once, so if a little slower, not a big deal.

  However, keeping that parsing code out of the loader would be nice.

  But for the move types, since the naming can would be consistent, minimal 
complications - it'd be done something like the body_ values.