I was trying to make a “spray paint” project. However, it was either really laggy, or just stopped making clones. Please take a look, I put a custom block so it ran without screen refresh. http://scratch.mit.edu/projects/10314520/

Is this better?

One thing to avoid is any kind of “wait” inside a no-screen-refresh block.

Remember that nothing else can happen while such a block is running, so it will lock up the flash player until it finishes - and it'll then be way behind on other ‘bookwork’ that it wants to do, and will never get chance to catch up again - hence the lag.

Similarly, note that “broadcast and wait” within a non-refresh block will bring about the same result - because it's waiting for the receiving script to finish, but that can't even get started until the non-refresh script is finished (although there is a time-limit of ~1sec for non-refresh, but it still brings everything to a crashing halt if it gets that far…)

Hope that helps!

The reason I think it's really laggy is…
~Not because of the amount of clones.
~Not because of the amount of wait time.
The reason it's laggy is because (I think) of the sheer amount of broadcasting.
I'm fairly sure broadcasting is very lag-inducing, so you could fix the project by using, say, variables.
Hope this helps!

(If you're stuck, or want to see my version (less lag), clicky!

(EDIT: My project still has a few glitches, but it fixed the lag problem! )
(EDIT: And it lessened the script amount. I fixed all of the things I listed above, so don't quote me! )

clones are also laggy,you have ALOT of them…

Yeah, but in this project, there are only like 30 clones, and the clones don't hve that many scripts running in them. Its usually laggy with clones when there's like 200 clones running a ton of scripts simultaneously.
Anyways, i hope my remix helps!

OK, yes, I also noticed you've fallen for the ‘clone explosion on broadcast’ problem…

When creating clones you should be aware that all clones receive and act upon broadcasts. So if you have a receive broadcast that creates another clone, *all* of the existing clones will do that, not just the original sprite.

The way to deal with it is to have the sprite set a local variable (say “iamaclone”) to zero, and the first thing a clone does is set it to one (because local vars are also local to each clone meaning they can take independent values per clone), so you can always get a script (typically from a receiving broadcast) to check if it's being run within a clone or not.

I fell into this trap a couple of times myself…

However, I think you can probably rewrite your scripts so that broadcasts are not really necessary at all, so I'd suggest you have a go at that.

Anyway, I've remixed an example for you to look at - I think it might be along the lines of what you're after? (And I've included a slider so you can increase the spray scatter area). Plus comments to explain what it's doing.
However, I switched to using ‘stamp’ instead of clones, since it's considerably faster, and they don't have to be deleted (though maybe you have a reason for doing that…?)
You can switch back to clones using the “Clones” switch top-left.

Hope that helps!

DadOfMrLog wrote:

Anyway, I've remixed an example for you to look at - I think it might be along the lines of what you're after? (And I've included a slider so you can increase the spray scatter area). Plus comments to explain what it's doing.
However, I switched to using ‘stamp’ instead of clones, since it's considerably faster, and they don't have to be deleted (though maybe you have a reason for doing that…?)
You can switch back to clones using the “Clones” switch top-left.

Hope that helps!

Nice remix!

Thanks to everyone!

I'm glad I could help!