magpie5212 wrote:

1234abcdcba4321 wrote:

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

Bad idea as it breaks down hand/eye coordination for the user.

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

say [I will now read out "list"] for (2) secs
for [list v]: (thing)
    say (thing) for (2) secs
end

[hide v] mouse

[start v] recording
wait (10) secs
[stop v] recording
set [video v] to (video)
switch [video v] to (video)
wait (length of (video)) secs
switch [costume v] to (1)

take picture
switch costume to (picture)

seanbobe wrote:

magpie5212 wrote:

1234abcdcba4321 wrote:

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

Bad idea as it breaks down hand/eye coordination for the user.

plus

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

and u cannot leave project

1234abcdcba4321 wrote:

I think there should be a function to move the mouse.

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 leave the project, and it gives you a warning about how to use esc to stop it. (Like the username block.)

when green flag clicked
forever
set pen color to random between (num1) and (num2)
go to (x:variable)  (y:variable)
change [num1+num2^y:variable v] by (x:variable)
set (num1+num2^y:variable v) to (num1^2)
end

say [I will now readout list] for (2) secs
for [list v] (thing)
    say (thing) for (2) secs
end

for [variable v] untill <> add (10) :: control cstart
    ...
 :: cend

Zambonifofex wrote:

let me fix that:

for [variable v] untill <> add (10) :: control cstart
    ...
 :: cend

for [variable v] untill <(variable) = []> add (10) :: control cstart
    ...
 :: cend

ev3commander wrote:

ARM32 wrote:

I do NOT support you on these.

change x by (10)
set x to (0)
change y by (10)
set y to (0)

change [variable v] by (1)

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

I DO want these though.

<[ARM32] is a [scratcher v]?> // category=sensing
([post v] number of [ARM32]) // category=sensing
<is [ARM32] a guest?> // category=sensing

I ALSO want these.

<[message1 v] received?> // category=events
<I am a [clone v]?> // category=control
<<> xor <>> // category=operators
<<> nand <>> // category=operators
<<> nor <>> // category=operators

People won't know about xor, nand and nor.

1234abcdcba4321 wrote:

Tramcrazy 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?

The problem is that this would cause discrimination with people making projects only for people who have as many followers as they have. This means it will lead to mean comments. The only use I can see for these 2 blocks is making sure New Scratchers don't try to get into a cloud project and spend hour trying to work out why it won't work (though the flash up at the top makes it quite obvious).

Yes, BUT NO ONE SEEMS TO NOTICE THAT I REMOVED THOSE TWO BLOCKS FROM THE LIST.

meowmoo wrote:

Zambonifofex wrote:

let me fix that:

for [variable v] untill <> add (10) :: control cstart
    ...
 :: cend

actually:

for [variable v] untill <(variable) = []> add (10) :: control cstart
    ...
 :: cend

for [variable v] until <(variable) = []> add (10) :: control cstart
    ...
 :: cend

1234abcdcba4321 wrote:

IMPORTANT! DO NOT POST YOUR OWN IDEAS IN THIS THREAD!
If you're quoting the post, please only quote areas of relevance. Seriously, it fills up the page really quickly.
Non-workaroundable things are in red.
THINGS PEOPLE NEVER, EVER READ ARE IN BOLD.
I think the “If on edge, bounce” block should just be “bounce if <>”.

bounce if <> // category=motion

I think there should be a function to move the mouse.

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 leave the project, 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)

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.
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?
I think you should be able to hide/show the mouse.

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

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

How about some advanced stuff?

set [variable v]'s display type to [normal v] // category=variables
set [variable v]'s slider min to [] // category=variables
set [variable v]'s slider max to [] // category=variables
([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
move [list v] to x: () y: () // category=list
resize [list v] to () pixels wide and () pixels tall  // category=list
<variable [variable v] is showing?> // category=variables
<list [list v] is showing?> // category=list

How about boolean variables? They would be faster to work with than normal variables in = boxes.

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

Replace the length of list with a new block:

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

The video has on-flipped, so why not show-flipped?

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

Now, a new section: Arrays!
Arrays would have several options:

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

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
bring [item] to place () in dimension () of [array v] // Effectively the set function for the above
delete [item] in [array v] // Do you need to know what it does?
[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.
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 <>.

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.

when project left :: events hat

The only reason why I want it is to change cloud data.
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)

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

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)

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?
(last broadcast received :: sensing) // same here too...

I want a boolean:

<[sprite v] is showing?> // category=sensing

Advanced timer settings!

(timer (1) :: sensing) // yes the number is for multiple timers
[reset v] timer (1) :: sensing // reset start and stop

The event block that uses the timer could be split a bit more.
How about a “stop asking” block?

Stop asking // category=sensing

Hmmm, I wonder what these would do?

<[left v] mouse down? :: sensing> // left middle right
<[sprite v] is [say v]ing? ::sensing>  // say think ask

A small update to this reporter block…

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

And what about this?

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

I can't think of a better wording.
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)

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.

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

Merge the =, >, and < blocks.

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

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

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

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.

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.
Custom reporters. These would be simple reporter blocks.
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 )

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.
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.
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)
Some blocks have too easy workarounds.

<not <>>
<<...> = [false]> // yes that's a boolean spot...
(variable)
([variable v] of [sprite/stage v])
(x position)
([x position v] of [sprite v])
(y position)
([y position v] of [sprite v])
(direction)
([direction v] of [sprite v])
(costume #)
([costume # v] of [sprite v])
// I could keep going on and on and on...

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

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

Reload page

alex082 wrote:

Better this thing…

Reload page

forever
reload page    
end
define reload page //ignore this
stop [ v]

set [current v] to [1]
repeat until <(current) = (length of [list v])>
    set [thing v] to (item (current) of [list v])
    change [current v] by (1)
    say (thing) for (2) secs
end