[CF-Devel] object movers

[Mark Wedel]

Preston Crow wrote:
>
     
     
     >
     
      Based on feedback here and some more thoughts of my own, I've updated my
     
     >
     
      generic mover.  I actually have it coded, though I haven't tested it.  The
     
     >
     
      major changes since I last discussed it are that I added the ability to
     
     >
     
      move based on the type of an object, and I made it so that you can use it
     
     >
     
      like a teleporter, moving to a non-adjacent square.
     
     >
     
     
     >
     
      Personally, I would like to have it be able to move to another map (loading
     
     >
     
      and adjusting the timeout value of that map as appropriate), but I haven't
     
     >
     
      looked into that.  Since there currently is no way to move anything between
     
     >
     
      maps besides players, I suspect that there would be some complications.
     
     
 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.

 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.

  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/...).


>
     
      As to my code, I have several questions:
     
     >
     
     
     >
     
      What do I need to do to make sure it doesn't move things like other movers,
     
     >
     
      the floor, directors, and such?  Should I have a list of object types that
     
     >
     
      are by default excluded?
     
     
 first check would be to check for FLAG_NO_PICK and FLAG_FLOOR (or it might be
FLAG_IS_FLOOR) - these should probably not be things to get moved.  Likewise,
invisible objects should not get moved.  I don't know if that will cover all
objects or not - certainly the checks will need to be hard coded into the
server.  using object types is not really ideal, as I can certainly see object
types getting added and the list not being updated.

>
     
     
     >
     
      In using these, how much do I have to worry about CPU time?  If no object
     
     >
     
      arrives on the same square as the mover, will the mover still have to scan
     
     >
     
      through the objects on the square?
     
     
 Depends on how the mover operates.

 If the mover operates via the walk_on/fly_on flags, then the apply function
will get called with the object that entered the space.  Its then up to the
coding in the apply to call the mover function with the appropriate object.

 If the mover operates via a timed method (ie, time .1 so it does something
every 10 ticks), then in that case it will need to look through all the objects
on the square.  there is no tracking to no if something has entered the square,
and if something has, no way to know what it might be.