HoofEMP wrote:

You know, the “Run without screen refresh” option is pretty useful. You're adopting AAA game developer mentality; trying to remove a perfectly fine feature to “justify” adding another.

walkcycle wrote:

HoofEMP wrote:

You know, the “Run without screen refresh” option is pretty useful. You're adopting AAA game developer mentality; trying to remove a perfectly fine feature to “justify” adding another.

It's an operator. It runs without screen refresh.

define ask (question) & report answer
ask (question) and wait
report (answer) :: control cap

HoofEMP wrote:

You know, the “Run without screen refresh” option is pretty useful. You're adopting AAA game developer mentality; trying to remove a perfectly fine feature to “justify” adding another.

stickfiregames wrote:

Not inherently. It's possible someone might want to make a reporter that takes time to run. Maybe an (fps) reporter would need no-refresh, although I'm not completely sure.

Jonathan50 wrote:

That would really make custom reporters less useful, there are reasons to make blocking reporters, (…) or if you have an algorithm that runs slowly but you don't want to make the whole project freeze.

Jonathan50 wrote:

Having stage custom blocks global is definitely what should happen though.

walkcycle wrote:

stickfiregames wrote:

Not inherently. It's possible someone might want to make a reporter that takes time to run. Maybe an (fps) reporter would need no-refresh, although I'm not completely sure.

In Scratch, though.

Scratch reporters run without screen refresh.

stickfiregames wrote:

As I said, this is not an inherent feature that reporters must have, it's just that all the built-in ones have it, in the same way that most of the built-in stack blocks do. Jonathan50's example of reporters waiting for input is a good example of where it could be used, I could understand if you wanted to make no-refresh the default but there's no reason to force it.

walkcycle wrote:

stickfiregames wrote:

As I said, this is not an inherent feature that reporters must have, it's just that all the built-in ones have it, in the same way that most of the built-in stack blocks do. Jonathan50's example of reporters waiting for input is a good example of where it could be used, I could understand if you wanted to make no-refresh the default but there's no reason to force it.

Since reporters in Scratch run one way, having a feature to have them run another way is counterintuitive. And not necessary: stack blocks fill the void for waiting and slower tasks.

define (block :: custom)
wait (1) secs
report [hello] :: custom

when gf clicked
say (block :: custom)

zaib_tanvir2008 wrote:

HoofEMP wrote:

You know, the “Run without screen refresh” option is pretty useful. You're adopting AAA game developer mentality; trying to remove a perfectly fine feature to “justify” adding another.

Plz stop sending the same picture

TheMonsterOfTheDeep wrote:

I believe that the exact opposite is true. I think that, a beginner, when playing around with custom blocks, might attempt something like this:

define (block :: custom)
wait (1) secs
report [hello] :: custom

when gf clicked
say (block :: custom)

And then be thoroughly confused that Scratch would choose to disallow this for some arbitrary reason.

when green flag clicked
wait (1) secs
say [hello]

walkcycle wrote:

TheMonsterOfTheDeep wrote:

snip

But it wouldn't. You can put the wait block in and slow it down if want.

when green flag clicked
wait (1) secs
say [hello]

Better to just go with stack blocks for that I would think.

Still, a Scratch programmer should not have to anticipate a 'say [ ] block' is going to wait unless it is a 'say [ ] for ( ) secs' block. So there would be a reason to exclude ‘wait’ blocks from the define script of a reporter or operator block.

define say [x] for (y) secs
say (x)
wait (y) secs
say []

walkcycle wrote:

stickfiregames wrote:

As I said, this is not an inherent feature that reporters must have, it's just that all the built-in ones have it, in the same way that most of the built-in stack blocks do. Jonathan50's example of reporters waiting for input is a good example of where it could be used, I could understand if you wanted to make no-refresh the default but there's no reason to force it.

Since reporters in Scratch run one way, having a feature to have them run another way is counterintuitive. And not necessary: stack blocks fill the void for waiting and slower tasks.

walkcycle wrote:

This is based on the way reporters run in Scratch. A feature to have them run another way is counter to the way Scratch does it.

The matter of waiting also originates with how Scratch does things.

The general gist is to add things in such a way that a Scratch programmer's knowledge of how Scratch works remains applicable to the new thing.

stickfiregames wrote:

You keep saying “it's how Scratch does things” but the same argument could be used to reject changing anything.

stickfiregames wrote:

All built-in blocks either wait or they don't, and the reason the built-in reporters don't wait is not because they are reporters but because the ST has designed each of them not to wait.

stickfiregames wrote:

Custom blocks have an option to wait or not wait depending on whether the creator wants them to. Extending that idea to custom reporters would be perfectly intuitive, and a would mean a Scratch programmer's knowledge of how custom blocks work remains applicable to the new thing.

A reporter block is a block that contains a value. These blocks can contain anything, from numbers to strings. Boolean Blocks are a special form of reporter blocks that report either “true” or “false”. To quickly view the value of a reporter, simply click it in the editor and a bubble will display the value.

All built-in blocks either wait or they don't, and the reason the built-in reporters don't wait is not because they are reporters but because the ST has designed each of them not to wait.

And, thus, that is a fundamental part of the nature of reporters in Scratch: Scratch Team's design choice for how reporters are. It is the reliable behavior of the building blocks that Scratch programmers depend on. “It's how Scratch does things.”

Custom blocks have an option to wait or not wait depending on whether the creator wants them to. Extending that idea to custom reporters would be perfectly intuitive, and a would mean a Scratch programmer's knowledge of how custom blocks work remains applicable to the new thing.

True. With two intuitions as to the nature of Scratch, which is more important? Should reporters be given stack-block like features to keep the custom block interface identical? Or should custom reporter blocks in Scratch be like reporter blocks in Scratch?

Outside of this thread, are there any suggestions for a new reporter in Scratch that would need the checkbox?