Yes, thank you @joecooldoo.
Gang, when something is in dev, it's because it's not finished! It's an experiment. The whole thing might be removed if it turns out to be way too slow. It may be completely redesigned. So it's really unhelpful for people to yell at us because it doesn't do everything you want. It doesn't (yet) do everything we want, either.
This is an adaptation of a piece of Smalltalk philosophy, namely, all of Smalltalk is implemented in Smalltalk itself. That's where Jens wants to get with Snap!. Right now, there are a lot of blocks implemented with that PRIMITIVE thing, but Jens has just begun work on what will be a big project! Over time, but before release, he'll try to get it down to maybe a dozen primitives. Or maybe zero primitives, but some lower-level primitives that aren't in the palette, e.g., I'm just making up this example, but the current primitive
SET var TO val might be implemented in terms of
SET var TO val IN ENVIRONMENT FRAME env, which would add or replace a binding in a particular frame. So the part of SET that searches the current environment to decide where to put a variable would be written in Snap!. (But then maybe in version 10.3 the creation and management of environment frames and environments would be implemented in Snap! too.)
TL;DR: This is a big deal; Jens is just beginning on it but is very excited about it; if you're excited too, don't rain on his parade.
FWIW: I’m very much in favor of Jens’ project as well! (this sounds like a , doesn’t it?)
One caveat: user-modified primitives, if not labeled as refactored, could cause confusion e.g. in forum posts.
 I should have said AFAIK no current library requires JS enabling for them to work
Update looks like this when I load the library
I'm thinking that you are loading an old project?
i wasnt trying to put you down, im happy we can edit them as well! its very cool but why not go all the way with it? so i was mainly giving a suggestion as to how it could be improoved to do what the goal of it seems to be
if the current system is kept (althought the way you worded this makes me think it def wont be) it would limit the editing of library blocks too much to the point i dont see a reason to even be able to edit them if they are only made up of a primitive definintion.
at the very least i think we should be able to place an if statement before the blcok
Thank you, Simon. It is an older - but not that old project. I made it half a year ago.
Do I now need to delete all the library blocks from the project and then load the library again?
i did find a preatty important bug and im not sure where to report it but uh
the touching block's dropdown is broken
In the past, we've been asked not to report any bugs on the dev version until it matures into a proper beta/release candidate
As Brian has said, the dev version is experimental.
It can be good fun to play with it, but things can changed/removed rapidly so don't bother the devs while they are developing
ah, thanks! thats why i didnt make a new post
Short answer - no - just reload the library
However, sometimes you can end up with two superficially similar versions of the same block and a bit of work is involved to resolve things - hopefully you'll have good luck
This is FAR from what I want. I was working on a tower defense game before and I wanted to set the center of the costume, not the entire sprite. Also, I tried to do that and it's the same for every clone, so I can't keep everything in one sprite. I know you could make a list that changes the rotation x and y every time but it's useless because whatever you do to one clone happens to all the other clones. I really tried. There is no way to do it the way I want to do it as Snap!'s predetermined centers are extremely inane. It apparently isn't even possible with JS.
in that case why dont you use "set my rotation xy" and a movement offset
Did you hear what I just said? In the tower defense game, I already tried making each tower set its own rotation position, but the "set my rotation xy" block does it for every clone of the sprite, so every other tower's rotation position gets changed when it wasn't supposed to. That is the problem I am facing. Maybe they could at least make the rotation xy different for every clone if you can't change the costume's center position, I have already thought of how to work around that. I am aware that it might take time to add features like this.
Actually, I was going to make a project to show you what was wrong but while making it I realized you have to add something to the center x, not set it to 5 or something, but it still doesn't go for each clone.
This seems able to set rotation x of each clone independently
how would you make it automatically open the window for you?