Better Custom Blocks

Jonathan50

jokebookservice1 wrote:
Blaze349 wrote:
Support Have I already
Please don't just support or no support a suggestion, it doesn't help the suggestion because the Scratch Team doesn't care how many votes a suggestion has . Click my signature for more information

I don't think it's a good idea to post this whenever you see posts like that, it's spamming.

Not yet a Knight of the Mu Calculus.

TheMonsterOfTheDeep

Jonathan50 wrote:
jokebookservice1 wrote:
Blaze349 wrote:
Support Have I already
Please don't just support or no support a suggestion, it doesn't help the suggestion because the Scratch Team doesn't care how many votes a suggestion has . Click my signature for more information
I don't think it's a good idea to post this whenever you see posts like that, it's spamming.

+1

I think posting “non-constructive” as a reply to a post is also non-constructive.

Although, that being said, this very post that I'm writing is also mostly non-constructive.

my latest extension: 2d vector math

Falcon1234567

Support

if <split1 ::variable> then
move (10) steps
end

Blaze349

jokebookservice1 wrote:
Blaze349 wrote:
Support Have I already
Please don't just support or no support a suggestion, it doesn't help the suggestion because the Scratch Team doesn't care how many votes a suggestion has . Click my signature for more information

I support this because of the reasons listed in my duplicate topic

Visit Christian HQ.

jokebookservice1

Jonathan50 wrote:
jokebookservice1 wrote:
Blaze349 wrote:
Support Have I already
Please don't just support or no support a suggestion, it doesn't help the suggestion because the Scratch Team doesn't care how many votes a suggestion has . Click my signature for more information
I don't think it's a good idea to post this whenever you see posts like that, it's spamming.

In some ways. Though doing a bit of spam should prevent more spam.

TheMonsterOfTheDeep wrote:
Jonathan50 wrote:
jokebookservice1 wrote:
Blaze349 wrote:
Support Have I already
Please don't just support or no support a suggestion, it doesn't help the suggestion because the Scratch Team doesn't care how many votes a suggestion has . Click my signature for more information
I don't think it's a good idea to post this whenever you see posts like that, it's spamming.
+1

I think posting “non-constructive” as a reply to a post is also non-constructive.

Although, that being said, this very post that I'm writing is also mostly non-constructive.

Falcon1234567 wrote:
Support
if <split1 ::variable> then
move (10) steps
end

Please don't just support or no support a suggestion, it doesn't help the suggestion because the Scratch Team doesn't care how many votes a suggestion has

. Click my signature for more information

I was already making a post so I don't classify this as spam

____________________________________________________________________________

I think the reporter blocks should be added because they are just as confusing (or not confusing) as the stack blocks in my opinion

Griffenlover

support! these seem really ussfal! (sorry if i misspelled) and not to complicated since custom blocks are already a thing new scratchers woudln't understand on the spot, and it would deffintly make everything more orginized
(if you need to know how i got here i got sent from a duplicate)

play my desert decorate game!
help me with pokemon channel please!
if you see me on forums a lot that's because i get bored a lot so i browse forums :L
i mostly use forums, but i'm debating weither to animate again now that i have my drawing tablet
if you see this then you earned a hug

HoofEMP

You shouldn't use

report <>::#5846B0 cap

for the booleans. Just use these:

report true::#5846B0 cap
report false::#5846B0 cap

I also prefer the C-block style local variables over the green-looking ones, just because it seems it would be easier to keep track of. The temp variables in the Cs should be colour-coded differently, though, like the green blocks. Temp lists should definitely not be colour-coded as normal vars.
Other than that, I support everything!
Here are some Scratchblocks versions of the blocks you can use in case nobody made them already:

report []::#5846B0 cap
Custom Reporter []::custom reporter
Custom Boolean []::custom boolean

