king of the page

helloagain_57 wrote:

Why? This doesn't have a use AT ALL. It wouldn't be useful for variable rectangle dropdowns, because imagine changing the X position with a variable change.

change (x position) by (0)//cursed

And list rectangle dropdowns neither. Every single reporter isn't a list, other than the list reporters, which you can already change.

Imagine

add [100] to (x position)

working for clones. WHY.

The only successful way I can find for this is changing the answer.

set answer to [Hello!]::sensing

But even that would need a new block.

Conclusion? I don't like this idea.

Define (foo)
set(foo) to []

No support. There is a reason why there is a separation between round dropdowns and square dropdowns.

ihavenocluewhythisis wrote:

king of the page

helloagain_57 wrote:

Why? This doesn't have a use AT ALL. It wouldn't be useful for variable rectangle dropdowns, because imagine changing the X position with a variable change.

change (x position) by (0)//cursed

And list rectangle dropdowns neither. Every single reporter isn't a list, other than the list reporters, which you can already change.

Imagine

add [100] to (x position)

working for clones. WHY.

The only successful way I can find for this is changing the answer.

set answer to [Hello!]::sensing

But even that would need a new block.

Conclusion? I don't like this idea.

Define (foo)
set(foo) to []

That doesn't help. Also, there is a reason for why when you put a round input, it is a text input and not a variable.

helloagain_57 wrote:

No support. There is a reason why there is a separation between round dropdowns and square dropdowns.

What is that reason?

DifferentDance8 wrote:

helloagain_57 wrote:

Why? This doesn't have a use AT ALL. It wouldn't be useful for variable rectangle dropdowns, because imagine changing the X position with a variable change.

change (x position) by (0)//cursed

And list rectangle dropdowns neither. Every single reporter isn't a list, other than the list reporters, which you can already change.

Imagine

add [100] to (x position)

working for clones. WHY.

The only successful way I can find for this is changing the answer.

set answer to [Hello!]::sensing

But even that would need a new block.

Conclusion? I don't like this idea.

Well,

add [100] to (x position)

is just absurd, but

change (x position) by (0)

might actually be useful for newcomers who don't know that the

change x by (0)

block exists

for the life of Pico please add inline scratchblocks to the forums

Have you seen a newcomer that doesn't know about the change x blocks? I surely haven't.

AHypnoman wrote:

helloagain_57 wrote:

No support. There is a reason why there is a separation between round dropdowns and square dropdowns.

What is that reason?

The reason is to not place reporters where they are not supposed to.

Round dropdowns are for places that can accept text inputs. For example:

point in direction (join[_random_]())

This is valid, of course.

Square dropdowns are for when Scratch only allows you to select from a certain amount of things that you edit either from Costumes or Sounds, or you don't edit them at all. For example:

(backdrop [number v]::looks)

Imagine putting “president” in the dropdown.

Bump PLEASE

DifferentDance8 wrote:

helloagain_57 wrote:

snip

Well, (…)

change (x position) by (0)

might actually be useful for newcomers who don't know that the

change x by (0)

block exists

for the life of Pico please add inline scratchblocks to the forums

That wouldn't actually work- say the current x position of the sprite is 42. Running the blocks you showed above would attempt to change the variable 42 by 0, not the x position.


Anyways, to anyone who says this has no use, consider the following case:

You need a way to copy one list to another list, efficiently (and this does come up somewhat often when working with lists). You create a custom block to do this.

define copy (list 1) to (list 2)

But how do you do that?

Currently, the only way to do that would be to make an if-statement for every list in a loop and go through each item of the list and add it to the new one. This would take up a lot of space and would break if you added a list, didn't update the block, and tried to copy something from/tried to copy the new list.

With this suggestion, you can just do

define copy (list 1) to (list 2)
delete all of (list 2)
set [index v] to (1)
repeat (length of (list 1) :: list)
add (item (index) of (list 1)) to (list 2)
change [index v] by (1)

Which is a whole lot shorter, less complicated, and takes less time to make, in addition to being less buggy.

helloagain_57 wrote:

Why? This doesn't have a use AT ALL. It wouldn't be useful for variable rectangle dropdowns, because imagine changing the X position with a variable change.

change (x position) by (0)//cursed

And list rectangle dropdowns neither. Every single reporter isn't a list, other than the list reporters, which you can already change.

Imagine

add [100] to (x position)

working for clones. WHY.

The only successful way I can find for this is changing the answer.

set answer to [Hello!]::sensing

But even that would need a new block.

Conclusion? I don't like this idea.

1, this would be really useful for certain things like user input, or in particular changing cloud variables quickly (there are time constraints on how fast you can change one, but not how fast you can change multiple, so projects often need really long code for determining which cloud var to use)

2. You've completely misinterpreted how reporters work - they report their value, so (x position) is a number, not the string ‘x position’:

change (x position) by (0)

//isn't

change [x position v] by (0)

//but rather it is

change [0] by (0)

(replace 0 with whatever the value of (x position) is)

3. With my last point established, this wouldn't affect clones. Nor would what you said about answer - it would set a variable by the name of what the value of answer is, not change the answer variable.

Admittedly in cases where it doesn't work there has to be some way of informing and not confusing a less experienced user, but bear in mind that this suggestion is only for variables and lists, not for things like the costume dropdown (an example you provided in your last post)

Support, would be incredibly useful and also help with optimization of file and script sizes.

AHypnoman wrote:

helloagain_57 wrote:

Why? This doesn't have a use AT ALL. It wouldn't be useful for variable rectangle dropdowns, because imagine changing the X position with a variable change.

change (x position) by (0)//cursed

