Scratch

I just hit the link and I got a file labelled 3.04 but the title bar said 3.03, and the block variables panel was still there.

bharvey wrote:

Could someone else confirm this problem

3.0.4 works for me with no more block editor variable panel.

bharvey wrote:

fullmoon wrote:

I just hit the link and I got a file labelled 3.04 but the title bar said 3.03, and the block variables panel was still there.

Very strange.  I've tried twice downloading this link, and it works for me.  Could someone else confirm this problem?  Alternatively, could you (fullmoon) make sure other BYOB.image files are deleted and run the new one again?

Whoops! I've been forgetting to drag the 3.04 image into the BYOB.app file..my bad!

bharvey wrote:

fullmoon wrote:

Whoops! I've been forgetting to drag the 3.04 image into the BYOB.app file..my bad!

If you move the file into the same folder as BYOB.app then you should be able to double-click the latter without having to drag each time.

I did...but oddly it doesn't work. When I execute BYOB with a new image it actually puts another BYOB icon in my dock so I can remove the old one and pin the new one.

shadow_7283 wrote:

Jonathanpb wrote:

I just got the latest version of BYOB (3.0.4) and the title bar says 3.0.4... Shadow, are you sure you got 3.0.4?

Not exactly off-topic: BYOB pwns!           

That was nXIII....

And can someone post a link to Jen's anti-modding speech? I want to hear it!

What was me?

nXIII wrote:

shadow_7283 wrote:

Jonathanpb wrote:

I just got the latest version of BYOB (3.0.4) and the title bar says 3.0.4... Shadow, are you sure you got 3.0.4?

Not exactly off-topic: BYOB pwns!           

That was nXIII....

And can someone post a link to Jen's anti-modding speech? I want to hear it!

What was me?

Sorry, my mistake. Jonathanpb said "Shadow, are you sure you got 3.0.4?". Not "fullmoon, are you sure got 3.0.4?"

shadow_7283 wrote:

(And Shadow carefully points the blame to someone else...) 

Well, it's only fair. 

3.0.5 now available.

Jens wrote:

a follow-up on the changes introduced in the last release, with a few subtle GUI-enhancements in the blocks' context menu:

1) renaming variable blobs

just as variable setter blocks can be pointed to any variable within their reach variable getter reporters ("blobs") can now also be renamed, or rather set, to any other variable regardless off its type via their context menu. Selecting the "rename" option pops up a menu similar to that of setter blocks, listing all reachable variables and indicating their scope. If "Scope Contrast" is turned on, renaming a script variable to a regular one (and vice versa) will also result in a change of the blob's color.

Note that this change now allows you to use any variable blob from anywhere else, because - like setter blocks - it can be pointed to any desired variable target once it has been dropped into its destination context, e.g. you can now drag a script variable from the variable pallette into a block editor and assign it to a formal parameter ("input") there.

This feature addresses the concerns in the Scratch forum voiced in response to having eliminated the block editor's variables pane, specifically those stating that it can be tedious having to scroll back and forth through potentially large scripts just to reach the SCRIPT VARIABLES block which is usually located at the top of the stack (yes, that's you, nXIII      , thanks for bringing this to my attention!).

2) morphing custom blocks

the same "rename" option is now also in each custom block's context menu. Selecting to rename a custom block lets you turn the current block into another one of the same category and shape, thereby trying best to preserve any inputs. This option is only offered for custom blocks, not for primitives. I find it to be handy in cases where I want to exchange one block within a large stack for another one (i.e. the custom block equivalent of TURN LEFT and TURN RIGHT), without having to disassemble the whole stack for this.

The main motivation for this feature, however, is to experiment with GUI aspects of eventually collapsing several similar block templates into a single one. As I've learned with Elements having to display too many blocks in the pallette really gets in the way of finding - let alone use - them. With such techniques I hope to somehow "MacGuiverize" block-families into "swiss army knife" like blocks, so that larger numbers and varieties of blocks and block libraries will become manageable.

3) duplicating single blocks in a stack

One thing that annoys me in Scratch is that whenever I duplicate a block in a stack all the other blocks that are attached below it become duplicated also. There now is an - experimental - context menu option named "this block" that lets you duplicate just "this block".

... of course there are also some bugfixes in this release ...

- boolean blocks are now rendered correctly (hexagonal) in the OF block's attribute menu
- clicking on the upper right corner of the stage's library icon no longer triggers an internal error
- ...

Enjoy!

Wow. I really need to update. I still have 3.0.

But I have to work with Prism team members, and I don't want an out-of-date program.

I love the new renaming feature, it pretty much solves the vars pane problem! But I take issue with calling it "renaming", because to me that makes it seem as though the variable is being renamed, as opposed to the reference to the variable being re-assigned a variable. If I were a new BYOB'er I would definitely assume that "rename" would update all the references to the variable I was "renaming", changing the code blocks but leaving the program to run exactly the same. Maybe just "change" or "select variable" would be better? Also, IS THERE A POSSIBILITY OF A DELETE OPTION IN THE BLOCK CONTEXT MENU? (Sorry, that's three years of pent-up rage released right there.  ) I think one of NXIII's Scratch Patches did that but it would be great to add.

@ bharvey & jens

1 - block renaming : for me it seems that the block can only be renamed to a pre-existing function ? If not the pick-list is void. When predefined, the renamed function is void, without any input variables. To me it does not bring any enhancement compared to my former way of doing : create a new block, and past into it the block of the "old" function.

2 - deletion of input variables : I feel curious that once an input variable is created it can't be deleted later on (if this variable is not anymore useful). It is manageable.

3 - I would underscore the interest of the SCRIPT VARIABLES block that I use extensively since I've discovered it. It is a major improvement (amongst many others !) compared with Scratch with its overcrowded variable panel  (notably if you need a lot of intermediary variables). Now I use to start building my blocks into the Script area rather than into the Block editor (open it, change it and save it takes more time with the Block editor). When the try-change-retry phase is almost completed then I can load the script into the block editor and finish to polish it.

A clean management of variables (global, local, script internal, block input etc) is possible with Byob, but it need some attention IF YOU INTEND TO COPY OR EXPORT YOUR BLOCKS into another project...In this case the risk is that you will export undesired variables into the other projects which can collapse with the pre-existing  variables (same name in general) and make a Variable salad. (differentiation of variable colors is very useful)

For example I've experimented the following issue : I create into a FIRST sprite a block of instructions calling a variable LOCAL used as a method . If I duplicate this block to a SECOND sprite, then the FIRST local variables is created into the second one. I've to delete each time this undesired variable.

I'm not asking for any new feature, I just want to underscore that the power and versatibility of Byob is so large that in some circumstances its driver need to be cautious. For the above mentioned reasons, at the final stage of creating a new function,  I delete all variables that are not any more needed.

rubiks_cube_guy238 wrote:

evaluate any given formula with input x.

Won't help, sorry.
Mine's compiled into a list tree structure.