Scratch

I feel like my role here is to be the incompetent kid who gets lost in the first class... 

Playing around with the spawning-tree demo (awesome), I managed to delete _all_ of the sprites (I wanted to delete sprites when we got to branch = 0, because I had accidentally restarted the tree when there were still 32 sprites -- as a result, 'is clone' was set to 'false' for all of them, and they all started making identical trees...  veeeerrrrry slowly).  I think there's a possibility for LOTS of frustration on the part of kids who make a similar mistake and suddenly find all of their work has disappeared.  I'm not sure whether the interface should protect against this somehow, or if we should just make it very clear in the documentation that this is a danger, and that you should (1) save your work frequently, and (2) be very careful about the 'remove (sprite) from stage' block. 

speaking of docs, I'd be happy to help out with them at some point if you want some assistance.  I'm sure there are other people on the list who'd help as well.

matt

ARGH. I just missed post 2500! Ah well. Congrats everyone!

xly wrote:

I don't understand the difference between DUPLICATE and SPAWN and which is the role of PROTOTYPE.

DUPLICATE is the Scratch feature that makes a copy of a sprite, with no information shared between the two after the copying.  The question hasn't come up yet in discussion with Jens, but personally, I would strongly consider eliminating the DUPLICATE feature once we have cloning ready for release, to avoid confusion between the two.

The PROTOTYPE menu entry displays the sprite's current prototype and allows you to change it.  Sort of like "will you adopt me?" 

clintonhackers wrote:

I've been wondering what this means, exactly.  if the original parent and the new parent have no common heritage, won't there be some confusion about implicitly defined characteristics of the clone?  I guess I should experiment a bit to figure it out.

I'm still a little vague on why anyone would do it, but what it will mean is that attributes shared with the old parent will disappear and attributes of the new parent will appear instead.  Attributes not shared with the old parent (e.g. because the child changed the binding, although I'm struggling with Jens about whether that'll be the case in the final release) will of course still exist in the child, and therefore the new parent's value for that attribute, if any, won't be seen by the child -- at least I think that's the most consistent way to make it work.

@ bharvey & jens

See my first Byob-Jan2011 application and comments at :
http://www.xleroy.net/ByobTuto/thumbnails.html

At this stage your 1st class sprites enhancement seems to be particularly well adapted to the design of OOP-like applications compliant with Scratch-Byob spirit : user-friendlyness, power, "tinkerability", support for creativity and education as well etc

Many mechanisms exist now to emulate OOP-like applications where capabilities and properties of any sprite can be precisely defined, extended or restricted :
- Duplication, spawning, prototyping ..
- Global/Local variables AND Functions,
- Extraordinary flexibility of SCRIPT VARIABLES instruction allowing to implement local scripts anywhere, when and where needed.
- Capability to implement, SET and GET  "added" sprite properties handled by one ASK function,
- Methods + <property OF sprite (can be elegantly used jointly with ATTRIBUTE )

Byob offers many ways to define, extend or restrict the capabilities of any sprite ( for example in the referenced application the family prototypes are not allowed to fight as to not be destroyed and continue to make children ). It's amazing how complex applications can be written with zillions of sprites without creating a bunch of variables crowding the panels ( in the referenced application, only one variable to count the number of hits !!)

@bharvey

"Wow!  The first serious project to use BYOB sprite cloning."

Many thanks for all and mainly for your advices ( I'm proud to have a personal CS teacher like you ). It is a preliminary version. To create new bumpers or missiles click on each fixed "prototypes". Each click creates  a new "child"  ( At this stage I wanted to avoid the problem of a geometric serie for sprite creation like in the first example of Jens. (1,2,4,8,16 etc). I am now to implement the feature to delete the Hit sprite. (For the time being we lack a mechanism to get the name of the current (myself) sprite) In the meantime the sprite - when hit - will send a broadcast to master sprite asking it to do the job. The balance between LAUNCH/RUN is not easy but I shall manage.

bharvey wrote:

xly wrote:

For the time being we lack a mechanism to get the name of the current (myself) sprite.

You don't need the name -- you have a handle on the actual sprite:  OBJECT <MYSELF>.  You can use that to send yourself a message:

Code:

LAUNCH [ATTRIBUTE <...> OF [OBJECT <MYSELF>]]

... although I guess you could just LAUNCH <...> instead.  Maybe I'm missing what you're trying to do.  But instead of constructing text messages to sprites, just directly run their blocks.

EDIT: I reread your message so now I see that you're trying to delete a sprite.  That's

Code:

REMOVE [OBJECT <MYSELF>] FROM STAGE

I've fixed the motion issue. I'm going to load a revised version.
As far as Name is concerned I just wanted to delete a sprite once it has been hit. It was obvious to me : when the sprite is hit it broadcasts a message to the master sprite asking it to read the global variable <nameself> supposed to contain <object myself>. In fact this does not work. In addition the risk is to delete the prototype itself. The REMOVE FROM STAGE instruction is amazing but also very dangerous !

xly wrote:

The REMOVE FROM STAGE instruction is amazing but also very dangerous !

Hmm.  I was going to say, just set a variable equal to OBJECT <MYSELF> in the parent before making any clones, and then when a clone is thinking about deleting itself it could say IF [NOT [<var> = [OBJECT <MYSELF>]]] REMOVE ...  but I just tried it, and so far the = block thinks all sprites are equal.  This is a bug; stay tuned for an announcement from Jens that he's fixed it!

shadow_7283 wrote:

I noticed that while the clone/prototype/inheritance/whatever-it-is blocks have a "myself" option, they also have their sprite name listed.

This isn't a bug; using "myself" and using "sprire23" or whatever will have different effects if the script is inherited by a clone! 

@bharvey "REMOVE FROM STAGE"

Yes, there are solutions as long as you are warned of the pb.
I've uploaded an updated working version of the application abmoop, plus  unchanged copyscreens of comments. For Instructions, see Project notes.

I've not yet implemented the "remove" feature consisting to remove one sprite each time a hit occurs, I delete the "last one" of the missiles/bumpers list. It is not a clean way, but it allows to "play" with REMOVE.

This is great! We're in "testing-mode" again! I honestly didn't expect any of this until the summer. 

bharvey wrote:

Yeah, this is way more fun than last semester!  What's a little scary is that we're testing in public while still arguing about the design.  But, I still say, 3.1 release in March, so the summer will be the testing of 4.0.

Testing 4.0 by the summer!?!?!? I'm so excited.

14God wrote:

Running a script through the attribute block is ingenious. I think it's my favorite experimental block so far.

Thanks! Actually I'm very unsure about this particular feature (running a script through the attribute block). Fact is, we're still in the process of discussing the design of how built-in OOP in BYOB might work. All those current experimental versions are just that - hands-on experiments, which might or might not make it into 3.1. I am pretty sure that the final design will be a lot different from today's.

So, what is it you like about running a script in the context of another sprite? wouldn't it be better and easier to understand if you could also send a message to an individual sprite instead of having to broadcast it publicly?