UPDATE: sorry, this isn't my suggestion anymore, I don't like this new version, feel free to keep discussing but I won't

so I read your posts here and I decided to update my suggestion, also apparently something was happening with my account idk what it was but I think I fixed it and I kept the original version of the topic here so people understand the posts before the update

new version
So if someone were to do this:

define ...
stop [ v]

the code would run, and then stop the code in the middle of it. Solution: custom cap blocks, that way people are less likely to do that

old version
Hello, I am suggesting this because say someone were to do this:

define ...
stop [ v]

the code would run, and then stop the code in the middle of it. Solution: turn custom blocks containing cap blocks into cap blocks. (this would also help with custom cap blocks)

EDIT: Probably should've specified this but it wouldn't do that if it was in an

if <> then 

  

else

end

block

what if this happens?

define example
if <(example) = [1]> then
stop [all v]
else
do nothin :: grey ::
end


when green flag clicked
set [example v] to (pick random (1) to (3))
example :: custom ::
say [ur lucky]

this would not work if

when green flag clicked
set [example v] to (pick random (1) to (3))
example :: custom :: cap ::
say [ur lucky]

JackK211424 wrote:

what if this happens?

define example
if <(example) = [1]> then
stop [all v]
else
do nothin :: grey ::
end


when green flag clicked
set [example v] to (pick random (1) to (3))
example :: custom ::
say [ur lucky]

this would not work if

when green flag clicked
set [example v] to (pick random (1) to (3))
example :: custom :: cap ::
say [ur lucky]

then it would not turn into cap block (probably should have specified that)

It seems like a good easy improvement on the surface, but looking deeper there is a lot more to consider.

Would it be able to identify if statements that always lead to it being a cap block, even when they're more complex?

define . . .
set [n v] to [0]
repeat (2)
change [n v] by (1)
end
if <(n) = [2]> then //n is always 2
stop [all v] //so the block must stop, even though the stop block is inside an if
end

It seems just sort of weird to not make it cap if it does in other situations, but also would be complex to make it detect that it always stops.

We also have some scripts that appear to be cap blocks because they have a cap block at the end, but the custom block ends before getting to it.

define . . . .
set [n v] to (pick random (0) to (2))
if <(n) < [3]> then //it's a random number from 0 to 2, meaning it's always less than 3
stop [this script v] //so it stops the custom block
end
stop [all v] //meaning this stop all is never called

We need to make sure these are not turned into cap blocks, but it's complex for a program to analyze.

We already have blocks that act like cap blocks but still let you put blocks after them:

wait until <[1] = [2]>

say [hi] for ((1) / (0)) seconds::looks

If custom blocks adjust, would these blocks do so as well? These could be just as difficult to detect if they are cap blocks as custom blocks, but it would be consistent with the fact that custom blocks change form.

Also, stop [this script v] is a cap block but it just ends the custom block, not the code after it, and delete this clone is a cap block that depends on if it is a sprite. So the only blocks that would do this are forever and stop [all v]. You aren't using these 2 blocks in custom blocks too often, so it isn't really something you would notice too often. Why go through all the effort of making a program that can detect if a custom block ends up not really being a cap block just so you can make it a bit more accurate when using these 2 blocks?

Support! This would make lots of sense to me.

