>Kerry, >This seems like a lot more over-head then just calling a sendSprite to >itself. I think i would prefer "containing" the functions to the sprite >itself, rather than having to create/distroy an object for each sprite. But >could this potentially cause errors or redundencies?
Actually, it would probably be less overhead. The object just takes up some memory for its properties--it's not executing all the time. You could run some tests, but I suspect that referencing an object's properties would be faster than sendSprite. You could have a behavior that you attach to the sprite itself, and create the object on beginSprite. Then the other behaviors would just need the reference to that object. Or maybe I'm misunderstanding what "sharing properties" meant. I envisioned a bunch of behaviors with properties in common. If you just want to know the state of a property in another script, use call. >I guess i was kinda hoping there was something simple in director's >architecture that i was missing for "sharing" properties between behaviors >on the same sprite? No, it's actually just the opposite. The whole point of properties is encapsulation--they are specific to a an instance. That way you can use one script, attach it to 200 sprites, and they each contain their own data. In fact, when you create an object, all you are really creating is the data for that object. If you have 10 objects created from one script, you have 10 sets of data, but only one instance of the code itself. Cordially, Kerry Thompson [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]) Lingo-L is for learning and helping with programming Lingo. Thanks!]
