I think Wait can accept second fragments, not just integers. If that is so, then it should write

wait 0.5 secs

instead of

wait 1 secs

in the Control palette, to be consistent with other commands where the acceptance of floating point parameters seems to be denoted by showing such a number as the “default” parameter value on the command palette

Ok, but what's the advantage of doing this over 1 second?
If we change this, we should also change:
- set variable blocks
- change variable blocks
- say blocks
- think blocks
- set pen colour blocks
- change pen colour blocks
- effect blocks
- when hat block
- pretty much all the motion blocks
- etc.

It's honestly too much work just to show that they can accept decimals.

No Support. I don't see a purpose for changing the default value.

Well, I see your point that it makes the capabilities of the wait block clearer to Scratchers. So if it doesn't take too much time for the ST, then yeah, this is a good idea. Maybe in Scratch 3.

There's

play drum ( v) for (0.25) beats

and

play note ( v) for (0.5) beats

Are there more?

I like the idea of using the input value to signify the block's accepted values. But ‘wait a second’ is fun and easy to understand.

Btw, I made a suggestion on the Scratch 3 thread for inputs to show up as a perfect circle to signify no input value (no space/no character, equivalent to zero when numeric).

I get the “wait a second” idea, but the thing is that there is no other way currently to easily see if a function accepts float parameter or just truncates it (or does it round it btw?). E.g. direction, position etc. in Scratch all seem to be integers (unfortunately in my opinion)

I can sort of see a way that this could be useful for New Scratchers, but honestly, I don't think it's necessary to change every () input to a decimal. Semi-support.

██       ██  ██            ██  ██       ██
██       ██  ██            ██  ██       ██
██       ██  ██     ██     ██  ██       ██
██       ██  ██     ██     ██  ██       ██
███     ███   ██   ████   ██   ███     ███
 █████████     █████  █████     █████████

birbilis wrote:

E.g. direction, position etc. in Scratch all seem to be integers (unfortunately in my opinion)

Direction and position are both floating point numbers. The

(pick random (0.0) to (10.0))

block will return floating-point values if one of the inputs is floating point. The default inputs for the

go to x: (0) y: (0)

block are the rounded coordinates of the selected sprite.

Does a sprite ever show floating point coordinates and/or direction if you press its info button? I think I tried with floating point numbers for position and direction and it just ignored/rounded them internally. That it accepts such values says nothing, thing is if it uses the part or not (and if it does rounding or truncation which can't be known unless one checks some documentation, supposing it was explaining what it does)

Also, I don't suggest showing floating point to commands that don't use such, only to those that use such. Else it looks inconsistent if the original intent of the default values in the palette was to signify which commands accept floating point (and use them I mean, not round/truncate them) and which not

birbilis wrote:

Does a sprite ever show floating point coordinates and/or direction if you press its info button? I think I tried with floating point numbers for position and direction and it just ignored/rounded them internally. That it accepts such values says nothing, thing is if it uses the part or not (and if it does rounding or truncation which can't be known unless one checks some documentation, supposing it was explaining what it does)

Well, it's very simple to test:

go to x: (-240) y: (0)
forever
change x by (0.1)
end

And just because it displays integers also means nothing. I've used floating-point coordinates before, and it worked just fine.

> And just because it displays integers also means nothing. I've used floating-point coordinates before, and it worked just fine.

so if one doesn't use the change by commands but use
x = x + 0.1
style commands it won't work because x+0.1 will always return x again

I think that how it is now is just fine and changing that is a bit pointless. No support.