Maximouse wrote:

xXRedTheCoderXx wrote:

I don't know what algorithm Scratch used to decided for “set x to 0” to go first, but I'm assuming Scratch would use that same algorithm with these blocks.

There is no algorithm – you could change the order by editing project.json.

Wait, is it just random?

BosenChang wrote:

I think @xXTheRedCoderXx should add “please read everything before making a post”

Maybe..

xXRedTheCoderXx wrote:

Wait, is it just random?

No, dragging scripts around changes the order.

Maximouse wrote:

xXRedTheCoderXx wrote:

Wait, is it just random?

No, dragging scripts around changes the order.

I did that and nothing changed.

If you need this block to implement a feature, you really need to find a better way to implement that feature.

-Rex- wrote:

If you need this block to implement a feature, you really need to find a better way to implement that feature.

Okay, so?

And, no, I was just making a tutorial and thinking, having this block could really organize this code!

I started thinking about how useful it was, so I made a suggestion about it.

Though I still support, I think there might be a workaround for custom blocks.
Make a second custom block with the other function.

Mr_PenguinAlex wrote:

Though I still support, I think there might be a workaround for custom blocks.
Make a second custom block with the other function.

What? Sorry, I'm confused

xXRedTheCoderXx wrote:

Mr_PenguinAlex wrote:

Though I still support, I think there might be a workaround for custom blocks.
Make a second custom block with the other function.

What? Sorry, I'm confused

if you make 2 different custom blocks,
and do this:

when green flag clicked
custom block 1 :: custom
custom block 2 :: custom

it would work like this script, right?

Mr_PenguinAlex wrote:

xXRedTheCoderXx wrote:

Mr_PenguinAlex wrote:

Though I still support, I think there might be a workaround for custom blocks.
Make a second custom block with the other function.

What? Sorry, I'm confused

if you make 2 different custom blocks,
and do this:

when green flag clicked
custom block 1 :: custom
custom block 2 :: custom

it would work like this script, right?

No…

Custom blocks run code underneath them when the custom block is done running.

And with forever loops, that would be never.

The only possible workaround is incredibly complicated and requires a list for every single argument of every single custom block.

Can't you just make two separate blocks for the two separate functions and have two scripts run them at the same time? It's an easy workaround.

JplaysStuff wrote:

Can't you just make two separate blocks for the two separate functions and have two scripts run them at the same time? It's an easy workaround.

No, no you can't.

And, no, it is not an easy workaround.

Read these posts:

xXRedTheCoderXx wrote:

Mr_PenguinAlex wrote:

if you make 2 different custom blocks,
and do this:

when green flag clicked
custom block 1 :: custom
custom block 2 :: custom

it would work like this script, right?

No…

Custom blocks run code underneath them when the custom block is done running.

And with forever loops, that would be never.

The only possible workaround is incredibly complicated and requires a list for every single argument of every single custom block.

xXRedTheCoderXx wrote:

This block's main use is to make custom blocks able to run multiple scripts.

And, as you may know, custom blocks are different from broadcasts because with custom blocks you can add boolean inputs and string inputs. You could only use those inputs when you define the custom block.

So, basically broadcasts can't carry over what you input in the custom block unless you use variables or something but like bruh.

xXRedTheCoderXx wrote:

DownsGameClub wrote:

xXRedTheCoderXx wrote:

So, basically broadcasts can't carry over what you input in the custom block unless you use variables or something but like bruh.

As a person who hasn't used custom blocks in a while, why would using variables be an issue?

Having to make a variable for every single argument in your custom block is beyond tedious and isn't ideal. Having so many variables could cause your variable list to clutter up.

Also, using variables means that you can only run a custom block when it isn't already running, otherwise your variables will change from the other custom block of the same type running, and you'd be left scratching your head wondering why your game doesn't work.

It's hard to put into words, at least for me, but trust me, using variables restricts you, which could lead to the breaking of your game, as well as clutters your variable list making your game as a whole just that bit more unorganized.

xXRedTheCoderXx wrote:

The only possible workaround is incredibly complicated and requires a list for every single argument of every single custom block.

Block you want to make:

define block (arg 1) (arg 2) (arg 3)
run {
thing 1::grey
} while running {
thing 2::grey
}::control

When flag clicked
block () () ()

Workaround:

define thing 1 (arg 1) (arg 2) (arg 3)
thing 1::grey

define thing 2 (arg 1) (arg 2) (arg 3)
thing 2::grey

When flag clicked
thing 1 ( ) ( ) ( )::custom

When flag clicked
thing 2 ( ) ( ) ( )::custom

Just make custom blocks with the same arguments and you shouldnt need variables

whiteandblackcat wrote:

xXRedTheCoderXx wrote:

The only possible workaround is incredibly complicated and requires a list for every single argument of every single custom block.

Block you want to make:
-snip-
Just make custom blocks with the same arguments and you shouldnt need variables

But doesn't that only allow a custom block to be run only twice at maximum at once? And having to figure out which custom block to use takes up a variable, not to mention this entire thing takes up a lot of space.

