Mark wrote: > As you said, it is rather subjective. > > However, I find it preferable to look at a map someone else did, look at the > archetype, and know 'hey - thats a mover - it moves the player one space'. > > A simple solution here would be to have a function like > 'find_mover_object_match' or the like, which takes a teleporter/mover/exit (and > potentially more, like checkers), and uses the information in the object we are > matching against to see if a matching object on the space exists, and if so, > return that object. Ok, that makes sense. I'll just be sure that the fields that I do my matching against won't touch those that will be used by movers, teleporters, and such. Peter wrote: > If you muck around and break the existing implementation, I expect you > to fix all the maps! 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. Now I have some questions about the code. 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? 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? Thanks! --PC