What happens if you want the defaut to be true? No support, simple workaround a confusing

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is too complex. It's like a

go to center:: motion

block when you can just do

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

(that one got rejected because then new scratchers will have to learn the coordinates system) also how are new scratchers supposed to understand this block? There is literally no text explaining it.

brooc210 wrote:

Workaround: The item of list block is secretly a boolean!

hiPeeps124816 wrote:

just do

if (item (1 v) of [list v] :: list) then
...
end

Bugs aren't workarounds!

Support. I personally find it annoying that I can’t type in and, or, or not booleans. And I can’t put variables in either. Instead, I have to put in a compatible set of booleans of less than /greater than in order to slot variables inside/type in there.
I’m not 100% sure this is what you are talking about, but I’m at least 60%.

TheSmartGuy1234 wrote:

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is a bit complex and completely useless (see above)

Did you read the original post?

medians wrote:

TheSmartGuy1234 wrote:

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is a bit complex and completely useless (see above)

Did you read the original post?

Updated my post please update yours

Support, if it works with falsy falues, like empty, 0, “false”, and true values if it's not “true”, or 1. If it's not those it should be true.

TheSmartGuy1234 wrote:

medians wrote:

TheSmartGuy1234 wrote:

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is a bit complex and completely useless (see above)

Did you read the original post?

Updated my post please update yours

Let me guess people are too stupid to click a button in 2021

TheSmartGuy1234 wrote:

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is too complex. It's like a

go to center:: motion

block when you can just do

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

also how are new scratchers supposed to understand this block? There is literally no text explaining it.

There's no text explaining all the math blocks (yes, I know what they are.)

new-to-scratch POV

((0) mod (0)) // ???
([mathy function v] of (9)::operators) // ???

How is this different? It could be structured like

<[] is true?::operators> 

Building on to this,

<[1] is true?::operators> // true
<[0] is true?::operators> // false
<[true] is true?::operators> // true
<[false] is true?::operators> // false
<(empty variable) is true?::operators> // false
<(empty list::list) is true?::operators> // false

lolecksdeehaha wrote:

TheSmartGuy1234 wrote:

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is too complex. It's like a

go to center:: motion

block when you can just do

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

also how are new scratchers supposed to understand this block? There is literally no text explaining it.

There's no text explaining all the math blocks (yes, I know what they are.)

new-to-scratch POV

((0) mod (0)) // ???
([mathy function v] of (9)::operators) // ???

How is this different? It could be structured like

<[] is true?::operators> 

maybe

<[] is [true v]? ::operators> //it would have true and false

medians wrote:

lolecksdeehaha wrote:

~snip~

maybe

<[] is [true v]? ::operators> //it would have true and false

Yeah, but there's always the

<not<>>

block.

<not <[false] is true?::operators>> // true

huh, was looking for this topic, found it in the dust! Bump!

VeryFamus wrote:

Support. I personally find it annoying that I can’t type in and, or, or not booleans. And I can’t put variables in either. Instead, I have to put in a compatible set of booleans of less than /greater than in order to slot variables inside/type in there.
I’m not 100% sure this is what you are talking about, but I’m at least 60%.

Nowadays, I actually disagree with my old support. Sure it has valid reasoning, but that doesn’t remove the fact that if <> then scripts only take true/false. My major problem is this: considering reporters don’t report true/false, wouldn’t that mean that it isn’t true, this not running the script in the if <> then even if the intention was for it to be true? Also, this could make repeat until blocks be just another forever block. No support. Overall would just break Boolean inputs.

Also, the reason the Boolean inputs are designed to not accept reporters or typing is because they can’t determine text as true/false. The Boolean inputs can only report 2 options: true or false.

TheSmartGuy1234 wrote:

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is too complex. It's like a

go to center:: motion

block when you can just do

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

(that one got rejected because then new scratchers will have to learn the coordinates system) also how are new scratchers supposed to understand this block? There is literally no text explaining it.

TheSmartGuy1234 wrote:

brooc210 wrote:

Workaround: The item of list block is secretly a boolean!

hiPeeps124816 wrote:

just do

if (item (1 v) of [list v] :: list) then
...
end

Bugs aren't workarounds!

The block is meant to return anything, not just true/false also I think that thing is done on purpose so that you can make list of booleans.

Edit:

And they could just rename to

Edit 2:

Proof

lolecksdeehaha wrote:

TheSmartGuy1234 wrote:

No support.

<[ ] :: control>

is just

<[] = [true]>

and it is too complex. It's like a

go to center:: motion

block when you can just do

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

also how are new scratchers supposed to understand this block? There is literally no text explaining it.

There's no text explaining all the math blocks (yes, I know what they are.)

new-to-scratch POV

((0) mod (0)) // ???
([mathy function v] of (9)::operators) // ???

How is this different? It could be structured like

<[] is true?::operators> 

Building on to this,

<[1] is true?::operators> // true
<[0] is true?::operators> // false
<[true] is true?::operators> // true
<[false] is true?::operators> // false
<(empty variable) is true?::operators> // false
<(empty list::list) is true?::operators> // false

I agree

lolecksdeehaha wrote:

TheSmartGuy1234 wrote:

No support.

blah blah

block when you can just do

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

also how are new scratchers supposed to understand this block? There is literally no text explaining it.

There's no text explaining all the math blocks (yes, I know what they are.)

new-to-scratch POV

((0) mod (0)) // ???
([mathy function v] of (9)::operators) // ???

How is this different? It could be structured like

<[] is true?::operators> 

booleans

You can expect new scratchers to understand math

TheSmartGuy1234 wrote:

lolecksdeehaha wrote:

~snip~

You can expect new scratchers to understand math

Yes, in fact, you can. However, there are many blocks in the palette that require at least a bit of programming knowledge to use, and including a label on the said block helps, by a TON, to understand it.

lolecksdeehaha wrote:

Building on to this,

<[1] is true?::operators> // true
<[0] is true?::operators> // false
<[true] is true?::operators> // true
<[false] is true?::operators> // false
<(empty variable) is true?::operators> // false
<(empty list::list) is true?::operators> // false

Bit of an issue – This isn't how Scratch handles booleans. More realistically, if I'm not mistaken, Scratch would currently return:

<[] is true?::operators> // true
<[1] is true?::operators> // true
<[0] is true?::operators> // true
<((0) + (1)) is true?::operators> // true
<((0) + (0)) is true?::operators> // false
<[true] is true?::operators> // true
<[false] is true?::operators> // true
<<not <>> is true?::operators> // true
<<not <not <>>> is true?::operators> // false
<(empty variable) is true?::operators> // Depends on the variable's type -- If it's a string, it returns true. If it's a number, it returns false
<(empty list::list) is true?::operators> // false

In order for any block like this to work, there would have to be some weird changes.
Note, this also means the suggestions stating to use

<(val) = [true]>

aren't completely correct (Try 1 == true, for example. It will return false). Doing

<(val) = <not <>>>

should work just fine in all cases I believe. It returns exactly what you brought up as the theoretical return values for this suggested block.
Importantly, this is not how

if (item (...) of [list v] :: list) then
end

works – It should work like the cases I had explained.

lolecksdeehaha wrote:

TheSmartGuy1234 wrote:

lolecksdeehaha wrote:

~snip~

You can expect new scratchers to understand math

Yes, in fact, you can. However, there are many blocks in the palette that require at least a bit of programming knowledge to use, and including a label on the said block helps, by a TON, to understand it.

math isn't one but this is one

Bump