michael971 wrote:

Can I rename a Sprite in SNAP

Sure, the text box at the top of the scripting area is editable. Just click in it.

It appears the search function is screwed up on this website. I have engaged my Google-fu, to make this thread searchable:

Do a Google search for the keyword plus site:scratch.mit.edu/discuss/topic/4455

For example all results for the word “clone” in this dense Snap threadmess:

https://www.google.com/search?q=site%3Ascratch.mit.edu%2Fdiscuss%2Ftopic%2F4455+clone

Is there some sort of speed limit on how fast child sprite entities can be produced?

I am trying to make a fast side-scroller game and it is taking a ridiculously long time to draw the sprite-tiles that make up the world.

This is bad, as I need to be able to place a strip of 16 new tiles/sprites probably up to 1/30th of a second as the world scrolls left or right when the player is moving.

Enclosing the slow tile-placer code blocks with Warp does not help, and instead warp seems to break the placement of the tiles and they don't appear at all..

The tile cloner/placer:
http://i.imgur.com/iKghbbh.png

Project window…. “Super Snappy World”
http://i.imgur.com/gxzoJSF.png

Dale_Mahalko wrote:

Is there some sort of speed limit on how fast child sprite entities can be produced?

No, there's no artificial slowdown.

One thing I noticed in your code is that you copy the variable Clone ID to a different variable, L_Clone.ID, when a clone is created. If you make Clone ID a sprite-local variable, then each clone you create will automatically get its own local Clone ID, so you don't have to copy it into a different variable. I'm guessing that the reason the display gets confused when you WARP the clone creation is that the global Clone ID has already changed for another clone creation before the previous clone gets to run.

