_nix wrote:

Dairop wrote:

Do you know if A=a in 3.0 please ?
Else how to know if the letter is a capital one ?

A is still the same as a in Scratch 3.0 (otherwise a lot of existing projects would probably be broken). You'll have to stick to one of the tried-and-true methods, like using costumes.

I'm hoping that the Scratch Team will eventually add a “case detection” extension - I think that would be really handy, and it would make sense as an extension.

Yeah, unfortunately this isn't the “case” (lol see what i did there). A case detection extension would make text engines sooooooo much easier. Right now, the easiest way to get case detection that i know of requires two strings to be entered, the second being the one determining the cases of the letters. I'll put some examples here to show how annoying it is to make text with this:

define Switch Costume To Letter (letter) (case)
switch costume to (join (letter) (case) )// letters named "letterCase" e.x. a0= a, a1= A

//so lemme show you how this gets to be a real pain (this uses the other blocks in a loop and clones them btw):
Type Text [The Cake Is A Lie] [100 1000 10 1 100]::custom

This is why we need case sensitivity badly.

Huge project loading performance boost – courtesy of mzgoddard, projects are loaded around 10 times faster! (Or even more, depending on the system/browser.) The optimization was purely in how audio is loaded. This also means projects take a lot less memory to load, which is definitely a good thing.

Here's the table from here which shows the improvements for a project on various systems:



Note that this doesn't change your internet speed – it just changes how long it takes for the project to open up once it's fully downloaded. Nonetheless, it's still a significant improvement, especially for slower systems or browsers.

_nix wrote:

Huge project loading performance boost – courtesy of mzgoddard, projects are loaded around 10 times faster! (Or even more, depending on the system/browser.) The optimization was purely in how audio is loaded. This also means projects take a lot less memory to load, which is definitely a good thing.

Here's the table from here which shows the improvements for a project on various systems:



Note that this doesn't change your internet speed – it just changes how long it takes for the project to open up once it's fully downloaded. Nonetheless, it's still a significant improvement, especially for slower systems or browsers.

Wow! Nice!

Greenduck54 wrote:

_nix wrote:

Dairop wrote:

Do you know if A=a in 3.0 please ?
Else how to know if the letter is a capital one ?

A is still the same as a in Scratch 3.0 (otherwise a lot of existing projects would probably be broken). You'll have to stick to one of the tried-and-true methods, like using costumes.

I'm hoping that the Scratch Team will eventually add a “case detection” extension - I think that would be really handy, and it would make sense as an extension.

Yeah, unfortunately this isn't the “case” (lol see what i did there). A case detection extension would make text engines sooooooo much easier. Right now, the easiest way to get case detection that i know of requires two strings to be entered, the second being the one determining the cases of the letters. I'll put some examples here to show how annoying it is to make text with this:

define Switch Costume To Letter (letter) (case)
switch costume to (join (letter) (case) )// letters named "letterCase" e.x. a0= a, a1= A

//so lemme show you how this gets to be a real pain (this uses the other blocks in a loop and clones them btw):
Type Text [The Cake Is A Lie] [100 1000 10 1 100]::custom

This is why we need case sensitivity badly.

There is a easier way, you can hack costumes to have the same letter but different case. It's also easier to create the costumes in the JSON with copy paste than it is in the Scratch editor.

It’s hard for me to get on Beta 3.0 because there is this error where it pops up
“Can’t connect cuz WebGL isn’t installed”
It’s very frustrating because I own a iPhone 8 and 5 and I use the browser Puffin.


Follow me!!

add [Follows] to list [Fluffcatplayz]
say [Follow me!!] for (2) secs
show variable [Follows]
change [Follows] by (1)

And I forgot are we going to restart our accounts?

-Fluffcatplayz

Fluffcatplayz wrote:

It’s hard for me to get on Beta 3.0 because there is this error where it pops up
“Can’t connect cuz WebGL isn’t installed”
It’s very frustrating because I own a iPhone 8 and 5 and I use the browser Puffin.

Scratch 3 works (almost) fine in Chrome on my iphone 7 (ios 11.4). Everything works except for the iphone top bar that doesn't allow me to click on tabs and buttons above the stage. As it works very well (and it is very smooth) I hope the Scratch Team is planning to fully support it (maybe it already works in ios12?)

Fluffcatplayz wrote:

It’s hard for me to get on Beta 3.0 because there is this error where it pops up
“Can’t connect cuz WebGL isn’t installed”
It’s very frustrating because I own a iPhone 8 and 5 and I use the browser Puffin.

Try a different browser.

Follow me!!

