I added a whole lot of custom blocks: Snap! Build Your Own Blocks what do you think, also im not dumb enough to drag them all on to the canvas
you probably right clicked the hat script, clicked ringify, dragged in into the definition of (don't see inside ::other) , right clicked the hat in the ring, then clicked unringify,
I’ve only looked at the motion blocks for now,
For the point towards x,y block, you can already do this. Just drag a list into a “point towards” block. The first item will be the x while the second will be the y.
What do the “direction” and “go to __ speed limit” blocks do?
i’m noticing a few issues throughout some of your blocks. i’ll go category-by-category with the issues/fixes:
Motion
go to [random position V] speed limit at (10)::motion
in this block, you check for the distance to n, but then you point towards the mouse pointer, rather than n. you can also optimize both parts of your script, first by replacing the bottom condition with just go to (n), and the top part by using your other block, move _ steps in direction _, as such:
Looks
go [forward V] (1) layers::looks
in this block, you check for n = forward in both conditions. the correct version should be:
bubble text::looks reporter
to make it more user-friendly, you should use your Javascript on? block to fallback to an empty string instead of throwing an error. you can also use this instead of obj with input object [myself] in your JS code, though it will require a fallback check so it doesn’t cause significant lag.
let bubble = this?.children?.[0]?.data
return bubble ? bubble : ""
so your new code would be
saying or thinking?::looks reporter
i feel like this would be more valuable to the user if it were a boolean, like am i [saying]?. the current version returning a string of saying or thinking feels intuitive, but makes real usage slightly annoying. here’s my revamped version:
[ V] rotated (15 v) degrees::looks reporter
for the let oldcost <- [name] of costume [current] part, it’s better to use my [costume], since the caller’s costume could potentially not be stored in the costume list.
tint [current V] [rgb(145,26,68)] (50)%::looks reporter
this block does have a possibly confusing side effect of changing the alpha of each color as well, making it potentially confusing to some people. i suggest retaining the alpha of the original image with the tinted new image (as a toggle though, in case some people want the alpha to also be affected), though I couldn’t find any fast/efficient way to do this for myself
Pen
stamp costume [ V]::pen
same problem here as with _ rotated _ degrees; you should use my [costume] instead of [name] of costume [current].
Control
go to url []::control
inside this block, you put a comment saying you don’t need js, but it’s easier to use it.
to this i say: everything is easier in Snap! with js! but if everybody went by that, it would take most of the fun out of Snap! in the first place. i recommend using the non-js solution (i’m curious to see it as well :D). though if you do keep the js, i recommend using your Javascript on? block to check beforehand. same thing for new tab with url _.
repeat for (1) secs {
}::control
inside the definition, you launch wait 1 secs instead of wait (sec) secs before completing the loop. also, i recommend checking the loop arrow for the c input, so it stays consistent with Snap! and easily conveys what is being looped.
switch [ V] {
}::control and switch [ V] {
} default {
}::control
why make the n input on these read-only? i know it’s what PenguinMod does (since I can tell most of these are inspired by PenguinMod’s block selection), but it’s nice to let the user directly type in values if they’re testing things and seeing what exactly it does.
exit case::control
this block isn’t used anywhere that I can see, in the case block nor either of the switch blocks.
every (1) [st V] frame::control hat
the th slot is a bit fancy, i admit, though it doesn’t really add anything to the block other than help be grammatically correct. i recommend removing it and changing the label to be every _ frames, which would also let you get rid of every other frame and always.
when <> \n if not then ({} @>)::control hat
this might look better as
if <> then {
} if <> then {
}@<:> ::control
this is the same block as if <> {
} else if <t> {
} @<>, but with the added functionality of letting you collapse it into @:> ::control.
what does this block do differently from the existing if block?
call [ V] @:> ::control reporter, run [ V] @:> :: control, and launch [ V] @:> :: control
okay, this is confusing me, because.. what do these do different from their existing versions?
apply (() @>) to [] (10) times ((index))::control reporter
this block exists already in the Iteration, composition library, with the name
cascade () times (() @>) [] ((#))::control
take [] @<:> ::control
what does this block do/what is it for? it’s definition is empty.
Sensing
time to run (() @>) in ms::sensing reporter
you don’t really need the extension [err_ignore] here, i suggest removing it.
pan [myself V] based on [] if <t> reversed? <f>::sensing
what’s the point of this block? based on the label and definition, i think it’d be better fit in the motion category, but I still can’t tell what it’s actually supposed to be doing.
open url https:// [] create-new-tab? <t>
you already have new tab with url _, so i recommend keeping one or the other.
clipboard text::sensing reporter and clipboard image::sensing reporter
i recommend using your Javascript on? check here.
Operators
sort @list from [least to greatest V]::operators reporter
this block already exists in the list category, in the dropdown for [length] of _
[mean V] of @list::operators reporter
for mode, you can use item (1 v) of (item (1 v) of ([distribution V] of @list)), since distribution returns how many times each item in the input list appears inside the list, and automatically sorts it.
also, in your median calculation, you make a small error in this part:
you meant to do
instead of 
letters from () to () in [{}]::operators reporter
the definition of this block can be simplified by using the numbers from _ to _ block, like this:
(4) [th V] root of (16)::operators reporter
same point from the every _ frame block with this block, the th slot is fancy but doesn’t really add anything.
(100) \n Σ (() @>) \n ((i)) = (1)::operators reporter
you can simplify the definition by again using numbers from _ to _, the map operation, and sum, as such:
(100) \n Π (() @>) \n ((i)) = (1)::operators reporter
same as the previous one, but with product:
(5)'s distance from (7) is [less V] than (3)::operators reporter
i think it’d be nicer to use, and give the user more options, if theless slot was a predicate instead, and the definition would be
Why the <<true> and <...>> part?
the <t> and (call (operation) @:>) part is to make sure the output is always a boolean, since using only call (operation) @:> returns (<> @>) if the predicate is left blank.
fix (3.999)::operators reporter
the definition of this one has to be tweaked slightly from the last change:
(4) [th V] log of (16)::operators reporter
once again, same point from the every _ frame block with this block, the th slot doesn’t add anything to the code.
Javascript on?::operators boolean
this one stumped me. the logic is correct, but there’s a weird side effect of directly using the safely try reporting _ definition over the block itself, where it sometimes returns its value from the scope of the script its in, rather than from itself:
and sometimes exits the current script early, causing nothing to happen at all:
Lists
find (1) [st V] item (<> @>) in @list::list reporter
once again again, the th slot isn’t contributing here.
@list metacontains []::list boolean
this block’s definition can be hugely simplified using [flatten] of _:
remove all of [thing] in @list::list
this one has a subtle issue. every time you delete an item from the list, everything shifts down by one, which misaligns the previously built index list:
you can fix this by adding change [sub V] by (-1) after the delete (item) of (list), since changing a list by a number decrements each number in that list, so each index is shifted down as the list items are removed:
list with pattern [] @<:> and length (10) shifted by (0)::list reporter and shift @list by (1)::list
a few things with both of these. first, i’d change the name of the first block to be repeat _ to length _ shift by _ to make it shorter. next i’d change the definition of shift _ by _ to mutating operations, since your implementation implies mutation, but doesn’t actually change the list:
the same effect can be achieved using this new definition:
then, the
repeat _ to length _ block can be updated to use a new, much much shorter definition:
clip @list from item (1) to (4)::list reporter
this block can be heavily simplified with the use of numbers from _ to _ and item _ of _, since item ( v) of @list is hyperized for the index slot:
every (3) [rd V] item in @list::list reporter
once again again again, i’d recommend removing the th slot and relabeling the block as every _ items in _
every index of [] in @list::list
if you want to make the label of this block shorter, i’d rename it to something like indices of _ in _.
you can use a combination of map, keep, and [columns] of _ to simply the definition as well:
@list exactly contains []::list boolean
the definition for this one can be simplified down to:
cross product @list::list reporter
this block already exists natively as combinations @list @list @<:>:
item (1) @<:> of @list::list reporter
you can cleanly simplify this block by mapping over the input indices:
those are all the basic categories for now, i’ll look over the 3 custom categories after i’m back from lunch!
You made a teeny typo:
ah, im so sorry about that! fixed!
ohh that’s right, i knew this existed and had seen it elsewhere, i just didn’t know where from..
You can also just set [list V] to (keep items (<not <[] = [thing]>> @>) from (list))
yeah, but,.. actually nevermind, you’re right- i was gonna attempt a point about keeping it similar to the original code they made, before i realized i changed a lot of things..
Yes, but if you’re using a command block, you’d expect it to be all done in place with the input list instead of creating a brand new list (which is what keep items does). I do agree, keep items is a much more elegant solution, but it would mean the block should be a reporter instead.
only thing I can recommend is that in the nth root reporter is to check the last letter of the input, as 102 shows as 102th and not 102nd (I know it’d rarely be used with high numbers like that and its more of a nitpick on grammar and doesn’t effect the function)
11st
way to spoil it huh
scratch took down their api i think
No, it’s cors…
I fixed the blocks :D
Using @owlsss 's CORS proxy and the scratch API, I fixed all the blocks. It includes deleted users though!
(bubble text::looks)
I recommend you use the ?? operator (which returns the second input if the first is null or undefined, otherwise the first):
Before
return bubble ? bubble : ""
After
return bubble ?? ""
Otherwise, the block will report an empty string if the bubble text is 0 (as a number in JS) or false (as a Boolean).
(Claim not backed, tell me if I’m wrong)
You must have a long lunch