Another thing you could try is to turn on turbo mode. (There's a block in Sensing to turn it on and off.) That will give running code priority over stage redisplay, so several clones will be created in each display cycle, while still letting each new clone run before the next clone is created.

P.S. If you click the left arrowhead ◄ on the LIST block at the top of the clone creation code it'll get rid of that input slot, which creates an empty list item that I'm guessing you don't really want.

P.P.S. Next time, if you share the project and include the shared URL in your message, we can actually try out ideas to improve it, instead of guessing.

Hey, gang!

Please try out the beta 4.1 release! We'd like to try it out among friends before we make it official. It's at

http://snap.berkeley.edu/snapsource/dev/snap.html

The big change is sprite OOP with inheritance. If you don't remember how it worked in BYOB 3.1, you can read the chapter on sprite OOP in the old BYOB manual. It's a little different in Snap! 4.1, but you'll figure it out. There are also a bazillion little improvements, including bug fixes. If you find a bug, please report it on Github and be sure to specify that it's a 4.1 beta bug.

It'd be great if everyone always runs the dev version over the next month. Thanks!

Wow! This is really cool! I can't say that I know exactly how to utilize it, but I'm still thrilled that these new features exist.

For some reason there is no way to easily tell a local variable from a regular global variable. Why do this?

And the way that variables are “all Local to a sprite” but not “individually Local to the script” is exceptionally weird. So I can have multiple scripts within a single sprite which all share the same so-called local variables? Um, no, this is not how it is done in the real world. You are teaching an invalid concept that is not used anywhere else and violates what the concept of “Local” is supposed to mean that every other language with locals uses. Why are we teaching students a wrong concept that will get them into trouble if they try to apply it anywhere else?

To get around all this and keep myself from getting confused, it appears I need to include the name of the script and whether the variable is local or global in the name.
L.RefreshScreen.MapX

Though even this is not exactly helpful because the list of variables is not sorted or apparently sortable.

Dale_Mahalko wrote:

So I can have multiple scripts within a single sprite which all share the same so-called local variables?

I believe what you're looking for are “script variables”, which can be created using the appropriate block in the variables section.

Dale_Mahalko wrote:

For some reason there is no way to easily tell a local variable from a regular global variable. Why do this?

It's a good idea to give a visible indication that a variable is sprite-local. It's on our list, probably soon since we're revisiting variables anyway for OOP.

Officially they're not called “local”; they're called “for this sprite only.” But that's too many syllables (or keystrokes) for use in conversation. I guess in the OOP world they're called “fields,” although a search for “object local variables” gets plenty of hits. I prefer to reserve “fields” for the pieces of a record in a database. I've used “instance variables” when teaching a class/instance OOP language. But, really, they are local; creating an object creates an environment frame just as calling a procedure does.

Languages in the Logo family, including Scratch and Snap!, take the position that we're not in the business of training professional computer programmers. Our mission is to bring programming to the masses. This has historically led to all sorts of informal language: “reporter” instead of “function” (whose CS usage is technically incorrect anyway, to a mathematician), “input” instead of “argument,” and so on. Technical jargon is valuable for specialists, but is also a barrier to entry for non-experts.

Well if you want to view my uncommented experiment in progress, here you go.

I fully accept that the following is a mess. Everything is in flux and can change at moment's notice. I have used Scratch in the past, and I don't yet know all the new blocks added in Snap! so this will keep changing.

http://snap.berkeley.edu/snapsource/dev/snap.html#present:Username=lhs-dmahalko&ProjectName=Super%20Snappy%20World%20v.0.4.1

World data is stored as monospaced ASCII art in long rows of text in the stage, then converted into a 2D array. It's unclear if the 2D array is any faster or slower than reading single characters from a long line of text in a 1D array.

The block data looks unreadable because list data is not monospaced. (Is there a way to set a monospace font for list data?)

I see the project is able to save data statically between runs, but I'd rather re-initialize all stored data constants with each run. Eventually all variables will likely be renamed L. -local G. -global C. -constant

Copy and paste the following into Windows Notepad
Original display area is 24 wide by 16 tall

Original display area is 24 wide by 16 tall

Screen:A| Screen:B|
1 2 3 4
123456789012345678901234567890123456789012345678
01,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
02,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
03,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
04,,,,,,,,,,,,,,,,,,,NOP,,,,,,,,,,,,,,NOOP,,,,,,,,
05,,,,,,,,,,,,,,,,,,,TUV,,,,,NOOOP,,,,TUUV,,,,,,,,
06,,,,,,,,,,,,,,,,,,,,,,,,,,,TUUUV,,,,,,,,,,,,,,,,
07,,,,,,,,,,,,,,,,,,,,,,C,,,,,,,,,,,,,,,,,,,,,,,,,
08,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
09,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
10,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
11,,,,,,,,,,,,,,,,C,,,XMXCX,,,,,,,,,,,,,,,,,,,,,,,
12,,_,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,{},,,,,,,,
13,/H\,,,,,,,,,,,,,_,,,,,,,,,,{},,,,,,,,,,,,,,,,
14/HhH\,,,,,,dBBBb/H\,,,,dBb,,,,,,,,,,,,,,,,,,
15################################################
16################################################

(EDIT: My periods are being converted to ellipses.. by the website? using commas here)

Mapping data source:
http://www.mariouniverse.com/images/maps/nes/smb/1-1.png

I cleaned it up a little:

http://snap.berkeley.edu/snapsource/dev/snap.html#present:Username=bh&ProjectName=Super%20Snappy%20World%20v.0.4.1

It's still needlessly copying x-y values from global to sprite-local variables. I cleaned up the creation of the array of sprite type letters, although I'm thinking the actual play of the game will be faster if you do the conversion from type letters to actual sprites during the setup, so you'll have an array of sprites instead of an array of letters. (I did turn the list of eight sprite names into a list of sprites.)

Um, heh, I'm not really expecting the author of the language to help fix up my noobishness. I need to read the manual on some of whatever you did there. “map() over()” … ???

The sprites contain an “am I cloned” check because all of them get the message to do stuff, and the uncloned original has no data so I get weird “undefined list” errors coming from the original.

I don't know yet what you refer to about duplicate local clone data. The plan is to scroll the world as expected. The clones need to know how to move together as a group, and all follow map.offset.

,

Having a few hundred sprite tiles on screen is not likely to be very fast. I'm sure it would be tons faster if I could just use the static sprites as stamps onto the background, and then move the background around, except the stage has nothing in the motion section. I don't know if it is possible to stamp patterns onto layers of sprites for “fake depth” multiplane / parallax scrolling.

I can see some ways to “cheat” graphically and make the scrolling faster. Big bitmaps are probably faster than tiny patterned sprites. The ground is nearly always solid so make a huge solid ground sprite, 2x as wide as the screen. When a hole is needed, place blue “hole” sprites over it.

Also the clouds, hills, pipes, and grass should probably be large single sprites rather than tiled pieces… that would cut the sprite count considerably.

Yay! Is the INHERIT block the same as DELETE?

Jonathan50 wrote:

Yay! Is the INHERIT block the same as DELETE?

Yes.

Dale_Mahalko wrote:

I need to read the manual on some of whatever you did there. “map() over()” … ???

Yeah, good idea! It says, call this reporter for each item of the list, and collect the results in a list. In this case, it says “find the sprite named ___” for each name in your list of sprite names, so you end up with a list of sprites. Then when you want to clone one, we don't have to search for the one you want.

I don't know yet what you refer to about duplicate local clone data.

You say “L.Clone.MapX prend la valeur Clone.X.New” but you could just make Clone.X a sprite-local variable and when you make a clone it'll get a copy of the parent's value automatically.

(By the way, do you know if there's some reason the translation isn't “donner à ( ) la valeur ( )”? All the other ones seem to be infinitives.)

Having a few hundred sprite tiles on screen is not likely to be very fast.

No, Jens has demo projects with 1000 clones. That's not the problem.

But I'd be tempted to try it this way: Have one tile sprite with eight costumes, each named with the single letter that you use in the array that represents the world. Fill the stage with clones of it. Then you can say

to redraw the world, shifted as desired.

bharvey wrote:

Yes.

Ok, thanks. Does “Release” in the right-click menu of a clone mean to turn it into a Scratch 2.0-like clone?

Jonathan50 wrote:

Does “Release” in the right-click menu of a clone mean to turn it into a Scratch 2.0-like clone?

Well, not exactly. It's still attached to its parent and can share data and attributes with its parent. But we have two kinds of clone, neither exactly like Scratch because their “clones” are just copies. The two kinds are permanent and temporary. Temporary ones aren't in the sprite corral (although I'm hoping that will sort of change, so you'll be able to find them by clicking something, not yet designed) and die when you hit the stop button. Permanent ones are in the sprite corral and don't disappear on stop. (I'm not sure having them in the sprite corral is the right choice. I think they should be hidden but findable, just like temporaries.) “Release” turns a permanent clone into a temporary one. Temporary ones are more like Scratch ones, but they still share with their parents.

