Glide block problems

LeadToGold

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

I have two clones. In response to an event the clone checks to see if it is the one to move and uses to move.
If the event is sent again (say for a different clone) the glide stops.

I would like the glide to continue even if the event is sent again.
Is that possible?

ltg

LeadToGold

I have added some code in the original project that solves the problem.

Scratch does seem to pay attention to threads you run messages on and suspends activity when the message is passed again. So what I'm doing now is when the glide is called for I create a clone and run the glide on that clone (deleting the original). It seems that spawns a new thread.

ltg

deck26

If you use a broadcast each clone will run the receiver script. If it was already running it will restart and if you check if it's the right clone then it's too late if the receiver is what does the glide. However if you use an if block to check if it's the right clone and use a custom block to do the glide you can ensure only the correct clone responds.

That may be what you've done.

LeadToGold

deck26 wrote:
If you use a broadcast each clone will run the receiver script. If it was already running it will restart and if you check if it's the right clone then it's too late if the receiver is what does the glide. However if you use an if block to check if it's the right clone and use a custom block to do the glide you can ensure only the correct clone responds.

That may be what you've done.

I tried that first but even in the custom block the glide will stop. My solution was to create a clone and delete the current one. On create the clone does the glide.

deck26

LeadToGold wrote:
deck26 wrote:
If you use a broadcast each clone will run the receiver script. If it was already running it will restart and if you check if it's the right clone then it's too late if the receiver is what does the glide. However if you use an if block to check if it's the right clone and use a custom block to do the glide you can ensure only the correct clone responds.

That may be what you've done.

I tried that first but even in the custom block the glide will stop. My solution was to create a clone and delete the current one. On create the clone does the glide.

You do seem to be right which surprised me. I'm sure I've done something like that before so either it depends on what the custom block does or something has changed (or my memory is false!).

I did get it to work by giving each clone a target position. In a forever loop if the current position doesn't match the target it starts a glide. The receiver to get one clone to move then looks at the clone ID and resets the target position for the clone.

DadOfMrLog

Calling a custom block's define script doesn't start a new ‘thread’, it's still running in the original thread that did the calling. (Just consider that the calling block is within the calling script, and ignore the define script.)

Yes, a broadcast receiver's thread gets terminated and restarted if was still running when the broadcast is sent again.

Other event hat blocks which behave like this are “this sprite/stage clicked” and “when backdrop switches”. (I guess you could also say the “when GF clicked” scripts restart when its event happens again, obviously…)

However, a “when key pressed” script does not restart if still running (which I suspect is mainly due to the difficulties that would arise since it gets fired by key-repeat events, not only key-down). Also “when timer/loudness” does not restart.

I wouldn't generally recommend recreating a clone – creating a clone is quite intensive for Scratch to do, so you'll experience lag if the project starts creating numerous clones frequently. It's more efficient to create the clones you need at/near the start, and re-use them as needed, if you can.

I think the alternative solution is basically as deck26 said above – some kind of ‘flag’ (local variable) which gets changed, and a loop in the clone which is continually checking it if not already in the middle of a glide.

Last edited by DadOfMrLog (Sept. 29, 2016 10:02:42)

deck26

I see now why my original idea didn't work. If clone 1 is started the script that called the custom block is still running, waiting for the custom block to complete. By restarting the broadcast receiver the old copy of the script is cancelled which also stops the custom block that was running.

asivi

LeadToGold wrote:
https://scratch.mit.edu/projects/123244360/

I have two clones. In response to an event the clone checks to see if it is the one to move and uses to move.
If the event is sent again (say for a different clone) the glide stops.

I would like the glide to continue even if the event is sent again.
Is that possible?

ltg

Yes, it is posible
https://scratch.mit.edu/projects/123299799

LeadToGold

DadOfMrLog wrote:
I wouldn't generally recommend recreating a clone – creating a clone is quite intensive for Scratch to do, so you'll experience lag if the project starts creating numerous clones frequently. It's more efficient to create the clones you need at/near the start, and re-use them as needed, if you can.

I think the alternative solution is basically as deck26 said above – some kind of ‘flag’ (local variable) which gets changed, and a loop in the clone which is continually checking it if not already in the middle of a glide.

The program where I noticed this problem FreeCell doesn't create a lot of clones when this happens. So absent a performance problem I think the code looks cleaner than if I added another variable/loop. And

Is the cost of clone creation dependent on the code size/costume count/script count?

Thanks for your reply. I'm a big fan of your work.

LeadToGold

deck26 wrote:
I did get it to work by giving each clone a target position. In a forever loop if the current position doesn't match the target it starts a glide. The receiver to get one clone to move then looks at the clone ID and resets the target position for the clone.

You also have to adjust the glide timing.

deck26

LeadToGold wrote:
deck26 wrote:
I did get it to work by giving each clone a target position. In a forever loop if the current position doesn't match the target it starts a glide. The receiver to get one clone to move then looks at the clone ID and resets the target position for the clone.

You also have to adjust the glide timing.

Depends what you want, you hadn't specified anything about when any glide should finish in relation to another. I can only answer a question based on the information I've been given

LeadToGold

deck26 wrote:
LeadToGold wrote:
deck26 wrote:
I did get it to work by giving each clone a target position. In a forever loop if the current position doesn't match the target it starts a glide. The receiver to get one clone to move then looks at the clone ID and resets the target position for the clone.

You also have to adjust the glide timing.
Depends what you want, you hadn't specified anything about when any glide should finish in relation to another. I can only answer a question based on the information I've been given

Discuss Scratch