Hey all! I'm new to scratch but I come from a programming background, I recently found this site and thought it would be a nice change from regular, typed out code.

So basically here is a weird.. issue I'm having to deal with.
I made a custom block that causes a character to spout out random gibberish constantly.
I put this custom block within an if statement. The problem is that if, at ANY time, that if statement changes from true to false. The custom block stops running, even though it had already started running. This is incredibly annoying xD.

This doesn't happen in typed out code. Normally, if an if statement is true, it will let all the code within it run even if it changes half way through. So I'm not sure about any good work-arounds.

Thanks guys

That shouldn't be happening. Scratch works in much the same way. Can I see the script?

First of all, welcome to Scratch!

I would reccomend that you have the if statement inside the definition block, intead of having the block inside the if statement, like this:

The above would replace this:

Peppermint's method looks like it would work quite well. The root of your problem, though, still baffles me. I've been on Scratch for a while, and I'm working on a project now that actually relies kinda heavily on custom blocks only continuing the script when they're done. I trust it's not just because it's only running itself once, as I'm sure you understand that sort of thing very well already.

JoeyTheChicken wrote:

Peppermint's method looks like it would work quite well. The root of your problem, though, still baffles me. I've been on Scratch for a while, and I'm working on a project now that actually relies kinda heavily on custom blocks only continuing the script when they're done. I trust it's not just because it's only running itself once, as I'm sure you understand that sort of thing very well already.

Hmm… yeah I'm still a little confused about this too. It would be great if we could see the scripts.

peppermintpatty5 wrote:

JoeyTheChicken wrote:

Peppermint's method looks like it would work quite well. The root of your problem, though, still baffles me. I've been on Scratch for a while, and I'm working on a project now that actually relies kinda heavily on custom blocks only continuing the script when they're done. I trust it's not just because it's only running itself once, as I'm sure you understand that sort of thing very well already.

Hmm… yeah I'm still a little confused about this too. It would be great if we could see the scripts.

JoeyTheChicken wrote:

That shouldn't be happening. Scratch works in much the same way. Can I see the script?

It's a huge, unfinished project. I will make an example project for this though. Maybe doing that will figure out the problem for me

GameArchitect wrote:

peppermintpatty5 wrote:

JoeyTheChicken wrote:

Peppermint's method looks like it would work quite well. The root of your problem, though, still baffles me. I've been on Scratch for a while, and I'm working on a project now that actually relies kinda heavily on custom blocks only continuing the script when they're done. I trust it's not just because it's only running itself once, as I'm sure you understand that sort of thing very well already.

Hmm… yeah I'm still a little confused about this too. It would be great if we could see the scripts.

JoeyTheChicken wrote:

That shouldn't be happening. Scratch works in much the same way. Can I see the script?

It's a huge, unfinished project. I will make an example project for this though. Maybe doing that will figure out the problem for me

Sounds great!

That is expected behaviour. Scratch is single threaded and although you can create multiple events you cannot create threads as such. Any running script ultimately starts from an event and anytime that event is repeated be it a broadcast. key press or green flag the script that is running will be reset, which is why your endless custom block does indeed end.

https://scratch.mit.edu/projects/58621390/

There's the project, look at the code inside, I left comments for you guys.

drmcw wrote:

That is expected behaviour. Scratch is single threaded and although you can create multiple events you cannot create threads as such. Any running script ultimately starts from an event and anytime that event is repeated be it a broadcast. key press or green flag the script that is running will be reset, which is why your endless custom block does indeed end.

I just got back from making the example project where I made the same realization. This is going to be very tough to overcome, I've already found some really bizarre work-arounds for some of this but I'm currently struggling with the same issue on a much larger scale.

It wouldn't be such a problem if I could just prevent the broadcast from being sent to certain sprites. That way the code would never run a second time without my say so.

What do you guys think about this.

I could make a security broadcast. Basically, the broadcast is sent, but instead of immediately running the code, it will go to another piece of code that will analyse it and determine if it is safe to use. If it is safe, it will send a second broadcast that will run the real code. If not, then it won't do anything.
This way, it would never run the code twice unless it gets past the security code first.
The question is this… is all that code still “connected” to each other?

