MathlyCat wrote:

DaEpikDude wrote:

DaEpikDude wrote:

I'd like to point out that there's a better workaround for setting pen colour to hex input:

set pen color to (join [0x][hex input])//this is the color picker, not the number input

This is more compact and easier to interpret at a glance (mainly due to the 0x).

within topic bump i guess???

The workaround listed is better because it's easier to understand; you don't need hex knowledge to be able to use it.

MathlyCat wrote:

The workaround listed is better because it's easier to understand; you don't need hex knowledge to be able to use it.

Jonathan50 wrote:

MathlyCat wrote:

The workaround listed is better because it's easier to understand; you don't need hex knowledge to be able to use it.

The workaround is supposed to be for hexadecimal input though.

Charles12310 wrote:

Jonathan50 wrote:

MathlyCat wrote:

The workaround listed is better because it's easier to understand; you don't need hex knowledge to be able to use it.

The workaround is supposed to be for hexadecimal input though.

All you need to do is define variables R, G, and B.

<True::operators>
<[1]=[1]>
<False::operators>
<[1] = [0]>
<<A> xor <B>::operators>
<<<A> or <B>> and <not<<A> and <B>>

for each [] in [list v] {
} :: list

set [count v] to [0]
set [count2 v] to [0]
repeat (length of [list v])
 change [count v] by (1)
 if <(item (count) of [list v]) = (item needed)> then
  change [count2 v] by (1)
 end
end
if <(count2) > [0]> then
 repeat (count2)
  ...
 end
end

Charles12310 wrote:

<(letter (count) of [list v]) = (item needed)>

<(item (count) of [list v]) = (item needed)>

Jonathan50 wrote:

MathlyCat wrote:

The workaround listed is better because it's easier to understand; you don't need hex knowledge to be able to use it.

The workaround is supposed to be for hexadecimal input though.

MathlyCat wrote:

It doesn't matter.
if you actually read the sticky you would notice the hex workaround already there?

MathlyCat wrote:

set pen color to hexadecimal input [] :: pen // Applies to all set pen color hex variants

set pen color to ((((R) * (65536)) + ((G) * (256))) + (B))

Sharp-Shark wrote:

<<A> xor <B>::operators>
<<<A> or <B>> and <not<<A> and <B>>

<<> xor <>::operators>
<not <<bool1> = <bool2>>>

ohheyderelol wrote:

THIS TEXT IS BIG

neeb132 wrote:

ohheyderelol wrote:

THIS TEXT IS BIG

Please don't spam or necropost.

set x to (0)

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

