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.
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
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.
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.
, doesn’t it?)