add [Follows] to list [Fluffcatplayz]
say [Follow me!!] for (2) secs
show variable [Follows]
change [Follows] by (1)

Please do not spam.

And I forgot are we going to restart our accounts?

-Fluffcatplayz

Nope!

Greenduck54 wrote:

_nix wrote:

Dairop wrote:

Do you know if A=a in 3.0 please ?
Else how to know if the letter is a capital one ?

A is still the same as a in Scratch 3.0 (otherwise a lot of existing projects would probably be broken). You'll have to stick to one of the tried-and-true methods, like using costumes.

I'm hoping that the Scratch Team will eventually add a “case detection” extension - I think that would be really handy, and it would make sense as an extension.

Yeah, unfortunately this isn't the “case” (lol see what i did there). A case detection extension would make text engines sooooooo much easier. Right now, the easiest way to get case detection that i know of requires two strings to be entered, the second being the one determining the cases of the letters. I'll put some examples here to show how annoying it is to make text with this:

define Switch Costume To Letter (letter) (case)
switch costume to (join (letter) (case) )// letters named "letterCase" e.x. a0= a, a1= A

//so lemme show you how this gets to be a real pain (this uses the other blocks in a loop and clones them btw):
Type Text [The Cake Is A Lie] [100 1000 10 1 100]::custom

This is why we need case sensitivity badly.

Case sensitivity does exist in costumes, but you can't have one costume as “a” and another as “A”.

AmazingMech2418 wrote:

Greenduck54 wrote:

_nix wrote:

Dairop wrote:

Do you know if A=a in 3.0 please ?
Else how to know if the letter is a capital one ?

A is still the same as a in Scratch 3.0 (otherwise a lot of existing projects would probably be broken). You'll have to stick to one of the tried-and-true methods, like using costumes.

I'm hoping that the Scratch Team will eventually add a “case detection” extension - I think that would be really handy, and it would make sense as an extension.

Yeah, unfortunately this isn't the “case” (lol see what i did there). A case detection extension would make text engines sooooooo much easier. Right now, the easiest way to get case detection that i know of requires two strings to be entered, the second being the one determining the cases of the letters. I'll put some examples here to show how annoying it is to make text with this:

define Switch Costume To Letter (letter) (case)
switch costume to (join (letter) (case) )// letters named "letterCase" e.x. a0= a, a1= A

//so lemme show you how this gets to be a real pain (this uses the other blocks in a loop and clones them btw):
Type Text [The Cake Is A Lie] [100 1000 10 1 100]::custom

This is why we need case sensitivity badly.

Case sensitivity does exist in costumes, but you can't have one costume as “a” and another as “A”.

You can if you edit the JSON file even in 3.0. It is a lot easier to do it like that.

Edit: Just realized I already posted this up above as well, oops.

imfh wrote:

AmazingMech2418 wrote:

Greenduck54 wrote:

_nix wrote:

Dairop wrote:

Do you know if A=a in 3.0 please ?
Else how to know if the letter is a capital one ?

A is still the same as a in Scratch 3.0 (otherwise a lot of existing projects would probably be broken). You'll have to stick to one of the tried-and-true methods, like using costumes.

I'm hoping that the Scratch Team will eventually add a “case detection” extension - I think that would be really handy, and it would make sense as an extension.

Yeah, unfortunately this isn't the “case” (lol see what i did there). A case detection extension would make text engines sooooooo much easier. Right now, the easiest way to get case detection that i know of requires two strings to be entered, the second being the one determining the cases of the letters. I'll put some examples here to show how annoying it is to make text with this:

define Switch Costume To Letter (letter) (case)
switch costume to (join (letter) (case) )// letters named "letterCase" e.x. a0= a, a1= A

//so lemme show you how this gets to be a real pain (this uses the other blocks in a loop and clones them btw):
Type Text [The Cake Is A Lie] [100 1000 10 1 100]::custom

This is why we need case sensitivity badly.

Case sensitivity does exist in costumes, but you can't have one costume as “a” and another as “A”.

You can if you edit the JSON file even in 3.0. It is a lot easier to do it like that.

How is downloading, editing, and managing several different copies of the same file easier than simply editing the original file?

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)

0037318 wrote:

imfh wrote:

AmazingMech2418 wrote:

Greenduck54 wrote:

[Quotations omitted for briefness]

Case sensitivity does exist in costumes, but you can't have one costume as “a” and another as “A”.

You can if you edit the JSON file even in 3.0. It is a lot easier to do it like that.

How is downloading, editing, and managing several different copies of the same file easier than simply editing the original file?

I think you misunderstood me. It's easier to create all the costumes needed for case detection by editing the JSON. This is for 2 reasons:

