Scratch

@ bharvey

.... with the semi-persistent solution each sprite has its own set of variables (defined and set when the sprite is created). Then remains the broadcast concurrency issue which can be addressed by creating one broadcast per sprite. I'm looking further on ...

Was my bug reproduced? Solved?

'Ask' block, sibling of the 'Send':


Gunna have to squint at those pictures, but it takes too long to get them to the right size without messing up quality.

Last edited by 14God (2011-02-01 16:05:41)

Are there any plans regarding networking and multiple connection meshes for 3.1/4.0?

fullmoon wrote:

Any chance of a "When I am created <params...>" hat?

No need, just make a  'for this sprite only' block and call it "created" and give it whatever arguments you see fit. Then when you spawn a sprite call it's "created" block.

14God wrote:

Are there any plans regarding networking and multiple connection meshes for 3.1/4.0?

Not 3.1, I'm pretty sure.  Anything is possible for 4.0 though.

14God wrote:

No need, just make a  'for this sprite only' block and call it "created" and give it whatever arguments you see fit. Then when you spawn a sprite call it's "created" block.

That's true, but we'll probably make a CREATED hat anyway, because, for one thing, CLONE is a reporter and you might not want to have to bother making sure that the CREATED block gets called because you're busy putting the child in a list or something.

bharvey wrote:

fullmoon wrote:

Actually, I just spotted a major flaw in my idea...if you were to have multiple parameter-accepting creation hats they would all have to accept the same arguments, which sounds like a disaster, since it wouldn't be clear how they are scoped.

I'm not sure I understand about the arguments.  Do you want to specify their values in the CLONE block?  (I talked Jens into changing the name from SPAWN.    )

I suppose it would be possible for it to just have one input, and if you want more, just put them in a list!

I was thinking the SPAWN block would behave similarly to RUN or LAUNCH with the option of specifying a hard-coded set of parameters or a list. However I think it might be confusing (or bad practice) to allow hats to receive parameters:

When I am created |param|:
  param = 'foo'

When I am created |param|:
  wait 1 sec
  say param

So, does the sprite say 'foo''? The answer seems like it would obviously be no, but if you were to write a "created" block that simulates this functionality the answer might be different:

created = |param|{
  launch({
     param = 'foo'
  })
  launch({
     wait 1 sec
     say param
     //Yes, param == 'foo' thanks to the closure that is created.
   })
}

So I might have changed my mind about constructor hats with parameters...

bharvey wrote:

That's true, but we'll probably make a CREATED hat anyway, because, for one thing, CLONE is a reporter and you might not want to have to bother making sure that the CREATED block gets called because you're busy putting the child in a list or something.

You can keep a reference to an object with a block like this:


(accidental left the 'save' var just name it keep)

So you can then do with the object as you please after adding it somewhere. Also you can make an 'interception' block (as I like to call it) which takes the same role as an existing block but adds functionality you want. So if you change the spawn block to clone I could make a 'spawn' block which uses the clone block and also adds the object to a clones list.

I think I talk to much...

Last edited by 14God (2011-02-01 22:50:54)

fullmoon wrote:

\ However I think it might be confusing (or bad practice) to allow hats to receive parameters:

Code:

When I am created |param|:
  param = 'foo'

When I am created |param|:
  wait 1 sec
  say param

So, does the sprite say 'foo''? The answer seems like it would obviously be no, but if you were to write a "created" block that simulates this functionality the answer might be different:

Code:

created = |param|{
  launch({
     param = 'foo'
  })
  launch({
     wait 1 sec
     say param
     //Yes, param == 'foo' thanks to the closure that is created.
   })
}

So I might have changed my mind about constructor hats with parameters...

This example doesn't bother me.  In one case you have two references to the same name in different scopes; in the other case you have two references clearly (as you say) in the same scope.  So they should behave differently!  I point out that if you want the latter behavior in the former situation you could use LAUNCH there, too.

I'm more nervous about the precedent of inputs to hat blocks altogether.  This sort of blurs the distinction between custom blocks and script-area scripts.  As I recall nXIII was arguing for that a while ago, but all else being equal it makes me nervous when a language provides two tools for the same task; I never know which I'm supposed to use when.

You're going to tell me about the pulldown menu in WHEN < > KEY PRESSED but that's not really an input; it doesn't bind a variable to whichever key you pressed.  (Maybe I shouldn't be giving nXIII ideas.    )

I don't know if this is the right place, but how does the debugger work?

@ Scimonster
wow thats weird, when you put " in front of %(some letter) its like some flag that will make different things happen on you block like:

 " Test %m

will give you a drop down of sprites... useless though because you cant use them as arguments.

Try:

 " Test %x

it looks like something they were going to put in scratch but didn't

If Jens made some of these work like arguments it would be pretty cool.