what is vanilla scratch?

If you want hat blocks, you can do:

when green flag clicked
forever
wait until <blablabla>
broadcast [qwerty v]
end

when I receive [qwerty v]
do stuf :: custom

KMFpenguin wrote:

what is vanilla scratch?

It's unmoded, scratch, (https://scratch.mit.edu)

Bringing this topic up

Bump again. Strangely, only Jonathan50 (hi Jonathan50) talked about the issue of a boolean inside a custom C-block only getting run one time, when you start the C-block.

Jonathan50 wrote:

Falcon1234567 wrote:

custom c defines should look like this:

define while <boolean> {block ::custom-arg}
repeat until <not <boolean>>
block ::custom-arg
end

And… hey presto!

while <something ::custom-arg> {
. . .} ::custom

Either that'll not run at all or it'll run forever, because the actual argument

<something :: custom-arg>

is evaluated ONCE and then bound to

<boolean :: custom-arg>

, and then the body of the custom block is run.

There is another suggestion “repeat reporter”, which was for a “repeat” block that re-runs its input the given number of times (and joins them together), so you can do stuff like this:

(repeat (6) (pick random (1) to (9)) :: control) // 362615, 126345, 983724, 988547, 759182, etc

I wrote a post over there about the possible workaround (if we had custom reporters). I said that it's impossible to get a workaround that works for the “pick random” example unless Scratch also supports custom C-blocks, because custom C-blocks are the main reason to have a check box in the custom block screen, “re-evaluate reporter blocks each time they're used”. (This would be beneath “run without screen refresh”.)

edit is typo fix

I also want to talk about a “count from 1 to 10” custom C-block. The usual use for this block is counting the indexes of letters in a string, or counting the indexes of items in a list. Here is a simple workaround and then two usages.

define {count from (a ::custom-arg) to (b ::custom-arg) {
  script :: custom
} ::custom loop}
set [counter v] to (a ::custom-arg)
repeat ((b ::custom-arg) - (a ::custom-arg))
  script :: custom-arg
  change [counter v] by (1)
end

count from (1) to (length of [my cool words v]) {
  say (join [I love this word! ] (item (counter) of [my cool words v])) for (1) seconds
} :: custom loop

