Paddle2See wrote:

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.

That's very true. Maybe there could be a button on a certain sprite to find where all the “as” blocks are?

No Support. The workaround is doing a message, and that is simple. If it only takes a few more seconds of programming, then why should we have a new block?

customhacker wrote:

No Support. The workaround is doing a message, and that is simple. If it only takes a few more seconds of programming, then why should we have a new block?

No that isn't the workaround, because this would allow Sprite2 to use Sprite1's custom blocks and local variable with minimal hassle.

Paddle2See wrote:

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.

Yes, that's what I was thinking. I honestly don't actually think this block is a very good idea, as most new users would simply learn poor practices - e.g. no encapsulation or modularization.

It could be used very effectively by more advanced users, but the use case is so small that it honestly does not seem like it's worth it.

theonlygusti wrote:

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.

You can change the stage's visual effects.

Good Idea! I can think of lots of alternate name for the block: Announce, Declare, Notify, Order, State And Command. But I think “Tell” is the best because of it's simplicity.

I think that variables in the target sprite should be accessed because one could use this code in sprite1:

as [Sprite2 v] {...
as [Sprite1 v] {change [Health v] by (2)}  ::control
...}  ::control

or

as [Sprite2 v] {...}  ::control
change [Health v] by (2)
as [Sprite2 v] {...}  ::control

bigpuppy wrote:

Paddle2See wrote:

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.

That's very true. Maybe there could be a button on a certain sprite to find where all the “as” blocks are?

I think that there's a more general “Find all _____ blocks” suggestion somewhere.

dvargasews wrote:

I think that variables in the target sprite should be accessed because one could use this code in sprite1:

as [Sprite2 v] {...
as [Sprite1 v] {change [Health v] by (2)}  ::control
...}  ::control

or

as [Sprite2 v] {...}  ::control
change [Health v] by (2)
as [Sprite2 v] {...}  ::control

Yes, if this was implimented that would need to be added to in order to prevent confusion and inconveniences.

Our swords clash again, 60 second rule.

How about this:

send message to [Sprite2 v] telling him to
be awesome
end