First of all, this seems like a suggestions thread for tiny little changes like an exponent block.

Secondly, I think we should focus on big changes.
When 2.0 was going to be released, people were excited about cloud variables, clones, online editors, etc, and not small blocks.

Scimonster said great things, like arrays, text stamping, etc.

I think those would be great, along with things like realtime collaboration (while there are problems, it could be worked out (as there are also problems with cloud variables, etc), a mentoring system (see below), and an integrated tutorial and other built in features to help new scratchers get started more easily.
Something to help remixes/prevent copies or theft would be nice too.

A mentoring system: (stolen from Leap Day )
Mentors are selected by the scratch team like curators are, or in a way that wiki members are chosen.
When a new scratcher joins Scratch and does the tutorial mentioned above, if there are any mentors online at the moment, the new Scratcher will be asked to go make a simple project with the mentor, and the mentor will teach tips and how to make projects, etc.
Ideally, chat would be needed for communication, but maybe there's a better way for this. (Safe chat with premade things like “drag this block here”, “draw a costume”, etc)

I should post this in suggestions, but oh well.

Well lets just say it will be soooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo c0000000000000000000000000000000000000000000000000000000000000000000000000000000l!!!!!!!!!!!!!!

HTML5 is all I ever wanted in the world.

DotDash wrote:

You can already easily workaround that.

ProdigyZeta7 wrote:

Not in 1s1s projects.

ProdigyZeta7 wrote:

Try pointing towards a clone. Not so easy workaround, huh?

I would be happy to add a couple of examples to my How To Studio which do both of these things.

Point to X,Y

1. We already know our x, y
2. We can calculate the angle between our x,y and the intended X,Y
3. We can convert that angle to a Scratch direction

Point to a clone
1. <When I Start As A Clone> - assign a unique identity
2. Broadcast which clone you want to point towards
3. Have the appropriate clone respond with their X,Y and then follow the instructions above

If you are interested, let me know. I will probably end up doing it eventually anyway but if you or someone else is interested, I would be motivated to move it up the priority list.

Cheers,
Joshua

I'd like to see Scratch actually check the current value of a graphics effect before it changes it - and *not* bother to do anything if it's already set to that value.

Same goes for switching costume, set/change size, and the direction (rotation and point-towards).

Also, I'd like to see it not perform any of those ‘looks’ operations if the sprite is currently hidden, instead only keeping track of what these looks settings get changed to while hidden, and only applying the final settings at the point the sprite gets shown (and only ones that are different to what they were when the sprite was last visible).

Suddenly, a lot of laggy projects would become playable - even with Flash 11.8.

(But none of above is really for Scratch 3.0 - it should be Scratch 2.0.X…)

DadOfMrLog wrote:

I'd like to see Scratch actually check the current value of a graphics effect before it changes it - and *not* bother to do anything if it's already set to that value.

Same goes for switching costume, set/change size, and the direction (rotation and point-towards).

Also, I'd like to see it not perform any of those ‘looks’ operations if the sprite is currently hidden, instead only keeping track of what these looks settings get changed to while hidden, and only applying the final settings at the point the sprite gets shown (and only ones that are different to what they were when the sprite was last visible).

Suddenly, a lot of laggy projects would become playable - even with Flash 11.8.

(But none of above is really for Scratch 3.0 - it should be Scratch 2.0.X…)

Support. You're like the lag master on here

turkey3 wrote:

I'm talking way into the future, but I was wondering: 3 or 4 years from now, when Scratch 3.0 comes out, what do you think it will be like? Answer these:

1.What do you want it to be like
2. What do you think it will be like

I was just curious at what you thought

What do you want it to be like

I want to have a "open link [ ] in new tab" block

What do you think it will be like

Maybe more blocks.

joshuaho wrote:

turkey3 wrote:

I'm talking way into the future, but I was wondering: 3 or 4 years from now, when Scratch 3.0 comes out, what do you think it will be like? Answer these:

1.What do you want it to be like
2. What do you think it will be like

I was just curious at what you thought

What do you want it to be like

I want to have a "open link [ ] in new tab" block

What do you think it will be like

Maybe more blocks.

Opening a link can lead you to a bad site. I think it should have to be at the domain scratch.mit.edu, and should have a limit of times it is used so someone couldn't open up 100 tabs and crash your computer.

Even if scratch is in flash (I'd rather it not be) PLEASE still be able to export projects to html5 (canvas),

OK, ok, you've talked me into it! Here's my real ‘wish-list’ (some overlap with other posts above…) - but I have to admit that a lot of it I still think is rather more 2.X material (or even 2.0.X) than 3.0…

First, some new features (in no particular order):

• global custom blocks that can be used from any sprite - some practical issues to consider here, though (Do they all get shown in More Blocks? Hopefully, split up local and global blocks, just like variables are not at the moment :/ Or how about custom blocks on the stage are global, just like how the stage can only have global variables…? -could break a few existing project, tho' :( )
• per-user save data - possibly even across projects (avoiding the need to use continual cloud-server polling for cloud-based data - this data would only need downloading at start when project is first loaded, but gets changed on server when changed by the project, just like cloudvars/lists-to-come, but only for that user)
• variables that are local to a custom block (not sure how best to make that work practically, but would be good if someone could figure out an intuitive way to implement it - the link is an interesting suggestion…)
• return values from custom blocks
• sprites … going … offscreen (at least an option to allow it - I don't care where, just somewhere, somehow!) - and offscreen pen, too
• saturation for pen colour (see my custom blocks in the rendering sprite of the 3d framework for drop-in replacement pen colour blocks that includes saturation control - but would be better/faster if it was built-in…)
• pen gradients (i.e. changing the colour, shade, saturation & size while drawing a line to a new position - would make a serious difference to pen-rendered graphics)
• pen ghost effect (tricky to know how best to implement this, but would be neat…)
• stretch effect (not obvious which way to make this interact with rotation, but just do it and explain how it works…)
• more choice over how variables appear when shown -available from within the script itself (position, font, size, colour, background - this would effectively allow arbitrary text printing within the sprite layering, and not just stamping that ends up layered behind all sprites and disappears on “clear”)
• a few more keys detected (at least return/enter, esc, backspace -how about also modifiers like shift/control/alt? Or even allowing a variable in the key pressed block?)
• even better than above, how about a new event block: "when [key] typed"? This would have “key” as an item that can be dragged, like from a custom block header.
• and above introduces this somewhat radical idea: more header blocks containing items that can be dragged - now that we've seen the idea of such things in custom block definitions, I'd like to see them appear more generally in other new header blocks (like the new key event suggestion above)

And now for some interface tweaks (some of them are really just bugs that need fixing):

• fix the key lag problem when scripts do more than 1/30th second of work per iteration
• alphabetic sorting of custom blocks in “More Blocks” pane (why? -take a look in the “Structures” sprite of this project…)
• separate global and local variables in “Data” section pane (as it was in 2.0 beta, but keep alphabetical sorting for each set)
• make list of variables in drop-down menus consistent with the order of variables in the the “Data” section pane
• put “new message” near top of broadcast drop-down list
• fix custom blocks dragged from backpack (currently appearing as “undefined”)
• fix disappearing scripts when dragging & disconnecting from under a custom block (into backpack or other sprite)
• place newly made custom blocks where you can see them, rather than always at top-left of editor
• new “go to definition” item in custom-block's right-click drop-down menu in “More Blocks” that takes you to where the custom block is located in the editor window
• make script comments behave much more sensibly (not jumping around, away from where they're supposed to be ‘anchored’)
• make show/hide variable also recognise when you change the name of its variable (like set/change do)
• prevent changes to a local variable name from affecting local variables of the same name in scripts of other sprites! (This can be REALLY nasty…)

And finally some new blocks (yeah, I know you can build workarounds -that's not the point…):

• letters ( ) to ( ) of [ ]
• color at x: ( ) y: ( ) [yeah, I guess we have to use the spelling from across the pond…]
• costume name reporter
• touching any clone of (sprite1 v) -no workaround for this that can be used multiple times along with movement within a non-refresh block?
• set random numbers seed: ( ) -which section would this go in, though?
• ( ) ^ ( ) - but can't go into same drop-down as other operators since it has two arguments…

Enjoy!

DadOfMrLog wrote:

OK, ok, you've talked me into it! Here's my real ‘wish-list’ (some overlap with other posts above…) - but I have to admit that a lot of it I still think is rather more 2.X material (or even 2.0.X) than 3.0…

First, some new features (in no particular order):

• global custom blocks that can be used from any sprite - some practical issues to consider here, though (Do they all get shown in More Blocks? Hopefully, split up local and global blocks, just like variables are not at the moment :/ Or how about custom blocks on the stage are global, just like how the stage can only have global variables…? -could break a few existing project, tho' :( )
• per-user save data - possibly even across projects (avoiding the need to use continual cloud-server polling for cloud-based data - this data would only need downloading at start when project is first loaded, but gets changed on server when changed by the project, just like cloudvars/lists-to-come, but only for that user)
• variables that are local to a custom block (not sure how best to make that work practically, but would be good if someone could figure out an intuitive way to implement it - the link is an interesting suggestion…)
• return values from custom blocks
• sprites … going … offscreen (at least an option to allow it - I don't care where, just somewhere, somehow!) - and offscreen pen, too
• saturation for pen colour (see my custom blocks in the rendering sprite of the 3d framework for drop-in replacement pen colour blocks that includes saturation control - but would be better/faster if it was built-in…)
• pen gradients (i.e. changing the colour, shade, saturation & size while drawing a line to a new position - would make a serious difference to pen-rendered graphics)
• pen ghost effect (tricky to know how best to implement this, but would be neat…)
• stretch effect (not obvious which way to make this interact with rotation, but just do it and explain how it works…)
• more choice over how variables appear when shown -available from within the script itself (position, font, size, colour, background - this would effectively allow arbitrary text printing within the sprite layering, and not just stamping that ends up layered behind all sprites and disappears on “clear”)
• a few more keys detected (at least return/enter, esc, backspace -how about also modifiers like shift/control/alt? Or even allowing a variable in the key pressed block?)
• even better than above, how about a new event block: "when [key] typed"? This would have “key” as an item that can be dragged, like from a custom block header.
• and above introduces this somewhat radical idea: more header blocks containing items that can be dragged - now that we've seen the idea of such things in custom block definitions, I'd like to see them appear more generally in other new header blocks (like the new key event suggestion above)

And now for some interface tweaks (some of them are really just bugs that need fixing):

• fix the key lag problem when scripts do more than 1/30th second of work per iteration
• alphabetic sorting of custom blocks in “More Blocks” pane (why? -take a look in the “Structures” sprite of this project…)
• separate global and local variables in “Data” section pane (as it was in 2.0 beta, but keep alphabetical sorting for each set)
• make list of variables in drop-down menus consistent with the order of variables in the the “Data” section pane
• put “new message” near top of broadcast drop-down list
• fix custom blocks dragged from backpack (currently appearing as “undefined”)
• fix disappearing scripts when dragging & disconnecting from under a custom block (into backpack or other sprite)
• place newly made custom blocks where you can see them, rather than always at top-left of editor
• new “go to definition” item in custom-block's right-click drop-down menu in “More Blocks” that takes you to where the custom block is located in the editor window
• make script comments behave much more sensibly (not jumping around, away from where they're supposed to be ‘anchored’)
• make show/hide variable also recognise when you change the name of its variable (like set/change do)
• prevent changes to a local variable name from affecting local variables of the same name in scripts of other sprites! (This can be REALLY nasty…)

And finally some new blocks (yeah, I know you can build workarounds -that's not the point…):

• letters ( ) to ( ) of [ ]
• color at x: ( ) y: ( ) [yeah, I guess we have to use the spelling from across the pond…]
• costume name reporter
• touching any clone of (sprite1 v) -no workaround for this that can be used multiple times along with movement within a non-refresh block?
• set random numbers seed: ( ) -which section would this go in, though?
• ( ) ^ ( ) - but can't go into same drop-down as other operators since it has two arguments…

Enjoy!

:O wow that's a lot. It probably took you an hour to make!

turkey3 wrote:

DadOfMrLog wrote:

OK, ok, you've talked me into it! Here's my real ‘wish-list’…

…TL;DR…

Enjoy!

:O wow that's a lot. It probably took you an hour to make!

Worked on it in little bursts of ~5 mins here and there since morning (UK time).

I guess a number of entries in the first list (e.g. pen saturation/ghost, stretch effect) would also be new blocks (so should be in the last list), but I kind of also thought of them as entirely new features (of the pen and costume, in these examples). Whereas the last list is more where I put simpler extra blocks.

The final one in the first list is quite interesting, since it brings up some very new possibilities. I mentioned "when [key] typed“ above as an example, but here's some more…

How about a more generic receive header block: ”when I receive [message]“ ? Suddenly you can easily send some simple data between sprites! (Provides some degree of the functionality that global custom blocks would give.)

A really interesting new event header block that such a feature makes possible would be ”when I am touching [sprite]". Now, how that could be implemented internally is an issue (I suspect it's problematic), and how it works with clones is another question, but if some sensible implementation could be found and explained, I can imagine it would make certain things a lot easier.

Anyway, just some thoughts…

DadOfMrLog wrote:

I'd like to see Scratch actually check the current value of a graphics effect before it changes it - and *not* bother to do anything if it's already set to that value.

Same goes for switching costume, set/change size, and the direction (rotation and point-towards).

Also, I'd like to see it not perform any of those ‘looks’ operations if the sprite is currently hidden, instead only keeping track of what these looks settings get changed to while hidden, and only applying the final settings at the point the sprite gets shown (and only ones that are different to what they were when the sprite was last visible).

Suddenly, a lot of laggy projects would become playable - even with Flash 11.8.

(But none of above is really for Scratch 3.0 - it should be Scratch 2.0.X…)

You seem to know a lot about lag! Whenever I search it, you always seem to be the one to answer Your tips are very helpful though, thanks

DadOfMrLog wrote:

turkey3 wrote:

DadOfMrLog wrote:

OK, ok, you've talked me into it! Here's my real ‘wish-list’…

…TL;DR…

Enjoy!

:O wow that's a lot. It probably took you an hour to make!

Worked on it in little bursts of ~5 mins here and there since morning (UK time).

I guess a number of entries in the first list (e.g. pen saturation/ghost, stretch effect) would also be new blocks (so should be in the last list), but I kind of also thought of them as entirely new features (of the pen and costume, in these examples). Whereas the last list is more where I put simpler extra blocks.

The final one in the first list is quite interesting, since it brings up some very new possibilities. I mentioned "when [key] typed“ above as an example, but here's some more…

How about a more generic receive header block: ”when I receive [message]“ ? Suddenly you can easily send some simple data between sprites! (Provides some degree of the functionality that global custom blocks would give.)

A really interesting new event header block that such a feature makes possible would be ”when I am touching [sprite]". Now, how that could be implemented internally is an issue (I suspect it's problematic), and how it works with clones is another question, but if some sensible implementation could be found and explained, I can imagine it would make certain things a lot easier.

Anyway, just some thoughts…

You know what I always wanted for a hat block? When <> where <> is a boolean input, so you can put any boolean statement into it.

scratchisthebest wrote:

HTML5 is all I ever wanted in the world.

Heh, just kidding, have some ideas:

point to xy, or at least an atan2 function.
Pen additive blending on/off? Stamp additive blending? You could make some sweet effects with it.
More documentation, more obvious links to the getting started projects. If you know nothing about Scratch, it can be hard to get started.
Use the “Explore” tab for something else. Currently it only seems to show front page projects, which are, you know, front paged. Why show them twice?

Hmmm, hasn't this turned into something that's more like “Suggestions” than “Questions about Scratch”…?
EDIT: And why do my posts always seem to end up so tl;dr…?

turkey3 wrote:

You know what I always wanted for a hat block? When <> where <> is a boolean input, so you can put any boolean statement into it.

Yep, I can imagine that'd be useful if it could be made reliable (see below)… wonder how expensive that would end up being? (Flash having to perform the check every time it gets chance, to see if it needs to start up that script…)
OTOH maybe it would be cheaper than having to re-interpret the script of some “repeat until <>” or “if <> then” again and again, because instead it just interprets the condition script once at the start, and could store the ‘interpreted’ version of the condition for continuous checking (which would presumably be much more efficient…)


Having said all of that, there's an interesting question whether there could actually be some fundamental problem with such a construct - something that can potentially be evaluated before any variables have chance to get set up in the way that you want by your GF scripts.

It may even end up rather like the “when timer>(variable)” problem - I'd guess you've not noticed this…? (I suspect not many have!)
But if you create a project containing just the following two short scripts (and have variable checktime and the timer showing so you can see what's happening when it runs):

when GF clicked
set checktime to (0.1)

when timer>(checktime)
set checktime to (timer+0.1)

…then it will work just as you'd expect when you start it, flickering between running and stopped, with both checktime and timer increasing - and you can't stop it!

But now reload the project's page… Then when you start the project it appears to get completely ‘stuck’ before running any scripts (the GF script doesn't even get executed). The only way to make it ‘unstuck’ is to see inside and disconnect the block from under “when timer>…”

My guess is that there is some issue with the “timer>(checktime)” test before things have got initialised correctly within the actionscript used by Scratch. Your “when <>” could well suffer from the same kind of problem - and even if it could be fixed within Scratch itself (so the above timer checking does then work), there are pitfalls associated with the project getting stopped in a state where that boolean could be evaluated as true as soon as the project is next started - and so its script gets executed before your GF script(s) get a chance to initialise your variables.

You would have to be pretty careful to ensure you sorted out such potential execution problems. Not impossible, of course, but does need some careful thought, and I can imagine many Scratchers would rush into using such an event header without considering such things (and then we'll end up with hundreds of confused forum posts to answer… )

DadOfMrLog wrote:

Hmmm, hasn't this turned into something that's more like “Suggestions” than “Questions about Scratch”…?
EDIT: And why do my posts always seem to end up so tl;dr…?

turkey3 wrote:

You know what I always wanted for a hat block? When <> where <> is a boolean input, so you can put any boolean statement into it.

Yep, I can imagine that'd be useful if it could be made reliable (see below)… wonder how expensive that would end up being? (Flash having to perform the check every time it gets chance, to see if it needs to start up that script…)
OTOH maybe it would be cheaper than having to re-interpret the script of some “repeat until <>” or “if <> then” again and again, because instead it just interprets the condition script once at the start, and could store the ‘interpreted’ version of the condition for continuous checking (which would presumably be much more efficient…)


Having said all of that, there's an interesting question whether there could actually be some fundamental problem with such a construct - something that can potentially be evaluated before any variables have chance to get set up in the way that you want by your GF scripts.

It may even end up rather like the “when timer>(variable)” problem - I'd guess you've not noticed this…? (I suspect not many have!)
But if you create a project containing just the following two short scripts (and have variable checktime and the timer showing so you can see what's happening when it runs):

when GF clicked
set checktime to (0.1)

when timer>(checktime)
set checktime to (timer+0.1)

…then it will work just as you'd expect when you start it, flickering between running and stopped, with both checktime and timer increasing - and you can't stop it!

But now reload the project's page… Then when you start the project it appears to get completely ‘stuck’ before running any scripts (the GF script doesn't even get executed). The only way to make it ‘unstuck’ is to see inside and disconnect the block from under “when timer>…”

My guess is that there is some issue with the “timer>(checktime)” test before things have got initialised correctly within the actionscript used by Scratch. Your “when <>” could well suffer from the same kind of problem - and even if it could be fixed within Scratch itself (so the above timer checking does then work), there are pitfalls associated with the project getting stopped in a state where that boolean could be evaluated as true as soon as the project is next started - and so its script gets executed before your GF script(s) get a chance to initialise your variables.

You would have to be pretty careful to ensure you sorted out such potential execution problems. Not impossible, of course, but does need some careful thought, and I can imagine many Scratchers would rush into using such an event header without considering such things (and then we'll end up with hundreds of confused forum posts to answer… )

Your posts are always long but yeah, I actually noticed the timer recursive type thing. I made a project once called “You can't stop me with the stop sign!” And it was the Scratch Cat continuously saying that

@turkey3:

turkey3 wrote:

Your posts are always long

ok, wl try 2 mk shrtr frm nw on

turkey3 wrote:

but yeah, I actually noticed the timer recursive type thing. I made a project once called “You can't stop me with the stop sign!” And it was the Scratch Cat continuously saying that

Dd u hv vrbl in “when timer” hdr blk thn? & u ntcd gt stck..?

DadOfMrLog wrote:

@turkey3:

turkey3 wrote:

Your posts are always long

ok, wl try 2 mk shrtr frm nw on

turkey3 wrote:

but yeah, I actually noticed the timer recursive type thing. I made a project once called “You can't stop me with the stop sign!” And it was the Scratch Cat continuously saying that

Dd u hv vrbl in “when timer” hdr blk thn? & u ntcd gt stck..?

Yes! It was working, but it malfunctioned and got stuck. And nice jibberish

turkey3 wrote:

DadOfMrLog wrote:

@turkey3:

turkey3 wrote:

Your posts are always long

ok, wl try 2 mk shrtr frm nw on

turkey3 wrote:

but yeah, I actually noticed the timer recursive type thing. I made a project once called “You can't stop me with the stop sign!” And it was the Scratch Cat continuously saying that

Dd u hv vrbl in “when timer” hdr blk thn? & u ntcd gt stck..?

Yes! It was working, but it malfunctioned and got stuck. And nice jibberish

I didn't notice it was DadofMrLog at first