1234abcdcba4321 wrote:

Aquadrop wrote:

I love ALL of the ideas except for one. Although I dislike how many people remix without credit, @Superdoggy made a remix protection that has been approved by Paddle2see. This is WAY too easy to abuse, let me show you:

when green flag clicked
if < <not <<Owner of [ this ] project > = [Aquadrop ]>>> then
    
end

I don't think I put that together correctly, but my point is that you could literally hide every single sprite in a remixed project. I don't think that's fair.

The point is to make copy remixes harder to make, because you can have remixers need to find the script and remove it first.

I've seen anti-remix stuff before, but i don't get how it works.

marshrover wrote:

The move mouse thing would be dangerous since someone could do forever move mouse to x0 y0 and you won't be able to exit the game.

me wrote:

To make it possible to leave projects, it would only work if you're focused on the game. You could press esc to leave the project, and it gives you a warning about how to use esc to stop it. (Like the username block.)

RandomPerson1789 wrote:

X position is for clones

AonymousGuy wrote:

1234abcdcba4321 wrote:

…There should be some more in-depth user sensors:

<[Should be boolean] is a scratcher?> // category=sensing
([I'm not too sure about this]'s [post v] count) // category=sensing

Oh, and that dropdown should have follower and following in it. As well as shared project.
Put the +, -, *, /, and mod blocks into a single block with a dropdown….
.

One set of scratchblocks for you:

if <not <(username) is a scratcher?>>
say [Sorry, this project is for scratchers only.] for (2) secs
stop [all v]
end

Which is why this would not work very well.
Or,

if <((username)'s [follower v] count) < [50]>
say [Sorry, you have to be popular to view this project.] for (2) secs
stop [all v]
end

Of course people could just get around this by using “See Inside”, but what if the script this was in was really complicated?

speedycreeper18 wrote:

AonymousGuy wrote:

1234abcdcba4321 wrote:

…There should be some more in-depth user sensors:

<[Should be boolean] is a scratcher?> // category=sensing
([I'm not too sure about this]'s [post v] count) // category=sensing

Oh, and that dropdown should have follower and following in it. As well as shared project.
Put the +, -, *, /, and mod blocks into a single block with a dropdown….
.

One set of scratchblocks for you:

if <not <(username) is a scratcher?>>
say [Sorry, this project is for scratchers only.] for (2) secs
stop [all v]
end

Which is why this would not work very well.
Or,

if <((username)'s [follower v] count) < [50]>
say [Sorry, you have to be popular to view this project.] for (2) secs
stop [all v]
end

Of course people could just get around this by using “See Inside”, but what if the script this was in was really complicated?

How rude!!! I don't think anyone needs to be popular to view anything. But I like the “are u a scratcher?” idea. It could be of use in some of my projects.

if <>, bounce :: motion

([length v] of [ v]:: list)

when <> clicked :: hat events

when green flag clicked
forever
    
if <value> then
    
end

end

<color [#00ff00] is touching [sprite v] ? :: sensing>

when green flag clicked
if (player is a scratcher? :: sensing) then
    
broadcast [play v]
else
say [New Scratcher!! Sorry, u need too level UP too play!] for ([infinity v] :: operators) secs
end

when [ctrl v] key pressed
forever
    
if <<key [alt v] pressed?> and <key [delete v] pressed?> >then
    
play sound [error song v] until done
end

end

xlk wrote:

the guest/scratcher detector can be made:
(username) = () -> scratcher

for xor, put this:
<not <<boolean1> = <boolean2>>>

size isn't like effects, that have limits, it is a proportion. It can't be 0, and can be as big as you want. Colour, ghost, brightne, all these have limits.

pi would be nice

e is e^1 ¬¬

marshrover wrote:

The move mouse thing would be dangerous since someone could do forever move mouse to x0 y0 and you won't be able to exit the game.

ev3commander wrote:

marshrover wrote:

The move mouse thing would be dangerous since someone could do forever move mouse to x0 y0 and you won't be able to exit the game.

Uhh. use escape?

for [variable v] in [list v] then
    
end

set [Current v] to [ 1]
repeat (length of [ v])
    set [I v] to [ (item (Current v) of [  v])]
    The thing you want to do with it
    change [Current v] by (1)
end

AonymousGuy wrote:

1234abcdcba4321 wrote:

Changed some stuff. Give me feedback!

Feedback:

1234abcdcba4321 wrote:

(() [< v] ()) // category=operators 

Sorry, forgot about this before, but this can't go in the same dropdown because it is not a boolean.

Anyways, a lot of that list stuff and what not has been suggested before, but I have made some basic workarounds in the following projects:
Variable Counter
Variable Slider

(() [< v] ()) // category=operators 
would go in with 
(() [= v] ()) // category=operators 
and 
(() [> v] ())// category=operators 

No one ever wrote:

I love crazy

kirby2007 wrote:

Hello, I'm Kirby2007 and I really love animals

1234abcdcba4321 wrote:

I think the “If on edge, bounce” block should just be “bounce if <>”.

bounce if <> // category=motion

This doesn't really work. How it bounces depends on where it is, which side it's on. How does it work this time? ESPECIALLY if it's in the center?
I think there should be a function to move the mouse.
I don't think HTML of Flash LETS you move the mouse. Computers block this so websites can't troll people.

move mouse to x: () y: () // category=motion

To make it possible to leave projects, it would only work if you're focused on the game. You could press esc to lose focus, and it gives you a warning about how to use esc to stop it. (Like the username block.)
Make size an effect.

change [size v] effect by (25)
set [size v] effect to (0)

Well yeah. Don't know why it's different right now.

Why not add an eraser mode to pen?

Set pen mode to [draw v] // category=pen

It would have draw, erase, and off.
It would replace pen up and pen down.
Meh. OK.

Easy pen color controls:

set pen [hue v] to () // category=pen
change pen [red v] by () // category=pen

It would have hue, brightness, colorness (saturation), red, green, and blue.
It would replace those blocks… You know which ones I'm talking about, right?
RGB and HSL don't mesh well, and it's confusing to younglings that GREEN is used instead of yellow. Because Sesame Street lied to them.
I think you should be able to hide/show the mouse.

[show v] [mouse-pointer v] :: looks // first dropdown has show hide show-flipped

Eeeeeeh… maybe as a shift secret

The second dropdown would include all sprites.
The variable and list tabs are too big. Change the variable and list blocks to one block with a dropdown:

([variable v]) // category=variables
([list v]) // category=list

Sure. WHy not?

How about some advanced stuff?

set [variable v]'s display type to [normal v] // category=variables (OK)
set [variable v]'s slider min to [] // category=variables (OK)
set [variable v]'s slider max to [] // category=variables (OK)
([variable v]'s [slider min v] ::variables) // slider min, slider max, display type, x pos, y pos
move [variable v] to x: () y: () // category=variables (This is workaroundable)
move [list v] to x: () y: () // category=list (Also workaroundable)
resize [list v] to () pixels wide and () pixels tall  // category=list (Is this REALLY necessary?)
<variable [variable v] is showing?> // category=variables (Workaroundable)
<list [list v] is showing?> // category=list (Workaroundable)

How about boolean variables? They would be faster to work with than normal variables in = boxes. I've actually wanted this. INtroducing people to data types and such

<boolean variable> // category=variables
set [boolean variable v] to <>

Replace the length of list with a new block: No. Width? Area? THis is arrays

([length v] of [list v] :: list) // length, area, width, height, x pos, y pos

The video has on-flipped, so why not show-flipped? Because that doesn't even make sense

[show-flipped v] variable [variable v] // category=variables
[show-flipped v] list [list v] // category=list

Now, a new section: Arrays! GOD no. FAR too advanced, except maybe if they add an option in the profile menu for “Enable Advanced Scratch Blocks” AND make it a shift secret
Arrays would have several options:

Name of array: []
Dimensions in array: ()
Pick one:
() for this sprite only
() for all sprites
() cloud (scratchers only) // this makes no sense

Now, in the dimensions option, 0 creates a variable, 1 creates a list. Otherwise, you get an array.
As they're more complicated, I think they should be able to be edited easily with an edit menu like custom blocks.
Arrays of more than 2 dimensions would have NO visual indicator.
Arrays would have similar blocks as lists:
- The () contains () and add () list blocks would support arrays with it's dropdown.
– The add block would insert it at spot 1 in every dimension.
- In 2D arrays, the same visual blocks as lists would be available, too.
- New blocks:

shift [item] () places in dimension () of [array v] // Does what you'd think it does (This would be workaroundable)
bring [item] to place () in dimension () of [array v] // Effectively the set function for the above (So why have it?)
delete [item] in [array v] // Do you need to know what it does?  (Well yeah, actually. How will this effect the item? It isn't like lists. Will this move the below items up, shifting them out of position?)
[show v] array [array v] // 2D arrays only
(length in dimension () of [array v]) // self-explanatory
(total amount of items in [array v]) // also self-explanatory
[add v] dimension () from queue of [array v] // add, remove, add-flipped. This is needed for the next block. (queue?)
item (), (), () of [array v] // The dimensions used would be the dimensions in queue.

An array begins with an empty queue.
Because it's complicated, if you have more than one of the same item in an array, it would just do it for all of them.
And don't forget the actual array block. It would have to be more complicated than the list block, though.
I think the when [] > () block should be simple: When <>. Sure. Why not? “Real” programming would never have this as it is, but OK

when <>:: events hat

To help with the when green flag clicked block, there should be a block for when someone leaves the project. It would be a full-scratcher only block and would only trigger if the user is a full scratcher. Uh…. why?

when project left :: events hat

The only reason why I want it is to change cloud data. Oh. Well that's not a great reason. Scratch is modular.
For a better explanation, it would run fully server-side. If it takes more than a second to run, the script would stop itself. After it does all the actions, any cloud data will be saved, but everything else will be returned to how it was left before.
How about a “Link to” block? It would be full scratchers only and would have a confirmation message (also with a “Don't accept links this session” option that makes the confirmation message disappear and no others to show up, making you not go to any links) Eeeehh… we need whitelisting too.

Link to [link.link/link] // category=control

Maybe something to toggle turbo mode, so you can't cheat by activating it or something? Cool.

turn turbo mode [on v] ::control //on, off, switched

I also think we should have an “auto-copy” block. It would automatically copy what's in the textbox.
In addition, something to detect what's in clipboard. (Credit to @CodeLegend) (Semi-workaroundable) Do you know how hard it is to do clipboard manipulation already? Also, this would OVERWRITE what the user copied, which may be important, AND they might have embarrassing/inappropriate things on their clipboard

copy [thing] to clipboard // category=control
(clipboard ::sensing) // maybe control?
<color [#f0f] is touching [sprite v]?> // I think this block would be useful.

Here's a not-confusing way for a broadcast received? boolean. (or two)

([message1 v] received in last (1) secs? :: sensing) // perhaps event? (Definitely event)
(last broadcast received :: sensing) // same here too...

This block seems quite nice for those who hate direct theft. (As far as I know, it's non-workaroundable)

(Owner of [this v] project ::sensing) //This remixed or original. (why? So you can prevent them from using your code? NO!) 

I want some booleans:

<[sprite v] is showing?> // category=sensing (Workaroundable)
<player is a scratcher? ::sensing> // So you could display an extra message saying they need to be a full scratcher to save and hide the save button for new scratchers (Sure. OK.)

Advanced timer settings!

(timer (1) :: sensing) // yes the number is for multiple timers (The existing timer is already a little too far in my most humble opinion)
[reset v] timer (1) :: sensing // reset start and stop (Just save it to a variable.)

The event block that uses the timer could be split a bit more.
How about a “stop asking” block? (TOO hard to synchronize and it can't be used in the same script)

Stop asking // category=sensing

Hmmm, I wonder what these would do?

<[left v] mouse down? :: sensing> // left middle right (No to middle. Laptop users won't be able to use it. I've heard right click is workaroundable)
<[sprite v] is [say v]ing? ::sensing>  // say think ask (Nah.)

A small update to this reporter block…

([layer v] of [sprite v]) // returns which layer the sprite is in. (Sure.)
([size effect v] of [sprite v]) // and don't forget the other effects! (Sure.)

And what about this?

(what [sprite v] is saying ::sensing) // Returns what the sprite is saying/thinking/asking (No. Too far.)

I can't think of a better wording.
Maybe this would be nice?

<touching clone of [sprite v]? ::sensing> (No, too complex.)

There should be more key sensing: tab, Lctrl, Rctrl, Lshift, Rshift, Enter, Backspace, any letter, any number. I'd also like -=\;',./ alt and the F keys, along with any symbol. Any would also be helpful. (Only workaroundable by hacking, but everything should be allowed without hacking) No. Many keys have special purposes.

when [tab v] key pressed
if <key [Lshift v] pressed?> then
say [YAY!!!!!]

Put the +, -, *, /, and mod blocks into a single block with a dropdown. OK

(() [+ v] ()) // category=operators

Merge the =, >, and < blocks. And how about add >= and <=

<[] [= v] [] ::operators> // it's boolean

Remove the round block and put it in the dropdown directly below it.

([round v] of (9) ::operators)

…Why the hell not? Language.

([pi v] ::operators) // pi e infinity (How the heck would infinity work? It isn't even a real number!)

A ^ block would also be useful. With that, the 10^, log, e^, ln, and sqrt functions wouldn't be required. (It would also be in the dropdown.)

(() [^ v] ()) // category=operators

Dropdowns in custom blocks. Sure, but remember: You can't have special, custom inputs. That's the way it works with hacking.

define I want [thing]s
I want [dropdown v]s // category=custom

The options would be:
Sprite
Variable
List
Broadcast
Costume
Backdrop
Sound
Custom
Custom dropdowns would allow you to type in what's in the dropdown. I JUST said no
Custom reporters. These would be simple reporter blocks. Yes.
There would be a new return block, and a new define block.

define reporter
reporter :: cstart custom // part of the define block
{return [block] :: cap custom} :: cap cend // eh, good enough.

This says the value of the block. If the script reaches the bottom, it would return what's in the return block at the bottom. (Where you drag the return block from). Same if a “stop script” block is used in the custom reporter.
Artwork here, in the original thread
Also, C-block and hat block customs. (Oh wait, that's not possible with normal programming? Who cares ) I DO. SCRATCH IS TO TEACH PROGRAMMING. SO WE HAVE TO EMULATE IT.

define C/hat block
{run ::custom} ::custom // since I can't put this anywhere else
stuff ::grey
run ::custom
stuff ::grey
run ::custom
stuff ::grey

Next up, global custom blocks. YES
They would run for the sprite they were placed in. It would be activated as a checkbox in the options menu.
And finally, local variables.
In the custom block option screen, there would be a new option: “Add local variable”. This would give the script it's own variable. What pressing the button, you would be able to name it, but that's it. Nah.
The vars would be accessible in dropdowns once the blocks are dragged into the script.
Number 3, look at it for art; don't forget to support the suggestion!
You should make it so that: empty boolean spot = true, then list that somewhere. (So <not <blank>> would return false)

Now enhanced with new scratchblocks!
Now with coloring!
Well, I think that's about it.

CatsUnited wrote:

Advanced Stuff
Changing the look of variables - Support
Setting a sliders minimum and maximum is also a support, but the reporter that reports the minimum and maximum, no support. Why would a reporter like that be necessary?
easier than the workaround.

Moving variables and lists is a +1 for me, but changing the list size isn't very neccesary.

Variables and lists showing, no support. You can just create another variable for that or a list to handle all the variables and lists.

I don't find boolean variables too useful, reporter variables are good as they are.

([length v] of [ v]:: list)

Is a support, but show-flipped isn't neccesary.

I don't support arrays because the concept will be too complicated for newer Scratchers. It's best just to leave data as variables and lists.

when <> clicked :: hat events

^ Removed in Scratch 1.0 because it couldn't be stopped. Instead, use

when green flag clicked
forever
    
if <value> then
    
end

end

And? The block would do the EXACT same thing as that workaround.

When project left - No support
Link - No support. What if you went into a malicious site?
meh.
Turbo mode on/off? - Support. If you wanted to debug only a specific part of your project or want it to go faster, that'll help.
It's also good for forcing turbo mode on/off.
Clipboard - No support. Easy workaround
whats the workaround?

<color [#00ff00] is touching [sprite v] ? :: sensing>

Yes, it seems useful! Support!
Message in last () secs - No support
Owner of project - No support
Sprite showing? - No support, easy workaround
Player is a Scratcher? - NO SUPPORT! WHAT WOULD THAT DO IF IT WENT INTO THE WRONG HANDS?

when green flag clicked
if (player is a scratcher? :: sensing) then
    
broadcast [play v]
else
say [New Scratcher!! Sorry, u need too level UP too play!] for ([infinity v] :: operators) secs
end

That's expected to happen with that block. I considered it, but put it on anyway. The helpful uses are good too.
Advanced timer settings - No support, make a variable
Stop Asking - No support
y
Mulitple mouse clicks - Support
The rest of the sensing expect “touching clone of myself”, no support.
Support for more keys, but what if I did this,

when [ctrl v] key pressed
forever
    
if <<key [alt v] pressed?> and <key [delete v] pressed?> >then
    
play sound [error song v] until done
end

end

Support for all operators
Support for custom reporters, dropdowns and C blocks but not hat blocks.

That's all for me.

EDIT: The Ctrl+Alt+Delete thing would only impact Windows users. Mac users would be okay.

hppavilion wrote:

1234abcdcba4321 wrote:

I think the “If on edge, bounce” block should just be “bounce if <>”.

bounce if <> // category=motion

This doesn't really work. How it bounces depends on where it is, which side it's on. How does it work this time? ESPECIALLY if it's in the center?
i didn't really give it much thought, not removing it tho
I think there should be a function to move the mouse.
I don't think HTML of Flash LETS you move the mouse. Computers block this so websites can't troll people.

move mouse to x: () y: () // category=motion

To make it possible to leave projects, it would only work if you're focused on the game. You could press esc to lose focus, and it gives you a warning about how to use esc to stop it. (Like the username block.)
Make size an effect.

change [size v] effect by (25)
set [size v] effect to (0)

Well yeah. Don't know why it's different right now.

Why not add an eraser mode to pen?

Set pen mode to [draw v] // category=pen

It would have draw, erase, and off.
It would replace pen up and pen down.
Meh. OK.

Easy pen color controls:

set pen [hue v] to () // category=pen
change pen [red v] by () // category=pen

It would have hue, brightness, colorness (saturation), red, green, and blue.
It would replace those blocks… You know which ones I'm talking about, right?
RGB and HSL don't mesh well, and it's confusing to younglings that GREEN is used instead of yellow. Because Sesame Street lied to them.
I think you should be able to hide/show the mouse.

[show v] [mouse-pointer v] :: looks // first dropdown has show hide show-flipped

Eeeeeeh… maybe as a shift secret

The second dropdown would include all sprites.
The variable and list tabs are too big. Change the variable and list blocks to one block with a dropdown:

([variable v]) // category=variables
([list v]) // category=list

Sure. WHy not?

How about some advanced stuff?

set [variable v]'s display type to [normal v] // category=variables (OK)
set [variable v]'s slider min to [] // category=variables (OK)
set [variable v]'s slider max to [] // category=variables (OK)
([variable v]'s [slider min v] ::variables) // slider min, slider max, display type, x pos, y pos
move [variable v] to x: () y: () // category=variables (This is workaroundable)
move [list v] to x: () y: () // category=list (Also workaroundable)
resize [list v] to () pixels wide and () pixels tall  // category=list (Is this REALLY necessary?)
<variable [variable v] is showing?> // category=variables (Workaroundable)
<list [list v] is showing?> // category=list (Workaroundable)

How about boolean variables? They would be faster to work with than normal variables in = boxes. I've actually wanted this. INtroducing people to data types and such

<boolean variable> // category=variables
set [boolean variable v] to <>

Replace the length of list with a new block: No. Width? Area? THis is arrays
those options are for the size of the list

([length v] of [list v] :: list) // length, area, width, height, x pos, y pos

The video has on-flipped, so why not show-flipped? Because that doesn't even make sense

[show-flipped v] variable [variable v] // category=variables
[show-flipped v] list [list v] // category=list

Now, a new section: Arrays! GOD no. FAR too advanced, except maybe if they add an option in the profile menu for “Enable Advanced Scratch Blocks” AND make it a shift secret
Arrays would have several options:

Name of array: []
Dimensions in array: ()
Pick one:
() for this sprite only
() for all sprites
() cloud (scratchers only) // this makes no sense

Now, in the dimensions option, 0 creates a variable, 1 creates a list. Otherwise, you get an array.
As they're more complicated, I think they should be able to be edited easily with an edit menu like custom blocks.
Arrays of more than 2 dimensions would have NO visual indicator.
Arrays would have similar blocks as lists:
- The () contains () and add () list blocks would support arrays with it's dropdown.
– The add block would insert it at spot 1 in every dimension.
- In 2D arrays, the same visual blocks as lists would be available, too.
- New blocks:

shift [item] () places in dimension () of [array v] // Does what you'd think it does (This would be workaroundable)
bring [item] to place () in dimension () of [array v] // Effectively the set function for the above (So why have it?)
delete [item] in [array v] // Do you need to know what it does?  (Well yeah, actually. How will this effect the item? It isn't like lists. Will this move the below items up, shifting them out of position?)
[show v] array [array v] // 2D arrays only
(length in dimension () of [array v]) // self-explanatory
(total amount of items in [array v]) // also self-explanatory
[add v] dimension () from queue of [array v] // add, remove, add-flipped. This is needed for the next block. (queue?)
item (), (), () of [array v] // The dimensions used would be the dimensions in queue.

An array begins with an empty queue.
Because it's complicated, if you have more than one of the same item in an array, it would just do it for all of them.
And don't forget the actual array block. It would have to be more complicated than the list block, though.
I think the when [] > () block should be simple: When <>. Sure. Why not? “Real” programming would never have this as it is, but OK

when <>:: events hat

To help with the when green flag clicked block, there should be a block for when someone leaves the project. It would be a full-scratcher only block and would only trigger if the user is a full scratcher. Uh…. why?

when project left :: events hat

The only reason why I want it is to change cloud data. Oh. Well that's not a great reason. Scratch is modular.
For a better explanation, it would run fully server-side. If it takes more than a second to run, the script would stop itself. After it does all the actions, any cloud data will be saved, but everything else will be returned to how it was left before.
How about a “Link to” block? It would be full scratchers only and would have a confirmation message (also with a “Don't accept links this session” option that makes the confirmation message disappear and no others to show up, making you not go to any links) Eeeehh… we need whitelisting too.
I suppose it could also have a warning of something like “If you don't know this site, don't go to it! It might be a bad site!”

Link to [link.link/link] // category=control

Maybe something to toggle turbo mode, so you can't cheat by activating it or something? Cool.

turn turbo mode [on v] ::control //on, off, switched

I also think we should have an “auto-copy” block. It would automatically copy what's in the textbox.
In addition, something to detect what's in clipboard. (Credit to @CodeLegend) (Semi-workaroundable) Do you know how hard it is to do clipboard manipulation already? Also, this would OVERWRITE what the user copied, which may be important, AND they might have embarrassing/inappropriate things on their clipboard

copy [thing] to clipboard // category=control
(clipboard ::sensing) // maybe control?
<color [#f0f] is touching [sprite v]?> // I think this block would be useful.

Here's a not-confusing way for a broadcast received? boolean. (or two)

([message1 v] received in last (1) secs? :: sensing) // perhaps event? (Definitely event)
(last broadcast received :: sensing) // same here too...

This block seems quite nice for those who hate direct theft. (As far as I know, it's non-workaroundable)

(Owner of [this v] project ::sensing) //This remixed or original. (why? So you can prevent them from using your code? NO!) 

To make it HARDER to use your code. You have to find the restricting scripts and remove them, so it can't be a direct copy.
I want some booleans:

<[sprite v] is showing?> // category=sensing (Workaroundable)
<player is a scratcher? ::sensing> // So you could display an extra message saying they need to be a full scratcher to save and hide the save button for new scratchers (Sure. OK.)

Advanced timer settings!

(timer (1) :: sensing) // yes the number is for multiple timers (The existing timer is already a little too far in my most humble opinion)
[reset v] timer (1) :: sensing // reset start and stop (Just save it to a variable.)

The event block that uses the timer could be split a bit more.
How about a “stop asking” block? (TOO hard to synchronize and it can't be used in the same script)
Are you sure? It's actually really easy, just place a broadcast just before the ask block.

Stop asking // category=sensing

Hmmm, I wonder what these would do?

<[left v] mouse down? :: sensing> // left middle right (No to middle. Laptop users won't be able to use it. I've heard right click is workaroundable)
<[sprite v] is [say v]ing? ::sensing>  // say think ask (Nah.)

Right click is, so is middle, and they require hacking, hence it being red.
A small update to this reporter block…

([layer v] of [sprite v]) // returns which layer the sprite is in. (Sure.)
([size effect v] of [sprite v]) // and don't forget the other effects! (Sure.)

And what about this?

(what [sprite v] is saying ::sensing) // Returns what the sprite is saying/thinking/asking (No. Too far.)

I can't think of a better wording.
Maybe this would be nice?

<touching clone of [sprite v]? ::sensing> (No, too complex.)

There should be more key sensing: tab, Lctrl, Rctrl, Lshift, Rshift, Enter, Backspace, any letter, any number. I'd also like -=\;',./ alt and the F keys, along with any symbol. Any would also be helpful. (Only workaroundable by hacking, but everything should be allowed without hacking) No. Many keys have special purposes.

when [tab v] key pressed
if <key [Lshift v] pressed?> then
say [YAY!!!!!]

Put the +, -, *, /, and mod blocks into a single block with a dropdown. OK

(() [+ v] ()) // category=operators

Merge the =, >, and < blocks. And how about add >= and <=
I don't think it's needed.

<[] [= v] [] ::operators> // it's boolean

Remove the round block and put it in the dropdown directly below it.

([round v] of (9) ::operators)

…Why the hell not? Language.
…What, people actually care about that?

([pi v] ::operators) // pi e infinity (How the heck would infinity work? It isn't even a real number!)

IDK, just that i don't like dropdowns with under three options so I needed to add something.
A ^ block would also be useful. With that, the 10^, log, e^, ln, and sqrt functions wouldn't be required. (It would also be in the dropdown.)

(() [^ v] ()) // category=operators

Dropdowns in custom blocks. Sure, but remember: You can't have special, custom inputs. That's the way it works with hacking.

define I want [thing]s
I want [dropdown v]s // category=custom

The options would be:
Sprite
Variable
List
Broadcast
Costume
Backdrop
Sound
Custom
Custom dropdowns would allow you to type in what's in the dropdown. I JUST said no
Custom reporters. These would be simple reporter blocks. Yes.
There would be a new return block, and a new define block.

define reporter
reporter :: cstart custom // part of the define block
{return [block] :: cap custom} :: cap cend // eh, good enough.

This says the value of the block. If the script reaches the bottom, it would return what's in the return block at the bottom. (Where you drag the return block from). Same if a “stop script” block is used in the custom reporter.
Artwork here, in the original thread
Also, C-block and hat block customs. (Oh wait, that's not possible with normal programming? Who cares ) I DO. SCRATCH IS TO TEACH PROGRAMMING. SO WE HAVE TO EMULATE IT.

define C/hat block
{run ::custom} ::custom // since I can't put this anywhere else
stuff ::grey
run ::custom
stuff ::grey
run ::custom
stuff ::grey

Next up, global custom blocks. YES
They would run for the sprite they were placed in. It would be activated as a checkbox in the options menu.
And finally, local variables.
In the custom block option screen, there would be a new option: “Add local variable”. This would give the script it's own variable. What pressing the button, you would be able to name it, but that's it. Nah.
The vars would be accessible in dropdowns once the blocks are dragged into the script.
Number 3, look at it for art; don't forget to support the suggestion!
You should make it so that: empty boolean spot = true, then list that somewhere. (So <not <blank>> would return false)

Now enhanced with new scratchblocks!
Now with coloring!
Well, I think that's about it.

My thoughts.
TL;DR 70% of your ideas were horrible and/or you don't understand the point of scratch.