zacadoole1 wrote:

Edit 2: Edit: Come to think of it, it might make sense for reporters that call for variables and lists that don't exist to create them, because it would allow for projects where the user can create their own variables and lists, if that's something the creator wants… hmm…

That could lead to this problem:

when green flag clicked
set (var v) to [1]
forever
set (var) to ((var) + (1))
end

This would just make infinite variables for the sole purpose of crashing the browser. Just wanted to point this out.

i would say

(item (1) of (string) :: list) //if string is like hello, it could return h, because list var if it has like a, b, c, it returns abc when said, so maybe same for strings and itmeing

Support. It will help with broadcasting, dealing with multiple variables (like a calculator!), and clone management.

Full support. I am currently working on a Family Feud board ,where I want to transfer contents of MANY conveniently-named lists with answers and points, so the data inside the inactive question lists can be kept for when needed. The only “workaround” is, of course, making a bunch of if(-else) statements, which make the code disgustingly elongated and prone to errors which are difficult to find.

helloagain_57 wrote:

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

Surely, in your instance, the dreaded square drop-down has options which are few in number and fully arbitrary (set in stone by the platform developers) - thus, a round drop-down in the backdrop reporter is NOT needed. The issue with broadcasts, variables, and most importantly LISTS, however, is that the options are entirely created by the project writer. Having a round drop-down (just like with the broadcast() block!) in the remaining broadcast/variable/list blocks/reporters/boolean would make operating on many variables and lists much less cumbersome and fever-inducing.

Regarding another concern, the variable/list (V/L) operating blocks creating V/Ls when the argument for the V/L name refers to a non-existent V/L, such blocks in my opinion should not exhibit such behaviour, but rather be ignored or even halt the script column they are in. That issue is somewhat mitigable with lists, where one list has names for “variables” while the other one has their values. I do not see much practicality for dynamically creating lists, one can handle that with list number two/three containing the number of the “list” an object belongs to

And also, I'm too lazy to transfer the whole project to Snap

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.

A solution to this issue could be making nested reporters, blocks etc. follow a zebra stripe rule, where a reporter inside a normal one goes brighter and vice versa, like this:

((2)+((2)+((2)+((2)+((2)+(2))::#69e071))::#69e071))

especially as the round drop-downs are noticeably darker than the rest of the block, though not enough. My proposition:

set (test var::#ffa942) to [TEST]

and

set ((test var v)::#fe8400) to [TEST]

bump

helloagain_57 wrote:

Imagine putting “president” in the dropdown.

there is actually a hacked meme block that has “president” in the dropdown

(current [president v]) 

and with round dropdowns, you can actually put round blocks into the dropdowns and make some pretty funny and absurd blocks, like this:

play drum (username) for (list :: list) beats

but with square dropdowns, im pretty sure you cant put booleans in there, which means you cant do stuff like this:

when (clicks per second) key pressed

so your suggestion half implemented, its just the square dropdowns that are not like this

That's… kind of the entire point of the suggestion, being able to drag reporters into square dropdowns.

Honest support. I bumped this topic so I could get a better chance at this being available, for example:

define change (variable) by (increment)//Now we're able to control variables indirectly!
change (variable) by (increment)

So I'll say it again:

CodeComet6161 wrote:

bump