ask [What's your favorite flavor of taco?] and wait
say [OK, say it with me...] for (2) seconds
count from (1) to (length of (answer)) {
  say (join (letter (counter) of (answer)) [!!!]) for (1) seconds
} :: custom loop

Both of those examples would work. But what happens if we try to put them together?

count from (1) to (length of [my cool words v]) {
  say [Say it with me...] for (1) seconds
  count from (1) to (length of (item (counter) of [my cool words v])) {
    say (join (letter (counter) of (item (counter) of [my cool words v])) [!?!?]) for (0.5) seconds
  } :: custom loop
} :: custom loop

Do you see the problem? We're acting like there are two “counters”, and we want to access both at the same time. But we can't access both counters at the same time, because they're really just one variable (whether that variable is “for all sprites” or “for this sprite only”).

We want our custom C-block to “communicate” to the code we end up putting inside it, and we'd like to use a variable to do that, but if we use a variable, then there is only one variable.

There are a lot of different options to help solve this problem. I think the best and most “Scratch-y” option is to just add an option to put variable dropdowns as an input inside our custom block. Then the workaround looks like this instead.

define {count ([variable v] :: custom-arg ring) from (a :: custom-arg) to (b :: custom-arg) {
  script :: custom-arg
} :: custom loop}
set ([variable v] :: custom-arg ring) to (a ::custom-arg)
repeat ((b) - (a))
  script :: custom
  change ([variable v] :: custom-arg ring) by (1)
end

Then putting loops together is simple. You just need to have two variables.

count [word # v] from (1) to (length of [my cool words v]) {
  say [Say it with me...] for (1) seconds
  count [letter # v] from (1) to (length of (item (word #) of [my cool words v])) {
    say (join (letter (letter #) of (item (word #) of [my cool words v])) [!!!]) for (0.5) seconds
  } :: custom loop
} :: custom loop

If Scratch doesn't add variable dropdowns (and list dropdowns *cough cough*) to custom blocks, then there are still other options. The “simple” one is to use a list to store a “stack” of variables. We still want to expose the result on “counter”, so here's how it ends up looking:

define {count from (a ::custom-arg) to (b ::custom-arg) {
  script :: custom
} ::custom loop}
add (a ::custom-arg) to [count stack v]
repeat ((b ::custom-arg) - (a ::custom-arg))
  set [counter v] to (item (length of [count stack v]) of [count stack v])
  replace item (length of [count stack v]) of [count stack v] with ((counter) + (1))
  script :: custom-arg
end
delete (length of [count stack v]) of [count stack v]

count from (1) to (length of [my cool words v]) {
  say [Say it with me...] for (1) seconds
  set [word v] to (item (counter) of [my cool words v])
  count from (1) to (length of (word)) {
    say (join (letter (counter) of (word)) [...!!]) for (0.5) seconds
  } :: custom loop
} :: custom loop

It's a bit clunky, but it works. The problem (besides that Scratch 3.0 still only pretends to support “item last of”…) is that if you have multiple scripts running at the same time then they can't both be using these “count” blocks, because they will mix up their numbers, since they're both using the same “count stack” list. Oh no! It's sort of the same problem all over again!

Believe it or not, there is still a workaround where two scripts won't collide… well, as long as they use the “counter” variable right away, since otherwise some OTHER “count from” loop might still change the “counter” variable under your feet. Anyway, here's the workaround.

define {count from (a ::custom-arg) to (b ::custom-arg) {
  script :: custom
} ::custom loop}
set [counter v] to (a :: custom-arg)
script :: custom-arg
if <(a ::custom-arg) < (b ::custom-arg)> then
  count from ((a :: custom-arg) + (1)) to (b :: custom-arg) {
    script :: custom-arg
  } :: custom loop
end

There's no way for two or more scripts to collide (again, besides being slow to actually use “counter”) because the state of the custom block is not stored in variables, lists, or any other data that might collide. It's only stored in the custom block arguments; “count from 1 to 4” runs “count from 2 to 4” with the same script, which runs “count from 3 to 4” with the same script, which runs “count from 4 to 4” with the same script. At that point the “if a < b” condition is false, so it doesn't run something like “count from 5 to 4”—the loop just ends.

I think the best approach is to just let custom blocks receive and modify variables. There is one suggestion for this from 2014: “Allow the changing of local variables within custom blocks.” (albeit not quite the interface I would recommend, personally)

Oh, I have one other workaround. This one just cheats the “let custom blocks receive and modify variables” by passing an index in a list. It's annoying, but it works.

when gf clicked
delete all of [variables for custom blocks v]
add [0] to [variables for custom blocks v]
set [INDEX: word # v] to (length of [variables for custom blocks v])
add [0] to [variables for custom blocks v]
set [INDEX: letter # v] to (length of [variables for custom blocks v])

count (INDEX: word #) from (1) to (length of [my cool words v]) {
  say [Say it with me...] for (1) seconds
  count (INDEX: letter #) from (1) to (length of (item (word #) of [my cool words v])) {
    set [letter # v] to (item (INDEX: letter #) of [variables for custom blocks v])
    set [word # v] to (item (INDEX: word #) of [variables for custom blocks v])
    say (join (letter (letter #) of (item (word #) of [my cool words v])) [!!!]) for (0.5) seconds
  } :: custom loop
} :: custom loop

define {count (variable index ::custom-arg) from (a ::custom-arg) to (b ::custom-arg) {
  script :: custom
} ::custom loop}
replace item (variable index :: custom-arg) of [variables for custom blocks v] with (a :: custom-arg)
repeat ((b ::custom-arg) - (a ::custom-arg))
  script :: custom-arg
  replace item (variable index :: custom-arg) of [variables for custom blocks v] with ((1) + (item (variable index :: custom-arg) of [variables for custom blocks v]))
end

Again, I think we should just be able to give variables to custom blocks.

Bringing this topic up.

danielhal wrote:

+1

Please say why you support

Isnt this a dupe

Axtonyin wrote:

danielhal wrote:

+1

Please say why you support

Please check the date of the post you are quoting before you make a “let's keep the conversation constructive” reply like this. It doesn't help to ask someone why they support when they gave their support twelve years ago.

Axtonyin wrote:

Isnt this a dupe

This thread is from 2014 and is 20 pages long, so it's unlikely that any similar suggestion 1) is older and/or 2) has a similar amount of discussion. It is also linked from (the main text of) The 7th Suggestion Directory.

Here are other threads that suggest custom C blocks which I found using forumfind. I'm sure I missed some, since I only looked at threads with the word “custom” in the title, but this may cover a lot of them.


Make a block: c blocks by joefarebrother
6 replies. May 2013–Nov 2021. Not closed, no one's called it a duplicate.

Custom block improvements by Pot-of-Cake
12 replies. June 2015–Dec 2015. Not closed.

a Series of Custom Block Suggestions by SolarSon
15 replies. July 2015–May 2016. Not closed, no one's called it a duplicate.

Define a custom block in your own shape! by alshfik
17 replies. Nov 2015–May 2020. Closed, no ST comment but others called it a duplicate of: Custom everything

Custom Block Types by thevampireninja
3 replies. Jan 2016. Not closed.

more types of custom blocks and a percentage block by CakeandBott
13 replies. June 2016. Not closed. Most discussion is about that percentage block; like other threads above which I didn't point out, people pointed toward Better Custom Blocks as a possible main thread, despite that Better Custom Blocks does not have custom C blocks.

More custom block shapes by TNThacker2015
2 replies. March 2017. Closed as a duplicate of… well… Better Custom Blocks.

More Custom Block Options by StaticPlatform
2 replies. April 2017–Dec 2019. It's a list of suggestions and was closed part as duplicates of various threads, part rejected; admittedly no comment from the ST, but the final post does link to this thread in response to custom C blocks.

Some Custom Block Suggestions by 0037318
5 replies. Jan 2018. Not closed, no one's called it a duplicate. Is a list of suggestions.

CUSTOM BLOCK SUGGESTION by BladiPetrov
1 reply. Oct 2021. Closed, without ST comment, as a duplicate of Better Custom Blocks.

Stack block inputs in custom blocks by soarroying
11 replies. March 2022–April 2022. Not closed, no one's called it a duplicate.

block inputs in a custom block by ThatCoder77471
3 replies. June 2022. OP clarified it's about more than just custom C-blocks. Not closed, but one person called it possibly a duplicate of Blocks in custom blocks.

Be able to make a custom block of any kind by killy_the_bid
1 reply. April 2023. Closed, without ST comment, as a duplicate of Better Custom Blocks.

we should add a setting on my blocks / custom blocks to set the block shape whatever you want (except hat blocks) by HarryCreator2416
2 replies. Sept 2023. Closed as a duplicate of two threads: Better Custom Blocks as well as this thread.

custom c block by among_us1w2
5 replies. Feb 2024. Closed, without ST comment, as(?) a duplicate of this thread.

Add more custom block settings by Ollie-Young
11 replies. Sept 2024. Closed, actually with a unique albeit not subject-specific ST comment from cheddargirl, as a duplicate of Better Custom Blocks.

Block as a Parameter in Custom Blocks by MillionOfficial
11 replies. Oct 2024. Not closed, no one's called it a duplicate.

Custom Hat, Cap and Mouth Block by Figoor
2 replies. Dec 2024. Not closed, no one's called it a duplicate.

Define Custom Block Shapes by CastleUser
5 replies. Feb 2025–April 2025. Closed, without ST comment, as a duplicate of Better Custom Blocks.


Threads are more often closed as a duplicate of Better Custom Blocks than this thread, however the Sept 2023 thread by HarryCreator2416 is exemplary: the discussions for custom C blocks and custom hat blocks are understood to belong in this thread. Most threads are closed as a duplicate of Better Custom Blocks simply because they suggest all different shapes of blocks, and Better Custom Blocks is the thread for custom reporter and boolean blocks.

I would not consider this thread to be a duplicate of Better Custom Blocks. The only other reasonable candidate is joefarebrother's suggestion from May 2013, which predates this thread, is more specifically for custom C blocks and does not mention custom hat blocks, and has only 6 replies, as opposed to this thread's approximately 400. (Better Custom Blocks currently has about 2800 replies.)