Leopard: Edit Scratch projects as JavaScript code

Bears8

PullJosh wrote:
Bears8 wrote:
This is great!. I've noticed that some of my projects don't work with leopard. When the code is converted nothing happens and it just remains a black screen. Then when I click “Edit as javascript” it has me download “codesandbox.json”
That's interesting. Could you post some broken project links?

these are both projects i made

https://scratch.mit.edu/projects/408941877/
https://scratch.mit.edu/projects/403896307/ - this one involves pen

also this amazing project by @putneycat doesn't work very well

https://scratch.mit.edu/projects/349614583/

theXliner

I have a suggestion: instead of sb-edit converting sb3/sb2 files to a JavaScript/TypeScript objects or enums, could you make a second output option as lexical tokens? Or perhaps, less abundant, cleaner JSON? Since you know the code better, and since it has matured more, it would be easier for others to just parse the lexical tokens/JSON. I'm not complaining (for I am still committed to make my scratch-2-py (currently private) thing) but it'll make stuff a whole lot easier, much more potential for extension, and much easier for me. Can you do that? Just asking.

theXliner

I found a bug (I ran in repl.it: ):

EDIT: It's apparently because I removed the await statement….
using await Project would cause the following error:

/home/runner/I-found-a-bug/index.js:6
const project = await Project.fromSb3(file);
^^^^^

SyntaxError: await is only valid in async function

