I personally think

do as [Sprite1 v] {

} :: control

seems like the best option.

I support this concept.

What's wrong with using

broadcast [ v] and wait

and if necessary,

([variable v] of [Sprite1 v])

Your suggestion violates object-oriented programming

Diamond_Projects wrote:

Your suggestion violates object-oriented programming

…how? It's already possible to access variables of other sprites (as you mentioned in your post), so the only thing this would do in terms of object-oriented programming is change blocks from private to public, which doesn't seem like a huge problem. And it will be used in the same way as a broadcast would be used - so all it really does is make one-shot code cleaner, right?

TheMonsterOfTheDeep wrote:

Diamond_Projects wrote:

Your suggestion violates object-oriented programming

…how? It's already possible to access variables of other sprites (as you mentioned in your post), so the only thing this would do in terms of object-oriented programming is change blocks from private to public, which doesn't seem like a huge problem. And it will be used in the same way as a broadcast would be used - so all it really does is make one-shot code cleaner, right?

It just seems pretty useless as a block… it fixes a minor problem and we will have two blocks that do the same thing. When a sprite does something you won't know which sprite made it happen. It will also create problems for costume blocks and other blocks that have different inputs for different sprites. I don't know how to explain it but it just isn't a good idea.

It's a pretty simple workaround, just 2 more blocks are needed. No support.

julianandwill wrote:

It's a pretty simple workaround, just 2 more blocks are needed. No support.

(unneeded reaction image removed by moderator - please don't spam)

I thought we'd established many times that you don't “No Support” a suggestion just because there is a workaround…..

repeat until <not <[] = []>>

end

Isnt that the same as the above though?

customhacker wrote:

repeat until <not <[] = []>>

end

Isnt that the same as the above though?

No, I think you might have misunderstood the suggestion.

We want to be able to make another sprite do something,

tell [Sprite1 v] to {
} :: control

This is what we are suggesting be added. So one sprite can control another sprite.

Alberknyis wrote:

Three wording ideas so far:

as [Sprite1 v] {

}::control
make [Sprite1 v] do {

}::control
tell [Sprite1 v] to {

}::control

So far I like the first wording the most, but to make it clear to others I think the second wording is the best.

You were wondering two things about the functionality of the block. I believe anything done inside the block is done as if it was done in the sprite it targets, meaning every variable is referenced from the target sprites' variables, and this:

make [Sprite1 v] do {
stop [other scripts in this sprite v] ::stack
}::control

Will stop all other scripts in Sprite1.

That aside, I don't see what's wrong with using a broadcast.

How about

have [Sprite1 v] do {

}::control

?
Also, isn't there another suggestion for a

stop all scripts in [SpriteName v] ::control ::stack

block? I won't bother finding the link, but the Scratch Team could just introduce that in Scratch 3.0, so there wouldn't be any problems with

make [Sprite1 v] do {
stop [other scripts in this sprite v] ::stack
}::control

.

Hey Scratch!

First, I think this block should be called “tell” instead of “as” since that makes the most grammatical and logical sense.
Second, for the local variables question I believe that if in sprite1 you have

tell [sprite2 v] to {
    point in direction (direction)
} :: control

then the “direction” block reports sprie1's direction, since you can already get sprite2's direction with the

([direction v] of [sprite2 v])

block.
Third, I have a problem in this block. If you have

tell [sprite2 v] to {
    switch costume to [ v]
} :: control

in sprite1 then how do you access sprite2's costumes?
What I'm thinking is once a block like that is placed in a “tell” block the dropdown menu will change to show sprite2's costumes.
so if you put “switch costume to” outside of the “tell” block, it gives you sprite1's costumes, while if it's inside the “tell” block, it gives you sprite2's costumes to choose from. E.g. if sprite1 has two costumes called “a” and “b” and sprite2 has two costumes called “c” and “d”:

switch costume to [a v]
switch costume to [b v]
tell [sprite2 v] to {
    switch costume to [c v]
    switch costume to [d v]
} :: control

Hope I made some small contribution to what really is a great idea!

kenny2scratch wrote:

Hey Scratch!

First, I think this block should be called “tell” instead of “as” since that makes the most grammatical and logical sense.
Second, for the local variables question I believe that if in sprite1 you have

tell [sprite2 v] to {
    point in direction (direction)
} :: control

then the “direction” block reports sprie1's direction, since you can already get sprite2's direction with the

([direction v] of [sprite2 v])

block.

Perfectly said, I agree with everything you've mentioned

Third, I have a problem in this block. If you have

tell [sprite2 v] to {
    switch costume to [ v]
} :: control

in sprite1 then how do you access sprite2's costumes?
What I'm thinking is once a block like that is placed in a “tell” block the dropdown menu will change to show sprite2's costumes.
so if you put “switch costume to” outside of the “tell” block, it gives you sprite1's costumes, while if it's inside the “tell” block, it gives you sprite2's costumes to choose from. E.g. if sprite1 has two costumes called “a” and “b” and sprite2 has two costumes called “c” and “d”:

switch costume to [a v]
switch costume to [b v]
tell [sprite2 v] to {
    switch costume to [c v]
    switch costume to [d v]
} :: control

Woah! Nice catch, looks like the dropdown would have to change. You can set costumes with variables though if need be:

switch costume to (number)

theonlygusti wrote:

You can set costumes with variables though if need be:

switch costume to (number)

That's true, @theonlygusti, but it would be a lot nicer and cleaner if the dropdown changed automatically.

OK I really like this idea and I think this can help new scratchers a lot.

Reason #1:

Turns this:

when green flag clicked
set [public v] to (private)
broadcast [do a thing v] and wait

when I receive [do a thing v]
turn cw (public) degrees

To this

tell [sprite2 v] to {
    turn cw (private) degrees
} :: control

This will help new scratchers a lot and can help with advanced projects also.

Why would you want a private variable if your just going to make it public?

Well first of all private variable are fast which brings me to my second reason.

Reason #2:

Helps with speed. It has been proven the private variables are slightly faster than public. If advanced scratchers can remove the use of public variables increasing the speed.

But this also depends on how this block would be implemented.

Reason #3:

Some of my projects have a lot of broadcasts this could eliminate a lot of the need for broadcasts making cleaner and smaller code.

Semi-support. One one hand, it could be useful in some projects, but on the other hand, it would cause issues with custom blocks, variables, and the stage.

Also, if you need to read a local variable in another sprite, use this:

([ LocalVar v] of [SpriteX v])

Greenduck54 wrote:

Semi-support. One one hand, it could be useful in some projects, but on the other hand, it would cause issues with custom blocks, variables, and the stage.

Also, if you need to read a local variable in another sprite, use this:

([ LocalVar v] of [SpriteX v])

How could it cause issues?

IcyCoder wrote:

Greenduck54 wrote:

Semi-support. One one hand, it could be useful in some projects, but on the other hand, it would cause issues with custom blocks, variables, and the stage.

Also, if you need to read a local variable in another sprite, use this:

([ LocalVar v] of [SpriteX v])

How could it cause issues?

I'm assuming in cases such as this:

define block (input)
turn cw (360) degrees // a custom block in Sprite1

when gf clicked
as [Sprite2 v] {
block (Sprite1's variable)
}::control

Would the stage be in the dropdown?

Bump

Support.

The Scratch team reported me for spamming in this forum. I'd like to apologise for my “spammy posts” and remind everyone to keep discussions on topic and relevant to the OP.

Sheep_maker wrote:

I'm assuming in cases such as this:

define block (input)
turn cw (360) degrees // a custom block in Sprite1

when gf clicked
as [Sprite2 v] {
block (Sprite1's variable)
}::control

Would the stage be in the dropdown?

I don't see any reason why the Stage should appear in the drop down.

Is there any reason you'd have to control the stage individually? The only “useful” things the Stage can do are change backdrop, but all Sprites have a `change backdrop` block anyway.

Also, another noteworthy issue your post may have inadvertently raised is that of custom blocks; I'm not sure how Scratch handles code at the moment, but something might have to be changed to be able to use custom blocks inside of a `tell` block.

I'd imagine that were a `tell ` block to call a custom block, which contains references to a local variable of Sprite1, the code behind this may be non-trivial.

While this idea is attractive at first glance, please consider what it would do to debugging. Now, when a sprite starts moving in an unexpected way, you know that the script (or scripts) that is causing the behavior is somewhere on the sprite. With this new capability, the script could be anywhere in the project. That's a big negative, in my opinion.

Using broadcast messages, it can still be difficult to track down bugs because of the nest of messages that end up being invoked from all over the project. But at least the actual action blocks and variable changing blocks are local to the sprite. And you can always build a “message tracker sprite” to tell you the state of the messages being sent. That would not be possible with public action blocks accessible from any sprite.