( ::#000000)

set y to (0)

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

( :: #000000)

next costume

switch costume to ((costume #) + (1))

( :: #000000)

move (10) steps

go to x: ((x position) + (([sin v] of (direction)) * (10))) y: ((y position) + (([cos v] of (direction)) * (10)))

( :: #000000)

forever

end

when green flag clicked
loop :: custom
define loop
...
loop

repeat for (. . . :: grey) secs {
} :: control
:: reporter #000
when gf clicked
set [wait v] to (0)
broadcast [wait v]
repeat until <(wait) = (1)>
...
end
set [wait v] to (0)
:: reporter #000
when i receive [wait v]
wait (. . . :: grey) secs
set [wait v] to (1)

TailsFanV51 wrote:

This is a workaround for

repeat for (. . . :: grey) secs {
} :: control
:: reporter #000
when gf clicked
set [wait v] to (0)
broadcast [wait v]
repeat until <(wait) = (1)>
...
end
set [wait v] to (0)
:: reporter #000
when i receive [wait v]
wait (. . . :: grey) secs
set [wait v] to (1)

neeb132 wrote:

TailsFanV51 wrote:

This is a workaround for

repeat for (. . . :: grey) secs {
} :: control
:: reporter #000
when gf clicked
set [wait v] to (0)
broadcast [wait v]
repeat until <(wait) = (1)>
...
end
set [wait v] to (0)
:: reporter #000
when i receive [wait v]
wait (. . . :: grey) secs
set [wait v] to (1)

Cool! This is very helpful!

set [repeat timer v] to (timer)
repeat until <((timer) - (repeat timer)) > [insert any amount of seconds here]>
...
end

DaEpikDude wrote:

Sharp-Shark wrote:

<<A> xor <B>::operators>
<<<A> or <B>> and <not<<A> and <B>>

Isn't another potential workaround to that…

<<> xor <>::operators>
<not <<bool1> = <bool2>>>

Because if both inputs are true or false it returns false, and if they're different (i.e. 1 true 1 false) it returns true.

<<not <<bool1::grey> and <bool2::grey>>> and <<bool1::grey> or <bool2::grey>>>

AmazingMech2418 wrote:

DaEpikDude wrote:

Sharp-Shark wrote:

<<A> xor <B>::operators>
<<<A> or <B>> and <not<<A> and <B>>

Isn't another potential workaround to that…

<<> xor <>::operators>
<not <<bool1> = <bool2>>>

Because if both inputs are true or false it returns false, and if they're different (i.e. 1 true 1 false) it returns true.

It would actually be this:

<<not <<bool1::grey> and <bool2::grey>>> and <<bool1::grey> or <bool2::grey>>>

You were thinking of nand.

Jonathan50 wrote:

MathlyCat wrote:

It doesn't matter.
if you actually read the sticky you would notice the hex workaround already there?

No, it's not. There's just this

MathlyCat wrote:

set pen color to hexadecimal input [] :: pen // Applies to all set pen color hex variants

set pen color to ((((R) * (65536)) + ((G) * (256))) + (B))

which might be a better workaround, but it's not for hex input

DaEpikDude wrote:

AmazingMech2418 wrote:

DaEpikDude wrote:

Sharp-Shark wrote:

<<A> xor <B>::operators>
<<<A> or <B>> and <not<<A> and <B>>

Isn't another potential workaround to that…

<<> xor <>::operators>
<not <<bool1> = <bool2>>>

Because if both inputs are true or false it returns false, and if they're different (i.e. 1 true 1 false) it returns true.

It would actually be this:

<<not <<bool1::grey> and <bool2::grey>>> and <<bool1::grey> or <bool2::grey>>>

You were thinking of nand.

…no…
Think about it:
Say you have “A xor B”. Imagine you used “not A = B”.
If A and B are true:
A = B, so it returns false.
If A and B are false:
A = B, so it returns false.
If A is true and B is false:
A != B, so now it returns true, same for if B is true and A is false.

MathlyCat wrote:

thanks alxephan


You may have noticed that I have decided to re-do this entire sticky. Please be aware, the Workarounds still exist.

What Is A Workaround?

You might come here and think to yourself: “What in the world is a workaround!” Well I'll explain it to you!

To put it simply, a workaround on Scratch is a way of making a script that does the function of a made-up block.

Workaround = A script that does a function = Made-up block

If you still aren't sure, here's an example:

I have a made-up block that I call:

(() + () + 1::operators) // fixed

A workaround looks like this:

(() + (() + (1)))

See how the top one is made-up, but the bottom one isn't? Though the bottom one works just like the top one!

Here in the suggestions forum many people make suggestions for new blocks. The purpose of this thread is to keep up with blocks which have workarounds to!

—-

Notable Posts/Workarounds from other Suggestions:

A new operators block, similar to (letter () of ) by dvargasews

TheMonsterOfTheDeep wrote:

So, for anybody who's curious, here is the full workaround, that is the absolute best approximation to the block suggested in the OP, which stores its output in ‘result’:

define letters (a) to (b) of (str) => result
if <<<(a) < [1]> or <(b) < [1]>> or <<(a) > (length of (str))> or <(b) > (length of (str))>>> then
set [result v] to []
stop [this script v]
end
delete (all v) of [chars v]
set [i v] to (a)
if <(a) < (b)> then
repeat (((b) - (a)) + (1))
add (letter (i) of (str)) to [chars v]
change [i v] by (1)
end
else
repeat (((a) - (b)) + (1))
add (letter (i) of (str)) to [chars v]
change [i v] by (-1)
end
end
set [result v] to (chars)

“But that's too long!” I hear you say. Note that this is the absolute complete workaround, that does everything mentioned in the OP (reverse output on backwards indices) and then some (return the same thing as letter (0) of (str) if indices are out of bounds).

For the majority of cases, something much simpler will work, such as:

define letters (a) to (b) of (str) => result
set [i v] to (a)
set [result v] to []
repeat (((b) - (a)) + (1))
set [result v] to (join (result) (letter (i) of (str)))

Note that the only things this block does not support are a) reverse strings, b) bounds checking, and c) strings above the join block limit, which is barely even a problem, as most string manipulation will involve the join block anyways.

Also note that this block will still return a valid value for invalid bounds, simply due to how Scratch bound checks the letter of () block.

If the i variable is bothering you, it gets even better:

define next letter (i) (b) (str)
set [result v] to (join (result) (letter (i) of (str)))
if <(i) < (b)> then
next letter ((i) + (1)) (b) (str)
end

define letters (a) to (b) of (str) => result
set [result v] to []
next letter (a) (b) (str)

And if we had custom reporters, this block would need no variables at all.

To compare, the speed of all three blocks is pretty good for small strings, and the second one should work for almost anything that you would actually need to do in Scratch. It's likely that whatever block the Scratch Team implemented would also be slow on ridiculously large strings, simply because creating substrings, unless they are interned, is by nature an O(n) operation.

My point with this post is that OP's argument that the workaround is laggy / slow is basically moot; although this custom block only works in a single thread, if you are doing multi-threaded string manipulation you are already probably doing something wrong.

I'm honestly not sure where I stand in terms of better string manipulation features in Scratch - certainly they are useful, but figuring out how to implement them myself was honestly one of the best critical thinking exercises I ever received from Scratch. It's important to be able to know how these sorts of operations work on the inside, as it allows you to see how slow they really are - I think people learning to implement them manually is a good experience, and I think that it is not at all bad that Scratch provides it.

I especially think that if we do ever get custom reporters, we should not implement blocks like these - if there were custom reporters (and maybe local variables) than implementing these blocks by hand would have very little negative effect, while it would have a huge educational effect.

Maybe not though. I am using anecdotal evidence here, but I don't think my point is entirely invalid.

Concerning the Bounce block

TheMonsterOfTheDeep wrote:

Because they seem to be cropping up, let me make an offtopic post to clear up some misconceptions about the bounce block…

It's very difficult to make a general “bounce” block, because what it does is reflect the sprite by mirroring its velocity across the line normal to the surface it hits. (Sorry, it's kind of hard to be exactly clear about what it does, so I'm trying to be specific).

However, it's very likely that this block would work imperfectly, at least for bitmap sprites, because the normal line calculated would be more of an “average” normal line than the actual line.

That's not the only problem, of course - the other problem is the question of what to do when the sprite is intersecting (not merely touching the edge of) the other sprite, and what to do when it's touching or intersecting multiple sprites.

The ‘if on edge, bounce’ block is comparatively simple - it merely means that if the sprite is touching or intersecting an edge, reflect across the line perpendicular to that edge in the middle of the sprite, which is really easy to do.

(The reason intersection works for the edge and not for sprites is because the edge is a single line - it's easy to define where the reflection line is, which is straight in the middle of the sprite. However, if it is intersecting a generally shaped object, you also have to calculate the normal line - and where to calculate that is based on where it is touching, which is ambiguous.)

P.S. If you would like to discuss the bounce block more, please make a new topic or find an old one (I'm pretty sure there is at least one old one you can use).