My browser / operating system: Windows NT 10.0, Chrome 114.0.0.0, No Flash versions detected



So after the recent update i have been experiencing a lot of instability with things i was used to working just not working anymore and it is so annoying.

The “bug” that has led me to create this thread is something that I've been using for a long time getting completely nerfed. It doesn't work anymore. If i have a public value and i want to create clones with that public value then i would add a repeat function and then maybe say (change (public x) by (10)) or something and then create that clone and in the clone (set (private x) to (public x)) so it saves the public x value for itself and that works completely fine! Here is the example:



And then if I didn't want to see it create every single one then I could use a custom block that would fix all of my issues and it usually would. Very powerful and easy to do but… Today i tried to do the same thing and i realised that now the custom block does everything inside itself but now it does it before the clone has time to (set (private x) to (public x)) which means instead of every clone being neatly lined up 10 moves away from each other every single clone clusters into the exact same ending place!



This must have something to do with my internet or something causing the code to be read differently or some other broken reason but this is really bad. And now comes the dealbreaker… It works using positions. Im instead of PUBLIC X using change x and then i (set (private x) to (x position)) instead then i set the clones x to 0 and then after that set the clones x to (private x) which works!!



What is this scratch lag code reading bug right here? I must be doing something wrong with my computer because scratch can't be this broken

It's not broken, this is exactly how Scratch works. With the custom block, this is the order the scripts execute, logged by an extension I cannot name:

As you can see, it clones first and then moves the clones to the current publicX. This is because the custom block will finish executing before it runs any other script. You can solve this by only using the local variable to assign positions:

This assigns the variable as it's cloned, not after all.

PhiPhenomenon wrote:

It's not broken, this is exactly how Scratch works. With the custom block, this is the order the scripts execute, logged by an extension I cannot name:

As you can see, it clones first and then moves the clones to the current publicX. This is because the custom block will finish executing before it runs any other script. You can solve this by only using the local variable to assign positions:

This assigns the variable as it's cloned, not after all.

Ok nice i can just swear ive used my method in previus updates and it worked!

Thanks you for clearing things up. This was mostly just for curiosity not a big issue i couldt work around