Scratch Debug/Dev console (Now as an extension with more blocks)

Scratchybear22

Disclamer:Please learn what a console is if you don't know before making remarks about it being needed or not, because you might not know what a JavaScript or other code console is. Also please stop suggesting the workaround, I knew it from the start, I am suggesting adding a console, and also many blocks like change my var by () have workarounds. See also this post.. (Thanks to @knowitall1237), please read before saying a workaround!

Wouldn't it be cool if there was a console that would put messages in the console from blocks (see mockups) like in java scripts. (it would be an extension, this decision was made because more blocks are being suggested, and I do not want to add too many blocks into the sensing catagory.

I am suggesting the following blocks, as an extension, as well as a console.

print [] in console [#aaaaaa] :: sensing // this is a solution instead of adding "warn, error, etc", to make it simpler for new scratchers. -@Cswitch

ask [] in console and wait :: sensing//note: This block would be skipped if you are not in the editor where the costume would be and commands can't be ran while the code is asking.

When [] ran in console ::sensing :: hat// commands would be ran by saying "/(command)", to allow people to put messages in without causing an effect 

clear console :: sensing

(console input :: sensing)// would broadcast the last command ran or the answer to the ask block ^^

-3rd block credit to @knowitall1237, would report the last command ran, (Seep post #25)

What would this be useful for

Debugging, especially because the current “debugging” part is not really helpful.
Making complicated scratch codes (The “say” block could send info only sent in console for development info such as logging variable changes)
Development commands for experimenting, without having to add something into the code
A more in-debth way of explaining what your code does to people “seeing inside”, and giving the a console to see how the code works step by step

Q&A
What would the debug part do to debug: It would be customizable, but if something like (hi - e) was ran in the code, an error message would pop up.

Could this be used for cloud chatting: No, it is a local console, and would start blank

What would the report say if no command was ran yet: Nothing, for more information on the use of the report see post #25

Where would it be located: The backpack menu would either move to under the sprites section or the backpack menu would be split in half, with half becoming the debug menu (I am not totally sure, please give suggestions on this!)

Isn't this not for the designed user of Scratch: Not at all, this would allow younger scratchers to learn about complicated codes step by step instead of comments just showing up, preparing them for more advanced coding platforms, and letting them create more things!

knowitall1237 wrote:
-snip-
I actually don't think this is too complex either. I mean, the default line of code in 99% of languages is basically “print ‘Hello, World’ to console”
-snip-

How would the When Ran in console block work (added because of confusion on this topic): Lets say I had an “/update variables” command,

When [update variables] ran in console :: sensing hat
...

Isn't there work around for all of this: Although there is a “say block”, it is a lot more bulky, harder to understand, and would get annoying if like you wanted to log all the times a variable changed. Additionally, it keeps the game fun for the users while making it easier to decide on the inside.

knowitall1237 wrote:
-snip-
Being able to type in the console would also be a more clean way to create debugging tools
-snip

Many people in the comments are saying this

Reference posts

If you like this idea, the most supportive thing you can do is post saying support and what you like about it/when could it be useful for you, and if you don't like it then please share feedback.

Last edited by Scratchybear22 (Yesterday 21:52:59)

ilIusionator

broadcast [ v]

and

when I receive [ v]

do exactly this

knowitall1237

ilIusionator wrote:
broadcast [ v]
and
when I receive [ v]
do exactly this

not really
receive blocks don't have rounded inputs
also you're ignoring the entire “printing to the console” part of this suggestion

Last edited by knowitall1237 (Oct. 14, 2026 00:32:23)

ChristianScratcher1

Support!
This'd also help for debugging quite a bit and help make a smoother transition to text-based programming later on while still not being too complex a concept

ilIusionator

knowitall1237 wrote:
ilIusionator wrote:
broadcast [ v]
and
when I receive [ v]
do exactly this
not really
receive blocks don't have rounded inputs
also you're ignoring the entire “printing to the console” part of this suggestion

1. The rounded reporter thing doesn't seem to be all that useful
2. The broadcast block still functionally achieves the same thing for the average viewer

I think all we need is a little console for broadcast messages instead of this,

Scratchybear22

ilIusionator wrote:
knowitall1237 wrote:
ilIusionator wrote:
broadcast [ v]
and
when I receive [ v]
do exactly this
not really
receive blocks don't have rounded inputs
also you're ignoring the entire “printing to the console” part of this suggestion
1. The rounded reporter thing doesn't seem to be all that useful
2. The broadcast block still functionally achieves the same thing for the average viewer

I think all we need is a little console for broadcast messages instead of this,

Can I clarify please.

Simple message blocks arent what a console is, a dev console is where the code puts in message in the dev log, and you can run commands in the log with functions
“Console.log (”Varible has been set to 3“)”

This is one example of what a java scripts console log acts as.

Your suggested workaround does not do either sending things into a dev console, nor running a dev console command, I suggest familiarizing yoursellf with what a dev console is before making options/workarounds on the topic.

_WOFDOG_

Scratchybear22 wrote:
~snip~ (one post above)

Workaround:

 
add (command) to [console v]
When I receive [message ran? v]
wait until <(item (length of [console v] :: list) of [console v] :: list) = (command)>

Or for more specificness,

add [Eeee] to [console v]
Define When (command) ran in console
wait until <(item (length of [console v] ::list) of [console v] ::list) = (command)>

If you want a special print block,

define Print (command)
add (command) to [console v]

Last edited by _WOFDOG_ (Oct. 14, 2026 02:48:55)

gdfsgdfsgdfg

_WOFDOG_ wrote:
-the post-

read the op
this is suggesting for a JS console log thing
not this

Scratchybear22

_WOFDOG_ wrote:
Scratchybear22 wrote:
~snip~ (one post above)
-snip-

I understand, but a console is much neater, and is exclusively for development (or seeing inside), making it easier. Lists are really hard to read, especially depending on your use of the console. lists have bad formatting so you wont be able to read the whole thing unless you extend it a lot, and then you wont be able to see the code.

Lists are bulky, and running commands in a separate console while viewing the code and the project is much easier than having a console inside of the code. This allows you to see the console, (helps with debuging), the code, and the project all at once, as well as letting you run commands during the test run.

Finally, Scratch is a beginner coding language, when an 8 year old starts, and wants to do coding later in life (maybe for a job or something), they most likely aren't going to do Scratch, so what's the harm in teaching them a fundamental of many coding languages early.

Scratchybear22

BUMP!!!

xylidine

After reading through the posts of this topic, I have arrived at the conclusion that this feature is essentially a debug log window, correct? Although several workarounds may exist, you are suggesting a completely separate, dedicated console window. Do you have any ideas on where this console would be accessed/located? Would it be positioned on the far left block category panel, or accessed through the “Debug” button on the menu bar?

Scratchybear22

xylidine wrote:
After reading through the posts of this topic, I have arrived at the conclusion that this feature is essentially a debug log window, correct? Although several workarounds may exist, you are suggesting a completely separate, dedicated console window. Do you have any ideas on where this console would be accessed/located? Would it be positioned on the far left block category panel, or accessed through the “Debug” button on the menu bar?

Yes, that is what I was getting at.

I would either move the backpack menu to under the sprites or I would split were the backpack menu is, half of it would be the debug console and the other half would be backpack.

ilIusionator

Scratchybear22 wrote:
ilIusionator wrote:
knowitall1237 wrote:
ilIusionator wrote:
broadcast [ v]
and
when I receive [ v]
do exactly this
not really
receive blocks don't have rounded inputs
also you're ignoring the entire “printing to the console” part of this suggestion
1. The rounded reporter thing doesn't seem to be all that useful
2. The broadcast block still functionally achieves the same thing for the average viewer

I think all we need is a little console for broadcast messages instead of this,
Can I clarify please.

Simple message blocks arent what a console is, a dev console is where the code puts in message in the dev log, and you can run commands in the log with functions
“Console.log (”Varible has been set to 3“)”

This is one example of what a java scripts console log acts as.

Your suggested workaround does not do either sending things into a dev console, nor running a dev console command, I suggest familiarizing yoursellf with what a dev console is before making options/workarounds on the topic.

The OP mentions 2.5 purposes of this dev console,

You mention debugging, and how this console can help identify problems in coding (you also mention explanations but that makes 0 sense because we have comments). This is already a pretty good reason to add a console, enough to justify it's addition by itself? No, because once the project has been shared the blocks serve 0 purpose to code at all and end up being a glorified comment

You also mention a

when () ran in console ::hat sensing

block, which does sound interesting and does indeed serve a purpose in code beyond debugging,
until you realize it's just a when broadcast received block, with the only difference being a console that most people will hide because it obstructs their platformer.
never mind, the debug console isn't even located on the project screen, you have to look inside the code to even catch a glimpse of the feature, further tearing apart the use cases of these blocks
oh and you mentioned js commands, even though the ST has said numerous times that more advanced forms of code wont be implemented into scratch in any way.

—-

So that leaves these blocks with one and only one purpose, debugging. So I ask, why implement a whole new block if it's just a glorified broadcast??
You could just add a console-like feature to the already existing broadcast system, that keeps ST from implementing 2 blocks.

Last edited by ilIusionator (Oct. 15, 2026 03:22:44)

Scratchybear22

ilIusionator wrote:
-snip-

Okay so I am just going to answer some of your questions/concerns

When I mean by comments, you could use the say () in console block to give explinations step by step, when the code is ran vs a bunch of text just sitting there.

The debug feature I might go more in depth into in the post (sorry for not doing so ahead), but it would basically (prolbey configurable) if you ran something like “bob - Joe = 0” it might send a message saying “false inputs put in on ()”. The main way the debugin actuly works in many coding launges is that you add if.. then… s and other stuff that send messages when an issue arises, or they log all changes to avribles/lists to help you debug (but you would have to make it).

And for the finaly time, its not a “glorified broadcast”, it is nothing like a broadcasts, it is ran when something is typed into the console ex“/get all variable data”, and other stuff, teaching new coders how to make codes to fix and debug there own codes, preparing them for more advanced launges, it would also have a actually debug menu.

You said that I talked about JS comands, and just to be clear I was just referencing, and giving an example, I expect for them to be simpler and easier to understand.

It would be located somewhere, not “obstructing ”here platformer"

Please give feedback in a more-friendly tone.

Last edited by Scratchybear22 (Oct. 15, 2026 03:24:43)

ilIusionator

Scratchybear22 wrote:
ilIusionator wrote:
-snip-
Okay so I am just going to answer some of your questions/concerns

When I mean by comments, you could use the say () in console block to give explinations step by step, when the code is ran vs a bunch of text just sitting there.

Comments have arrows to the code it's connected to, I believe.

Scratchybear22 wrote:
The debug feature I might go more in depth into in the post (sorry for not doing so ahead), but it would basically (prolbey configurable) if you ran something like “bob - Joe = 0” it might send a message saying “false inputs put in on ()”. The main way the debugin actuly works in many coding launges is that you add if.. then… s and other stuff that send messages when an issue arises, or they log all changes to avribles/lists to help you debug (but you would have to make it).

This is great, I honestly love this idea. No complaints here

Scratchybear22 wrote:
[
And for the finaly time, its not a “glorified broadcast”, it is nothing like a broadcasts, it is ran when something is typed into the console ex“/get all variable data”, and other stuff, teaching new coders how to make codes to fix and debug there own codes, preparing them for more advanced launges, it would also have a actually debug menu.

When I referred to this suggestion I was talking about the

when () ran in console ::hat sensing

Which achieves the same thing as

when I receive [ v]

(unless I'm missing something)
mb, should've been more specific

Scratchybear22 wrote:
You said that I talked about JS comands, and just to be clear I was just referencing, and giving an example, I expect for them to be simpler and easier to understand.

I see, mb
—
Here's my new stance on this suggestion:

I think this suggestion great, but I doubt it will be added.

For one, this suggestion focuses on more advanced topics (for new programmers, that is), which ST has constantly and repeatedly opted to not include in any suggestions (they have trig though, I don't get that)

The block and console feature also feels a little vague, anybody stumbling upon it for the first time would definitely be confused. This would be fixed with the re addition of the tips menu (or a tutorial, I don't think those get made anymore though)

And again,

  
when () ran in console ::hat sensing

still feels a little redundant,

Scratchybear22

ilIusionator wrote:
-snip-

The main thing the block would do is allow you to run commands from the console without messages automatically coming up asking you if you want to run a command, which is intended for development.

Last edited by Scratchybear22 (Oct. 15, 2026 13:56:18)

knowitall1237

I posted here but I completely forgot to say whether I support or not

Support
This would be way better than the say block for debugging, because it would allow you to get multiple values at once per frame. You would also be able to look through and analyze data in order to see exactly where something went wrong.
Being able to type in the console would also be a more clean way to create debugging tools
(Btw illusionator I assume that's the intended purpose of the hat block)
I actually don't think this is too complex either. I mean, the default line of code in 99% of languages is basically:

print "Hello, World!" to console

There is one problem with this though. There's no way to actually see user input
To solve that, the hat block could be changed to this:

when (input :: sensing) ran in console :: hat sensing

CuteRobot22

I'm conflicted on whether to support or not. I think that this would be a bit to complicated to kids using scratch (most don't even know what JS or a console is) and you can just use lists. On the other hand, this would be helpful for debugging complicated projects if you know what you are doing (especially cloud variables)

Personthatisnormal

ilIusionator wrote:
And again,
when () ran in console ::hat sensing
still feels a little redundant,

You could change the input you are looking for with a variable.

when (variable) ran in console ::hat sensing

—

say [] in console :: sensing

Is this block kind of like the print() function in Python and (I assume) other coding languages?
I think the menu should not be part of the backpack, just a button next to the backpack that covers the same area when opened. By what you said, you made it sound like the backpack button also pulled up the console.

medians

Honestly support for sth like this bc the “dEbUg” thing feels so useless and just common sense to me, and it's just tutorials rather than actual debugging tools

Discuss Scratch