1. Because seems easier to name 26 * 2 = 52+ costumes in a JSON editor
   
2. Because you can create costumes with the same name but different case(eg. ‘A’ and ‘a’) greatly simplifying the programming needed to detect case.
   

If you don't want to worry about multiple files or messing something up, you can just download a blank sprite and edit it. Plus you can then reuse it as much as you want to.

Probably crazy Scratch extension idea I had: a way to make the pen draw on top of a costume. (Like, temporarily - so that you can create dynamically-generated costumes for your sprite, or just draw the pen on a layer above actual sprites. The costumes wouldn't be saved.) I have no idea how to program something like that, though. (Mainly I don't think there's any way to hack the pen blocks to draw on top of something else. You'd probably have to implement all the pen/motion/drawing blocks as part of that new extension.) But hey, still an idea..

_nix wrote:

Probably crazy Scratch extension idea I had: a way to make the pen draw on top of a costume. (Like, temporarily - so that you can create dynamically-generated costumes for your sprite, or just draw the pen on a layer above actual sprites. The costumes wouldn't be saved.) I have no idea how to program something like that, though. (Mainly I don't think there's any way to hack the pen blocks to draw on top of something else. You'd probably have to implement all the pen/motion/drawing blocks as part of that new extension.) But hey, still an idea..

If this was implemented, then it would be a pretty simple workaround to link a canvas to a sprite

Current project: [s3Blocks: scratchblocks rewritten for Scratch 3.0] ::#4b4a60 //https://scratch.mit.edu/discuss/topic/290031/ Basically done!

NitroCipher wrote:

_nix wrote:

Probably crazy Scratch extension idea I had: a way to make the pen draw on top of a costume. (Like, temporarily - so that you can create dynamically-generated costumes for your sprite, or just draw the pen on a layer above actual sprites. The costumes wouldn't be saved.) I have no idea how to program something like that, though. (Mainly I don't think there's any way to hack the pen blocks to draw on top of something else. You'd probably have to implement all the pen/motion/drawing blocks as part of that new extension.) But hey, still an idea..

If this was implemented, then it would be a pretty simple workaround to link a canvas to a sprite

Yes, that's pretty much the idea I had in mind (just maybe a somewhat simpler version).

