Hi! I'm DooplisBlue, and I've been using Scratch through different accounts (I always forget passwords when switching computers) for about, well, 5 years.

It has occured to me, after 5 years of using the language, that there is no operator block that checks if a value is NOT equal to a given value.
Instead, in order to do such a thing, I would have to do this:

if <<(value) < [0]> or <(value) > [0]>> then
broadcast [ValueNotZero]
end

The code block will broadcast the message “ValueNotZero” IF:
- the variable “value” is LESS than 0
- OR the variable “value” is MORE than 0

That's a lot of excess junk that could be avoided just by adding a != block.
I think adding such a block would make things a LOT easier, such as eliminating redundancy in RANDOM loops.
I think it would help beginners make value checkers a lot easier, too.

Please consider adding this!

easy workaround

<not <[] = []>>

Actually, this is why we have the “not <>” block in operators.

<not <>>

This block works perfectly fine as you'd expect, so if you for example don't want var1 to equal 3 for some checksum, then you can just simply add an equals operator, the variable and the value…

<not <(var1) = [3]>>

And you have it done.

While I see this would save atleast a singular block, I doubt it's really all that neccasary.

EDIT: Ninja'd.

ok fr though
why do we have

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

if we can do this

set x to (0)
set y to (0)

once again its called convenience
its the same as why do we have to pay for a bottle of water
when we can just get water from the tap for free
it’s because of convenience
So you don’t have to do multiple workarounds
for a messy thing

gdfsgdfsgdfg wrote:

ok fr though
why do we have

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

if we can do this

set x to (0)
set y to (0)

once again its called convenience
its the same as why do we have to pay for a bottle of water
when we can just get water from the tap for free
it’s because of convenience

The not < > block is a lot more versatile than the go to x() y () block though

Zydrolic wrote:

Actually, this is why we have the “not <>” block in operators.

<not <>>

This block works perfectly fine as you'd expect, so if you for example don't want var1 to equal 3 for some checksum, then you can just simply add an equals operator, the variable and the value…

<not <(var1) = [3]>>

And you have it done.

While I see this would save atleast a singular block, I doubt it's really all that neccasary.

EDIT: Ninja'd.

Forgot the “not” block existed, my personal fault. Still, it just feels weird…

Xzillox wrote:

The not < > block is a lot more versatile than the go to x() y () block though

I was saying the reason that convenience is better than workaroundablity

gdfsgdfsgdfg wrote:

ok fr though
why do we have

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

if we can do this

set x to (0)
set y to (0)

once again its called convenience
its the same as why do we have to pay for a bottle of water
when we can just get water from the tap for free
it’s because of convenience

Because thats not completely redundant
the addition of the x: y: block wont make the X and the Y block pointless, nether would the inverse, yet the addition of a “not equals” block would be completely redundant to the not block's function.

yadayadayadagoodbye wrote:

Because thats not completely redundant
the addition of the x: y: block wont make the X and the Y block pointless, nether would the inverse, yet the addition of a “not equals” block would be completely redundant to the not block's function.

It was saying that convenience is better can workaroundablity
so everything will be clean

gdfsgdfsgdfg wrote:

yadayadayadagoodbye wrote:

Because thats not completely redundant
the addition of the x: y: block wont make the X and the Y block pointless, nether would the inverse, yet the addition of a “not equals” block would be completely redundant to the not block's function.

It was saying that convenience is better can workaroundablity
so everything will be clean

everything except the block pallet
if we add this, why dont we also get “Not greator then” “Not less then” “Nand” “Nor” “Not touching” and all those other blocks?

gdfsgdfsgdfg wrote:

Xzillox wrote:

The not < > block is a lot more versatile than the go to x() y () block though

I was saying the reason that convenience is better than workaroundablity

Yes, but the not < > block is convenient for many purposes. A != block would be very easily workaroundable (that's not a word) and, as yadayadayadagoodbye said, would be very redundant.

I honestly think for once that ≠ would be useful. Even with an easy workaround, why not? But then they'd have to add stuff like ≥ so yeah semi support

unmissable wrote:

Even with an easy workaround, why not?

Because the workaround is so easy that the block would just be redundant and cause clutter. From the For Developers page:

for developers page wrote:

Despite the common drive to add more features to software products, we have found that reducing the number of features often improves the user experience. What initially seems like a constraint or limitation can foster new forms of creativity.

The ST doesn't want to add unneeded blocks. I think the workaround is easy enough that the last sentence of the quote applies here: What initially seems like a constraint or limitation can foster new forms of creativity.

yadayadayadagoodbye wrote:

Because thats not completely redundant
the addition of the x: y: block wont make the X and the Y block pointless, nether would the inverse, yet the addition of a “not equals” block would be completely redundant to the not block's function.

Also, if pen is down the 2 blocks can be different than go to x: () y: ().