ocular rewritten

Manuj and Shruti Dhariwal wrote:

(…) we introduce Let’s Chance—a novel computational microworld that extends the widely popular Scratch Programming Language with new types of code blocks and representations that make it accessible for children to encounter and tinker with the rich ideas and sophisticated concepts of probabilistic modeling and learning. Using the tool, children can imagine and code their own expressive, playful, and personally meaningful probabilistic projects, such as—generative art, music, or text; chance-based games and stories; interactive visualizations; and even advanced projects for making a computer learn from input data using simple Markov models of probabilistic learning, among many other creative possibilities.

Are they in any way different from

(pick random (1) to (10))

The_Game_ wrote:

Are they in any way different from

(pick random (1) to (10))

from a quick glance it looks more child friendly of a rng system but the workaround is probably easy enough as is

bump

I mean it’s also made by mit and it would fit well in scratch (by the limited info I could find) as well as give it a public release

This would also correct the extremely limited rng system in scratch and with ai on the rise a better way to do rng would be in very high demand

How convenient, almost as if it where planned
There’s a possibility that this is actually already planned. But if not maybe a better post title to catch st’s eye could do the trick
Something mentioning its from another mit branch definitely
Support!

That looks pretty cool. I think I'd like to see this implemented!

7salad3salad wrote:

That looks pretty cool. I think I'd like to see this implemented!

Id love to be able to play with it but it looks like it’s only available to people who took the course. This would be a great opportunity to give it a public release!

I did a full in depth research of this and it seems like it was originally going to be playable by the public at the chamberage CHI 2020 but then that event got cancelled and replaced with the digital zoom meeting and while it was (documented at least) showcased on the meeting it was not playable (obviously) Then in April 2020/2021 (not sure) was part of a course for students meaning there’s only a few people (apart from the devs) who got to use this thing

The fact that it is in danger of being lost media, is already compatible with scratch, and is already part of mit so they wouldn’t really need to do a whole lot to get the code itself make this one of the largest usefulness/effort ratios on any suggestion I’ve seen to date