peppermintpatty5 wrote:

First of all, welcome to Scratch!

I would reccomend that you have the if statement inside the definition block, intead of having the block inside the if statement, like this:

The above would replace this:

Hmmm, that's a good idea, but I think that only works in certain situations unfortunately. Because if I ever want to reuse the custom block for another purpose (which I will be doing a lot), I wouldn't be able to because it's customized to work in only one situation.

Looked at the project and just wonder what you want to happen? If the wander block did keep running and was called again what would you want to happen? If that was the case in typed code, in which case it would have to be another thread, then the clones properties are all unprotected resources and you'd be in trouble.

I could make a security broadcast. Basically, the broadcast is sent, but instead of immediately running the code, it will go to another piece of code that will analyse it and determine if it is safe to use. If it is safe, it will send a second broadcast that will run the real code. If not, then it won't do anything.
This way, it would never run the code twice unless it gets past the security code first.

Sounds like a sensible solution.

YES! The security broadcast works! Oh my word I've been working on this for a couple hours now.
So beautiful… lol

So, because broadcasts aren't connected to the code they're running, they are then able to run code without effecting the code it ran previously.

In other words.. I can put as many if statements as I want without worry.

Look forward to seeing the complete project in the future.

drmcw wrote:

Looked at the project and just wonder what you want to happen? If the wander block did keep running and was called again what would you want to happen? If that was the case in typed code, in which case it would have to be another thread, then the clones properties are all unprotected resources and you'd be in trouble.

What I want to happen, is to be able to run the Wander code once and not have it called over and over again. This couldn't be achieved because the broadcast occurs every 5 seconds, and would therefore, run the wander code over and over again. I tried to stop this by adding “if” statements to make it so that the code wouldn't run over and over again. But because of the way this works, putting if statements actually stopped the code from running altogether, rather than simply prevent the code from being run.

I don't want it to run over and over again because that can cause odd glitches when you stop code in the middle of running.
And that Wander block was the simple one, I have a much more annoying block that has recursion and it also calls other custom blocks from within it.
Needless to say, running that complicated custom block over and over again is a hairball

GameArchitect wrote:

YES! The security broadcast works! Oh my word I've been working on this for a couple hours now.
So beautiful… lol

So, because broadcasts aren't connected to the code they're running, they are then able to run code without effecting the code it ran previously.

In other words.. I can put as many if statements as I want without worry.

There you go :3 We get some pretty advanced stuff around here, but I never thought of that kind of recursion or whatever, as I'm barred from moving to a new language by lack of knowledge of what to type, commands, etc. I'm getting pretty advanced, and I'm doing a big project right now. Glad you found a workaround. Since Scratch is primarily to introduce beginners to coding, I can understand why we'd have that broadcast rule. I only recently realized the true value and power of a broadcast, so my latest project lagged a ton… We should all learn to broadcast a little more. Anyhow, I'm rambling. Have a great time on the site!

GameArchitect wrote:

drmcw wrote:

Looked at the project and just wonder what you want to happen? If the wander block did keep running and was called again what would you want to happen? If that was the case in typed code, in which case it would have to be another thread, then the clones properties are all unprotected resources and you'd be in trouble.

What I want to happen, is to be able to run the Wander code once and not have it called over and over again. This couldn't be achieved because the broadcast occurs every 5 seconds, and would therefore, run the wander code over and over again. I tried to stop this by adding “if” statements to make it so that the code wouldn't run over and over again. But because of the way this works, putting if statements actually stopped the code from running altogether, rather than simply prevent the code from being run.

I don't want it to run over and over again because that can cause odd glitches when you stop code in the middle of running.
And that Wander block was the simple one, I have a much more annoying block that has recursion and it also calls other custom blocks from within it.
Needless to say, running that complicated custom block over and over again is a hairball

It sounds like you're hung up on “old” habits, so to speak. It looks like you're after a pseudo-tick system, which I've never heard of on Scratch. However, you might find the “broadcast and wait” block very useful on here.

JoeyTheChicken wrote:

GameArchitect wrote:

YES! The security broadcast works! Oh my word I've been working on this for a couple hours now.
So beautiful… lol