I spent a couple hours and did get to the point where I could switch which PenSkin the pen draws on (oh gosh the hacks are aplenty). The code is semi-awful enough that it would probably never, ever get considered an “official” extension, though. (I haven't gotten to actually displaying the PenSkin.. first step to do that is probably just to see if somehow stamping it works.)

Update – wow, that was actually pretty easy to code. Here's a demo. (It actually runs at 30 FPS; the recording is just slow. Pretend “draw on my costume” is “draw on my canvas” - basically the same thing. ) Note that the pen-costume sprite and clone are positioned above the other sprites - so, finally, we can do generated text and pen on top of sprites!

The problem is that it is still very hacky code, and there's not a lot I can do about it. (The hacky part is getting the pen blocks to act on one “pen skin” (basically a canvas) when they would usually act on another.) Also I think you can only draw on one sprite's canvas at a time (because the pen blocks don't know the context they're running in), so you have to stick any pen stuff inside a “run without screen refresh” custom block or it explodes.

Source code if anyone's curious: https://gist.github.com/towerofnix/f63654428fb93ba7e4218cd153f18092

_nix wrote:

Update – wow, that was actually pretty easy to code

Hi _nix, I can see that you can work on the source code! I spent several days asking around in all the forums but no one gave me an answer . I successfully installed the code but I have no idea how you rebuild the code once you made a change. Can you please give me some (even very short) instructions? Thanks in advance.

s_federici wrote:

I successfully installed the code but I have no idea how you rebuild the code once you made a change. Can you please give me some (even very short) instructions? Thanks in advance.

Check this post and my reply to it. If it's still confusing, let me know where you're stuck and I could probably put together a more thorough tutorial.

_nix wrote:

Probably crazy Scratch extension idea I had: a way to make the pen draw on top of a costume. (Like, temporarily - so that you can create dynamically-generated costumes for your sprite, or just draw the pen on a layer above actual sprites. The costumes wouldn't be saved.) I have no idea how to program something like that, though. (Mainly I don't think there's any way to hack the pen blocks to draw on top of something else. You'd probably have to implement all the pen/motion/drawing blocks as part of that new extension.) But hey, still an idea..

That should be easy if you just get the webGL context of the player and draw on it with webGL.

PullJosh wrote:

s_federici wrote:

I successfully installed the code but I have no idea how you rebuild the code once you made a change. Can you please give me some (even very short) instructions? Thanks in advance.

Check this post and my reply to it. If it's still confusing, let me know where you're stuck and I could probably put together a more thorough tutorial.

Thanks for letting me know how to create a new extension. What I would like to know is if I have to run (I suppose yes) any script after I make whatever change to the source code to, just to give an example, change the height of Scratch blocks or change the VM, etc.

s_federici wrote:

What I would like to know is if I have to run (I suppose yes) any script after I make whatever change to the source code to, just to give an example, change the height of Scratch blocks or change the VM, etc.

Quick Tips
This whole page is super useful. If you want changes to scratch-vm to be live-reloaded, make sure you run “npm run watch” in the scratch-vm directory at the same time as “npm start” in the scratch-gui directory (and make sure everything is npm linked together correctly!)

Full Tutorial
Here's how I set up my dev environment for Scratch 3.0. Every edit to the source code causes the entire page to be reloaded automatically for you. (Future readers note that this post could become outdated over time. Try referring to this page as well.)

First of all, it's important to understand the structure of the npm packages used by scratch. Scratch-gui is the top-level piece of code, and it imports all of the other parts of the code from separate packages using npm:



By default, the latest stable version of each is uploaded to npm by the Scratch team (gui, vm, blocks, and render) and will be automatically downloaded to the node_modules folder as a dependency of scratch-gui when you run npm install (from within the scratch-gui folder).

If you just want to edit the GUI, life is good. As long as you don't plan on changing any of the dependent packages (vm, blocks, or render), it's okay for them to just be pulled automatically from npm:

1. I'd recommend creating a directory in which all of you Scratch 3.0 modifications can take place. Once you create it, cd into it in a terminal.

2. Run git clone https://github.com/LLK/scratch-gui

3. cd scratch-gui

4. npm install Do this once to install all of the dependencies. From then on, you only need to run this command if the dependencies (in package.json) ever change.

5. npm start This will start the development server that allows you to see scratch-gui in action. Open the url it gives you to view the result. (By default it's http://localhost:8601). This command will keep running in the background and will automatically refresh the page every time you save a change to the scratch-gui code. (A good way to test that this is working is by making a change to one of the colors in src/css/colors.css) Once you're completely done, press ctrl+c to stop the development server.

Things get trickier if you want to modify the dependencies (the vm, render, or blocks). To do so, we'll use the npm link command to replace the version downloaded from npm automatically with a version we manually downloaded and are able to edit.

For every dependency (vm, render, or blocks) you want to edit, perform the following steps:
1. Stop the scratch-gui dev server if you happen to have it running. (The dev server is what gets triggered when you run npm start from within scratch-gui. See step 5 of the previous list.)

2. cd into the directory above scratch-gui. (If you run ls, “scratch-gui” should be in the output.) This step isn't necessary, but I highly recommend it, as it will help keep everything nice and organized.

3. Clone the dependency you want to edit. It should be one of these commands:

• VM: git clone https://github.com/LLK/scratch-vm
  
• Render: git clone https://github.com/LLK/scratch-render
  
• Blocks: git clone https://github.com/LLK/scratch-blocks
  

4. Only if you're installing scratch-blocks, run git clone https://github.com/google/closure-library as well.

5. cd into the directory you just created using one of these commands:

• cd scratch-vm
  
• cd scratch-render
  
• cd scratch-blocks
  

6. npm install

7. npm link This tells npm to store this location as the place where the dependency you're working with is located. Later this will allow scratch-gui to use your current location as the dependency in place of the version downloaded from npm.

8. This step will allow your changes to the newly-downloaded dependency to be reflected in the GUI. It is different for each dependency, so check the correct one:

• scratch-vm and scratch-render: Run npm run watch. This will start another dev server which makes changes to the dependency trigger the automatic reload of scratch-gui. You'll need to keep this command running and open another terminal to do anything else. As always, you can stop it with ctrl+c when you're finished.
  
• scratch-blocks: This one is a little tougher. Every time you make a change to the code in scratch-blocks, you need to manually run the npm run prepublish command to rebuild scratch-blocks. (Make sure you run the command from the scratch-blocks directory!) Then, from the scratch-gui directory, stop and restart the dev server (ctrl+c to stop it if it's running, then npm start to restart it).
  

9. cd back to scratch-gui. If you're using the directory structure I recommended, you can run cd ../scratch-gui

10. Use the npm link DEPENDENCY_NAME command to pull in the local dependency you just downloaded in place of the regular one from npm:

• npm link scratch-vm
  
• npm link scratch-render
  
• npm link scratch-blocks
  

11. Run npm start to start the scratch-gui dev server. By default, it will launch at http://localhost:8601/ (just like before)