Sooooo there's a difference between a snap-block-generated list and the list typed manually... This bug exists for all types of costume reporters like "skew () to () degrees" or "() of costume ()". It's fine with the "switch to costume ()" though.
Also a problem with the "touching (color)?" block, the editor runs this block so slow that if you only have 2 clones running a forever loop with a "touching (color)?" block, you will already be lagging (running the following scripts).
The difference isn't actually a lust generated by snap and a list manually typed, it's actually the contents of the list.
It's not obvious, in fact snap tries to hide it, but what gets reported from the (numbers from (1) to (2) block are numbers, whereas when you manually type in the (list [] @<>) block are strings (text).
What the costume blocks do is, if the value is a number, it gets the costume at that index, but if it's a string, it tries to get a costume by name. This can be demonstrated easily.
I'm not saying this isn't a bug, in fact I do agree that this should be changed, I'm just explaining that it's not the lists.
It is well known that the <touching color [#000] ?> block is slow, but what intrigues me is that you specified "in the editor". Does it not lag in presentation mode (full screen) and on the project page?
ohhh there we go. So it's a string type if you type in manually... But I was convinced it's the number type using "is identical" (block coding is annoying when a variable could be any type). And no, it lags on both sides. Okay sounds like I need to figure a way of not using that block. Thanks for the reply
I'm pretty sure the touching color block is horribly inefficient no matter what, it's just the lag can be counteracted with a better computer. For example, I sometimes make games that run at an incredibly stable 60 fps for me, but when I have a friend try them on a different computer, it lags so badly that it's entirely unplayable.
is enabled.