And list rectangle dropdowns neither. Every single reporter isn't a list, other than the list reporters, which you can already change.

Imagine

add [100] to (x position)

working for clones. WHY.

The only successful way I can find for this is changing the answer.

set answer to [Hello!]::sensing

But even that would need a new block.

Conclusion? I don't like this idea.

You've completely misinterpreted how reporters work - they report their value, so (x position) is a number, not the string ‘x position’:

Reporters are not variables. If you want to change a reporter, change it by it's corresponding block, not by a variable set.

helloagain_57 wrote:

(#230)

AHypnoman wrote:

-snip-
You've completely misinterpreted how reporters work - they report their value, so (x position) is a number, not the string ‘x position’:

Reporters are not variables. If you want to change a reporter, change it by it's corresponding block, not by a variable set.

I think you're still misunderstanding, this isn't to change any arbitrary reporter, it's to change an arbitrary variable.

helloagain_57 wrote:

AHypnoman wrote:

~Snip~

Reporters are not variables. If you want to change a reporter, change it by it's corresponding block, not by a variable set.

No, not variables. They are values. Click a reporter in the editor and it will tell you what its value is. And look at the example I gave - I try to make it clear what I meant there.

AHypnoman wrote:

helloagain_57 wrote:

AHypnoman wrote:

~Snip~

Reporters are not variables. If you want to change a reporter, change it by it's corresponding block, not by a variable set.

Snip. Click a reporter in the editor and it will tell you what its value is. And look at the example I gave - I try to make it clear what I meant there.

The CoreEx reporter, for example, gives Stage. They are not values, they are reporters. Sorry, they are. Just that they don't input a number always.

o97doge wrote:

helloagain_57 wrote:

(#230)

AHypnoman wrote:

-snip-
You've completely misinterpreted how reporters work - they report their value, so (x position) is a number, not the string ‘x position’:

Reporters are not variables. If you want to change a reporter, change it by it's corresponding block, not by a variable set.

I think you're still misunderstanding, this isn't to change any arbitrary reporter, it's to change an arbitrary variable.

But it is to change an arbitrary reporter. Look at my original post.

helloagain_57 wrote:

Square dropdowns are for when Scratch only allows you to select from a certain amount of things that you edit either from Costumes or Sounds, or you don't edit them at all. For example:

(backdrop [number v]::looks)

Imagine putting “president” in the dropdown.

Bump PLEASE

Though, there's already blocks that have round dropdowns, despite only having a few pre-select dropdown options. For example, you can literally put reporters in the turn video () and video () on () blocks for the motion/direction and on/off/on-flipped options. Why can't you do the same for variables and lists, if you can create as many as you want?
Also, it could just report a blank string or just default to either number/name.

helloagain_57 wrote:

AHypnoman wrote:

helloagain_57 wrote:

AHypnoman wrote:

~Snip~

Reporters are not variables. If you want to change a reporter, change it by it's corresponding block, not by a variable set.

Snip. Click a reporter in the editor and it will tell you what its value is. And look at the example I gave - I try to make it clear what I meant there.

The CoreEx reporter, for example, gives Stage. They are not values, they are reporters. Sorry, they are. Just that they don't input a number always.

CoreEx? And yes, reporters don't always give a number. 'costume ' for example, returns a string

AHypnoman wrote:

helloagain_57 wrote:

AHypnoman wrote:

helloagain_57 wrote:

AHypnoman wrote:

~Snip~

Reporters are not variables. If you want to change a reporter, change it by it's corresponding block, not by a variable set.

Snip. Click a reporter in the editor and it will tell you what its value is. And look at the example I gave - I try to make it clear what I meant there.

The CoreEx reporter, for example, gives Stage. They are not values, they are reporters. Sorry, they are. Just that they don't input a number always.

CoreEx? And yes, reporters don't always give a number. 'costume ' for example, returns a string

That is the name of a test extension that does not actually appear in the extension gallery, so I think that was a confusing example.

medians wrote:

AHypnoman wrote:

helloagain_57 wrote:

AHypnoman wrote:

Snippity snoop

The CoreEx reporter, for example, gives Stage. They are not values, they are reporters. Sorry, they are. Just that they don't input a number always.

CoreEx? And yes, reporters don't always give a number. 'costume ' for example, returns a string

That is the name of a test extension that does not actually appear in the extension gallery, so I think that was a confusing example.

I agree. That was the only thing that came to my mind.

We definitely need this, im working on a project where im trying to recreate Conway’s Game of Life and I’m currently using variables to store every “cell’s” position, but I have lists to store the cell’s states. I currently have to do this:

if <(Horizontal) = [1]> then
replace item ((Vertical) v) of [1 v] with (STATE)
end

And repeat that about 20 times, but if we could do this then I could just say this:

replace item ( (Vertical)v) of [(Horizontal) v] with (STATE)

Which is much easier

Zoomer_X wrote:

This could happen, but it could lead to confusion about these:

set (test var) to [TEST]

and

set [test var v] to [TEST]

There is a big difference.

It'd be pretty hard to accidentally do specifically that, but let's go back to the custom block scenario:

Say you had this set up:

define set variable(var)to(value)
set (var) to (value)

Someone could do the following, thinking it would set the variable to the value

set(my variable)to(1)::custom

when, in fact, they should have done this:

set[my variable]to(1)::custom

Even an experienced Scratcher could mess that up. There should probably be a page in the Debug window dedicated to this issue if/when this suggestion is implemented:


Check inputs
Look at the inputs in your blocks. Does it make sense to nest your blocks, or should you use native dropdowns instead? Changing these can affect how your program works.