Promise { <rejected> TypeError: Cannot read property ‘find’ of undefin
ed at Function.<anonymous> (/home/runner/WiryWobblyDisc/nod
e_modules/sb-edit/lib/io/sb3/fromSb3.js:454:42) at step (/home/runner/WiryWobblyDisc/node_modules/sb-edi
t/lib/io/sb3/fromSb3.js:44:23) at Object.next (/home/runner/WiryWobblyDisc/node_modules
/sb-edit/lib/io/sb3/fromSb3.js:25:53)
at /home/runner/WiryWobblyDisc/node_modules/sb-edit/lib/io/sb3/fromSb3.js:19:71
at new Promise (<anonymous>) at __awaiter (/home/runner/WiryWobblyDisc/node_modules/s
b-edit/lib/io/sb3/fromSb3.js:15:12)
at Function.fromSb3JSON (/home/runner/WiryWobblyDisc/nod
e_modules/sb-edit/lib/io/sb3/fromSb3.js:339:12)
at /home/runner/WiryWobblyDisc/index.js:6:25
at Script.runInContext (vm.js:131:20) at Object.<anonymous> (/run_dir/interp.js:156:20)
}(node:195) UnhandledPromiseRejectionWarning: TypeError: Cannot
read property ‘find’ of undefined at Function.<anonymous> (/home/runner/WiryWobblyDisc/node_
modules/sb-edit/lib/io/sb3/fromSb3.js:454:42) at step (/home/runner/WiryWobblyDisc/node_modules/sb-edit/
lib/io/sb3/fromSb3.js:44:23) at Object.next (/home/runner/WiryWobblyDisc/node_modules/s
b-edit/lib/io/sb3/fromSb3.js:25:53)
at /home/runner/WiryWobblyDisc/node_modules/sb-edit/lib/io/sb3/fromSb3.js:19:71
at new Promise (<anonymous>) at __awaiter (/home/runner/WiryWobblyDisc/node_modules/sb-
edit/lib/io/sb3/fromSb3.js:15:12)
at Function.fromSb3JSON (/home/runner/WiryWobblyDisc/node_
modules/sb-edit/lib/io/sb3/fromSb3.js:339:12)
at /home/runner/WiryWobblyDisc/index.js:6:25
at Script.runInContext (vm.js:131:20)
at Object.<anonymous> (/run_dir/interp.js:156:20)
(node:195) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `–unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:195) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Last edited by theXliner (July 8, 2020 20:43:22)

PullJosh

theXliner wrote:
I have a suggestion: instead of sb-edit converting sb3/sb2 files to a JavaScript/TypeScript objects or enums, could you make a second output option as lexical tokens? Or perhaps, less abundant, cleaner JSON? Since you know the code better, and since it has matured more, it would be easier for others to just parse the lexical tokens/JSON. I'm not complaining (for I am still committed to make my scratch-2-py (currently private) thing) but it'll make stuff a whole lot easier, much more potential for extension, and much easier for me. Can you do that? Just asking.

This is an interesting idea.

Once Leopard is more stable, I would consider going back and improving the API provided by sb-edit. Right now sb-edit inherits a lot of the jank from the sb3 file format, which is a shame. The ideal scenario is that sb-edit serves mostly as a clean, universal Scratch project representation, and inputs/outputs are modular.

This means that anyone could easily write code to either…
A) Import a Scratch project or asset from a particular format (sb, sb2, sb3, scratchblocks, tosh, etc) OR
B) Export a Scratch project or asset to a particular format (sb, sb2, sb3, Leopard, scratchblocks, tosh, etc)

It seems like you are most interested in manipulating project files using Python rather than JS. Once sb-edit improves, I see two paths forward:
A) Create a new format for importing/exporting projects as simple, generic JSON (which then allows you to pass a project between sb-edit and some external code) OR
B) Write some code in python and compile it with WebAssembly so that it can be packaged up and used with sb-edit directly.

Sorry I don't have all the answers right now. Unfortunately, improving sb-edit remains a lower priority item for me until most of the problems with Leopard are solved.

PullJosh

theXliner wrote:
I found a bug (I ran in repl.it: ):

EDIT: It's apparently because I removed the await statement….
using await Project would cause the following error:

/home/runner/I-found-a-bug/index.js:6
const project = await Project.fromSb3(file);
^^^^^

SyntaxError: await is only valid in async function

Your repl is private (or something–I'm getting a 404 page), but it looks like you need to run your code inside an async function. The easiest solution is just to take everything in index.js and wrap it like this:

(async function() {
  // index.js contents go here
})();

(By the way, did you know that you can include code in your forum post using the [code][/code] tags? It's a neat trick that's not very well-known.

)

PullJosh

Sprite layering is now partially supported!

Previously when converting a project with Leopard, sprites could end up out of order, appearing above or below where they should. Now, sprites are layered the same way they are in the Scratch project.

The looks blocks (go to front/back, go forward/backward) are NOT yet supported, so your sprites will remain wherever they were when the project began. Stay tuned for more updates in this department!

Programmer_Parth_99

Sorry, but Leopard does not support Cloud Variables.

Programmer_Parth_99

It does not support layers too!

Nunwu

https://scratch.mit.edu/projects/406581176/
when i did it the clones dident work maybe just cause the skript was so bad

PullJosh

Spaceflyer234 wrote:
Programmer_Parth_99 wrote:
Sorry, but Leopard does not support Cloud Variables.
I'm not sure it is possible to support Cloud Variables. Is it @PullJosh?

Cloud data requires a backend server of some kind. That means Leopard would either need to hijack Scratch's system or I would have to deploy my own.

Hijacking Scratch might be possible, I haven't really looked into it, but it isn't something I feel good about. The Scratch team deserves to have complete control over cloud data, and that might include limiting how the Scratch client sends and receives data. If Leopard was interacting with cloud data too, it could cause problems. So that absolutely will not be happening.

Deploying my own cloud data system is a possibility, but I fear that it could become expensive to host (or be used maliciously).

Last edited by PullJosh (July 9, 2020 12:51:43)

PullJosh

Sprite layering blocks are now supported in Leopard!
That's right! Go to front/back and go forward/backward work now!

Here's what the JavaScript code looks like:

// go to front
this.moveAhead();
 
// go to back
this.moveBehind();
 
// go forward 1 layer
this.moveAhead(1);
 
// go backward 1 layer
this.moveBehind(1);

There is also a bonus feature which is ONLY available in JavaScript and is not possible in Scratch. When you're using Leopard, you can pass a sprite into the moveAhead and moveBehind functions and the current sprite will move ahead of or behind the sprite you passed in:

// Place the current sprite one layer in front of Sprite2!
this.moveAhead(this.sprites.Sprite2);
 
// Place the current sprite one layer behind Sprite2!
this.moveBehind(this.sprites.Sprite2);

This code doesn't equate to any particular Scratch block. It's just a nice bonus feature.

Bears8

PullJosh wrote:
Sprite layering blocks are now supported in Leopard!
That's right! Go to front/back and go forward/backward work now!

Here's what the JavaScript code looks like:
// go to front
this.moveAhead();
 
// go to back
this.moveBehind();
 
// go forward 1 layer
this.moveAhead(1);
 
// go backward 1 layer
this.moveBehind(1);
There is also a bonus feature which is ONLY available in JavaScript and is not possible in Scratch. When you're using Leopard, you can pass a sprite into the moveAhead and moveBehind functions and the current sprite will move ahead of or behind the sprite you passed in:
// Place the current sprite one layer in front of Sprite2!
this.moveAhead(this.sprites.Sprite2);
 
// Place the current sprite one layer behind Sprite2!
this.moveBehind(this.sprites.Sprite2);
This code doesn't equate to any particular Scratch block. It's just a nice bonus feature.

oh yes i've wanted this new feature in scratch for so long

theXliner

Oh yeah! One more thing:

(username)

Could equal to

PullJosh

or

User

theXliner

PullJosh wrote:
theXliner wrote:
I have a suggestion: instead of sb-edit converting sb3/sb2 files to a JavaScript/TypeScript objects or enums, could you make a second output option as lexical tokens? Or perhaps, less abundant, cleaner JSON? Since you know the code better, and since it has matured more, it would be easier for others to just parse the lexical tokens/JSON. I'm not complaining (for I am still committed to make my scratch-2-py (currently private) thing) but it'll make stuff a whole lot easier, much more potential for extension, and much easier for me. Can you do that? Just asking.
This is an interesting idea.

Once Leopard is more stable, I would consider going back and improving the API provided by sb-edit. Right now sb-edit inherits a lot of the jank from the sb3 file format, which is a shame. The ideal scenario is that sb-edit serves mostly as a clean, universal Scratch project representation, and inputs/outputs are modular.

This means that anyone could easily write code to either…
A) Import a Scratch project or asset from a particular format (sb, sb2, sb3, scratchblocks, tosh, etc) OR
B) Export a Scratch project or asset to a particular format (sb, sb2, sb3, Leopard, scratchblocks, tosh, etc)

It seems like you are most interested in manipulating project files using Python rather than JS. Once sb-edit improves, I see two paths forward:
A) Create a new format for importing/exporting projects as simple, generic JSON (which then allows you to pass a project between sb-edit and some external code) OR
B) Write some code in python and compile it with WebAssembly so that it can be packaged up and used with sb-edit directly.

Sorry, I don't have all the answers right now. Unfortunately, improving sb-edit remains a lower priority item for me until most of the problems with Leopard are solved.

I'm actually planning to convert scratch projects to pygame… But I'm writing my own parser/tokenizer in python first. Because currently, the sb-edit doesn't do this, yet. Maybe, if my tokenizer matured first, you can use it! I plan to dump the output of the tokens into an OUTPUT.txt file. Then parse that into scratchblocks (again, using python).

WalleBee

PullJosh wrote:
--Explosion-- wrote:
Cool! I'll try it out!
Let me know if you run into any issues!

3D projects dont work

PullJosh

WalleBee wrote:
3D projects dont work

Could you please link to some broken projects so that I can take a look?

PullJosh

Making good progress on variable watchers.

One of the interesting things with JavaScript is that an array (list) is just a value you store in a variable, not a different kind of thing. You can reassign a variable to an array at any moment, so each watcher needs to be ready to transform at any time.

The result is that all three watcher styles–normal, large, and slider–work for both variables and lists! (Because in JavaScript they're all just variables.)

Also notice that I have multiple watchers for the same variable. The underlying system is incredibly flexible. Any JavaScript expression, computed any way you want, can be displayed in a watcher. You just provide a function that computes the value to display. (Often this will be as simple as () => this.vars.myVariable, but it can also compute a value that isn't stored in any one variable and display that.) This also means that watcher labels don't have to match the internal variable name. (In the screenshot I'm displaying the variable “myVariable” as “My Variable”.)

I'm also planning to make it possible to change the color of each watcher. (And if you want something totally different, you can always write some custom CSS to change the appearance completely.)

This isn't ready to release yet, but it's on the way.

Boomer001

PullJosh wrote:
Making good progress on variable watchers.

One of the interesting things with JavaScript is that an array (list) is just a value you store in a variable, not a different kind of thing. You can reassign a variable to an array at any moment, so each watcher needs to be ready to transform at any time.

The result is that all three watcher styles–normal, large, and slider–work for both variables and lists! (Because in JavaScript they're all just variables.)

~snip~

Also notice that I have multiple watchers for the same variable. The underlying system is incredibly flexible. Any JavaScript expression, computed any way you want, can be displayed in a watcher. You just provide a function that computes the value to display. (Often this will be as simple as () => this.vars.myVariable, but it can also compute a value that isn't stored in any one variable and display that.) This also means that watcher labels don't have to match the internal variable name. (In the screenshot I'm displaying the variable “myVariable” as “My Variable”.)

I'm also planning to make it possible to change the color of each watcher. (And if you want something totally different, you can always write some custom CSS to change the appearance completely.)

This isn't ready to release yet, but it's on the way.

Cool!

PullJosh

Oh yeah! You'll also be able to change a bunch of the watcher properties on the fly from within your JavaScript code. So beyond just showing/hiding variables, you can also change a watcher position, width/height, or color, all while your project is running.

-Rex-

PullJosh wrote:
Any JavaScript expression, computed any way you want, can be displayed in a watcher.

Will there also be default functions for each of Javascript's data types?

If so, I assume

a = {};
a.a = a;

would produce a watcher with a “…”?

What about Maps and Sets and everything else on this page?

Last edited by -Rex- (July 9, 2020 18:42:24)

Discuss Scratch