I don't think the start script block is necessary, it just sounds like broadcasting with extra steps.

fdreerf wrote:

I don't think the start script block is necessary, it just sounds like broadcasting with extra steps.

Broadcasting to start a long script can take a lot more space in a project file

The_5th_Scratcher wrote:

fdreerf wrote:

I don't think the start script block is necessary, it just sounds like broadcasting with extra steps.

Broadcasting to start a long script can take a lot more space in a project file

You mean, broadcasts can take the space of one block more than a start script.

What would this offer that broadcasts already don't?

The_5th_Scratcher wrote:

fdreerf wrote:

I don't think the start script block is necessary, it just sounds like broadcasting with extra steps.

Broadcasting to start a long script can take a lot more space in a project file

It just one block for one file, it won't change much. I honestly don't see the point of this if you can just use brodcasts

DarthVader4Life wrote:

You mean, broadcasts can take the space of one block more than a start script.

PGBFLITE6373 wrote:

It just one block for one file, it won't change much. I honestly don't see the point of this if you can just use brodcasts

Which is smaller?

when I receive [Script v]
start [script: 1 v] ::control

or

when I receive [Script v]
...
...
...
...
...

The_5th_Scratcher wrote:

Which is smaller?

when I receive [Script v]
start [script: 1 v] ::control

or

when I receive [Script v]
...
...
...
...
...

when I receive [Script v]
broadcast [script: 1 v]

Seems small enough to me. IMO the only reason to add this feature would be if you could have multiple instances/threads of a script running, but your suggestion implies the opposite due to the stop script block.

Please remove the supporters list. It's unneeded and takes up space.

-Rex- wrote:

Seems small enough to me. IMO the only reason to add this feature would be if you could have multiple instances/threads of a script running, but your suggestion implies the opposite due to the stop script block.

1. What does imo stand for?

2. the “stop” is a completely different block than the start

The_5th_Scratcher wrote:

-Rex- wrote:

Seems small enough to me. IMO the only reason to add this feature would be if you could have multiple instances/threads of a script running, but your suggestion implies the opposite due to the stop script block.

1. What does imo stand for?

In my opinion.

The_5th_Scratcher wrote:

-Rex- wrote:

Seems small enough to me. IMO the only reason to add this feature would be if you could have multiple instances/threads of a script running, but your suggestion implies the opposite due to the stop script block.

1. What does imo stand for?

2. the “stop” is a completely different block than the start

I'm saying that being able to start and stop scripts by label is already what broadcasts do. If you could start a script on a separate thread (unlike a custom block) with as many instances as you'd like (unlike broadcasts), this suggestion would be much more useful, because it its current form I fail to see any functional difference between this and broadcasts.

Stop Script Block
Semi support because you'll have to put a lot of checks to see if a variable is 1 or not if you have a lot of loops (unless the script is running without screen refresh then not a problem)
Start Script Block
No support because broadcasting is a thing.

The_5th_Scratcher wrote:

DarthVader4Life wrote:

You mean, broadcasts can take the space of one block more than a start script.

PGBFLITE6373 wrote:

It just one block for one file, it won't change much. I honestly don't see the point of this if you can just use brodcasts

Which is smaller?

when I receive [Script v]
start [script: 1 v] ::control

or

when I receive [Script v]
...
...
...
...
...

You can just do this:

whatever hat is used for script 1 :: events hat
broadcast [Script v]

Both blocks can already be implemented using broadcasts, not just the start script block.

define start script (script name)
set [var v] to (item # of (script name) in [scripts to stop v] :: list reporter)
if <(var) > [0]> then
delete (var) of [scripts to stop v]
else
broadcast (script name)
end

define stop script (script name)
if <not <[scripts to stop v] contains (script name) ?>> then
add (script name) to [scripts to stop v]
broadcast (script name)
end

when I receive [example script v]
set [var v] to (item # of [example script] in [scripts to stop v] :: list reporter)
if <(var) > [0]> then
delete (var) of [scripts to stop v]
stop [this script v]
end
...

Edit: this does not work with multiple “when I receive” blocks, but that can be fixed with an appropriate wait block placed where a when I receive script is told to stop. I do not think this is a major issue, since the block name “stop script” doesn’t make much sense with multiple scripts with the same name.

-Rex- wrote:

Both blocks can already be implemented using broadcasts, not just the start script block.

I've removed the start block from the suggestion. I don't think those workarounds are simple enough to have this suggestion rejected.

-Rex- wrote:

define stop script (script name)
if <not <[scripts to stop v] contains (script name) ?>> then
add (script name) to [scripts to stop v]
broadcast (script name)
end

when I receive [example script v]
set [var v] to (item # of [example script] in [scripts to stop v] :: list reporter)
if <(var) > [0]> then
delete (var) of [scripts to stop v]
stop [this script v]
end
...

This is not a workaround. It would only check to stop the script the second it was started.

The_5th_Scratcher wrote:

-Rex- wrote:

-snip-

This is not a workaround. It would only check to stop the script the second it was started.

The code would stop immediately before running.

The_5th_Scratcher wrote:

The_5th_Scratcher wrote:

-Rex- wrote:

-snip-

This is not a workaround. It would only check to stop the script the second it was started.

The code would stop immediately before running.

It works fine for me: https://scratch.mit.edu/projects/544382874/