define cap block
say [I'm saying stuff!]
stop [all v]

cap block::custom cap

hedgehog_blue wrote:

It seems like a good easy improvement on the surface, but looking deeper there is a lot more to consider.

Would it be able to identify if statements that always lead to it being a cap block, even when they're more complex?

define . . .
set [n v] to [0]
repeat (2)
change [n v] by (1)
end
if <(n) = [2]> then //n is always 2
stop [all v] //so the block must stop, even though the stop block is inside an if
end

It seems just sort of weird to not make it cap if it does in other situations, but also would be complex to make it detect that it always stops.

it wouldn't detect that because that would be too complex.

hedgehog_blue wrote:

We also have some scripts that appear to be cap blocks because they have a cap block at the end, but the custom block ends before getting to it.

define . . . .
set [n v] to (pick random (0) to (2))
if <(n) < [3]> then //it's a random number from 0 to 2, meaning it's always less than 3
stop [this script v] //so it stops the custom block
end
stop [all v] //meaning this stop all is never called

We need to make sure these are not turned into cap blocks, but it's complex for a program to analyze.

but that would be a cap block because it would still stop the code when it runs the block, it wouldn't run the stop block but it would still stop the script.

hedgehog_blue wrote:

We already have blocks that act like cap blocks but still let you put blocks after them:

wait until <[1] = [2]>

say [hi] for ((1) / (0)) seconds::looks

If custom blocks adjust, would these blocks do so as well? These could be just as difficult to detect if they are cap blocks as custom blocks, but it would be consistent with the fact that custom blocks change form.

that would still be the same because it wouldn't be necessary when actually making projects to turn them into cap blocks.

hedgehog_blue wrote:

Also, stop [this script v] is a cap block but it just ends the custom block, not the code after it, and delete this clone is a cap block that depends on if it is a sprite. So the only blocks that would do this are forever and stop [all v]. You aren't using these 2 blocks in custom blocks too often, so it isn't really something you would notice too often. Why go through all the effort of making a program that can detect if a custom block ends up not really being a cap block just so you can make it a bit more accurate when using these 2 blocks?

I actually tested to make sure this suggestion wasn't already added, and stop [this script v] was the block I used to test it and it didn't run the code after the block.

This is a good idea but pretty impssible to get working.

lapisi wrote:

I actually tested to make sure this suggestion wasn't already added, and stop [this script v] was the block I used to test it and it didn't run the code after the block.

Really? I always use stop [this script v] to end a custom block without stopping anything else… and when I did tests before writing my post, it did stop only the custom block.
I'll do more tests now…

Okay, I did some testing and my version of scratch (3.12.0) the stop [this script v] block only stopped the custom block.
Do this to test for yourself:

define block
stop [this script v]
when flag clicked
say [it stopped the whole script]
block
say [it only stopped the custom block]

Whatever the sprite says is the result.

No support, I see no reason to put this in, just don't put blocks after the custom block.

Oh, I think I understand… Support! This would be much more intuitive! Perhaps only do this is the cap blocks were actually at the end of the custom block with no if statements around them though, right?

--Explosion-- wrote:

Oh, I think I understand… Support! This would be much more intuitive! Perhaps only do this is the cap blocks were actually at the end of the custom block with no if statements around them though, right?

This won't work, because of a case like this:

define . . .
if <[1] = [1]> then
stop [this script v] //stops the custom block before it gets to stop all
end
stop [all v]

This custom block is not a cap block, despite ending with a cap block.

hedgehog_blue wrote:

lapisi wrote:

I actually tested to make sure this suggestion wasn't already added, and stop [this script v] was the block I used to test it and it didn't run the code after the block.

Really? I always use stop [this script v] to end a custom block without stopping anything else… and when I did tests before writing my post, it did stop only the custom block.
I'll do more tests now…

Okay, I did some testing and my version of scratch (3.12.0) the stop [this script v] block only stopped the custom block.
Do this to test for yourself:

define block
stop [this script v]
when flag clicked
say [it stopped the whole script]
block
say [it only stopped the custom block]

Whatever the sprite says is the result.

it stopped the whole script, here are screenshots:

lapisi wrote:

Mine doesn't do that… I have no idea why it would be different between us. I might report a bug so we can find out what way this is supposed to work. Can you state your exact browser/operating system for the bug report?

I can't get it to act the way it does for you; I tried all of the following devices and it only stopped the custom block on all of them:
My browser / operating system: MacOS Macintosh X 10.11.6, Chrome 83.0.4103.116
My browser / operating system: ChromeOS 13020.87.0, Chrome 83.0.4103.119
My browser / operating system: IPadOS 12.1.4, Safari 12.0

Hmm.
For me,

define block
stop [this script v] // this only stops the custom block script.

when something :: hat events // if I did this,
block
. . . // this would still run.

ioton wrote:

Hmm.
For me,

define block
stop [this script v] // this only stops the custom block script.

when something :: hat events // if I did this,
block
. . . // this would still run.

Can you provide your browser/operating system? Then we can try to identify what might be causing it to be different between devices.

I don't see the reason to add this. The current version works alright. And this doesn't really change much, while being hard to implement, as @hedgehog_blue said.

hedgehog_blue wrote:

It seems like a good easy improvement on the surface, but looking deeper there is a lot more to consider.

Would it be able to identify if statements that always lead to it being a cap block, even when they're more complex?

define . . .
set [n v] to [0]
repeat (2)
change [n v] by (1)
end
if <(n) = [2]> then //n is always 2
stop [all v] //so the block must stop, even though the stop block is inside an if
end

It seems just sort of weird to not make it cap if it does in other situations, but also would be complex to make it detect that it always stops.

We also have some scripts that appear to be cap blocks because they have a cap block at the end, but the custom block ends before getting to it.

define . . . .
set [n v] to (pick random (0) to (2))
if <(n) < [3]> then //it's a random number from 0 to 2, meaning it's always less than 3
stop [this script v] //so it stops the custom block
end
stop [all v] //meaning this stop all is never called

We need to make sure these are not turned into cap blocks, but it's complex for a program to analyze.

We already have blocks that act like cap blocks but still let you put blocks after them:

wait until <[1] = [2]>

say [hi] for ((1) / (0)) seconds::looks

If custom blocks adjust, would these blocks do so as well? These could be just as difficult to detect if they are cap blocks as custom blocks, but it would be consistent with the fact that custom blocks change form.

Also, stop [this script v] is a cap block but it just ends the custom block, not the code after it, and delete this clone is a cap block that depends on if it is a sprite. So the only blocks that would do this are forever and stop [all v]. You aren't using these 2 blocks in custom blocks too often, so it isn't really something you would notice too often. Why go through all the effort of making a program that can detect if a custom block ends up not really being a cap block just so you can make it a bit more accurate when using these 2 blocks?

say [hi!]
Cap thing :: custom
say [bye!]

define Cap thing
stop [all v]

In conclusion, No support.

If you were to detect if a script were able to stop or not, wouldn't you run into the Halting Problem?

--Explosion-- wrote:

Oh, I think I understand… Support! This would be much more intuitive! Perhaps only do this is the cap blocks were actually at the end of the custom block with no if statements around them though, right?

How about this?

define cap :: cap custom
if <[1] = [1]> then
stop [all v]
end

or this?

define cap :: cap custom
broadcast [stop all v]
when I receive [stop all v]
stop [all v]

hedgehog_blue wrote:

lapisi wrote:

Mine doesn't do that… I have no idea why it would be different between us. I might report a bug so we can find out what way this is supposed to work. Can you state your exact browser/operating system for the bug report?

I can't get it to act the way it does for you; I tried all of the following devices and it only stopped the custom block on all of them:
My browser / operating system: MacOS Macintosh X 10.11.6, Chrome 83.0.4103.116
My browser / operating system: ChromeOS 13020.87.0, Chrome 83.0.4103.119
My browser / operating system: IPadOS 12.1.4, Safari 12.0

My browser / operating system: Windows NT 10.0, Chrome 84.0.4147.89, No Flash version detected

EDIT: I tried it again and it only stopped the custom block, idk how this is happening

EDIT: This is weird, I tried it again and it stopped the whole script…

It would make no sense that

define my block :: cap
broadcast [stop v]
when I receive [stop v]
stop [all v]

is a hat block since the broadcast block practically starts a multitasking thingy.