So, because broadcasts aren't connected to the code they're running, they are then able to run code without effecting the code it ran previously.

In other words.. I can put as many if statements as I want without worry.

There you go :3 We get some pretty advanced stuff around here, but I never thought of that kind of recursion or whatever, as I'm barred from moving to a new language by lack of knowledge of what to type, commands, etc. I'm getting pretty advanced, and I'm doing a big project right now. Glad you found a workaround. Since Scratch is primarily to introduce beginners to coding, I can understand why we'd have that broadcast rule. I only recently realized the true value and power of a broadcast, so my latest project lagged a ton… We should all learn to broadcast a little more. Anyhow, I'm rambling. Have a great time on the site!

Nice, it's cool to hear you are going for a nice, large project (obviously much more satisfying in the end than a small project)
Yea, broadcasting is a must have, even more now that I know I can use it as a work around. It saves you from having to use variables and forever loops for everything, which as you said, decreases lag.

I've used the broadcast and wait a few times, it is also really helpful in specific situations. I should probably use it more though, it may make my code more clean at times, lol.
As for the pseudo tick system, I use a sort of “tick” system for the day night cycle in the game. But all it really does is count up in seconds and then reset each in-game hour back to 0. Although I must admit, I tried to make a real tick system xD that counts up in milliseconds, but as you said, that's not something scratch was meant to do.

Also just curious, what project are you working on? If you don't mind my asking

GameArchitect wrote:

JoeyTheChicken wrote:

GameArchitect wrote:

YES! The security broadcast works! Oh my word I've been working on this for a couple hours now.
So beautiful… lol

So, because broadcasts aren't connected to the code they're running, they are then able to run code without effecting the code it ran previously.

In other words.. I can put as many if statements as I want without worry.

There you go :3 We get some pretty advanced stuff around here, but I never thought of that kind of recursion or whatever, as I'm barred from moving to a new language by lack of knowledge of what to type, commands, etc. I'm getting pretty advanced, and I'm doing a big project right now. Glad you found a workaround. Since Scratch is primarily to introduce beginners to coding, I can understand why we'd have that broadcast rule. I only recently realized the true value and power of a broadcast, so my latest project lagged a ton… We should all learn to broadcast a little more. Anyhow, I'm rambling. Have a great time on the site!

Nice, it's cool to hear you are going for a nice, large project (obviously much more satisfying in the end than a small project)
Yea, broadcasting is a must have, even more now that I know I can use it as a work around. It saves you from having to use variables and forever loops for everything, which as you said, decreases lag.

I've used the broadcast and wait a few times, it is also really helpful in specific situations. I should probably use it more though, it may make my code more clean at times, lol.
As for the pseudo tick system, I use a sort of “tick” system for the day night cycle in the game. But all it really does is count up in seconds and then reset each in-game hour back to 0. Although I must admit, I tried to make a real tick system xD that counts up in milliseconds, but as you said, that's not something scratch was meant to do.

Also just curious, what project are you working on? If you don't mind my asking

Oddly, I actually thought that broadcasting was a way to introduce simple variable communication to new coders, so I was trying to keep mostly away from it. I relied on it some in my early days, but I was moved off of it once variables and lag-inducing forever loops became my entire world. I would actually simulate my own broadcasts by changing a variable to one and then back to zero .1 seconds later. I tend to use 1 and 0 instead of true and false. As for broadcast and wait, I use it because it's reliable. I'm working more with atomic scripts now, so they can be good to make sure everything's clear before I go atomic. As for tick systems, I can understand how one would work, but making one with Scratch sounds like torture… but it would keep everything nice and in line. The project is a collaboration that's to be a 2D adventure game when it's done. We're using a tile-based loader. I'm the programmer, and the loader took me about a month to finish, but I'm so glad it's done. It took so long because of how much data is converted, converted, and converted again and how many bugs were cropping up with it. There's a link to the collaboration's forum thread in my signature if you wanted more information :3

