I don't understand why you think it shouldn't work the way it is now. I know you explained it to me, but still I don't understand.
Yes @kinestheticlearning, as Brian said, the right map will be like
with these explicit "0"s ("0,0,0,(255-transparency)"). Now, your maps is writing a list (the four values of each pixel) inside those R, G and B slots.
The matter is (was strange to Brian and also to me) that the "switch to costume" block arrange this error, because this block puts "0" where there are "strange" values, as those lists.
Joan
Thanks @jguille2 for clarifying what Brian was saying. With the "0"s, in combination with the (for me, at least) unknown fact... (since visually everything has worked out okay) ...which you discovered, that the "Switch to costume" block actually 'took care' of any RGBA list by putting a "0" instead, I now understand.
To make the solution by you two a bit more elegant, a new (as explained here) block of a Reporter type is needed.
not really important
See it in project Media_Map_with_JS_block {the link will open it in editMode & noRun} within my "Output" sprite there you can see the custom block I made; it works, again, just fine, however it reports an error and I'd appreciate explanation for it. (I have tested the custom block on its own and it works just fine, so why it reports an error?)
EDIT: maybe this thread/topic should be split
For large lists, would it be faster to do something like this?
That way, the program would not have to go through the entire list.
What you said is pure gold.
Thank you so much!
EDIT: I don't know - so I will ask you - does not the "KEEP ITEMS FROM <>" need to go through the entire list?
Because it's being given a bad input. My guess is that the variable R,G,B,A has no value.
Yes. There's a new primitive block FIND FIRST that does what you want.
Yes, I just noticed that it does. However, I'm guessing the simple < true > block for each item evaluates faster than an if-then-else statement.
It really is that much faster? Wow.