Scratch

@ clintonhackers -nested sprites
Jens provides "somewhere" into Byob 3.0 distribution pack 2 remarkable examples of nested sprites. See also a simple demo application at  :
http://www.xleroy.net/ByobTuto/thumbnails.html (n° 17) . It's tricky. Don't forget to set correctly the "set" point of each nested sprites.

@ bharvey and jens :100 pages ! Congratulations.
The nested feature is still active but I ignored this as there is no visible command or instruction for it, we just have to know the how-to-do-it.

@ clintohackers - nested sprites
Make 3 sprites, a rectangle and 2 circles for the wheels. Nest the wheels to the rectangle. You get a "group" unique shape that can be moved with the mouse AND moving instructions. Simple but impressive.

JTxt wrote:

Lucario621 wrote:

Hmm. Almost 100 pages! Cool.

And, I've recently just about half an hour ago been working on a new project (tile-based), however, because there's no good way to copy lists, I have to use BYOB.    I can't even individually copy items - because I want to have a "Visible chunk" list, and it has the visible chunk out of all of the chunks in the game (a chunk is a part of the world - so it can be rendered separately). So I can't just say copy from chunk1 to Visible Chunk - it has to be from chunk # (visible chunk (variable)) to Visible Chunk. Which isn't currently possible.

And it passed 65536 views! 
Cool problem, I responded to you here.

On topic: Go BYOB. 
Really, thanks for your hard work on this.

Ah yes. Thanks. (I'm writing my response to the new thread ATM)

BYOB does make things a lot easier. However I haven't actually created any new blocks yet, like most people would think  .

BYOB+CYOB+OOP+Faster JavaScript Morpchic+Cross WAN multiple connection meshes=Awesome

Here's today's experimental build!

Jens wrote:

another experimental pre-alpha release. Lots of changes under the hood:

1) spawning and deleting clones now also works in presentation mode
2) new experimental _ OF _ reporter block in the sensing category allows scripts to be handled by corresponding / inherited blocks of another sprite.
3) new experimental getVariable reporter gets any named variable or named list. Use the experimental new OF block to query another sprite's variables and lists:

Code:

CALL (ATTRIBUTE (THE (GET varname) BLOCK) OF (OBJECT (spritename)))

4) experimental STICK TO (sprite) command block for scripted nesting or sprites in the motion category. Choose "nothing" to detach / "unstick" the sprite again.

I'm including a little demo project for the new OF block. It shows - among other things - how you can use this new block interpretation to initialize and individualize clones.

Saving projects works /sometimes/. More often than not projects get stuck in circularity. We might have to invent a general object table after all (but maybe not for 3.1).

Enjoy!
--Jens

Wow! This is the best release yet! Am I supposed to be able to remove the stage from the stage? 

This is getting so exciting.

The get block can't access script vars.

While I don't think it's necessary (to be able to access script variables), I could need to GET them from a custom block at some point... Just a thought...

shadow_7283 wrote:

I could need to GET them from a custom block at some point...

So, let me see if I understand.  Script A has a script variable FOO.  It calls custom block B, and inside B you want to get the value of FOO?

If that's it, you're asking for dynamic scope.  This is the name for the scoping rule in which a procedure call has access to the variables of its caller.  By contrast, what we have now is lexical scope, which means that a procedure call has access to the variables of the enclosing definition.  This is what allows us, among other things, to have explicit OOP using dispatch procedures.

I have a foot in each camp; Logo uses dynamic scope, while Scheme uses lexical scope.  I actually have this crazy idea for how to provide both; I don't know of any language that really tries to do that, although some languages have fallen into mixtures by mistake, because their designers didn't think about scope at all.

My idea is that scope is primarily lexical.  Besides providing OOP capability, this also makes for faster compiled programs.  But if there is no lexical referent for a variable reference, then we'd look through the dynamic environment for a binding.

I think variable scoping just barely works in the Smalltalk implementation, and my guess is that Jens is unlikely to tinker with it for 3.1.  (But, you never know...)  But when we do the 4.0 rewrite, I'll try to sneak this in. 

P.S.  One problem with dynamic scope is that your custom block B can't be used just anywhere; it can only be called from script A, or some other script that also provides a variable FOO.  This is a little undesirable because it means the user of a block has to know about what's inside it, not just what job it does.

Last edited by bharvey (2011-01-26 23:45:46)

One thing I'd like to see in future versions of BYOB is the ability to create dropdown menus. Maybe have where you choose from existing ones (ie. sprite list), or create your own (ie. all but (last/any/first/[insert]) of (list) ).

bharvey wrote:

Yet another experimental build.

Jens wrote:

After an all-nighter this version is another step towards "getting it to work" and fixes some of the worst issues of the past experimental releases:

     - first class sprites no longer cause circularity hang-ups when saving
     - it is now possible to use script variables for first class sprites
     - (recursive) custom blocks can again be defined in this version

No new changes to the GUI or the blocks, but I'm enclosing yesterday's "generation" demo project using script variables and a new "spawning-tree" demo project that's especially fun to watch in presentation mode.

Enjoy!
-Jens

Hi guys,

I menat to write yesterday but I think my browser crashed before the message went out.  So, ot summarize:

wow!  this is fantastic!

and

what do you think about the idea of adding "My Parent" to the list of sprites in e.g. the SPAWN and OF blocks?  I think there're likely to be many situations in which communication between parent and child will be important.

Otherwise fantastic.  thanks guys.

matt