Hi,

I am new to Snap! and I am investigating to use it for teaching very focussed programming lessons. To do this we planned to have a version of Snap without any blocks, and then by using custom block libraries, show the blocks we need, so that a learner would say only have access to 5 blocks, which would be enough to solve the lesson they are working.

I was looking at the source code today and figured out how to hide blocks by commenting them out (in the objects.js) and I was wondering if there was a way to export (all or a subset) of the basic blocks into libraries, such that, we can hide ALL blocks and then create libraries of subsets of the basic blocks, to be imported when the project is loaded up?

After a Learner has done one of these lessons, would love to be able to share their creation, without loading the whole editor, is that possible? Is there a viewer that we can just push the XML to, and it runs? Any pointers to examples of this would be appreciated.

Which Version would you suggest is the most production friendly? 4.0? or is the 4.1 Beta sufficiently stable?

Regards

Mark

dev_in_spain wrote:

To do this we planned to have a version of Snap without any blocks, and then by using custom block libraries, show the blocks we need, so that a learner would say only have access to 5 blocks, which would be enough to solve the lesson they are working.

Hi, welcome!

We have ways to do more or less what you want, without any need to modify the Snap! source code. But you may not be satisfied with our solution because it's possible (by design!) for students to “escape” into the full Snap! environment.

To hide primitives, right-click (control-click, however your computer does secondary click) on the grey background of the palette (the area at the left where the available blocks are listed) and choose “hide primitives.” (You have to do this in each of the eight palettes.) Alternatively, you can hide primitives one by one, by right-clicking on a particular block in the palette and choosing “hide.” When you save a project, the hidden status is saved with it, so when students load the project they will see the reduced palette you've set up.

But of course a student can right-click on the palette and choose “show primitives.” Our idea is that students understand that games have rules, and that a reduced-palette project is a game, in which they are to solve a puzzle under constraints. And we really hate the idea of limiting students' being in control of their tools.

As for sharing projects, by default when someone opens a shared project it starts in presentation mode, in which only the stage (at double size) is visible. We haven't implemented a separate viewer because it wouldn't really be able to eliminate much of the Snap! code; in order to interpret scripts and run animations, you need the scheduler, the interpreter, the Morphic widget manager, etc. You can add “&hideControls” to the URL of the shared project to hide the buttons above the stage, making it harder to get out of presentation mode, but of course this isn't a real security feature because someone who wants to read the code can just load the project and delete that part of the URL.

One thing you should know is that if you run your own copy of Snap! it will be unable to save projects to our cloud storage back end, which accepts connections only from snap.berkeley.edu and our official mirror sites. This restriction isn't because we want to discourage people modifying the code; there are several fantastic Snap! mods that we love, but they run their own back ends. We just don't want people to use our online storage for things other than Snap! projects.

I hope this helps.

How do I access the cloud storage for my account to delete or rename projects?

Is there a way for a teacher to access the cloud storage of their students?

Apparently naming a project is one-shot and if someone saves a project named “fred-is-a-doody-head” there does not seem to be a way to delete it via the Snap File menu.