I don’t even care if it’s added to scratch really, even if we just get st to release this to the public id be happy

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])
switch costume to (pick random (1) to (# of costumes))
start sound (pick random (1) to (# of sounds)) :: sound

The most complex thing showcased was a Markov chain, and that can be done easily and more flexibly with a couple lists. I don't see any reason to add this to Scratch, except maybe as an extension.

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])
switch costume to (pick random (1) to (# of costumes))
start sound (pick random (1) to (# of sounds)) :: sound

The most complex thing showcased was a Markov chain, and that can be done easily and more flexibly with a couple lists. I don't see any reason to add this to Scratch, except maybe as an extension.

You know what? I was thinking it could be an extension.
I still think it'd be cool to add because of its ease of use.

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])
switch costume to (pick random (1) to (# of costumes))
start sound (pick random (1) to (# of sounds)) :: sound

The most complex thing showcased was a Markov chain, and that can be done easily and more flexibly with a couple lists. I don't see any reason to add this to Scratch, except maybe as an extension.

no its not, it lets you set the odds of each thing getting picked, and lets you modularly set those odds using a seperate list
this is basically impossible inside scratch, watch the showcase video

Support, because it would be awesome and useful for AIs. However, you should be able to programmatically change the chances of each item and add/remove items programmatically.

PPPDUD wrote:

Support, because it would be awesome and useful for AIs. However, you should be able to programmatically change the chances of each item and add/remove items programmatically.

How exactly can this feature be used for AIs compared to what we already have?

cookieclickerer33 wrote:

no its not, it lets you set the odds of each thing getting picked, and lets you modularly set those odds using a seperate list
this is basically impossible inside scratch, watch the showcase video

I suppose you can do this as a workaround:



So in the above code, “3” would be the least randomly occuring choice as there's only 10/100 of them. Just some basic probability
–
But still, this Let's Chance thing creates really nice visualizations, so I'll support

cookieclickerer33 wrote:

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])
switch costume to (pick random (1) to (# of costumes))
start sound (pick random (1) to (# of sounds)) :: sound

The most complex thing showcased was a Markov chain, and that can be done easily and more flexibly with a couple lists. I don't see any reason to add this to Scratch, except maybe as an extension.

no its not, it lets you set the odds of each thing getting picked, and lets you modularly set those odds using a seperate list
this is basically impossible inside scratch, watch the showcase video

It's not that hard. You can duplicate items in the list, or make two lists and run through them like so:

set [choice v] to [1]
set [remaining chance v] to [100]
repeat (length of [choices v])
if <not <(pick random (1) to (remaining chance)) > (item (choice) of [probabilities v])>> then
set [result v] to (item (choice) of [choices v])
stop [this script v]
end
change [choice v] by (1)
end

This workaround is a nice kid-sized chunk of algorithm design that the “Let's Chance” extension would make pointless. I'd rather have custom reporters and first-class lists, so it's easier to make things like this yourself and reuse it for all sorts of use cases.

rdococ wrote:

cookieclickerer33 wrote:

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])
switch costume to (pick random (1) to (# of costumes))
start sound (pick random (1) to (# of sounds)) :: sound

The most complex thing showcased was a Markov chain, and that can be done easily and more flexibly with a couple lists. I don't see any reason to add this to Scratch, except maybe as an extension.

no its not, it lets you set the odds of each thing getting picked, and lets you modularly set those odds using a seperate list
this is basically impossible inside scratch, watch the showcase video

It's not that hard. You can duplicate items in the list, or make two lists and run through them like so:

set [choice v] to [1]
set [remaining chance v] to [100]
repeat (length of [choices v])
if <not <(pick random (1) to (remaining chance)) > (item (choice) of [probabilities v])>> then
set [result v] to (item (choice) of [choices v])
stop [this script v]
end
change [choice v] by (1)
end

This workaround is a nice kid-sized chunk of algorithm design that the “Let's Chance” extension would make pointless. I'd rather have custom reporters and first-class lists, so it's easier to make things like this yourself and reuse it for all sorts of use cases.

I would disagree with the “its not hard” part, as you should be considering that many users of scratch are completely new to programming and are like 7. On the other hand, I do agree that rather then adding an entire extension just to workaround this, it would be better to have them figure it out themselves, as this is way too complicated and specific to be summarized into a simple block. A better solution would be to add or feature tutorials on matters such as these.

blablablahello wrote:

rdococ wrote:

-snip-

I would disagree with the “its not hard” part, as you should be considering that many users of scratch are completely new to programming and are like 7. On the other hand, I do agree that rather then adding an entire extension just to workaround this, it would be better to have them figure it out themselves, as this is way too complicated and specific to be summarized into a simple block. A better solution would be to add or feature tutorials on matters such as these.

How is this “too complicated and specific?” I knew what they meant when people said there was a 1% chance of getting something when I was a kid.

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])

Or just this?

(item (random v) of [list v])

BobRocks20 wrote:

How is this “too complicated and specific?” I knew what they meant when people said there was a 1% chance of getting something when I was a kid.

I mean, you could just do this though:

set [outcome v] to (item (random v) of [outcomes v])
if <(outcome) = [outcome 1]> then
...
else
if <(outcome) = [outcome 2]> then
...
else
...
end
end

Or:

set [outcome v] to (pick random (1) to (x ::grey))
...

Using comparison blocks might work too.

rdococ wrote:

cookieclickerer33 wrote:

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])
switch costume to (pick random (1) to (# of costumes))
start sound (pick random (1) to (# of sounds)) :: sound

The most complex thing showcased was a Markov chain, and that can be done easily and more flexibly with a couple lists. I don't see any reason to add this to Scratch, except maybe as an extension.

no its not, it lets you set the odds of each thing getting picked, and lets you modularly set those odds using a seperate list
this is basically impossible inside scratch, watch the showcase video

It's not that hard. You can duplicate items in the list, or make two lists and run through them like so:

set [choice v] to [1]
set [remaining chance v] to [100]
repeat (length of [choices v])
if <not <(pick random (1) to (remaining chance)) > (item (choice) of [probabilities v])>> then
set [result v] to (item (choice) of [choices v])
stop [this script v]
end
change [choice v] by (1)
end

This workaround is a nice kid-sized chunk of algorithm design that the “Let's Chance” extension would make pointless. I'd rather have custom reporters and first-class lists, so it's easier to make things like this yourself and reuse it for all sorts of use cases.

this is not simple?? plus alot of blocks have workarounds so im tired of hearing the argument of “it can be easily replicated with 30 other blocks”

Bump

medians wrote:

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])

Or just this?

(item (random v) of [list v])

That was removed in 3.0

cookieclickerer33 wrote:

7salad3salad wrote:

That looks pretty cool. I think I'd like to see this implemented!

Id love to be able to play with it but it looks like it’s only available to people who took the course. This would be a great opportunity to give it a public release!

Yeah, i would really like to experiment with these.

DifferentDance8 wrote:

medians wrote:

rdococ wrote:

You're all massively overestimating the abilities of this. This is just a slightly souped up ‘pick random’ block with simple workarounds:

(item (pick random (1) to (length of [list v])) of [list v])

Or just this?

(item (random v) of [list v])

That was removed in 3.0

Yeah I was told, but I found out you can still do this:

(item (join [any] []) of [list v])

(item (join [random] []) of [list v])

Bump

Something I haven't mentioned until now is that Let's Chance seems to meet Scratch's design goals, in that effort was put into designing for a low floor, wide walls, and a high ceiling. For the “low floors,” they decided to load only two of the blocks instead of all 11 so it can be supportive and flexible for beginners. For the “wide walls,” children had a basic idea of probability thanks to an activity they did prior involving dice. With the blocks, they were able to think of various ideas for projects such as a maze generator, a chatbot, a chance-based animation, and music. For the “high ceiling,” blocks for Markov probabilities were designed to let advanced Scratchers enjoy the blocks. It is possible to make some cool projects with some form of artificial intelligence this way.

Oh yeah. For those of you who don't support because of workarounds:

Manuj and Shruti Dhariwal wrote:

By making random variables a primitive in Scratch, the chance blocks provide additional functionality and right level of abstraction for children to tinker with sophisticated probabilistic ideas which can often remain inaccessible or overly complex to imagine or construct using only the pick random block in Scratch.

Source: all from the thesis! For more details, see chapters 2.4, 2.5, and 2.6, as well as 3.3 which goes into detail on how workarounds can be problematic when you're trying to learn about probability.

despacito spider on page 32???

If you think there is a workaround then make it. I guarantee you it’s almost impossible to replicate what this extension does

7salad3salad wrote:

cookieclickerer33 wrote:

7salad3salad wrote:

That looks pretty cool. I think I'd like to see this implemented!

Id love to be able to play with it but it looks like it’s only available to people who took the course. This would be a great opportunity to give it a public release!

Yeah, i would really like to experiment with these.

How exactly would you like to experiment with the blocks? Any examples?

PPPDUD wrote:

Support, because it would be awesome and useful for AIs. However, you should be able to programmatically change the chances of each item and add/remove items programmatically.

You can with another list

BobRocks20 wrote:

7salad3salad wrote:

cookieclickerer33 wrote:

7salad3salad wrote:

That looks pretty cool. I think I'd like to see this implemented!

Id love to be able to play with it but it looks like it’s only available to people who took the course. This would be a great opportunity to give it a public release!

Yeah, i would really like to experiment with these.

How exactly would you like to experiment with the blocks? Any examples?

No specific examples, I'd just like to play around with them and see what they're capable of.

Bump?

Bump may need to make something original for these bump posts of mine later…

Bunp

BobRocks20 wrote:

blablablahello wrote:

rdococ wrote:

-snip-

I would disagree with the “its not hard” part, as you should be considering that many users of scratch are completely new to programming and are like 7. On the other hand, I do agree that rather then adding an entire extension just to workaround this, it would be better to have them figure it out themselves, as this is way too complicated and specific to be summarized into a simple block. A better solution would be to add or feature tutorials on matters such as these.

How is this “too complicated and specific?” I knew what they meant when people said there was a 1% chance of getting something when I was a kid.

Complicated and specific doesn't mean hard to understand, rather, just that I dont believe scratch should be implementing functions which do an extremely specific thing or one which is not simple.

(for example, “a block that makes the sprite say hello when it touchs another sprite which is in a positive y position” is easy to understand and self explanatory, but too specific. At the same time, a block which quicksorts a list wouldn't be as specific, but involves way too many ideas and cannot have how it works explained with a simple “this does this which does this leading to this”)

The weighting of probabilties is is pretty simple yet important concept, so I believe it'd be better to attempt to teach how it works then to simply implement a function for it.
(especially since the whole “help what does this block do” button is gone now)

This would be pretty neat to see, plus Scratch Labs needs something new after they added color contrast! Wait, they have video sprites. Never mind!

Bwa

blablablahello wrote:

BobRocks20 wrote:

blablablahello wrote:

rdococ wrote:

-snip-

-snip-

How is this “too complicated and specific?” I knew what they meant when people said there was a 1% chance of getting something when I was a kid.

Complicated and specific doesn't mean hard to understand, rather, just that I dont believe scratch should be implementing functions which do an extremely specific thing or one which is not simple.

(for example, “a block that makes the sprite say hello when it touchs another sprite which is in a positive y position” is easy to understand and self explanatory, but too specific. At the same time, a block which quicksorts a list wouldn't be as specific, but involves way too many ideas and cannot have how it works explained with a simple “this does this which does this leading to this”)

The weighting of probabilties is is pretty simple yet important concept, so I believe it'd be better to attempt to teach how it works then to simply implement a function for it.
(especially since the whole “help what does this block do” button is gone now)

Well, according to the thesis (1.2, 1.3), the Let's Chance blocks do teach probability, specifically probabilistic thinking, in a constructionist way. It also states that the current way probabilistic thinking is taught is too specific and restrictive for children to understand the concept. By introducing probabilistic blocks to Scratch, children will be able to explore and experiment with the blocks and become more aware of probabilistic thinking in the process. This is constructionist learning in action.

And for the “specific” part, think of the many projects children were able to create with these blocks. You can see me talking about how this meets Scratch's design goals here.

I MIGHT be able to make a reimplementation of this in snap using tables but it won’t be anywhere near as good as this

With that you would just have to feed it raw numbers and it would give an output, this has an entire display with it that lets you tweak the chances without having to learn how the block “works”

blablablahello wrote:

Complicated and specific doesn't mean hard to understand, rather, just that I dont believe scratch should be implementing functions which do an extremely specific thing or one which is not simple.

(for example, “a block that makes the sprite say hello when it touchs another sprite which is in a positive y position” is easy to understand and self explanatory, but too specific. At the same time, a block which quicksorts a list wouldn't be as specific, but involves way too many ideas and cannot have how it works explained with a simple “this does this which does this leading to this”)

The weighting of probabilties is is pretty simple yet important concept, so I believe it'd be better to attempt to teach how it works then to simply implement a function for it.
(especially since the whole “help what does this block do” button is gone now)

List sorting is a great example. Sorting is a good programming task for beginners, and adding it as a block means kids will take the easy way out instead of rising to the challenge of implementing a sorting algorithm and actually learning some programming in the process. Similarly, probabilistic algorithms like Markov chains are also interesting programming tasks. This extension would rid the kids the opportunity to solve these kinds of programming challenges in what is supposed to be an educational programming language.

BobRocks20 wrote:

Something I haven't mentioned until now is that Let's Chance seems to meet Scratch's design goals, in that effort was put into designing for a low floor, wide walls, and a high ceiling. For the “low floors,” they decided to load only two of the blocks instead of all 11 so it can be supportive and flexible for beginners. For the “wide walls,” children had a basic idea of probability thanks to an activity they did prior involving dice. With the blocks, they were able to think of various ideas for projects such as a maze generator, a chatbot, a chance-based animation, and music. For the “high ceiling,” blocks for Markov probabilities were designed to let advanced Scratchers enjoy the blocks. It is possible to make some cool projects with some form of artificial intelligence this way.

Maybe Scratch's design goals are the issue, or at least their implementation. The Scratch Team have made a language which makes the specific games, stories and animations they envision trivially easy, but anything from a side-scrolling platformer to advanced projects is disproportionately difficult. In terms of the “big room” analogy, Scratch has a low floor, and it might technically have “wide walls” and a “high ceiling”, but it's easier just to switch languages if you want to actually climb.

rdococ wrote:

blablablahello wrote:

-snip-

List sorting is a great example. Sorting is a good programming task for beginners, and adding it as a block means kids will take the easy way out instead of rising to the challenge of implementing a sorting algorithm and actually learning some programming in the process. Similarly, probabilistic algorithms like Markov chains are also interesting programming tasks. This extension would rid the kids the opportunity to solve these kinds of programming challenges in what is supposed to be an educational programming language.

OK this is where I bring this up:

Constructive Recommendations On How to Respond to and Make Suggestions! wrote:

Sixth Suggestion:
(Thanks to Tymewalk)
Stop saying this:

No support, there's a workaround.

The point of Scratch is to be a challenge, not just hand every block over to the user on a sliver platter. Users should work to get these scripts, not just have it done for them.

It's that last sentence especially that gets me angry. People just discard an idea because it “makes things too easy”.

The common response is “why do we have move () steps then”, but it goes much farther than that - why do we have “go to” if we can use “set x” and “set y”? Why use any of the pen stuff, you can replicate it with “stamp”? Why have clones, just make other sprites?

The answer is because not everything has to be challenging. So what if “real programming languages don't do that”? Scratch is supposed to be an introduction to programming, meaning that it's easier. And yes, there are cases where you have to say “no support”. But don't just say it because “it's not challenging enough”.

A block that calculates the sunset based on the user's given location? That's a little too far. A block that converts a “days since 2000” to real-time? That would be OK.

So please, take the time to read through suggestions before dissing them as “not challenging enough”.

rdococ wrote:

Maybe Scratch's design goals are the issue, or at least their implementation. The Scratch Team have made a language which makes the specific games, stories and animations they envision trivially easy, but anything from a side-scrolling platformer to advanced projects is disproportionately difficult. In terms of the “big room” analogy, Scratch has a low floor, and it might technically have “wide walls” and a “high ceiling”, but it's easier just to switch languages if you want to actually climb.

And here's where you come in:

rdococ wrote:

The Scratch Team has a very clear vision of what they want Scratch to be. Scratch is designed to be incredibly simple; kids as young as 8 years old must be able to pick up Scratch on their own and express themselves with stories, animations and games, as well as understand each other's code well enough to use it in their own projects.

Flexibility and power are also goals, but they take a backseat to this core vision. Any suggestion you make has to be so good that it outweighs the challenge of 8 year olds facing it for the first time, useful enough for Scratch's core vision of kids creating stories, animations and games, as well as supporting the sharing of projects, collaboration, and kids learning from each other's code, as well as outweighing these factors enough to justify the weight of simply having an extra feature.

Let's Chance was made to simplify probabilities so you don't have to do any difficult workarounds. Kids know what dice are. I bet they will have a basic idea of what the “roll die” blocks do the instant they see them. I have said this before and I will say it again: the children who had access to Let's Chance were able to make stories, animations, and games using these blocks (source: the thesis, link is in the first post).

If a project with Let's Chance blocks is shared with the community, people will have the option to remix that project and change the percentages set in the Let's Chance blocks. By doing this they are learning from that project's code and becoming capable of probabilistic thinking. I don't know about Let's Chance blocks being used for collaboration, but that doesn't matter, because it's possible and we are capable of thinking outside the box.

Bump! I updated the original post so please read it before replying!

Definite support, makes probability far less complicated

BobRocks20 wrote:

And here's where you come in:

rdococ wrote:

The Scratch Team has a very clear vision of what they want Scratch to be. Scratch is designed to be incredibly simple; kids as young as 8 years old must be able to pick up Scratch on their own and express themselves with stories, animations and games, as well as understand each other's code well enough to use it in their own projects.

Flexibility and power are also goals, but they take a backseat to this core vision. Any suggestion you make has to be so good that it outweighs the challenge of 8 year olds facing it for the first time, useful enough for Scratch's core vision of kids creating stories, animations and games, as well as supporting the sharing of projects, collaboration, and kids learning from each other's code, as well as outweighing these factors enough to justify the weight of simply having an extra feature.

Let's Chance was made to simplify probabilities so you don't have to do any difficult workarounds. Kids know what dice are. I bet they will have a basic idea of what the “roll die” blocks do the instant they see them. I have said this before and I will say it again: the children who had access to Let's Chance were able to make stories, animations, and games using these blocks (source: the thesis, link is in the first post).

That is indeed the Scratch Team's vision, and “Let's Chance” works very well to fulfil that vision. But you're assuming that I agree with the vision. While kids should be creating fun and interesting projects on Scratch, the Scratch Team massively prioritises self-expression over learning computational thinking, and I think that's a huge mistake.

BobRocks20 wrote:

You can see how this meets Scratch's design goals here.
If you don't support this please provide a valid reason and don't say that workarounds exist or that children should learn probability themselves using the existing blocks.

But they should. Scratch has a stated goal to teach computational thinking, not probabilistic thinking, and extensions that solve computational problems for the user make this more difficult.

To borrow terminology from the thesis, the “low level building blocks” to “black box” scale is relative to what you're trying to get kids to do. And while the “Let's Chance” extension blocks are in the middle for probabilistic thinking (though even that is debatable), they're a total black box for computational thinking, and that is more important in the context of Scratch.

BobRocks20 wrote:

If a project with Let's Chance blocks is shared with the community, people will have the option to remix that project and change the percentages set in the Let's Chance blocks. By doing this they are learning from that project's code and becoming capable of probabilistic thinking.

Remixing a project and changing some Let's Chance percentages isn't going to make you capable of computational thinking - on the other hand, seeing how it uses ‘pick random’ to select from a weighted list of choices certainly is.

rdococ wrote:

-responding to all his counterarguments, snip-

If Scratch promotes computational thinking and not probabilistic thinking, then why did Manuj Dhariwal (who wrote the thesis), plan out Let's Chance for Scratch? Why did Scratch's co-founder Mitchel Resnick decide to become the advisor for this work? To add on to that question, why did he certify the thesis?

With the increasing relevance of AI, and the fact that programmers use computational thinking to make AI, it would make sense to also consider probabilistic thinking, which is essential for AI because it needs that kind of thinking to make decisions in case of uncertainty.

I believe I'll have to stop here, since this topic is getting derailed. I like how your counterpoints made me think about Scratch as a whole in a new way, and though it may not seem like it to you I understand your reasons for not supporting. One thing won't change, though: I still support Let's Chance.

No arguments beyond this point!

BobRocks20 wrote:

With the increasing relevance of AI, and the fact that programmers use computational thinking to make AI, it would make sense to also consider probabilistic thinking, which is essential for AI because it needs that kind of thinking to make decisions in case of uncertainty.

I don't think probabilistic reasoning is the same as probabilistic computation

ajskateboarder wrote:

BobRocks20 wrote:

With the increasing relevance of AI, and the fact that programmers use computational thinking to make AI, it would make sense to also consider probabilistic thinking, which is essential for AI because it needs that kind of thinking to make decisions in case of uncertainty.

I don't think probabilistic reasoning is the same as probabilistic computation

Oh! Well TBH I'm not an expert in computer science and all that so I'd like it if you explained further on my profile. RIght now I'm concerned about getting back on topic so people can add on to my suggestion.

bump

Bump

Bump, with some minor-ish revisions to the original post.

Mr_Woomy wrote:

The_Game_ wrote:

Are they in any way different from

(pick random (1) to (10))

from a quick glance it looks more child friendly of a rng system but the workaround is probably easy enough as is

you can make a RNG system like this:

set [RNG ] to (pick random (1) to (100))
if <[RNG] > [10]> then 
do thing
else
if <[RNG] > [20]> then 
do other thing
  

else
do third thing
end
end

dogfish517 wrote:

Mr_Woomy wrote:

The_Game_ wrote:

Are they in any way different from

(pick random (1) to (10))

from a quick glance it looks more child friendly of a rng system but the workaround is probably easy enough as is

you can make a RNG system like this:

set [RNG ] to (pick random (1) to (100))
if <[RNG] > [10]> then 
do thing
else
if <[RNG] > [20]> then 
do other thing
  

else
do third thing
end
end

That’s kind of what this does? But also not at all what this does

It lets you set the values of each chance easily as well as modularity set the likeliness of each option using a list, as well as what it outputs

We really can’t learn more than this without an official release

I have some good news though about this!
I have a high likelihood of getting into mit, if I do I’ll make sure to work with the people there on getting this thing to the public

But in the meantime I had an idea
If this is possible to make in blockly wouldn’t it be possible to remake in a scratch mod?
If so could we get the developer of penguin mod involved?

Do you really need to say

The Obscure MIT Project by Lifelong Kindergarten of Scratch