Scratch

Jens wrote:

markyparky56 wrote:

markyparky56 wrote:

I found another glitch.

http://img101.imageshack.us/img101/2558/glitch2.gif
If you put a rounded reporter block into a boolean block, such as the ones in the picture, then take it out it makes it only allow you to enter numbers (Or intergers) and no text (Or strings)

Did anyone see this?

Hi, markyparky56.

Thanks for this detailed bug report! The screenshot is really helpful, but I'm still having problems reproducing this obvious bug. Can you tell me if this is happening in the Block Editor or in the regular scripting area? Is there perhaps any way you can post it somewhere on the web?

Thanks again for all the awesome bug reports, guys!

Ok, i managed to re-create it. Try puting a variable block in the if block.
Like this:

does this help?

Edit:
Update:Ok, i just downloaded 2.99.005
How to do it:
Make a random block. Names not important.
Insert a script variables block.
Add an If block. Put a boolean < ( ) > ( ) > in, in that, put (a) > 0 then a variable set block into that, then copy the if block and take out the (a), you will have glitched it!

Last edited by markyparky56 (2010-05-04 04:34:15)

Jens wrote:

Hmmm, I must be making something wrong, because I still cannot reproduce the glitch that obviously happens to you. But I'll keep trying anyway. Thanks!

Strange, i can't get it to do it again... strange...

Jens wrote:

bharvey wrote:

nXIII wrote:

While searching for a different glitch to take a picture of, I got this:
http://i40.tinypic.com/24ymuc7.png
Is that supposed to happen?

Hah!  Thanks for helping me win an argument with Jens.     He thinks that THE SCRIPT [REPORT FOO]
and THE [FOO] BLOCK are equivalent, and one can be displayed as if it were the other.

And I still do!

The problem with this is that you're trying to call THE (CALL <>) BLOCK with a command block ("say ..") as argument. This has nothing to do with THE SCRIPT, in fact, if you just add a REPORT <foo> command block the the script inside THE SCRIPT this will turn it into a perfectly valid reporter (!) and will prevent it from freezing, and even answer "foo".

Therefore I still maintain that THE <aReporter> BLOCK is just syntactic sugar for THE SCRIPT (report <aReporter> ). I even implemented it that way. 

I think I should be taking notes on how to have a good arguement...

Oh, okay, in this case you win 
Wait! didn't I fix that last night?

Thanks Jens for all your hard work, Byob 3 is another great idea !
The thing i was hoping for is advanced mesh? 
Still good 

Last edited by dav09 (2010-05-04 16:01:40)

nXIII wrote:

bharvey wrote:

bharvey wrote:

I guess each SWITCH could fluid-let the global variable (I mean, save it and restore it when done).

No, it couldn't, not if you want multiple threads to be able to use your SWITCH block in parallel.

I still think your (nXIII) idea is amazingly brilliant, but it won't really replace support for variadic input groups.

I don't think you know what I mean by switch statements, here is my implementation: Switch Statements in BYOB
_________

Small glitch:
http://i44.tinypic.com/xpuky.jpg

Whoa, nXIII. I'm awestruck! Your switch mechanism is brilliantly beautiful. This is great stuff, you should be writing the tutorial about it, honestly!

Not sure about the "small glitch". It's a feature that BYOB lets you drop (certain) reporters (variables, list items, call blocks, of blocks and some others) onto a C-shaped command slot, and I believe it's an extremely cool and useful one, too: You don't have to put the command blocks themselves into the C-shaped slot, instead you can assign them to a variable first or get them from another function (it's all first class, remember?). I even made it so that the block reformats itself if this happens: Instead of vertical alignment a C-shaped slot that's filled with a reporter reverts to the regular label-text-flow and looks just like any old command block.

Or were you meaning something else?

Jens wrote:

nXIII wrote:

bharvey wrote:

No, it couldn't, not if you want multiple threads to be able to use your SWITCH block in parallel.