Also, why are people so obsessed with trying to find a workaround to this? >-<

xXRedTheCoderXx wrote:

(everything else is addressed below)
Also, why are people so obsessed with trying to find a workaround to this?

Because this is how the suggestions forum works. People suggest things, and others discuss the options, then think of workarounds while we wait for the feature.
I don't think it would be necessary. Yes, it could be useful, but only in some very select occasions. 99% of the time you'd be able to just use two scripts. I don't think it's necessary to implement.

But doesn't that only allow a custom block to be run only twice at maximum at once?

What do you mean by this? You can run three things at the same time, just make a third custom block. And so on.

And having to figure out which custom block to use takes up a variable

You say this, but I don't think you understand my workaround. If they run at the same time, why do you need to figure out which custom block to use?

not to mention this entire thing takes up a lot of space

But only in the rare cases where you'll need it. As I said before, most of the time, you won't need to use a big long workaround, just two scripts. Occasionally, you'll need this workaround, but it's not that long, in fact I consider it to be quite short. It's less than ten blocks.

whiteandblackcat wrote:

Because this is how the suggestions forum works. People suggest things, and others discuss the options, then think of workarounds while we wait for the feature.
I don't think it would be necessary. Yes, it could be useful, but only in some very select occasions. 99% of the time you'd be able to just use two scripts. I don't think it's necessary to implement.

A. Hmm… okay. Sorry, I think I'm just really getting tired of people saying you could just use 2 or more scripts…
B. If you don't find that useful, then that's okay, that's up to you. It's just how I may not find the

if on edge, bounce

block useful, but a new scratcher might will. The thing is, I don't think you understand that this block would actually be very useful for many people. Here are some good examples.

kitten769 wrote:

Support. This would be great for compressing scripts and especially walk cycles, where you want two procedures under one hat block.

PizzaAddict4Life wrote:

Support! While I have never encountered the problem with custom blocks (because I often don't use them) I am tired of using that workaround with two forever loops, so major support!

Madcatofdoom wrote:

Support! This would be very helpful to simplify stuff and make it easier to do this!

ResExsention wrote:

Coroutines!

Support. Useful beyond belief.

xXRedTheCoderXx wrote:

coder2045 wrote:

Support. I've had to use eight broadcasts and ten scripts in an animation just to have characters fight over a paper airplane and I could just do:

set [marker v] to [0]
run{
line 1:: #0000dd
set [marker v] to [1]
}while running{
run{
wait until <(marker) = [1]>
line 2:: #f00000
set [marker v] to [2]
}while running{
run{
wait until <(marker) = [2]>
line 2:: #f0f000
set [marker v] to [3]
}while running{
...
}:: control
}:: control
}:: control

Wow! 10 scripts compressed into 1! Impressive!

Glad to know you'd find this useful.

99% of the time you'd be able to just use two scripts. I don't think it's necessary to implement.

And 100% of the time, instead of having to use

if on edge, bounce

you could use

if <touching [edge v] ?> then
point in direction ((direction) - (180))
end

However, that doesn't mean that the if on edge bounce block is unnecessary and not useful.

whiteandblackcat wrote:

What do you mean by this? You can run three things at the same time, just make a third custom block. And so on.

Oh, yeah. There's still a unideal limit, though.

whiteandblackcat wrote:

You say this, but I don't think you understand my workaround. If they run at the same time, why do you need to figure out which custom block to use?

No, I don't think you're understanding me.
To figure out which custom block to use, you have to create a variable that says how many custom blocks are currently running, and depending on tat you use a different custom block.

whiteandblackcat wrote:

But only in the rare cases where you'll need it. As I said before, most of the time, you won't need to use a big long workaround, just two scripts. Occasionally, you'll need this workaround, but it's not that long, in fact I consider it to be quite short. It's less than ten blocks.

It depends on what you're trying to do and what you want the max amount of custom blocks to be running at once are. So, 10 blocks could quickly become 250 blocks, and 95% of that would be duplicated code.

Now, I'm going to (temporarily) close this topic.

I think we are just confusing each other, to be honest. I'm also really tired and, I spent so long on this post, and that time could've been spent debugging and working on my game, which has to release in 2 days. So, I've been really stressed and this topic isn't helping with that.

I'll close this topic in 10 minutes, and I'll request for it to be opened again when I'm ready for more discussion.

Ok. I can't guarantee I'll feel ready to participate in this conversation at all later but I completely respect your decision to close this. It was about to turn into flame wars.

whiteandblackcat wrote:

Ok. I can't guarantee I'll feel ready to participate in this conversation at all later but I completely respect your decision to close this. It was about to turn into flame wars.

Okay.

I support. the

block would be super useful!

DabDatBass wrote:

I support. the

block would be super useful!

Thanks! Another person who finds this useful. XD

Cool 3.0 mock-ups too.

This thread will now be temporarily closed.

Goodbye for now.

Opened.