all at once
    ...What should be run without screen refresh.
end

run without screen refresh

end

Gaza101 wrote:

I'm not entirely sure what you're suggesting here.

P444 wrote:

Gaza101 wrote:

I'm not entirely sure what you're suggesting here.

This and nothing is done simultaneously on scratch, there is always a time lag.

all at once :: control cstart
end

run :: control cstart
without screen refresh :: cend

stickfiregames wrote:

Support, it will also make scripts easier to follow since they are all in one place.

P444 wrote:

Gaza101 wrote:

I'm not entirely sure what you're suggesting here.

This and nothing is done simultaneously on scratch, there is always a time lag.

all at once :: control cstart
end

was a block from development versions of 2.0 which was the same as running without screen refresh. If it does come back it should have a better name though, like

run :: control cstart
without screen refresh :: cend

Gaza101 wrote:

I'm not entirely sure what you're suggesting here.

NDSDNS wrote:

Gaza101 wrote:

I'm not entirely sure what you're suggesting here.

It was a control block that acted like a custom block without screen refresh in 2.0 alpha. It was removed because of custom blocks

run without screen refresh::control cstart

end

define 

all at once::control cstart
show
wait (1) secs
hide
end

Sheep_maker wrote:

So in this situation:

all at once::control cstart
show
wait (1) secs
hide
end

I'm hoping that unlike custom blocks without screen refresh, the wait block gets pushed to the end of the script, so it will show, hide, then wait one second. Otherwise it would be easier to lag projects.

Or maybe the wait block gets ignored?

Also will repeat blocks run faster? How about forever loops; what would happen if I put one in there?

Although I support, custom blocks reduce the chances of accidentally lagging yourself.

TheMonsterOfTheDeep wrote:

Sheep_maker wrote:

So in this situation:

all at once::control cstart
show
wait (1) secs
hide
end

I'm hoping that unlike custom blocks without screen refresh, the wait block gets pushed to the end of the script, so it will show, hide, then wait one second. Otherwise it would be easier to lag projects.

Or maybe the wait block gets ignored?

Also will repeat blocks run faster? How about forever loops; what would happen if I put one in there?

Although I support, custom blocks reduce the chances of accidentally lagging yourself.

I think it should behave exactly the same as custom blocks.

Support.

pvz_pro wrote:

no support, right click the define block (looks like this)

define 

run :: control cstart

all at once :: control cend
// or
run :: control cstart

at Sanic speed :: control cend

run::control cstart
...
without screen refresh::cend

Gaza101 wrote:

NDSDNS wrote:

Gaza101 wrote:

I'm not entirely sure what you're suggesting here.

It was a control block that acted like a custom block without screen refresh in 2.0 alpha. It was removed because of custom blocks

I'm aware of what the block did; I was just confused by your lack of explanation.

pvz_pro wrote:

no support, right click the define block (looks like this)

define 

NDSDNS wrote:

pvz_pro wrote:

no support, right click the define block (looks like this)

define 

I do not think you understand the point. We are talking about 1script1sprite. If you add a custom block it is ANOTHER SCRIPT, making it NOT 1script1sprite, which is the goal.

P444 wrote:

NDSDNS wrote:

pvz_pro wrote:

no support, right click the define block (looks like this)

define 

I do not think you understand the point. We are talking about 1script1sprite. If you add a custom block it is ANOTHER SCRIPT, making it NOT 1script1sprite, which is the goal.

1 single custom block (with scripts to run inside) will only differ from what your block would be is a hat block. Plus, you can run the custom block with only 1 block rather your block has to copy paste the whole script inside if you are going to run it multiple times, so it will actually increase in size (if that is the concern you are having).

griffpatch wrote:

Test out how it might work here: https://scratch.mit.edu/projects/113321949/

My emulated version of this block allows for nesting of wait and broadcast & wait without causing the project to lag out. It just assumes that such a request means that you do indeed with to wait, even though you are within the atomic section. Once the wait is over the execution continues in an atom manor. Seems to work well.