RE : [Squeakland] "add a parameter" script feature in etoys

Hi,

you'll find two examples, polygon and tree, at:

http://swiki.ofset.org:8000/super/uploads/OlpcRecursion.001.pr

Note that handling recursion will often hang squeak. Use alt/dot keys to stop an infinite loop. player's Variables should only used as constants, they are not local variables.

I'll try to use a container as heap to simulate local variables.

Best regards

-------- Message d'origine-------- De: squeakland-bounces@squeakland.org de la part de Bill Kerr Date: mer. 07/11/2007 03:13 À: Scott Wallace Cc: squeakland org mailing list Objet : Re: [Squeakland] "add a parameter" script feature in etoys

hi Scott,

thanks for reply

when I download your pr file I get this message: "Reading an instance of MorphExtensionPlus, which modern class should it translate into"

What should I do, I'd like to see your demo

thanks, - Bill

On Nov 7, 2007 11:55 AM, Scott Wallace scott.wallace@squeakland.org wrote:

On Nov 1, 2007, at 3:50 PM, Bill Kerr wrote:

...

I can't assign a variable to the "add a parameter" feature available through the scripts menu in etoys. The parameter type is displayed and the type can be altered but it doesn't go green when I try to replace it with a variable of the right type. I can drag off a tile for the parameter type but that doesn't seem to help.

Hi, Bill,

I'm not sure I understand exactly what you're asking, but perhaps a few general words about script parameters, and a simple example, will be helpful...

The "Tile for the parameter type" that you can drag from the header of a Scriptor is actually a tile representing the parameter value itself. You can drop such a tile at any type-appropriate place within the body of the script. Thus, if the parameter type is "color", the tile will be labeled "Color", and can be dropped on any Color-type tile in the script, and if the parameter type is "number", the tile will be labeled "Number" and can be dropped on any Number-type tile in the script, etc.

I attach a small example which illustrates use of a script parameter. The script that has a parameter is called "wobble", and it takes a numeric-valued parameter. Its role is to make the object turn by a random amount within the limit specified by the parameter. The larger the value of the parameter, the wider will be the variance. Notice that in the body of the script, there are two places where a "Number" tile, representing the value of the numeric parameter, is used. Both of these "Number" tiles were obtained by dragging them from the "number" tile in parameter area in the header, then dropping them on numeric-valued tiles:

A typical use of such a script can be seen in the two other scripts in the example, one called "wideWobble", which calls "wobble" with a parameter value of 70 (degrees), which makes for fairly wild random wobble, and the other called "narrowWobble", which calls "wobble" with a parameter value of 20 degrees, which makes for much less erratic motion.

Here's the script for "narrowWobble":

You can experiment with the behavior of these two scripts by holding down the yellow "!" control for one or the other, or by first making one of them "ticking", then observing the effect, then stopping that script and making the other one tick, etc. Or, for a combined effect (fwiw) make them both tick at the same time, perhaps at different ticking rates.

BTW: we have successfully prototyped a much better UI for presenting parameters to the user; the new design allows the user to *name* the parameter, allows a *default value* for the parameter to be specified in the scriptor's header, and (because of now having a default value) also allows a script with a paremeter to be set "ticking". But unfortunately we haven't had time yet to bring this into the mainstream etoys system.

...

I'm trying to make a fractal tree in etoys but need two parameters. Is it possible?

No, sorry, only one parameter is allowed per script in this version of etoys.

The standard workaround for this is to pass the desired additional parameter info in a *variable* which you add to the object for just this purpose, and which you set in the caller, and which you "get" in script itself. This requires extra bookkeeping by the person writing the script, and can cause problems in recursive-call situations, but otherwise in practice is quite workable. And, since the data being passed reside in visible variables belonging to the object, their values can be conveniently observed in Viewers and Watchers, which can be quite a good debugging aid.

Cheers,

-- Scott