Scratch

14God wrote:

Let me clarify, the name was meant to be 'one for God' It wasn't me calling myself God    My Sister thought that would be confusing & I guess I shoulda believed her 

No, I got it -- my point wasn't that you're claiming to be a god (age 14, I suppose that would be    ), but rather that the claim you are making (being godly, I guess you could say) is no more supported by evidence than EvilGenius's claim to be evil.

And the meta-point is that I don't want to be in the business of making such decisions.  They're doing something along those lines at the Scratch wiki; not everyone gets to have an account there, and it takes a fair amount of effort and grief for the people running it.

[/offtopic]

I like your project, but it's even better, imho, if you unclick the atomic checkbox in the lightning block.

@ bharvey, Jens and other byobers...

The following link is for a project using the new experimental Byob features to build a large background map/battlefield typical of applications like strategy/war/adventure/rpg games. The result is impressive, thanks to the genial parents of Byob !

http://www.xleroy.net/ByobTuto/New/Thumbnails.html

@ xly I liked your scrolling map so much I decided to remix it a bit by adding mouse scrolling.

Last edited by 14God (2011-02-12 14:32:46)

14God wrote:

Oops, I didn't believe that circular inheritance would do anything wrong so I tried it and instantly BYOB froze and slowed down my whole computer and it shot up to using almost 200mb of RAM

Sounds like a bug!  I won't try to reproduce it; when BYOB does stuff like that it overheats my computer, which shuts itself down! 

Of course it shouldn't let you set up a circular inheritance.

14God wrote:

I actually did it with the set block which apparently allows you to set a parent mid execution.

Thanks for the detail, which will help debugging.  But it still shouldn't let you! 

EDIT: Let you make it circular, I mean.  It should let you change parents in some benign way.

Last edited by bharvey (2011-02-12 16:58:35)

Pecola1 wrote:

Did you b any chance get that from a suggestion website which tells what should be in the next BYOB? LOL I entered it if you did.

Well, several people have suggested it in several fora.  Once you set your mind to user-defined hat blocks it's the obvious way to do it.

I would love to see the assignment operator become a reporter in BYOB; this allows chaining of assignments, i.e. [set foo to (set bar to 0)], and assignments in conditions, i.e. [if (set i to (index of (a) in (list)))]
    [replace item (i) of (list) with (bar)]
[else]
    [throw (Can't find item!)]

(throw would be nice too :P)

Last edited by nXIII (2011-02-13 11:57:08)

bharvey wrote:

But since it's now official that they're never going to move in the direction of first class data, I'm open to discussion of this point as we start on 4.0 (in April).  (I mean, we can start discussing now, but nothing's going to happen as a result of the discussion until April.    )

That's too bad.

bharvey wrote:

nXIII wrote:

I would love to see the assignment operator become a reporter in BYOB

I think we could do that only if we abolished the distinction between commands and reporters altogether, or at least allowed a hybrid block type (an oval with attachment tabs!).  That would settle the argument about whether CLONE should report a value, too.

Up to now we've tried really hard to be backward compatible with Scratch, and not to do anything that would confuse a Scratch user coming to BYOB.  Changing the appearance of the SET block would, I think, be a huge break with that goal.

But since it's now official that they're never going to move in the direction of first class data, I'm open to discussion of this point as we start on 4.0 (in April).  (I mean, we can start discussing now, but nothing's going to happen as a result of the discussion until April.    )

Yep. It makes sense to allow users to ignore the return value of a function (such as CALLing a command) rather than provide them with two blocks that (should) do the same thing but have a different shape.

I would suggest that command blocks could have a subtly outlined oval shape on them when they have a return value. When they are dragged over an argument slot, the command-shape disappears and only the oval remains, indicating that the block will be inserted as a reporter. When they are dragged over a command slot, the oval will disappear and will remain hidden when the block is dropped there.

Some other blocks which I think should have return values:
- [delete (1) of (list)], [add (thing) to (list)], [insert (thing) at (1) of (list)], [replace item (1) of (list) with (thing)]: should return the value of the deleted/replaced/added item
- [set (var) to ()], [change (var) by (1)], [set (attribute) to ()], [change (attribute) by ()]: should return the new value
- [delete (object)]: should return the deleted object
- [go to front], [go back (1) layers]: should return the new layer
- [next costume], [switch to costume ()]: should return the costume number
- [turn () degrees], [point in direction ()], [point towards], [if on edge, bounce]: should return the new heading
- [go to x: () y: ()], [go to ()], [glide (1) secs to x: () y: ()]: should return something, but I don't know what

Last edited by nXIII (2011-02-13 13:39:52)

scimonster wrote:

Code:

change position by (num)
go to (map (the (()+(*num*)) block) over (position) <>)

Sweet!  Isn't it great how MAP lets you do arithmetic directly on vectors instead of thinking element by element?

Agreed, mostly. I still don't know anything about the experimental versions, except that BYOB is getting cloning.

nXIII wrote:

I only say this because in my opinion the replaced value is the more useful of the two, like when you [delete] an item or splice() an array.

Okay, then why isn't the old value of a SET variable more useful?  It's the same thing -- you can always get the new value by asking for it, but you've lost the old value.

But there is no "standard" vector object, so what exactly would the primitive return? A list? A vector?

A list is a vector!  (Especially a Scratch list, which isn't a list at all, but an array.)  "Vector" is just a technical term for "an ordered list being thought of as a single thing rather than as a sequence."

adding a subtle oval or something else to the block. An image might help

That's really subtle!  I had to zoom way in to see how it differed from a regular command block. Of course I'm a farsighted adult.     I was thinking something more like

bharvey wrote:

Okay, then why isn't the old value of a SET variable more useful?  It's the same thing -- you can always get the new value by asking for it, but you've lost the old value.

I suppose so.

A list is a vector!  (Especially a Scratch list, which isn't a list at all, but an array.)  "Vector" is just a technical term for "an ordered list being thought of as a single thing rather than as a sequence."

Ah, that kind of vector. I thought you meant a mathematical vector.

That's really subtle!  I had to zoom way in to see how it differed from a regular command block. Of course I'm a farsighted adult.     I was thinking something more like
http://cs.berkeley.edu/~bh/hybrid.png

I see what you mean, but then scripts would have awkward rounded parts instead of being flat on the left side. Maybe a command-shaped block with the corners darkened, or use that form in the palette and change it into a command block when it's dragged into a script (which might be a little less confusing for users)

This is an appealing idea, but also a potential source of confusion for users, who may look in vain in the palette for a block that matches the one they see in a script.

Good point. Any suggestions, everyone?

PS I like the really minimal sig!

Thanks!