Currently, scratch only allows you to ‘get’ a variable from a given sprite using the Sprite Attribute reporter - with no way of ‘setting’ a variable from outside itself. By allowing the reporter to be accepted as a parameter for the ‘Set’ block, it allows for this behavior in a simple to understand way.

Note: If the use of combining the reporter and set block is considered too confusing, a new block can be created instead that specifically sets a variable for a given sprite

Currently, trying to keep track of clones individually has been cumbersome and difficult. By allowing the ‘Create Clone of’ block to be cast as a reporter, this allows the block to automatically return a unique ID for that clone, which we can then use to reference that clone elsewhere in the code. You could store the clone ID's both in a standard variable, or in a list - allowing you to manage many clones systematically

Note: If casting a regular block into a reporter is considered too confusing, a new reporter can be created instead that specifically creates a clone and returns it's ID

Now that we have inherent unique clone ID's, we can allow certain blocks to accept them as a parameter wherever a sprite is expected - such as in the ‘Sprite Attribute Reporter.’

Naturally, this allows for you to set variables for a clone much like we would for a regular sprite

Building on this idea, and combining it with my other suggestion (read here: Global Access to Custom Blocks), we can also call custom blocks for specific clones

This vastly increases the power of what's possible with scratch both from an organizational standpoint as well as an extensibility standpoint, all without increasing the complexity or difficulty of scratch. No new blocks are required (with exception to the separate custom-block feature), and the blocks behave in ways you'd normally expect them to

The goal here is encapsulation; something that scratch only, well, scratches the surface on, but has tremendous potential for. One of Scratch's main goals is to learn by sharing/tinkering. In practice, although there are many mechanisms in place to encourage it, it can be quite difficult due to how tangled scratch code can become. The way I see it, encapsulation encourages true sharing. It allows users to take pieces and use them in their own projects without getting lost in spaghetti code.

Allowing for local variables to be accessed globally (essentially making them ‘public’), allows for programs to interface with encapsulated code in a non-destructive fashion. This is especially important in the case of clones which have very little support for managing them en masse. Even more important to this cause is to allow publicly accessible custom blocks - making possible things like reusable math classes, physics classes, anything really.

fezzinate wrote:

Which aspect exactly do you think would be too confusing? From what I can see, all of the blocks behave in ways you'd expect them to - with maybe the exception of being able to cast a Create Clone block as a sensor. If that aspect is too confusing, I suppose creating a separate sensor block for it would solve that issue.

//at the start of the project
when gf clicked
delete (all v) of [Clone X v]
delete (all v) of [Clone Y v]
delete (all v) of [Active Clone ID's v]
make clones ::custom

//when a clone spawns
when I start as a clone
set [myCloneID v] to (length of [Clone X v])
add (myCloneID) to [Active Clone ID's v]
add (x position) to [Clone X v]
add (y position) to [Clone Y v]
and so on and so forth ::grey

//example data retrieval from clone
define get distance to clone (id)
if <[Active Clone ID's v] contains (id)> then
  set [x v] to ((item (id) of [Clone X v]) - (x position))
  set [y v] to ((item (id) of [Clone Y v]) - (y position))
  set [distance to clone v] to ([sqrt v] of (((x) * (x)) + ((y) * (y))))
end

//end of clone's life
define delete clone (id)
set [cloneCheck v] to [1]
repeat until <(item (cloneCheck) of [Active Clone ID's v]) = (id)
  change [cloneCheck v] by (1)
end
delete (cloneCheck) of [Active Clone ID's v]
delete (id) of [Clone X v]
delete (id) of [Clone Y v]
delete this clone

SaturdayKnight27 wrote:

I need help. I really don't know how to explain this but I am making a game were you defend your base from zombies. But the turrets i'm using are clones so i can have a lot. The problem is the zombies are also clones. I know how to make the clones update there coordinates to a list but not how to give each clone a individual list part. There are like 500 zombies at a time at some points in the game. Please help!!!!