Scratch

Try splitting those parts of the script into their own little script, and use the [broadcast [ ] and wait] block to activated the script while the 'main' script waits for it. 

Of course, it won't be 1s1s then. Dx

Harakou wrote:

And by the way, I've noticed that you use the term "pointers." Have you used C or C++ before? 

------------------------------------------------------------------------------------------------------------------------

No, but I have read through portions of C++ programming books and a few others.
I own several books but haven't yet actually tried to code anything with them.
I'm quite sure that I can do any example in the books (while i'm reading it)
but I also know that making a nice game is no easy task. If I can make a few things
in Scratch, GameMaker, The Games Factory, Multimedia Fusion 2, Klik & Play,
Construct, and the other klik-interface programs that I find, and do well on
coding, design, and story aspects, then I'll finally feel ready to tackle some
of the "real" coding languages like C, C++, Java, etc.

I have messed around with some scripting programs though but only to make
macros for mmorpgs and to fight long boss battles as a rogue/assassin sorta
class that just stays hidden in a corner the whole time throwing daggers etc.

I look at it this way; If I'm not going to be able to code a game or an application
in it, then why learn it when there are easier things I could master first?  ...
I might one day get more into the technical aspect of things and play with code
conversions or something nearly impossible like that, but until then
this philosophy holds true.

------------------------------------------------------------------------------------------------------------------------

Aw, I wish I had been here to answer this! Outposted... by 2 people. Of course, I wasn't there 

The "broadcast" blocks do exactly what you want, and they can transfer between sprites. The "broadcast [] and wait" block will wait until all scripts started by the broadcast will finish, and then continue on, whereas the "broadcast []" block will not wait at all.

MabonBaladevaKain wrote:

Those will work, but I'm sort of curious about the efficiency.
Do the slowdowns have something to do with the amount of scripts used total
or is it only the flow of logic that matters (the scripts currently initiating code)?

I'm not sure I understand you here... Are you referring to the waits provided by the "broadcast [] and wait" block?

But you can completely forgo broadcasts by using what I call trigger variables. One script sets the variable A to 1 then waits until A = 2 or sits in an if a=2 loop. The other script/loop executes when A=1 and when it finishes, sets a = 2.

You could test Scratch for a million years and never figure out all the fast/slow options. For example, the Show block often gets used in such a way that it gets executed every loop. A solution would be to use a variable that gets reset every time the sprite is Shown or Hidden. But the very nature of using that variable may result in more slowdown than just repeating the Show block. Of course you can test such things but keep in mind, your results may be more or less correct as your project grows with more scripts and sprites.

Harakou wrote:

Locomule wrote:

But you can completely forgo broadcasts by using what I call trigger variables. One script sets the variable A to 1 then waits until A = 2 or sits in an if a=2 loop. The other script/loop executes when A=1 and when it finishes, sets a = 2.

Keep in mind, forever loops slow down Scratch more than broadcasting. If you want proof of that, try playing my game. Back when I made it, I used a ton of forever loops using trigger variables, essentially exactly like your suggestion. And as you can see, it is horrendously slow online as a result.

Yes, forever loops slow projects down more than any other block. Because by the end, you're having it check dozens of things, constantly, when it doesn't need to - essentially, you have about 20 scripts that you don't need running. Broadcasts makes only the scripts that you need to run, run, so... crisis averted!

Locomule wrote:

I didn't say anything about using a bunch of forever loops. I use one per sprite and all my triggering gets done inside that. I further minimize the effect by using as few sprites as possible, each with many costumes. And everything slows down projects, the question is whether it is still fast enough to run effectively or not.

Thanks for the tips though! I am definitely going to try not using any Forever loops. The reason I have always avoided broadcasts was because when I was new, people convinced me that they were disastrous to online project functionality. I sure didn't mean trigger variables were the best option, just an alternative. >=P

They do work better in some situations (such as projects where you want as few scripts as possible), they just have a tendency to slow projects down.