Please use this thread to discuss Leopard, share your projects, and ask for help.

Thank you so much to the contributors who made Leopard possible!

--Explosion-- wrote:

Cool! I'll try it out!

Geotale wrote:

Quick bug: Testing this project in forkphorus, it seems to work fine, though with Leopard it freezes the webpage. I don't know what could cause this, but it does render everything before freezing completely fine. Looking through it in the code sandbox it seems to be a problem with the custom block not having a yeild, and for some reason certain booleans are expected to use “===” instead of “==”. Overall, really cool!

Randoming wrote:

Wow, awesome! I don't know any JavaScript so I'm using this to help me learn a bit. Quick question though, how would you make an “if on edge, bounce” function because I kind of need it.

Sheep_maker wrote:

Geotale wrote:

…

I think the linter just prefers ===, but JavaScript won't really care. == is more akin to Scratch's _ = _ block because the number 1 is equal to the string “1.”
…

Geotale wrote:

Quick bug: Testing this project in forkphorus, it seems to work fine, though with Leopard it freezes the webpage. I don't know what could cause this, but it does render everything before freezing completely fine.

Geotale wrote:

Looking through it in the code sandbox it seems to be a problem with the custom block not having a yeild, and for some reason certain booleans are expected to use “===” instead of “==”.

Geotale wrote:

Overall, really cool!

Randoming wrote:

How would you make an “if on edge, bounce” function because I kind of need it.

define slightly worse if on edge, bounce
if <([abs v] of (x position)) > (240)> then // Change 240 to be smaller until it works for your size sprite
  point in direction ((0) - (direction))
end
if <([abs v] of (y position)) > (180)> then // Change 180 to be smaller until it works for your size sprite
  point in direction ((180) - (direction))
end

PullJosh wrote:

Randoming wrote:

How would you make an “if on edge, bounce” function because I kind of need it.

Good question! That block isn't currently supported, but it should be possible to add it in the future. In the meantime, this custom block might get the job done:

define slightly worse if on edge, bounce
if <([abs v] of (x position)) > (240)> then // Change 240 to be smaller until it works for your size sprite
  point in direction ((0) - (direction))
end
if <([abs v] of (y position)) > (180)> then // Change 180 to be smaller until it works for your size sprite
  point in direction ((180) - (direction))
end

It isn't perfect, but it's better than nothing. Here it is in a working project.

KarateToast wrote:

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

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

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

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

https://scratch.mit.edu/projects/393099913/
All didn't seem to work.

1. You're using the “letter of” operator block to get a character within a number (like 111110000111000). Scratch treats the number like a string, but Leopard just gets confused. I can fix this by changing the translator to always include .toString() in the exported JavaScript. That makes the code a little uglier for the average project, but at least it works.
   
2. In Leopard, the touching block returns false when ghost effect is 100, but Scratch seems to ignore ghost effect for “touching”. This can also be fixed.
   
3. The most annoying part about this is that Leopard doesn't stop the arrow keys from scrolling the page. I'm not sure exactly what's up with the physics.
   
4. Super unexpected issue on this one. The “ground tick” broadcast isn't working properly because it translated wrong. In the translated JavaScript code, the broadcast being sent out is called “ground tick”, but the one being received is called “Ground Tick”. The capitalization is different! I'll have to look into why this is happening. Not one I expected to encounter, but hopefully an easy fix?
   
5. “Touching edge” is not yet implemented and it's causing an error.
   

1. Projects seem to run too fast. While Scratch projects usually run at 30 FPS, I've found that Leopard runs them at a framerate equal to the monitor's refresh rate - in most cases, this will result in projects running between 2x and 2.5x their correct speed. Is this intentional? You may want to consider adding an optional “compatibility mode” of sorts that locks the framerate at 30.
   
2. Variable readouts aren't supported. Is this intentional?
   
3. While trying to make a project to demonstrate the first issue, I had to work around the second issue by making my own readout for the framerate, but it doesn't work in Leopard (note that it abuses Scratch's implicit type conversion). Here is the project in question: https://scratch.mit.edu/projects/409788163
   

PullJosh wrote:

CodeSandbox uses a tool called ESLint to analyze your JavaScript and give you helpful tips to improve your code. Certain rules, like requiring a yield, or using === instead of ==, are usually a good idea, but it makes sense for us to break them so that projects remain compatible with Scratch. I've tried to find a way to turn ESLint off for converted projects but haven't found one.

/* eslint require-yield: "off", eqeqeq: "off" */