Also, i mean screenshot the stage only.

My cousin says that to programmer user too. (Not exactly, he just used a lot of code for just adding an external script.)

Your cousin?


[scratchblocks] (my [other sprites v] :: sensing) [/scratchblocks] in the Stage reports all of the sprites in their layer order.

lol...not me, I barely know JS.

one time I tried pasting a thin line onto the stage, and it didn't turn out right. I agree with using a javascript way to make it way better quality.

Why would you want to use JS at all? It's way easier to do that in Snap!, and way more elegant!

Make a new sprite, make a fully opaque costume for that sprite that covers the entire stage. Place it at 0,0. Then run this:

Digger script pic

Ok. Ill try that

Not that fast dear friends :wink:
"paste on" ignores graphics effects (this time mosaic).
untitled script pic (5)
But stamping misses the background... so extra step (and Sprite4StageBack helper).
untitled script pic (6)
Scripts are on the Stage : https://snap.berkeley.edu/snap/snap.html#present:Username=dardoro&ProjectName=screenshot

I have one request. Can you make it act as if nothing happened? Like add the original pentrails to clear and put them back.

Also, for out-of-stage use. Add [tell stage to to (that)

One more thing......

Make it include the pentrials in the costume.

Ill do it too.

I made this "dead simple" procedure to maintain, store, and restore objects state just to get a screenshot of Snap! stage. But the watchers are still not possible.
screenshot script pic (6)
Talking to the truth, I'm feeling like a fool. I've found that there is a ready-made block available in dev mode.
screenshot script pic (5)
It's not made with blocks, just 2 lines of JS, surprisingly isn't it?
Test project https://snap.berkeley.edu/snap/snap.html#present:Username=dardoro&ProjectName=screenshot

Not so surprising, considering that the code to do that is already in the GUI. The only reason the block is hidden is that @Jens believes in Eisenberg's Law only for himself, not for the actual users. :~(

So that was quite useful hints ....

... whereas @bh believes that there should be a primitive block in Snap's palette for every function in the implementation code, and deeply nested dropdown menus for every parameter.
Do y'all really want or need a "screenshotting" primitive? What for?

So it's usual routine to build in some random, useless blocks for Snap, just because of having too much free time :wink:

We dont need a screenshotting primitive(why nog we make that primitive? Except, it is not a primitive.) not everyone will use it often.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.