> PeterM wrote: > >I think your proposed generalization makes > >a great deal of sense. You need one more flag: > >8 -- paralyze living objects so they MUST move > > as directed > > > >Are you going to code this? > > I suppose I should try coding this. Before I start, though, we should agree > on the design What you have proposed looks good to me. My only other request is that you make editor/maps/picks/special have some reasonable default movers in it. PeterM > Currently the paralyze status is determined by attacktype and hp. It seems > to make sense that we should set the attacktype to paralyze for this. I > suppose we could allow other attacktypes to have movers that cause dammage > of various types (for example, a lava stream that causes fire dammage). On > the other hand, I don't see as that needs to be a part of the mover, so > unless someone sees a good reason to implement that, I'll leave it out. > > So I'll create a new generic_mover object. Once people are happy with it, > I'll convert the player_movers over to the generic_movers. > > Here's how it's slated to work right now (mostly based on the player_mover): > > sp: direction in which to move (0 for random) > speed: how often to move > lifesave: disappear after hp+1 moves if set > hp: number of moves (plus one) before disappearing, if lifesave is se > t. > attacktype: paralyze when moving > maxsp: how long to paralyze (relative to victim->speed/speed) [default t > o 2 if zero] > level: bitmap to determine which objects move; add the values together > 1 -- move monsters > 2 -- move players > 4 -- move non-living objects > 8 -- move flying objects (was maxhp in player_mover) > 16 -- don't move non-flying objects > slaying: only move objects that match the text string > maxhp: control how slaying matches are performed: > 0 -- ignore slaying field > 1 -- exact match > 2 -- fuzzy match [similar to item_matched_string()] > > Notes: > > The only reason that level 16 is not "move non-flying objects" is because > it would probably always be set. This way it can be ignored most of the > time. > > For the fuzzy slaying match, I would use item_matched_string() to do the > match, except that it uses pl->contr->count. I may be missing something, > but I think we want to ignore counts here. > > --PC > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel