von DAniel am 22.Dezember 96 um 15:26:42:
zu: actorList manager von Daniel am 22.Dezember 96 um 15:17:47:
Nothing prevent you to construct a hierarchical structure of objects
activated by the actorList.
In his example W. Dana Nuon tell us that he has various objects that acts
as "managers" of other objects referenced by those objects managers. Then
he has a "run" handler that activates those managers, and then each one
activates in turn the objects they manage on a selective basis, so only a
few of the managed objects (or low level objects) receive a message during
a frame move. In his previous implementation, ALL the objects were in the
actorList and each one received the stepFrame message on each frame event.
Instead of a hierarchical list, he had a flat list, something not very
effective when he have to work with a lot of objects.
What I don't understand is why W. Dana Nuon does not use the actorList
instead of his "run" handler: place all those object managers in the
actorList and only those say 6 or 8 managers receive the stepFrame event
and then dispatch the message to the appropriate managed object on a
selective basis. So drop you "run" handler and come back to using the
actorList.
What is the advantage of this? The stepframe handler is sent automatically
to the objects contained in the actorList each time the play head makes a
move. You don't have to put a "run" handler in the score scripts. Director
manages it automatically for you.
Another trick detailed on the list recently is to put ONLY ONE object in
the actorList and have that object controlling all the other objects when
it receives the stepFrame message. You can then construct a hierarchy of
objects at various levels:
- the ActorList contains ONE object, a virtual actorList manager.
- the virtual actorList manager object has a list that contains 6 or 8
objects managers and ALL those 6 or 8 objects receive a message when the
actorList manager receives a stepFrame (or only a subset of those at will).
- each one of the object managers have a list containing other specialized
objects that receive or not a message, depending on conditions coded in the
parent script of that object manager.
This way you can have both the benefits of the actorList and of the
minimization of the number of stepFrame messages sent between two frame
moves you asked for. This has also another benefit: you can interrupt
easily all the stepFrame messaging activity by removing temporarily that
unique virtual actorList object of the "real" actorList (and also this
eliminates a frequent cause of Director crashes: altering the content of
the actorList during a stepFrame event. If you have two objects and more in
the actorList and delete one of them from that list, you are at risk of a
deferenced pointer crash if Director is currently at a stepFrame event).
Daniel Devolder
D. Plänitz