create variable (var::#EEC216 reporter)::#6D897C stack
create list (list::variables reporter)::#6D897C stack
set (var::#EEC216 reporter) to []::#6D897C stack
add [thing] to (list::variables reporter)::#6D897C stack

using (Var::variables reporter)(+::variables reporter){
using (List::list reporter)(+::list reporter){
}::#666666
}::#666666//I was not able to make the pluses render black.

The_Amaru wrote:
But does a
when <> :: hat events
block exist?

/discuss/topic/223202/

jokebookservice1 wrote:
I think the reporter blocks should be added because they are just as confusing (or not confusing) as the stack blocks in my opinion

I agree with this.

Last edited by HoofEMP (Nov. 19, 2016 17:46:31)

TheMonsterOfTheDeep

@all:

Do you guys think I should remove the supporters count / list from the first post, as arbitrary supporter count is now considered to be a less than ideal metric on the suggestions forum?

my latest extension: 2d vector math

Saiid

TheMonsterOfTheDeep wrote:
@all:

Do you guys think I should remove the supporters count / list from the first post, as arbitrary supporter count is now considered to be a less than ideal metric on the suggestions forum?

Yes, absolutely

Saiid

Google Sv4mvJbXBJPClyDgc7p5WkYITBi618 to see all my posts

;

jokebookservice1

HoofEMP wrote:
You shouldn't use
report <>::#5846B0 cap
for the booleans. Just use these:
report true::#5846B0 cap
report false::#5846B0 cap

I disagree, sometimes you want to put an expression in there and you then would have to an if report else report. How about extra reporters are added,

<true::operators>
<false::operators>

This way, you could do

define XOR (a) (b) ::boolean
report <(a) = (b)> ::custom

or if you just want to do it you can do

define do something ::boolean
if <...> then
...
report <false::operators>::custom
end
report <true::operators>::custom

Last edited by jokebookservice1 (Nov. 19, 2016 10:58:56)

peppermintpatty5

jokebookservice1 wrote:
HoofEMP wrote:
You shouldn't use
report <>::#5846B0 cap
for the booleans. Just use these:
report true::#5846B0 cap
report false::#5846B0 cap
I disagree, sometimes you want to put an expression in there and you then would have to an if report else report. How about extra reporters are added,
<true::operators>
<false::operators>
This way, you could do
define XOR (a) (b) ::boolean
report <(a) = (b)> ::custom
or if you just want to do it you can do
define do something ::boolean
if <...> then
...
report <false::operators>::custom
end
report <true::operators>::custom

Report, being the equivalent of a return statement, should be a cap block so that no blocks can be placed under it. After a return statement, the method breaks and the code underneath doesn't run. But I agree, sometimes I want to evaluate an expression in the return statement rather than using a literal. and close your scratchblocks tags please :P

#BringBackDiscuss

HoofEMP

jokebookservice1 wrote:
HoofEMP wrote:
You shouldn't use
report <>::#5846B0 cap
for the booleans. Just use these:
report true::#5846B0 cap
report false::#5846B0 cap
I disagree, sometimes you want to put an expression in there and you then would have to an if report else report. How about extra reporters are added,
<true::operators>
<false::operators>
This way, you could do
define XOR (a) (b) ::boolean
report <(a) = (b)> ::custom
or if you just want to do it you can do
define do something ::boolean
if <...> then
...
report <false::operators>::custom
end
report <true::operators>::custom

Please, in the future, use a closing Scratchblocks tag.
Now…
Those <true> and <false> booleans? Just do this:

<not <empty::grey>>//reports true
<not <not <empty::grey>>>//reports false

Shouldn't an XOR be this?

define <a> XOR <b>::boolean
if <a> then
if <not <b>> then
report true::#5846B0 cap
end
else
if <b> then
report true::#5846B0 cap
end
end
report false::#5846B0 cap

The example you showed that said “XOR” was just a clone of <[] = []>.
You could also do this for it:

define (a) = (b) clone::boolean
if <(a) = (b)> then
report true::#5846B0 cap
end
report false::#5846B0 cap

I'd imagine most people wouldn't put a boolean like you did in report, because of above. Besides, for other purposes, you would also need “report true” and “report false”. Example:

define (base) contains (sub)?::custom boolean
using (pos1::#EEC216)(pos2::#EEC216)(grouper::#EEC216)(+::#EEC216){
set [pos1 v] to [0]::#EEC216
repeat (((length of (base)) - (length of (sub))) + (1))
set [grouper v] to (empty::grey)::#EEC216
set [pos2 v] to (pos1::#EEC216)::#EEC216
repeat (length of (sub))
set [grouper v] to (join (grouper::#EEC216) (letter (pos2::#EEC216) of (base)))::#EEC216
change [pos2 v] by (1)::#EEC216
end
if <(grouper::#EEC216) = (sub)> then
report true::#5846B0 cap
end
change [pos1 v] by (1)::#EEC216
end
}::#666666//I like the yellow for temp variables. So I'll use that colour with the C.
report false::#5846B0 cap

You might also have a very specific boolean, in which case you'd need quite a few return caps. I'm sure creators would prefer if they didn't have to drag nots into there every time they made a report. If the ST wanted to, they could even do this:

report [true v]::#5846B0 cap

and let bools be placed inside of it. You'd get the functionality of both combined!

(note: you wouldn't be able to condense

if <(grouper::#EEC216) = (sub)> then
report true::#5846B0 cap
end

into just a report bool. I only want the script to end when grouper = sub.)

Last edited by HoofEMP (Nov. 19, 2016 16:26:49)

HoofEMP

peppermintpatty5 wrote:
jokebookservice1 wrote:
snip::variables
Report, being the equivalent of a return statement, should be a cap block so that no blocks can be placed under it. After a return statement, the method breaks and the code underneath doesn't run. But I agree, sometimes I want to evaluate an expression in the return statement rather than using a literal. and close your scratchblocks tags please :P

Lol, I took so long to write my reply someone wrote before me
See my above statement regarding literals

Last edited by HoofEMP (Nov. 19, 2016 16:03:43)

jokebookservice1

Oops, I don't usually forget to close my tags, sorry about that.

@peppermintpatty5 yep

@HoofEMP

Your true/false workarounds work, but what is the point? When you can always just add a couple blocks to Scratch (or a single blocks with a dropdown)

XOR in terms of booleans is the same as the equals block. When it comes to the bitwise operator, it is not. Anyway, yes, that works, but why do that when you could do it in one line. Being able to drag booleans into a dropdown, but not reporters, would be a new twist to Scratch. I think that there is not much point though.

HoofEMP

jokebookservice1 wrote:
Oops, I don't usually forget to close my tags, sorry about that.

@peppermintpatty5 yep

@HoofEMP

Your true/false workarounds work, but what is the point? When you can always just add a couple blocks to Scratch (or a single blocks with a dropdown)

I don't think ST will add <true> and <false> for the same reason they won't bring back forever if.

jokebookservice1 wrote:
XOR in terms of booleans is the same as the equals block. When it comes to the bitwise operator, it is not.

I see. But why create a custom XOR when you already have <[] = []>?

jokebookservice1 wrote:
Anyway, yes, that works, but why do that when you could do it in one line. Being able to drag booleans into a dropdown, but not reporters, would be a new twist to Scratch. I think that there is not much point though.

I meant just for the report block specifically. The boolean in the return block would return “true” or “false”, and “true” and “false” are the only items in the drop-down list. I just proposed that to condense the following all into one block:

return true::#5846B0 cap
return false::#5846B0 cap
return <>::#5846B0 cap

I did make a post about using ors with some specific drop-downs in Scratch, and in hindsight, it does not make much sense.

Last edited by HoofEMP (Nov. 19, 2016 17:44:48)

Thelnvoker

I support #3. What exactly would #1 and #2 be used for? Like, how could they be used in coding?

I'm a basically a potato or cat or something with a very dark sense of humor who likes steampunk, traditional art, Skyrim, etc.

Anyone wanna RP with me?

HoofEMP

Thelnvoker wrote:
I support #3. What exactly would #1 and #2 be used for? Like, how could they be used in coding?

Think of custom reporters as functions. See my above posts for an example of what you could do with a custom bool.

Last edited by HoofEMP (Nov. 19, 2016 17:40:54)

cs395875

1. No Support. Already exists.
2. No Support. Use variables.
3. No Support. Use variables.

((((((((((((((((((((((((((((((((((((((((((((colourful blocks::custom)::looks)::sound)::sensing)::motion)::pen)::operators)::control)::variables)::obsolete)::list)::custom)::looks)::sound)::sensing)::motion)::pen)::operators)::control)::variables)::obsolete)::list)::custom)::looks)::sound)::sensing)::motion)::pen)::operators)::control)::variables)::obsolete)::list)::custom)::looks)::sound)::sensing)::motion)::pen)::operators)::control)::variables)::obsolete)::list)

Saiid

cs395875 wrote:
1. No Support. Already exists.
2. No Support. Use variables.
3. No Support. Use variables.

No they don't…
Some things you just can't use variables for
He wants to use variables, but variables that are local to the block.

Saiid

Google Sv4mvJbXBJPClyDgc7p5WkYITBi618 to see all my posts

;

Jonathan50

HoofEMP wrote:
But why create a custom XOR when you already have <[] = []>?

1. For abstraction
2. To make the code more self-documenting

Not yet a Knight of the Mu Calculus.

Discuss Scratch