[CF-Devel] object movers

[Preston Crow]

>
     
      It seems to me that the ability to move to a non adjacent square or to another
     
     >
     
     map isn't really what the player movers should be used for.
     
     >
     
     
     >
     
      The way they have been used in the past, they just move to adjacent squares. 
     
     >
     
     With the changes you have made above, I really wonder if that is what the player
     
     >
     
     movers should be used for, or if the teleporters should just be used for that.
     
     
Is there really any fundamental difference between a mover and a teleporter?

I could probably make a good argument for a teleporter with all the same
options for selecting what gets teleported.  Is there really any reason to
have a separate object?

>
     
      Player movers are obviously not a really good term anymore, since they
     
     >
     
     certainly move more than players.  I'm unsure where the line should be drawn,
     
     >
     
     but it seems pretty clear that you are moving beyond what the player movers did
     
     >
     
     and into what teleporters already do.  I don't know what teleporters are missing
     
     >
     
     so they just can't be used in this case, but it would seem that it may make more
     
     >
     
     sense to modify teleporters to have these features and not have movers do that
     
     >
     
     job.
     
     
The main thing I want is the ability to move an object selectively.  For
example, it might be nice to have the dancing trees set up so that the
movers only move trees, so the assorted ghosts and skeletons move as
normal.

As to the name, I'm calling my mover a "generic mover," as it will move
almost anything.

>
     
       Now there could be some debate on how crossfire should deal with objects type
     
     >
     
     - the current method is basically to have each object type do some fairly
     
     >
     
     specific actions, and linking objects with other objects allows for more
     
     >
     
     powerful operations.
     
     >
     
     
     >
     
      The other would be to reduce the number of object types (ignoring the
     
     >
     
     type/subtype idea in the TODO list) - just have a limited number of object
     
     >
     
     types, but one type may do many different things (ie, a
     
     >
     
     mover/teleporter/exit/trapdoor/...).
     
     
I guess I would argue that the best way to decide if you should have one
object type or several is to figure out which way leaves you with better
code.  If you're reusing most of the same code for two different objects,
it's probably better to have a single object.  If you're having too many
conditionals, then it might be time to split it into multiple objects.

Of course, that's rather subjective.

--PC