I made a sprite in my project where it will create a clone, have the clone follow another sprite's clone, say a string, and delete itself once the followed sprite is deleted.
This works flawlessly, regardless of how many clones I have, and stacking the custom block allows multiple text clones to follow a sprite. However once I replace the say block with costume from text / fancy text costume blocks, it just fails to create some clones if I start creating 10 or more clones. Hence the title "race condition".
Adding a delay to creating clones / between each custom block helps mitigate the issue, but the consistency was heavily affected by the device it was running on (I need to submit it for a group project), and its probably the method I'm using to assign each clone with values with script variables. I guess it's also the fact that snap's scheduler is intentionally made to run slower? Using turbo mode doesn't fix the issue either.
I do have another sprite like this that doesn't have forever loops, and as I was writing this I managed to completely fix the race condition issue for it. I could delete this but I feel like it's still worth posting.
However if I use a forever loop only the last clone can update its costume, same if I use script variables.
I made the project public on my profile
Did you click "Share" or "Publish"? I don't see it on your profile.
Oh, sorry, I wasn't thinking about the name of the project.
I'll look over it.
Well, it looks great! Glad you fixed the issue, but the initial problem is pretty weird.
I guess the fancy text extension might have a limit on morphs it will generate at a time.
I don't believe Snap!'s scheduler is intentionally slower. As far as I know, the only thing in Snap! that's meant to be slow is how many times per second variable reporters update on the stage.
The project may have been slow due to the amount of clones you might be creating and the fact that you're telling each one to run a script, I have a feeling that'll slow down a project a lot, but I could be wrong.
Do you mean when you put a tell (a new clone of [myself V]) to ({} @>) @:> script inside of a forever loop? I'm pretty sure a new clone of [myself V] only targets the most recent clone of a sprite. Sorry if I'm not correctly understanding.
I mean putting the "switch to costume" blocks in a loop.
I implied using the switch costume inside of the tell block, but if you're talking about this script...
...well, I have no clue what the issue is.
Ah, wait, you meant this, didn't you?
That's also what I meant.
No, the reporter creates a new clone and reports it. I wish it did what you said though
I tested it on my phone and it still seems like the problem is still there. I might just put an egregious delay on everything
Yeah, sorry.
Not quite at my best today.
I've found the solution. Just needed to tell a sprite to do something instead of broadcasting a bunch of variables.
