[CF-Devel] object movers

[Mark Wedel]

 A few thoughts (which may already be addressed, I just glanced over the
message):

 1) Your changes either need to be compatible with the existing archs (ie, field
doesn't change meaning), or you should create a new arch that does this.  We do
not want to force a change such that all the movers currently used in maps do
not work.
 2) As for the bitmask of what to move - I personally really dislike inverse
logic - especially if it contradicts the other values.  so having '16 -- don't
move non-flying objects' to me just seems like a bad idea.  its just confusing
to have some fields be 'move XXX', and another field in the same structure be
'done move XXXX'.  And a decent default value can easily be set in the master
archetype.
 3) item_matched_string use pl->contr->count because it is only meant to be used
by players for dropping and picking things up.  If you use it with a non player
structure, the server will crash (and ob->contr only has value for players).  I
would think youu could take item_matched_string and make a simpler derivation of
it.  item_matched_string also returns values based on the closeness of the map
(so that if you say pickup XXXX over a large pile of stuff, it picks up the item
with the closes match) - that is not relevant for this object - if the match is
close enough in the fuzzy range, we want to move it regardless.
 4) is the bitmask value of level and slaying a AND or OR operation?  Ie, if the
leve lsays move monsters, and the slaying has orc (with say fuzzy match), does
that mean we only move orc monsters, or orc monsters + orc bodyparts?  Same
question for level to move monsters but slaying to say 'swords'.  Do nothing get
moved (unless there is a monster named 'swords')?  Not a big deal either way,
but this is somethign that should be determined - more than once in the past we
have been bitten by non precise behavioour of things like this.
 5) either as part of fuzzy match or perhaps another flag for maxhp would be
more general item types, but not exact.  ie, slaying could be 'weapons', in
which case anything of type weapon would be moved along.  Note if this is done
to include 'players' and 'monsters', then the level field would not need to
include these fields.  the dropall function has some examples of this.
 6)  In any case, the actual of integration of this should not happen until post
1.0