At 12:00 AM -0800 11/9/98, Ryan Davis <zss at ZenSpider.com> wrote:

>1) I wrote a method called touches: which is based on some of the logic in
>moveTowards: in order to have a test for collisions (which has obvious
>value to a 9 year old programmer-wannabe). I am now able to create a cat
>and mouse simulation where the cat can catch the mouse and make it attack
>(the mouse turns red when touched, the cat makes a noise when it touches).
>But the mouse code would be better if he could detect if ANY cat is
>touching him... Can it?
>
>checkBleeding
>   (self touches: (self class refPlayer61)) " <--- here is the problem"
>	  ifTrue:
>		[self setColor: blood]
>	  ifFalse: [
>		[self setColor: normal]

If you make every cat be a monochrome object of the same distinguished color, then the method #seesColor: will do exactly what you want, and, even better, it will do it not by comparing bounding boxes but by actually looking for pigment overlap.

Moreover, you can do this script entirely within the tile-scripting regime, if you prefer.  The script would be:

    TEST
        mouse isOverColor   catColor
    YES
        mouse's color <-   bloodColor
    NO
        mouse's color <-   normalColor

(however, sketches don't have a single "color", so the "mouse's color <- bloodColor" assignment will only work if your mouse is *not* costumed as a SketchMorph; you could use a Polygon or curve instead).

Aside: general collision-detection will be coming soon.

------

>2) I don't understand the model too well... From the debug menu, I learn
>that the mouse is an instance of StarMorph. But when I edit one of his
>methods it is an instance of a subclass of Player... Is this an analog to
>View and Controller?

The same Player can at various times wear various different costumes.  Each costume can belong to a different subclass of Morph.  The Player abstraction allows code and identity to be borne by something that remains the same amidst the potential swirl of changing costumes.  

As long as your're simply constructing surface graphics, you'll operate entirely in a world of morphs.  Whenever you wish to script a morph, a Player subclass is created for you, and it's that Player subclass that bears all the scripting code.

(The Player is somewhat analogous to Model, the Morph (aka Costume) to View/Controller.)

-----

>3) Is there a registry of known players in a given morph? (possibly a
>shorter version of #1).

Yes, but it's maintained under the covers.  When you construct scripts for a given Player, every other Player that is referenced by the those scripts is kept track of; that's what the refPlayerxxx things are about.

You can also define your own instance variables, of type "player", which hold on to references to specific other objects, and you can set their values by direct manipulation if desired.  If it's not obvious how to do all of this, please holler.

-----

>4) I assume that the costumes are akin to sprites? That way I could have
>several different costumes for a spaceship or car and have it rotate
>through them??? How?

The standard technique for doing this at present is to have the collection of variant costumes reside in a PasteUpMorph that you're using as a "holder".  To do this, get a PasteUpMorph (playfield) and choose "behave like a holder" from its "playfield options" submenu.  Place the variant costumes within it.

To get an object (e.g. a "spaceShip") to animate by switching from one to another of the variant costumes, use a script patterned after the following:

        holder's cursor <- holder's cursor + 1.
        spaceShip look like holder's valueAtCursor

The idea is that the "cursor" is an index into the holder's collection of subparts; holders's "valueAtCursor" is a reference to the element in the holder that is currently "selected".  The "look like" script says for its receiver to wear a costume that resembles the costume worn by that selected element of the holder.

-----

>5) Is there some clean way to get all my changes saved to a text file? I
>found the save morph, but they are at least partial binary files...

The short answer here is no -- not yet, anyway. The scripts often refer to specific objects (e.g. "car move toward trafficLight") and this is not very straightforward to represent in a naked fileout.  The morphic "save files" are in essence persistent objects.

------

>6) Any way to automatically clean or not generate these:
>
>!Player5 methodsFor: 'anonymous scripts'!
>xxxScript7
>	^ self! !

An "anonymous script" is a script created on your behalf (through your work with tiles) which has not been "named and saved", and has not yet deleted.  

Our idea here is that it's just too blocking to the imagination if you have to think up a name for a script before you can play with it and see how it behaves.  So we support the idea of constructing scripts without names.  Internally, of course, they have to have *some* name, since they're represented by actual Smalltalk methods.  Thus the xxxScriptn methods.

To get rid of such methods, just delete the corresponding Scriptors (by hitting their pink "X" dismiss buttons).  If you're seeing scripts like the one you mention, they're obviously empty, which means that graphically they are script shells that currently have no tiles in them.

If you're seeing such vacuous methods lingering in your image even though you thought you'd deleted the scripts, it's probably because you didn't delete the scripts using the pink "X" on the Scriptor.  A lingering bug in the system is that if you delete a script-editor by any other technique (e.g. hitting its "dismiss" halo handle or dragging it to the trash), the corresponding method is not deleted.  This is obviously something that we need to fix!

------

>7) I can name a player in the debug menu, can I have something rename the
>class?

No, sorry.  For the moment, the "reality" is the actual objects on the screen and their palpable state and behavior.  The oddly-named classes are privately maintained under the covers to support that external reality.  As we move forward with our scripting experiments, we are conscious of the need for a convergence between the user-illusion reality and the under-the-covers reality.

(Incidentally, note that to name a player, you should either do it in a Viewer [click on the player's name at the top of the viewer, backspace to delete unwanted characters, and type the name you want] or in the object's halo [click on the name at the base of the halo, etc].  I believe that the ability to name the object in the "debug" menu is a throwback to earlier times that operates outside the scripting regime and probably will not do everything you hope it will.)

------

Thanks for your interest in our early experiments in morphic scripting.  Obviously, this work is in a preliminary state; it does a few things well and many other things not-so-well or not-at-all.  At the moment, it's much more suited for the presentation of suggestive demos in the hands of people who already know precisely what they're doing, and not really well-suited at all to the true novice user, nor to the accomplished Smalltalk programmer who wants to be able to remain in complete control of everything.  As time goes on, we intend to evolve this facility outward in both of these directions.

  -- Scott