Oddly, I actually thought that broadcasting was a way to introduce simple variable communication to new coders, so I was trying to keep mostly away from it. I relied on it some in my early days, but I was moved off of it once variables and lag-inducing forever loops became my entire world. I would actually simulate my own broadcasts by changing a variable to one and then back to zero .1 seconds later. I tend to use 1 and 0 instead of true and false. As for broadcast and wait, I use it because it's reliable. I'm working more with atomic scripts now, so they can be good to make sure everything's clear before I go atomic. As for tick systems, I can understand how one would work, but making one with Scratch sounds like torture… but it would keep everything nice and in line. The project is a collaboration that's to be a 2D adventure game when it's done. We're using a tile-based loader. I'm the programmer, and the loader took me about a month to finish, but I'm so glad it's done. It took so long because of how much data is converted, converted, and converted again and how many bugs were cropping up with it. There's a link to the collaboration's forum thread in my signature if you wanted more information :3

Ooo, a tile loader would be brutal on scratch 0.0
Let me ask this, how useful would it be for your project if Custom blocks weren't limited to just numbers, letters, and booleans?
For example, what if custom blocks could include a variable or list slot. So that you can actually say what variable you want to have changed, or what list you want to convert in the custom block? If you know what I'm trying to say

GameArchitect wrote:

Oddly, I actually thought that broadcasting was a way to introduce simple variable communication to new coders, so I was trying to keep mostly away from it. I relied on it some in my early days, but I was moved off of it once variables and lag-inducing forever loops became my entire world. I would actually simulate my own broadcasts by changing a variable to one and then back to zero .1 seconds later. I tend to use 1 and 0 instead of true and false. As for broadcast and wait, I use it because it's reliable. I'm working more with atomic scripts now, so they can be good to make sure everything's clear before I go atomic. As for tick systems, I can understand how one would work, but making one with Scratch sounds like torture… but it would keep everything nice and in line. The project is a collaboration that's to be a 2D adventure game when it's done. We're using a tile-based loader. I'm the programmer, and the loader took me about a month to finish, but I'm so glad it's done. It took so long because of how much data is converted, converted, and converted again and how many bugs were cropping up with it. There's a link to the collaboration's forum thread in my signature if you wanted more information :3

Ooo, a tile loader would be brutal on scratch 0.0
Let me ask this, how useful would it be for your project if Custom blocks weren't limited to just numbers, letters, and booleans?
For example, what if custom blocks could include a variable or list slot. So that you can actually say what variable you want to have changed, or what list you want to convert in the custom block? If you know what I'm trying to say

I wanted that so badly… That was the exact reason the loader took that long. However, the end result means less lists, less clutter, and much more ease! I'm breathing easy because of the end result. Essentially what it is is this: You hit the K key to open level-building mode. You just change the costume of the tile, move the mouse, and hit space to place tiles where you want. You can then hit S and you'll be given a save code. This is what took so long. The save code is actually a recording of everything you did, so in order: x,y,tile. So placing dirt at x: 5 and y: -9 would return ,5,-5,dirt,. The list is a long string of those. The bridge between this is a script with a large stack of custom blocks. Each custom block has three bits of data: the coordinates of the area (x,y,z,w) in that order, the required backdrop for that screen, and the level save code. The first value is made of four variables, Mapx,y,z,and w, all put together in one variable called (Map). The second value is just a stage name, like blue sky. But it takes the third value and runs over the numbers until it hits a comma, at which point it ejects what it has so far into a list called Area. Once the custom block is done converting the data, it continues the script and eventually hits the Load Screen custom block. This puts Tile1 at x, the first value, y, the second value, and changes its costume to the third value, so it's like three lists being saved as one by keeping order to the values. If it's a tangible tile, one the player can collide with, the tile clones. If it's not, it stores all that information in a list called Special XYC. Once all the tangible tiles have loaded, it broadcasts something to Tile2 to get it to read over Special XYC to place all the non-tangible tiles. Then it broadcasts that loading is done and uncovers the playing screen, which is covered during loading by a large black sprite. Sorry if that was confusing. I'm a horrible describer.

Also, the x and y are rounded by forty. When designing, it takes the x position of the mouse, divides that by forty, rounds it, then multiplies it back up by forty so that it creates a true grid. Then it uses that same method to place the tiles.