[CF-Devel] object movers

[Mark Wedel]

Preston Crow wrote:

>
     
      Just to be clear: I'm using a new object type (63, which was unused) for my
     
     >
     
      new mover.  The plan is to get it fully-tested (it's already working for
     
     >
     
      the cases I've tried), and get it included in the server.  The next step is
     
     >
     
      to create new arch types for the new mover (and set up crossedit to make
     
     >
     
      them available).  Then I convert the existing maps over from using the old
     
     >
     
      mover to using the new mover.  Then, if everyone is happy, we eliminate the
     
     >
     
      old mover and associate arch types.
     
     
 Is there any good reason to actually remove all the old ones?  It just seems
that that would be a lot of work, and if the movers and code still works, why
not leave them in?

 More reasonable may be to make new mover icons (really just change the color),
so you can tell if it is an old mover or new one.

 Certainly, if maps can benefit from the new movers, update them.  And perhaps
as updates are done to old maps for whatever reason, also update to the new
movers.  The old movers support would need to stick around for some amount of
time simply because there may be non standard maps that use them.


>
     
      As it is now, the mover works by having a speed.  As I understand it, that
     
     >
     
      means that it will periodically scan through all the objects above it and
     
     >
     
      move them if they match the move criteria.  If I drop a few hundred
     
     >
     
      non-matching items on a mover, this could be bad for performance.  It would
     
     >
     
      make a lot more sense to have the object activated anytime something
     
     >
     
      changes on that square that might matter.  How should I go about this?
     
     
 set the walk_on and fly_on flag.  In this way, whenever something walks or flys
onto the space, the apply code gets called, and you should have a case statement
for your mover in the apply loop to then call your processing (the object that
entered will get passed to apply as well I believe)

 Your understanding of using speed is correct.

>
     
     
     >
     
      Someone suggested the possibility of having a mover have a connected value.
     
     >
     
      Can someone give me an outline of how the code handles connected objects?
     
     
 You really want to look at common/button.c.  Typically, op->value controls if
the object is active or not (but its really up to your mover code to look at
that).  but you would need to put a case statement in tehre to deal with your
movers.  Some also change animations or have other special affects when
activated (ie, set something else so they can't be de-activated, or if so they
activate only once, etc)