Mike,

I'm not sure whether anyone ever answered your queries -- if so, please excuse the redundancy.  I just wanted to make sure this didn't slip through the cracks.

-----------

>... But I wasn't able to use your (Dan's) code as written -- I
>couldn't evaluate "World" (or any variant of it that I tried) in the
>workspace...

It sounds as if you're operating in a morphic window in an mvc project.   "World" is only non-nil when you're in a pure morphic project; in an mvc project, there can be multiple sibling morphic worlds open concurrently

-----------

>What can I use in a workspace embedded in a morphic world to refer to
>the world?

If you're in a workspace in a morphic window within an mvc project, there is no direct variable that indicates the "world".  However, if you really need it you can get at it by the following awkward expression:

     ScheduledControllers activeController view firstSubView model

-----------

>2) My script on the ellipse leads me to believe that "self" in any script
>on a morphic object is really the Player object, the costume of which is
>the morphic view.  Is this correct?

Yes, precisely.

-----------

>3) In Morphic, are there always paired Players and Morphs (like models and
>views)?  

Mostly you have just plain morphs.  A companion Player is created alongside a Morph when needed, e.g. for scripting.

-----------

>Can a Player have more than one Morph?

Yes.  The set of morphs belonging to a player can be thought of as its wardrobe of possible costumes.  Various aspects of the ui -- e.g. in the halo menu, "Viewers", and in scripts -- allow you to change costumes.

-----------

>4)  What's the namespace used by the workspace embedded in a morphic world,
>i.e., is there a Project globals dictionary?  I noticed that I could
>execute assignments to undeclared variables, e.g., "foo := ...", in the
>workspace without complaint and retrieve their values later.  Where are
>these associations stored?

The answer here is the same for morphic workspaces as it is for mvc workspaces.

You can deploy undeclared variables in any workspace.  The "model" of a workspace is a Workspace object which has its own private dictionary of bindings.  Workspaces automatically create local bindings for any recognized variables encountered during a parse within them.  Beyond these local bindings, the namespace in a workspace consists only of the system globals.  Projects don't have their own personal globals.

-----------

Hope these answers help.

  -- Scott