Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
Locked
Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
 
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
In reply to this post by Offray Vladimir Luna Cárdenas
Hi, Offray,
> We are also stuck on how to make copies on an eToy, so we work only on > one, defining scripts, and animations and the we put the amount we > want > in the game. We know about the green halo button for copy, but we > would > like to use not graphically but from inside of a script. We have tried > to use the message eToyName's copy but it can't be dragged on a > script. > The animations defined for the first eToy are not copied when we > copy it. copy of Car (strictly speaking a "sibling", viz. a fellow instance of the same class as Car.) However, if you don't *place* that copy somewhere, you won't see it. The standard idiom for placing an object somewhere via script is to tell the *container* in which you place it to "include" it. Here's a typical usage pattern: ------------------------------------------------------------------------ ------ > Pdt: It seems that we're reaching some kind of stress point of the > eToys. Would be nice to have the possibility to go from them to their > code, but the scripts of the eToys seem to have only a code view, > but is > not usable for writing new code. Hmm, well, etoy objects are first-class Smalltalk objects, and etoy scripts are real, first-class Smalltalk methods, belonging to real, first-class Smalltalk classes, and if you switch any script's Scriptor to textual mode (by clicking on the checkbox in the Scriptor's header,) you can enter any Smalltalk code you wish there. A plausible practice is to use tile scripting for everything in a project that *can* be readily done using tile scripts, then to supplement this with conventional Smalltalk code in one or two places where necessary. Textual coding can actually be done using two kinds of scripts: First, as mentioned above, you can write textual code for any existing "etoy script" that you see in a Viewer by switching its Scriptor to textual mode via the checkbox. Secondly [and this is not so well known] you can open a conventional Smalltalk browser on the class of an etoy "object", and using that Browser you can not only see and edit the etoy scripts, you can also add any other methods you wish, including methods with multiple arguments (whereas etoy scripts are limited to 0 or 1 argument,) mid- method returns, and many other things that you can't directly obtain using tiles alone. To get such a Browser, in the Viewer's menu choose "more..." and from the auxiliary menu that pops up, choose "browse class." I'm not claiming that this is the ideal way to transition from e-toy tile-scripting to full-scale Smalltalk, if that's what your goal is -- indeed, it may lead to false expectations; I just wanted to make sure you're aware of the availability of these two ways of blending tile-scripting with writing unrestricted Smalltalk code. It would be interesting to hear of experiences people have had with this kind of hybrid approach. Cheers, -- Scott _______________________________________________ Squeakland mailing list [hidden email] http://squeakland.org/mailman/listinfo/squeakland |
unknown.png (36K)
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
In reply to this post by Offray Vladimir Luna Cárdenas
Hi, again, Offray,
> My students and me are working in a kind of basic pingus/lemmings > clone[1] using eToys. We would like to use the mouse pointer to > select a > eToy and execute an script. The idea is to make click on a button, for > example the one with the message "Detener al otro" ("Stop the other") > and then select the eToy who would have this script enabled using > the mouse. Perhaps you'll find the techniques illustrated in the attached project useful for your purposes. In the project, all the star-lemmings (which are all siblings of one another) understand the messages "makeRed", "makeBlue", "startSpinning", and "stopSpinning", etc. When you click on any of the buttons at the bottom, the cursor changes into a cross-hair, inviting you to choose a recipient for the button's message. After you click on one of the star-lemmings, the designated message will be sent to the one you chose. Thus, click on "One Red", and when the cursor changes to a cross- hair, click on a blue star-lemming, and it will be told to run its script named "makeRed", which in turn will make it red. And so on for all four of the "One" buttons. The four buttons with "Others" in their names tell all of the designated recipient's *siblings* to do the button's action, with the result tht every lemming *except* the one you click on gets the indicated message. So the "One" buttons and the "Others" buttons are kind of opposites of each other. Invoking the "cursor mode" for selecting the target is outside the scope of etoy tiles, so this required a single tiny textual script, named "chooseMessageTarget", which I wrote for the "world". All the other code in the project is strictly tile scripts. How close is this to what you're seeking? Cheers, -- Scott |
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and usingthe mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
In reply to this post by Offray Vladimir Luna Cárdenas
On Nov 13, 2006, at 10:18 AM, Offray Vladimir Luna Cárdenas wrote:
> Hi Scott :), > > Thanks for your help again. What you're providing me is pretty > close to what me and my students are looking for. Because my lack > of knowledge of the Smalltalk code I'm trying to understand the > textual script. I see that in that script, there is not switch from > tile mode to code/text mode, only the last one is enabled. There is > some special way to add this scripts? If I try, for example to use > the visor of a Star I always can switch from tile to code modes, > but coming back to tile, always makes the changes in text mode to > get loosed (not saved). Hi, Offray! Once you have typed in textual code for a script, you cannot return to tile mode without losing the textual code you typed. There is no automatic translation from user-entered textual code back into etoy tiles. Indeed, the constructs supported by etoy tiles represent but a tiny fraction of what can be expressed in textual Smalltalk code. Some people are quite disappointed, and even offended, when they first learn this brutal fact. But "etoys" is a tile-scripting system, with severe and intentional limits to vocabulary, sentence structure, expression structure, and control structures. The textual- scripting alternative provides nothing more than a "keyhole" which allows some people to "escape" from tiles, into textual Smalltalk programming, specifically to program things that cannot be expressed with tiles. Because reverting from a textually-entered script back to tiles is destructive, the user is presented with a warning if he tries to do it -- a stern warning that any code he has manually entered via the keyboard for this script will be lost. The reason why this warning was not presented when you tried to click the text/tiles checkbox of the #chooseMessageTarget script to revert to tiles is because of a bug that appears when you attempt to toggle a textually-coded script which has never had any non-empty tile code. (I have a fix for that bug, which I'm about to publish to the Squeakland alpha update stream.) However, even if had been allowed, you would not have wanted to revert that script to its last-known tile form, because in so doing you would have lost the textual code which is the whole point of the script. > chooseMessageTarget "the name of the script" > > "Choose a player as target for a message" "<- comment with the > explanation" > | aMorph | "<- some kind of local variable" > aMorph := self costume chooseClickTarget. "<- this part changes > the mouse pointer of the world from arrow to cross-hair" > > "The following part gives a message to self to set message target, > if a not nil morph is chosen then the selected morph is assigned to > aMorph variable, if is Nil, I'm not pretty sure what's happening" > > self setMessageTarget: (aMorph > ifNil: [ActiveWorld presenter standardPlayer] > ifNotNil: [aMorph assuredPlayer]) > > ----- > > I'm seeing that the world is "holding its breath" until a morph is > chosen, and everything stops for a while until the target of the > message has been choose. I image that this is related with the code > "ifNil: [ActiveWorld presenter standardPlayer] ...". There is a way > to keep the objects in the world moving, even with the message > target still to be selected? which causes the system to "hold its breath". This breath-holding is not absolutely necessary, it's just that that's how the underlying support for morph-picking has always worked in Squeak -- i.e. totally modally. To explore the possibility of relaxing this limitation, I've made a suggested fix and included it in the attached revised version #5 of the StarLemmings project; in this version, things will continue to breathe during target selection. Please try it out and let me know what you think. Cheers, -- Scott PS: Just as an aside, I think that perhaps better than trying to learn Smalltalk by puzzling over little oddball textual snippets such as the one I provided for this project would be to download some of the great and free Smalltalk books (including a nice one in Spanish by Diego) from Stephane Ducasse's wonderful web site, which you probably already know about: http://www.iam.unibe.ch/~ducasse/FreeBooks.html ATTACHED: StarLemmings.5.pr, revised version of the StarLemmings project which allows breathing during morph-picking. |
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
In reply to this post by Offray Vladimir Luna Cárdenas
On Nov 13, 2006, at 8:21 AM, Offray Vladimir Luna Cárdenas wrote:
>> When you execute "Car's copy", the result will be the creation of a >> copy of Car (strictly speaking a "sibling", viz. a fellow instance of >> the same class as Car.) >> >> However, if you don't *place* that copy somewhere, you won't see it. >> The standard idiom for placing an object somewhere via script is to >> tell the *container* in which you place it to "include" it. >> >> Here's a typical usage pattern: >> ... > > This works pretty good. I use the world as a container and now I > have a > lot of stars in the wold. At the beginning I thought it was not > working > because all starts were copied over the original one, but then I > realized what was happening. There is still something I don't know how > to do: how can I send a message to a particular copy. Suppose I have > copied a Car and I have a script for the original one to make the > car > go forward and now I wan to make the recent copy to use that script. > There is some natural number in each of the copies' names. Can I > use it > as a reference for the copies scripts to enable them? belonging to the object that creates the newborn. That gives you a way to refer to the it. (To create a player-valued variable within an object, first hit the V button at the top of the viewer to add a variable; give it a name; then from its menu, choose "change value type" and from the pop-up of available types, choose Player.) Thus, if the birthing script belongs to an object named "Foo", and that the script you want the newborn to run is called "zork". Foo's newborn := Car's copy. "creates the newborn and stashes it in a variable belonging to Foo" World append: Foo's newborn. "add the newborn to the world" Foo's newborn zork. "have the newborn run its zork script" There is an awkward and non-intuitive construction necessary to build "Foo's newborn zork". To do this right now, the usual way is to get a "Foo's zork" statement, and then grab a "Foo's newborn" tile from the "variables" section of Foo's viewer, and drop it on top of the "Foo's" in "Foos zork", thus making "Foos' newborn's zork". The meaning of this construct is" "Send the message #zork to the object referred to by the value in Foo's variable named 'newborn' ". One common use for this approach, since newborns created with "copy" will typically pile up all in the same location, is to have the post- birth code move the newborn a small distance away from the donor, and perhaps make some further adjustments to the newborn to give it a good start in life. I attach a tiny project that illustrates this use. Every time you click on an object, it gives birth to a new object, which starts out life at the same location as its parent, but is given its own heading and a slightly increased speed. |
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
Re: Making a Copy of an eToy from a script and usingthe mouse pointer to activate an eToy script
|
|
Free Spanish Squeak Book
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
In reply to this post by Offray Vladimir Luna Cárdenas
On Nov 14, 2006, at 1:08 PM, Offray Vladimir Luna Cárdenas wrote:
Hi, Offray! I *did* create that script from a Viewer, dragging an "empty script" tile from the viewer and dropping it on the desktop, then clicking the checkbox in the resulting Scriptor's header to switch to textual mode. The reason you can't (destructively) switch that script back to tile mode (which would a script with no tiles) is because of the bug I mentioned yesterday.
BTW I attach a slightly improved version of the prospective code change, which you could have your students file in when needed.
Cheers, -- Scott _______________________________________________ Squeakland mailing list [hidden email] http://squeakland.org/mailman/listinfo/squeakland |
Re: Free Spanish Squeak Book
|
|
Re: Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
|
|
| Free forum by Nabble | Edit this page |