[CF-Devel] Post-release development

Wed Jan 12 01:45:42 CST 2005

Todd Mitchell wrote:
>

      This is still a long standing wish of mine to see this.  There is I

     >

      think, a lot of discussion in the dev archives about it.  I still thing

     >

      it would be not too diffucult to do (I playing with it a while ago -

     >

      making some a changes in arch_blocked() and get_map_flag() but I ran out

     >

      of brains) but maybe more difficult than I think.  The portion you

     >

      didn't mention is that blocking bitmasks have to be matched up the

     >

      object movement type flags and there needs to be some overlap

     >

      (flying/swimming).  It is in the order of a rather big change in the

     >

      game however unless new arches were made and the old arches phased out

     >

      since it would break a lot of maps.  It would also really impact

     >

      gameplay.  It would make a lot more neat fun things possible however :)

  Right - you really don't want to hardcode values in that are explicity checked 
in the code (I think this is a spell, so see if spells are allowed).

  By allowing the bitmasks to be matched up with movement types in objects, this 
makes the system much more extensible - want to add a new movement type, it just 
means updating some archs.

  From the list below, I do think it perhaps need to be generalized some.  For 
example, jump should either be considered walking or flying (probably the later) 
- it probably doesn't need to be its own movement type.

  The real problemw ith this is that this is reverse logic from what we have 
right now - right now, by default, all movement is allowed unless otherwise 
specified - reversing to the 'nothing allowed unless specified' means pretty 
radical changes to most any archs (or having implicit defaults, which usually 
causes problems later on).

  Scripts could certainly be be written to update all the archs.  And I don't 
really like the idea of negative values (no_fly, no_magic, etc).  The problem 
with negative values like that also mean that adding new movement types isn't as 
easy, as in a sense, by default all objects don't need that specialized new 
movement.

  so probably the easiest thing is to make the default that everything be 
allowed (0xffffffff), with certain historic keywords negating it (no magic 
clears flags, no_pass sets that to zero, etc).

  The other complication is for the objects that move - presumably there move 
type, for lack of better term, represents all the movements that they are 
capable of, not all they are actually using (eg, a dragon for example might have 
fly|walk, representing it can fly or walk, not that it needs to do both).  I'm 
just trying to think if there are any cases where these values would in fact 
have to be ANDed together (eg, the object question needs to be able to do both 
type X and Y on a space).

  I'd also, through some method, also like to incorporte the slow_move stuff 
into such a bitmask, but that is probably a seperate bitmask (move_modifier or 
something), which can then get matched up against items/skills that help negate 
the penalty.

>

     >

      On Tue, 2005-11-01 at 10:30 -0500, Preston Crow wrote:

     >

     >>

     Unless I missed it, we still don't have a bitmap for floors indicating

     >>

     what can pass over them.  Something like:

     >>

      bit  feature

     >>

       1   allow walk

     >>

       2   allow jump

     >>

       3   allow dimension door

     >>

       4   allow levitate

     >>

       5   allow missiles (including magic projectiles)

     >>

       6   allow spell area effects (turn off for counterwall effect)

     >>

       7   allow view

     >>

     >>

     One example use would be an arrow slit.  Set only bits 5 and 7, and put

     >>

     a director on the same square, with some dark elves behind it.

     >>

     >>

     Another example is avoiding anti-magic zones when all you need is to

     >>

     block dimension door.

     >>

     >>

     If someone creates real transportation, such as boats, that would be

     >>

     another bit.

     >>

     >>

     --PC

     >>

     >>

     >>

     >>

     _______________________________________________

     >>

     crossfire-devel mailing list

     >>

      crossfire-devel at lists.real-time.com

     >>

      https://mailman.real-time.com/mailman/listinfo/crossfire-devel

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel