Scratch

Page 104!!!

A concept I got for making programing a bit faster. https://sites.google.com/site/byobimage … letteblock
Its a variable palette that gives you a faster reference then browsing thru the blocks list.
(If you guys prefer I can continue to post blocks in this way instead of putting them directly in the forum.)

I accidentally put 'kill threads' in <(kill threads) contains> it should be 'kill name'

Last edited by 14God (2011-02-02 14:37:17)

Suggestion: (attribute [parts] of [Stage]) returns a list of all sprites.

scimonster wrote:

Suggestion for BYOB 3.1: Like the Default value next to the single input in the block editor variable creator, have Default amount or the multiple inputs.

So, you mean, every time you click the right arrow you get a pre-filled-in new input slot?  Interesting.  What I've been agitating for in that position is a place to specify a default number of input slots, for things like my JOIN WORDS block, which takes any number of inputs but should have 2 by default because it doesn't make much sense for just one word.

Like all feature requests unrelated to first class sprites and cloning, this is unlikely to get into 3.1, but maybe later.

You can enter feature requests at http://byobugs.com by choosing "enhancement" from the "severity" dropdown menu, by the way.

rubiks_cube_guy238 wrote:

Suggestion: (attribute [parts] of [Stage]) returns a list of all sprites.

Hmm, interesting.  We certainly need a way to get a list of all the sprites.  I was thinking we'd have to provide an ALL SPRITES block; your way reduces the block footprint, but tinkerers who don't read the manual might never find it!

EDIT:  Jens wants to solve this problem by adding an ALL SPRITES choice to the OBJECT block's pulldown.

Last edited by bharvey (2011-02-02 16:11:30)

14God wrote:

Its just a concept for any block that passes out variables or reporters so you don't have to go to the panel on the left to get them. Still kinda a half baked idea.

Oh now I get it!

I'm a little surprised that you can use the upvars outside the scope of the block that creates them.  I didn't know BYOB could do that. 

I was confused before because the code mostly seemed to be about killing something and I discounted the use of the upvars.
I don't know if I like the FOREVER part, though; it'll slow down other computations.

bharvey wrote:

14God wrote:

Its just a concept for any block that passes out variables or reporters so you don't have to go to the panel on the left to get them. Still kinda a half baked idea.

Oh now I get it!

I'm a little surprised that you can use the upvars outside the scope of the block that creates them.  I didn't know BYOB could do that. 

... (ahem) being able to use upvars outside the scope of their home context is a - let's call it - side effect, that you shouldn't make your project rely on. It's sometimes hard to explicitly kill stuff in Smalltalk 

Last edited by Jens (2011-02-03 03:02:41)

scimonster wrote:

bharvey wrote:

scimonster wrote:

Suggestion for BYOB 3.1: Like the Default value next to the single input in the block editor variable creator, have Default amount or the multiple inputs.

So, you mean, every time you click the right arrow you get a pre-filled-in new input slot?  Interesting.  What I've been agitating for in that position is a place to specify a default number of input slots, for things like my JOIN WORDS block, which takes any number of inputs but should have 2 by default because it doesn't make much sense for just one word.

Like all feature requests unrelated to first class sprites and cloning, this is unlikely to get into 3.1, but maybe later.

You can enter feature requests at http://byobugs.com by choosing "enhancement" from the "severity" dropdown menu, by the way.

No, that's what I meant. Default amount of inputs.

Actually, both would be really cool, but the link doesn't work.

xly wrote:

At this stage I see 3 levels of sprite hierarchy : 1 - master for control and coordination of the whole project 2 - one prototype per group (or family) 3 - as many "lambda" copies (or children) as needed. All this stuff is linked by broadcast + semi-persistent variables.

I'll look at it this evening, but meanwhile, the above may well describe your style of work, but other people will work differently.  A project doesn't have to have a master sprite, and there can be children of one sprite who are themselves parents of other sprites.  The classic example is the project with elephants, a few of whom are pink elephants.

http://byobugs.com was apparently down the last couple of days, but now it's online again. Can you check again? Thanks!

edit: you might have to empty your browser cache or shift-click on the reload button in Firefox for force it to re-read the previously unreachable page.

Last edited by Jens (2011-02-03 11:40:19)

So... I've got a bit of a coding problem that may or may not be solvable through the new experimental features.

Recently I came back to A* path-finding in Scratch. A couple years ago I tried to make an AI pathfinder, but my first attempt didn't work so well. This time however, I've had more success. My only problem now involves parents and children. Once my AI has reached its goal, it is supposed to follow the parent of each tile back to the original square to find the shortest path. I can't find a practical way to do this, and I've been avoiding BYOB since with it I won't be able to upload my results to the Scratch website. How do you recommend I go about having a parent-child list system?

An exciting (well, to me, at least!) new experimental version.

Jens wrote:

This version introduces a whole new interface for dealing with objects. Most of it is internal and only half done, but you can already get an idea of where this might be going to (remember, we're still pre-alpha with this):

    - the new blocks have been moved into the "Operators" category and renamed
    - GET, SET TO, and DELETE have been generalized

You'll be able to query the value of any attribute with the universal GET block. The drop-down currently shows a list of almost all built-in attributes. Additionally you can drop a lambdafied (!) built-in reporter block into the argument slot and get the value of the attribute which it refers to. The beauty of this is, that you can also use the new ATTRIBUTE OF block to query arbitrary attributes of other sprites using the sender's blocks.

The same works for the new universal SET TO block, and even for the DELETE block. Deleting a sprite's built-in attribute (by deleting its system getter block) causes that particular attribute to be inherited from its prototype. You can try this currently for xPos, yPos and heading.

This is all very fresh and half-baked. Eventually this will also work with variables and custom blocks. There's still a lot to do, e.g. visual propagation of inherited attributes from prototoype to children (for parts it should work already), supporting all attributes etc. etc.

I had to enhance the file format to make the inheritance state of individual attributes persistent. You can still open any Scratch project and projects up to the current official release (3.0.8), but not projects saved with previous experimental versions. Don't worry, the final version will be fully backwards compatible, but it, too will not support every project made by an internal experimental release.

Enjoy!
--Jens

fullmoon wrote:

Is this how the new get block is supposed to be used to query attributes of other sprites?

Yeah, but you can say THE [GET <PEN SIZE>] BLOCK instead of THE SCRIPT [REPORT ...].  As Jens keeps reminding me, the former is an abbreviation for the latter. 

Do you like it?  When this design is totally implemented it's going to be so cool!  For example you'll be able to have class variables by having the clones say

RUN [[THE SCRIPT [SET <foo> TO <bar>]] OF [OBJECT <PARENT>]]

(whereas just SETting it in the clone would make a private copy).