Discuss Scratch

xly
Scratcher
100+ posts

Snap! user discussion

bharvey wrote:

xly wrote:

But I forgot that when closing a project…clones are killed and thus no more network !
Ah, great! Tell Jens that you really want to be able to generate clones programmatically and have them be permanent. (If you make clones by clicking on menus, they are permanent!)
One can create a clone inside the sprite corral.
But, then, the issue is that when you want to change the clone properties by adding a new feature then you need to change scripts for each of them.
There is a turnaround : to keep in a list the clone positions as to reinstall them at the same place when restarting.

Last edited by xly (Jan. 9, 2018 14:47:39)

bharvey
Scratcher
1000+ posts

Snap! user discussion

xly wrote:

One can create a clone inside the sprite corral.
But, then, the issue is that when you want to change the clone properties by adding a new feature then you need to change scripts for each of them.
No, you don't have to do that, as long as you don't put any scripts in the clones. They will inherit the entire scripting area from their parent.

Sadly, inheriting scripts is all-or-nothing. So if you drag a block into the scripting area of a child, it no longer inherits from the parent. (You can control whether the child inherits by right-clicking on the background of its scripting area.)

Jens, what about letting children inherit scripts from their parent and also have their own? Maybe ghost the inherited scripts (I think that's a good idea anyway). It would be the user's responsibility to worry about not overlapping the area used by parent scripts.

Jens
Scratcher
100+ posts

Snap! user discussion

Yes, Brian, I agree that it would be nice for a clone to be able to both inherit scripts and also be able to override individual ones and add other ones not present in the parent. The more I work with inheritance myself script inheritance turns out to be the part I actually love the best. And once you do that it's obvious that a more fine-grained distinction would be really, really, neat. Let's think about this!
xly
Scratcher
100+ posts

Snap! user discussion

Hi Jens ,

There is “still” a vocabulary issue. When talking of “clones” you have two categories. On one side “created-clones” (by a command inside a sprite like “create a clone of…” ). And on the other side “duplicated-clones” created inside the sprite-corral.

If you make a crowd of dup-clones and you need after to add a new piece of script (hat command for example) you have to add it, one by one, to each dup-clone.With a created-clone any script added is available for all clones, But reversely created-clones are lost when the project is saved.
Jonathan50
Scratcher
1000+ posts

Snap! user discussion

xly wrote:

Hi Jens ,

There is “still” a vocabulary issue. When talking of “clones” you have two categories. On one side “created-clones” (by a command inside a sprite like “create a clone of…” ). And on the other side “duplicated-clones” created inside the sprite-corral.

If you make a crowd of dup-clones and you need after to add a new piece of script (hat command for example) you have to add it, one by one, to each dup-clone.With a created-clone any script added is available for all clones, But reversely created-clones are lost when the project is saved.
Maybe you're thinking of duplicated sprites, which aren't the children of the sprite you duplicated. If you right-click on a sprite and click “clone” then it will inherit all the scripts from its parent, but if it doesn't you just need to right click on the scripting area and check “inherited”. (These are the replacement for BYOB 3 clones as far as I know.)

Last edited by Jonathan50 (Jan. 10, 2018 01:39:24)

bharvey
Scratcher
1000+ posts

Snap! user discussion

Jonathan50 wrote:

(These are the replacement for BYOB 3 clones as far as I know.)
Right, we have two different kinds of clones:

1. Scratch-style: Temporary, not in sprite corral, you can have lots of them and it's still fast.

2. BYOB-style: Permanent, appear in sprite corral, have their own scripting area, but still can inherit stuff from parents.

Sprites created programmatically are by default temporary. Sprites created using the “clone” command in the right-click menu of a sprite are by default permanent. Changing a clone from permanent to temporary is easy (although the command to do it is peculiarly named). Changing a clone from temporary to permanent requires calling up Jens at home for permission, because he's worried that people will make too many permanent ones and their projects will slow down and they'll be upset.

In principle, clones should initially inherit /everything/ (why won't it let me use italics today?) from their parent, but that would break too many Scratch projects. I'm trying to convince Jens that if that's the reason, we should have BYOB-style clones inherit everything, and make that change quickly, before too many /Snap!/ projects get broken.

Jens
Scratcher
100+ posts

Snap! user discussion

Snap has clones, period. Not “two kinds” of clones. Clones can inherit properties of their parent, i.e. variables, custom blocks, attributes, costumes, sounds, scripts, in other words: “slots”.

There is only one kind of clones, not “Scratch-style” or “BYOB-style”. Whether a clone gets automatically deleted when the red stop sign button is pressed depends on whether the user has edited it or not. As soon as you edit a clone it won't disappear automatically, because we don't want users to accidentally lose their work. You can edit a clone either by explicitly creating it in the GUI, e.g. by right-clicking on a sprite or a sprite-icon in the corral and choosing “clone”, or - in case the clone has been created programmatically - by choosing “edit” in the clone's context menu. When you do that the clone also gets its own sprite-icon in the corral. This will make the clone permanent (and immune to the “delete this clone” command). You can then save and re-open the project and the clone is still there. If, in turn, you would like to make and edited clone temporary again you can choose “release” in the context menu of its sprite-icon the corral.
bharvey
Scratcher
1000+ posts

Snap! user discussion

Jens wrote:

There is only one kind of clones, not “Scratch-style” or “BYOB-style”. Whether a clone gets automatically deleted when the red stop sign button is pressed depends on whether the user has edited it or not. As soon as you edit a clone it won't disappear automatically, because we don't want users to accidentally lose their work.
No, Jens, I don't think that's a fair presentation of our thinking about this. Edited clones, as you put it, are permanent not only “because we don't want users to accidentally lose their work.” There really are two theoretical models behind these two behaviors.

In BYOB 3.1, all clones were permanent, and the hierarchy was explicit in the sprite corral – you could click on a sprite to see its children, and then click on a child to edit it. (Is this use of “edit” something Scratch people say, by the way? I find it a little confusing because it makes me think about opening a Block Editor.) The model is Lieberman prototyping: Every sprite is both a class and an instance, in that it has methods and can pass them on to its children, but also has instance variables and a concrete presence in the world, i.e., is onstage. All sprites are in the same category, including the one you see when you start a new project. Historically, this was the /first/ use of cloning, rather than just duplication, in Scratch-ish software.

Then came Scratch 2.0, with a very different model, in which clones are in a semantically different category from “real,” primary sprites. They're temporary; there is no hierarchy (if you clone a clone, what you get is a direct clone of the primary sprite); a clone can have its own instance variables but not its own methods.

You fell in love with Scratch-style cloning, and it was relatively easy to implement, so you just did it, in Snap! 4.0. Much later, in 4.1, you implemented BYOB-style cloning, but with a major restriction: you can't create BYOB-style clones programmatically, and you can't turn a Scratch-style clone into a BYOB-style clone programmatically, for speed reasons, not intellectual reasons. Internally, the two kinds of clones have a lot in common, but they are still quite different as seen by users. The two behaviors are based on two different intellectual histories; the difference is not a small thing to be handwaved away in how we describe them to users, especially since users can't change from one behavior to the other programmatically. Otherwise, there would be no reason why editing a clone should make it appear in the sprite corral! It's a real category shift. There would be no reason why MY CLONES reports only the temporary ones and there's a separate MY CHILDREN for the permanent ones.

PullJosh
Scratcher
1000+ posts

Snap! user discussion

I feel like much of the confusion with clones could be solved with some GUI changes.

Out of curiosity… What is the difference between the “clone” and the “duplicate” context menu options? The only difference I've found is that "my [parent]" returns a different value.

Last edited by PullJosh (Jan. 10, 2018 20:29:41)


bharvey
Scratcher
1000+ posts

Snap! user discussion

PullJosh wrote:

I feel like much of the confusion with clones could be solved with some GUI changes.
Could you be more specific? The two GUI changes I want are to change the names “edit” and “release” to “→permanent” and “→temporary”; and the long-awaited 3-D sprite corral (so top-level sprites are displayed by default, but in the context menu for a sprite you can ask to see its children). Mostly what I want are changes to the primitives.

Out of curiosity… What is the difference between the “clone” and the “duplicate” context menu options? The only difference I've found is that "my [parent]" returns a different value.
A duplicate is a new copy of the sprite, but with nothing shared. Changes to the original are not passed on to the duplicate, whereas they are to a clone. (Except that not all attributes are shared by default; methods are, but local variables aren't. This is to avoid breaking Scratch projects. I'm advocating for a Flag Day in which we change the version number on saved project files and introduce bunches of Scratch incompatibilities at once, while automatically loading a Scratch compatibility library for projects with the old version number or converted from Scratch, e.g., angles counterclockwise from East, non-numeric values in numeric slots are runtime errors rather than zero, etc. And also all attributes are shared by default. (I don't personally care about the angles thing either way, but it's probably the most common complaint we get from teachers.))

Jens
Scratcher
100+ posts

Snap! user discussion

Brian wrote:

No, Jens, I don't think that's a fair presentation of our thinking about this. Edited clones, as you put it, are permanent not only “because we don't want users to accidentally lose their work.” There really are two theoretical models behind these two behaviors.

Actually, that's not right. Snap has clones, and clones now have been enhanced with Lieberman-style inheritance. There is exactly one single coherent inheritance model for all clones, and - that's the beauty - it's compatible with previous projects. Also, you have control over whether a clone is temporary or not, and you can toggle that at any time as much as you want. The only thing I won't let you do (for now) is make clones permanent using a built-in primitive in user-mode (there is a “is temporary?” setting in dev mode and you can write a JS function for a library). And yes, the reason totally is that I don't want users to lose their work, that's why editing a clone prevents it from being automatically or programmatically deleted.
PullJosh
Scratcher
1000+ posts

Snap! user discussion

bharvey wrote:

PullJosh wrote:

I feel like much of the confusion with clones could be solved with some GUI changes.
Could you be more specific?
Sorry; I was originally typing up my post to include more details, until I came across the clone/duplicate confusion. Although you've pretty much nailed everything I was going to recommend in your own post.

The most useful UI change, I think, would be to nest cloned sprites beneath their parent inside the sprite thumbnail area (does that panel have a name?), as well as rename a few context menus (especially the “permanent” and “temporary” options you mentioned).

@Jens While I have no doubt that you're correct about the way that clones are implemented, I can tell you that as a user they feel like two very distinct things (even before I started reading Brian's ramblings.) Honestly, reorganizing the UI to make the similarities between types of clones more clear would be hugely beneficial in clearing up the confusion. (Although that's just my two cents.)

PullJosh
Scratcher
1000+ posts

Snap! user discussion

Just for good measure, here's a very rough mockup of how I envision the sprite panel looking:


Any sprite which is a parent to at least one clone would have a dropdown arrow (or possibly a more easily-understandable button) which would open up a panel of clone sprites when clicked.

Edit: Looks like in my mockup I forgot to include top-level sprite #5. Pay no attention to that.

Last edited by PullJosh (Jan. 10, 2018 23:22:59)


bharvey
Scratcher
1000+ posts

Snap! user discussion

PullJosh wrote:

(does that panel have a name?)
We call it the “sprite corral.” And your mockup is more or less the long-awaited “3-D sprite corral.” It's really 3-D, not just 2½-D, because the permanent clones can have children of their own, so in principle the hierarchy could be indefinitely deep.

Jens wrote:

There is exactly one single coherent inheritance model for all clones, and - that's the beauty - it's compatible with previous projects.
I agree with the first part of this: there is one inheritance model. If you just think about inheritance, the two kinds of clones are the same. But if you think at all about interacting with them, they're quite different. Most importantly, you can't make permanent ones programmatically – which means that the current implementation, while compatible with /Scratch/ projects, is /not/ compatible with /BYOB/ projects. But also
* Temporary clones aren't in the sprite corral.
* Temporary clones are killed by DELETE THIS CLONE.
* Temporary clones can be created by the CLONE block.
* Temporary clones have only siblings, not children.
* Temporary clones are killed by the Stop button.

As far as the user is concerned, these two types of clone are much more different than they are the same.

I'm not really sure why we're having this argument, since you agreed with this when we last talked f2f. And it's what's in the manual, and you didn't complain about that.

Jonathan50
Scratcher
1000+ posts

Snap! user discussion

What would this:
Sprite1 Sprite2
/ \ |
Sprite3 Sprite4 Sprite5
/ \ \
Sprite6 Sprite7 Sprite8

look like in the 3-D sprite corral?

Last edited by Jonathan50 (Jan. 11, 2018 05:18:44)

Haz-_-
Scratcher
100+ posts

Snap! user discussion

Yas some new coding websites!


❖—————————-❖ HandyAuthorizedZord ❖—————————-❖
❖ I like blue its my fav color ❖
❖ Check out my games! ❖
❖———————————————————❖

bharvey
Scratcher
1000+ posts

Snap! user discussion

Jonathan50 wrote:

What would this:
Sprite1 Sprite2
/ \ |
Sprite3 Sprite4 Sprite5
/ \ \
Sprite6 Sprite7 Sprite8

look like in the 3-D sprite corral?
It would show Sprite1 and Sprite2. Clicking the downarrow or whatever on sprite1 would show 3 and 4. Clicking the downarrow on 4 would show 8. Etc.

Actually the way it worked in BYOB was that all the clones were in the corral, but you could right-click on a sprite with children and choose “children”…

… you'd get a white box with its children…

and then if you click on one of the children in the white box…

… you would get a new white box with its children (and focus would shift to the one you clicked – notice that Sprite3 is now selected in the corral).

I don't know why the sprite names in the white boxes look so awful; I'm pretty sure they didn't before. Maybe something about retina displays?

xly
Scratcher
100+ posts

Snap! user discussion

@ Jens & Brian

I don't think it is necessary to substantially modify the corral as it is suggested.
A Snap! programmer has just to know the difference between “clones” and “clones”.
Personally , although being an user of clones I did not know some of their features I've learnt thanks to our present discussions.
While revising some project clone-intensive I have observed that older projects (one year old) do not propose the “edit” choice in the right-click menu .
Jens
Scratcher
100+ posts

Snap! user discussion

temporary clones can have children

Last edited by Jens (Jan. 11, 2018 21:36:03)

bharvey
Scratcher
1000+ posts

Snap! user discussion

Jens wrote:

temporary clones can have children
Ah, sorry, my bad. I was confused because if you make one clone, and ask it to make one clone, then MY CLONES is of length 2, even though MY CHILDREN is of length 1.

Powered by DjangoBB

Standard | Mobile