title is self explanatory I guess but why does this happen even though it hasn't been happening before?
Can you share some examples?
where are the blocks u made
they WERE in a script pic, but here we are again, so now I am redoing them AGAIN.
ok
send a script pic of inside the block. and you said you got the map working
Usually when people have trouble with smart script pics it's because they're trying to use a non-full-size version from the forum. Click on the picture and it'll open a full-size one, and down in the corner there'll be a Download button.
both rnt working
Images seem to be modified by some third party or not from genuine Snap!
Snap! created images have an XML Payload attached at the end of the file.
Those images have a payload at the front.
Sometimes a mobile carrier (or some browsers internally) forces image "optimization" to save bandwidth. This may be the case.
This script defines the modified primitive block.
If you drop this script into DEV the primitive becomes overridden but also an "Undefined" block is created. So it partially works.
More information is required: OS, browser name & version, exact scenario.
Also, the embedded XML is corrupted. Formal parameters do not match block definition and seem to be duplicated.
<block-definition s="> for each %'item' in %'data' %'action'" type="command" category="lists" selector="doForEach">
<header/>
<code/>
<translations/>
<inputs>
<input type="%upvar" readonly="true" irreplaceable="true">item</input>
<input type="%l" readonly="true"/>
<input type="%loop" readonly="true" irreplaceable="true"/>
<input type="%upvar" readonly="true" irreplaceable="true">item</input>
<input type="%s">
<options>§_getVarNamesDict</options>
</input>
<input type="%loop" readonly="true" irreplaceable="true"/>
</inputs>
If it's a modified primitive from the dev version, then due, it may not work correctly. Jens will fix exporting modified primitives without users reporting issues with it.
If it's an issue with the dev version, don't report issues with it (and if it's some issue that seems to go unnoticed for a long time (and isn't super obvious), report it on github, not here).
If it's an issue with the current stable release (snap 9), report it on the forum.
In fact, you shouldn't even be using the dev version for your projects anyway. It's in DEVELOPMENT, which means THINGS CHANGE ALL THE TIME, meaning THINGS WILL BREAK. I shouldn't be saying this, because it says all that in a big popup when you open the dev version.
OK.
To be removed
Are you talking to me??? 
Sorry, I just edited that part to say
And I put a line after the first paragraph (showing that it's for everyone, not you).
The entire post was not targeted at you specifically, I was just quoting you, and the forum automatically made me reply to you.
I'm not going to enable / allow automatic embedding of customized primitives in exported libraries, scripts or smart costumes. You can save them in your own project, and they will be restored when you load the project again (and you can share that project with others), but not in other shareable artifacts such as libraries or scripts (or script pics, for that matter). The reason is that I don't want you to lose control over your project and your Snap environment, just because you look at someone else's script pic. Nothing you merely import into your Snap is going to change how your standard blocks look or behave. You can, however, run some script that will change the standard blocks through metaprogramming.
All in all I'm both very excited about the kinds of extensions we can now do with this, and annoyed by the unwarrented excitement this gets in this forum. We're currently exploring a new embroidery TurtleStitch library, and we can finally merge many former forks of Snap "back" into the main Snap branch, this is great because it focuses on community instead of fragmenting us into small special interest groups. On the other side folks in this forum are way too much excited about abusing metaprogramming and extensions for infuriatingly stupid projects such as private chats and just outright awful ideas such as making "variables without variables" but stuffing literals into syntax elements.
This wouldn't be so bad if it weren't all the rage among a handful of full-time kids posting all the time about seemingly "advanced" concepts that aren't, but that reinforce all the misconceptions about the kinds of people that love programming. Namely that it's only for ... ah you get the idea.
For me that's always been the downside of forums. There's always been a general push against soial media and a push towards forums, but that's mostly being pushed by the kind of people who dominated that space and got drowned out in social pages.
Honestly, I would much rather the ability to "like" and "react" and comment on things, because it means I can provide my opinion without taking up space in the discussion if other voices have better information.
I'm a chronic lurker, always have been and always will be, but I'll pop in every now and again if I have an idea or a complaint.
The drag and drop idea is one of my favourite things that snap! does, but the way the forums restrict and limit it with that "this has been tainted by cross policy" error means that I'm seldom going to use it unless I absolutely adore the idea presented.
Exposing that feature more widely is one road that can be taken. I doubt it's the whole solution, but I do think it's atleast a path forward.
I also think one of the leading problems is that snap! is powerful but because it keeps getting compared to scratch, and you see endless complaints about how "snap! is slow" even though it isn't.
Thinking about this, I wonder if there needs to be a "welcome to snap!" guide that demonstrates key differences between the two and just what gets unlocked inside this language and the powerful features it has.
For example, the Griffpatch videos, and awesome as they are, there are all these little issues that crop up. Every time I attempt to cross port something like his rpg engine or first person game, there's an obstacle like how each language handles lists or something that mean that you'll get some of the way through, but there'll be bugs that pop up because snap! works differently behiind the scenes and doesn't explain it.
Which is why I keep wanting to port something written in c across instead, and one of the reasons why I think the drag and drop is very cool, but could very much be extended. I don't think c is better, I greatly despise most text languages, but because they still currently drive the computation world, they're an unavoidable obstacle. For now atleast. (Mind you, I think the push against block languages is the same as the push against social media)(It disrupts all those little insulated silos of "my language rocks, yours sucks rocks" and pulls the discussion wider and that makes a lot of people uncomfortable)
That makes perfect sense to me. But I'm not sure the same argument applies to libraries. For example, if I load a 3D drawing library, I expect the behavior of MOVE n STEPS to change. What's actually drawn, the projection onto the 2D screen of the 3D motion, will in general be shorter than n steps, as little as zero if the sprite is facing straight into the screen. Requiring me to run something in order for that change to the primitive to happen feels silly; the whole point of my loading the 3D library is that I want to draw in 3D.
I don't understand. What does the forum have to do with tainting, which I think applies only to vector pictures anyway?
I did not originally make this in the dev version. I have no idea why snap! thought that it was a modified primitive.
The amount of steps to acquire something from these forums for the drag and drop mechanism makes it unweildy and unusable. Which is annoying because it is one of my favourite features. Maybe a site outside of the discourse software that can act as a repo for script pics that means I can drag from there to snap! easier, making it easier to examine others code.
Anywhere! Google Drive. A folder on your desktop.