I still think your (nXIII) idea is amazingly brilliant, but it won't really replace support for variadic input groups.

I don't think you know what I mean by switch statements, here is my implementation: Switch Statements in BYOB
_________

Small glitch:
http://i44.tinypic.com/xpuky.jpg

Whoa, nXIII. I'm awestruck! Your switch mechanism is brilliantly beautiful. This is great stuff, you should be writing the tutorial about it, honestly!

Not sure about the "small glitch". It's a feature that BYOB lets you drop (certain) reporters (variables, list items, call blocks, of blocks and some others) onto a C-shaped command slot, and I believe it's an extremely cool and useful one, too: You don't have to put the command blocks themselves into the C-shaped slot, instead you can assign them to a variable first or get them from another function (it's all first class, remember?). I even made it so that the block reformats itself if this happens: Instead of vertical alignment a C-shaped slot that's filled with a reporter reverts to the regular label-text-flow and looks just like any old command block.

Or were you meaning something else?

Oh, OK. I was using that in the switch statement originally, due to it wanting a completely-vertical layout (which looks nice for a switch statement), but it ended up having large holes near the edges of the reporters, like this:

PlayWithFire wrote:

Jens wrote:

Hey dav09, I'm curious which advanced mesh functions you'd be interested in. Is there anything special you'd like to do that requires mesh?

i'm not dav09 but i'd like to see a way to create lobbies or hopefully something you could program with like a block saying host mesh or join mesh.  something to make it more like an online console game as opposed to a game where you have to share ip addresses.  and when i say console game i don't mean something like super smash bros brawl where you have to type in a friend code, i mean like modern warfare where you join a lobby automatically.

I don't think that is too complex of an idea. Having a group you can join would probably (correct me if I'm wrong) only require a bit of extra code and work.

The only problem with your idea is the online playing experience. You don't really know who you are playing with, and for all you know, the people playing might not have the same ideas as yourself about how to... conduct themselves online. It could lead to problems with bullying, unwanted experiences, and just overall bad game play. So I don't think this is a very good idea.

nXIII wrote:

I don't think you know what I mean by switch statements, here is my implementation:

Oh!  You're brilliant!

I did know what you meant by SWITCH; what I missed was that CASE is a reporter.

May we put this in the tools project?  (With attribution of course.)

(PS Sorry for the delayed response; I spent the day at a School, which has mediafire in its proxy's blacklist.)

nXIII wrote:

Switch Statements in BYOB

P.S. Inside SWITCH you refer to a variable VAL; that's supposed to be the upvar VALUE, right?

I was going to ask why you needed the upvar at all, since in your example the value-providing expression is just a variable reference and you could drag that variable into the case scripts, but I guess the idea is that the value expression could be something more complicated that you wouldn't want to have to duplicate, right?

Oh, but you still don't need it, because your CASE block just matches a single value, so it knows which value it matched.     If if were me, the first input to CASE would be a predicate slot, so you could put in a [< > = <foo>] block for the single-value case, or a [<my-list-of-cases> CONTAINS < >] block to match a fixed set of values, or a [IS < > A NUMBER?] block, or anything!  Or do you think that would be too confusing?

Tp Bharvey 22:54

OK, fine, it works.
Another issue : I can easily create bugs when trying to set into the block editor Control commands using WHILE.

See the first page (XLbug01) into of http://www.xleroy.net/Byop/Thumbnails.html

Jens wrote:

Hey dav09, I'm curious which advanced mesh functions you'd be interested in. Is there anything special you'd like to do that requires mesh?

I think he means something like what we have in Panther.

nXIII wrote:

Well, the main reason I used an upvar was for the default case

Oh yeah.  I was so excited about CASE that I didn't think about the default branch. 

I think I can make the mod for taking predicates, thanks!

Don't be speechless.  You're fantastic.  You've taken the BYOB ideas to heart faster and more deeply than anyone else, especially the OOP parts, and you're listed as "main programmer" on the Panther wiki to boot.