Better Custom Blocks

peppermintpatty5

HoofEMP wrote:
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

That's indeed a very long reply
You're dropdown/insertion cap solution is very elegant!
And I'd like to remind everyone that exclusive or (XOR) is:

<not <<a::#000000> = <b::#000000>>>

wow, the scratchblock plugin has changed a lot!

#BringBackDiscuss

jokebookservice1

peppermintpatty5 wrote:
HoofEMP wrote:
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
That's indeed a very long reply
You're dropdown/insertion cap solution is very elegant!
And I'd like to remind everyone that exclusive or (XOR) is:
<not <<a::#000000> = <b::#000000>>>
wow, the scratchblock plugin has changed a lot!

Uhh uhh my thing returned false on success.. so yeah

(jk, I made a mistake)

And I really like the use of the new scratchblocks. Black looks shiny

Scratch_Mapping

//support!
define(custom reporter::custom)
{} (report []::custom-arg) :: custom cap //You can use these
define<custom boolean>
{} (report <>::custom-arg) :: custom cap

 :: obsolete
 :: #FFFFFF
 :: pen

Saiid

Scratch_Mapping wrote:

//support!
define(custom reporter::custom)
{} (report []::custom-arg) :: custom cap //You can use these
define<custom boolean>
{} (report <>::custom-arg) :: custom cap

please don't talk in scratchblocks

Saiid

Google Sv4mvJbXBJPClyDgc7p5WkYITBi618 to see all my posts

;

HoofEMP

Saiid wrote:
Scratch_Mapping wrote:
//support!
define(custom reporter::custom)
{} (report []::custom-arg) :: custom cap //You can use these
define<custom boolean>
{} (report <>::custom-arg) :: custom cap
please don't talk in scratchblocks

Saiid

He's right though.

AonymousGuy

Sorry for the annoying bump.

Saiid wrote:
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

Well, this is the only feedback I've gotten on this, and I agree, so I've gone ahead and done this. If anybody is interested in the old OP, you can find it here.

One more thing is that this topic has two distinct suggestions as part of it:

Custom reporters and booleans (I consider this one category - booleans are simply an optional feature of this suggestion)
Local variables

I think that it might be best to split off this suggestion - this topic would be custom reporters / booleans, and maybe I could make a new topic for local variables (or find one that already exists that would be designated as the “official” one).

cs395875

Use variables for reporters-booleans. Stack blocks already exists. You can use the “say” block to print out the reporter/boolean. So let's face it, no.

((((((((((((((((((((((((((((((((((((((((((((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)

jokebookservice1

cs395875 wrote:
Use variables for reporters-booleans. Stack blocks already exists. You can use the “say” block to print out the reporter/boolean. So let's face it, no.

I do not follow your logic. How are you supposed to do recursion? And even if you create an over-complicated workaround for recursion, I don't see how that means a suggestion shouldn't be implemented.

HoofEMP

cs395875 wrote:
Use variables for reporters-booleans. Stack blocks already exists. You can use the “say” block to print out the reporter/boolean. So let's face it, no.

Pardon, but why on earth would you use the “say” block?

braxbroscratcher

HoofEMP wrote:
cs395875 wrote:
Use variables for reporters-booleans. Stack blocks already exists. You can use the “say” block to print out the reporter/boolean. So let's face it, no.
Pardon, but why on earth would you use the “say” block?

Yes. It's really unprofessional.

My signature is kumquat proof.
But not tangerine pro-
nomnomnomnomnom

Current Project:
n/a
Quotes: “In our last hour, we burn the most brightly, trying to deny that we are burning out.” -Me
“Well, no. 1024 Killerbytes make a Murderbyte.” -MegaByteCorporations
“I hate out of context quotes.” -Me
“I hate it when Cubeupload breaks.” -Also me

HoofEMP

braxbroscratcher wrote:
HoofEMP wrote:
cs395875 wrote:
Use variables for reporters-booleans. Stack blocks already exists. You can use the “say” block to print out the reporter/boolean. So let's face it, no.
Pardon, but why on earth would you use the “say” block?
Yes. It's really unprofessional.

Appearance aside, what I meant was: why would you use the “say” block to print your function/boolean? There's barely any circumstance where one would want their sprite to say “true” or “false”.

Saiid

HoofEMP wrote:
braxbroscratcher wrote:
HoofEMP wrote:
cs395875 wrote:
Use variables for reporters-booleans. Stack blocks already exists. You can use the “say” block to print out the reporter/boolean. So let's face it, no.
Pardon, but why on earth would you use the “say” block?
Yes. It's really unprofessional.
Appearance aside, what I meant was: why would you use the “say” block to print your function/boolean? There's barely any circumstance where one would want their sprite to say “true” or “false”.

That is exactly what I was wondering

Saiid

Google Sv4mvJbXBJPClyDgc7p5WkYITBi618 to see all my posts

;

Rodidudu

But how to make

(this block)

in scratch?

Last edited by Rodidudu (Dec. 9, 2016 17:30:55)

Tomas2468

Support

when I wake up::hat events
go to [computer v]
turn on [computer v]::stack motion
repeat until <(time) = [23:59]>
think::custom
draw::pen
code::motion
think again::custom
code::motion
share::variables
end
sleep::custom

space_elephant

I think there should also be custom hat blocks and cap blocks.

custom hat ::custom hat

is the same as

when<custom boolean ::custom>is true ::events hat

and

custom cap ::custom cap

is the same as

custom stack ::custom
stop [this script v]

So custom hat blocks are programed as boolean blocks and custom cap blocks are programed as stack blocks.

red link

[url=redlink.com][color=red][u]red link[/u][/color][/url]

HoofEMP

space_elephant wrote:
I think there should also be custom hat blocks and cap blocks.
custom hat ::custom hat
is the same as
when<custom boolean ::custom>is true ::events hat
and
custom cap ::custom cap
is the same as
custom stack ::custom
stop [this script v]
So custom hat blocks are programed as boolean blocks and custom cap blocks are programed as stack blocks.

Well, really,

custom stack::custom
stop [this script v]

is probably too easy of a workaround to a custom cap for the ST to implement, if they implement this suggestion at all. Besides, your custom hat also has a very easy workaround;

when flag clicked
wait until <custom bool::custom>
...::cap

dvargasews

Snap! has these.

Please read my signature! It might explain some lingo that I used in my post or comment. However, not all of it shows, so you have to highlight the entire bottom of the post, from “Please read my signature!” to where it says report, and copy and paste in into a new sheet or tab or whatever.
I can't decide my signature between:
1. I'm a grammar stickler, and my pet peeve is when people use good as an adverb.
2. I have lots of [creativity]original ideas[/creativity]. [creativity]This[/creativity] is one of those ideas.
3. If I used this symbol: ⸮ in my comment, please look it up before doing anything else.
4. {Minot, North Dakota/Donald Trump parodies} “WE'RE GONNA BUILD A DAM AND MAKE CANADA PAY FOR IT!” “When Canada sends its water, they’re not sending their best drinking water…They’re bringing sleet. They’re bringing floods. The water's toxic.” (It's just a joke that I came up with.)
5. One should make his/her signature text small; that way (s)he can cram more text into the signature.
6. New [scratchblocks] idea each week! (Thanks to Bright-Idea (Read her signature.) for inspiration/the general idea.) Here's the archive:
Note: I stopped this because of signature character limits.
Week of 1-23-2017: Hat-caps tinyurl.com/htauyu2
Week of 1-16-2017: Country-colored scratchblocks tinyurl.com/z8lz6c4
Week of 1-9-2017: Drop-down booleans tinyurl.com/j5d3k6l
Week of 1-2-2017: Block->string inputs and more truth values tinyurl.com/jqu7avs

dvargasews

HoofEMP wrote:
space_elephant wrote:
I think there should also be custom hat blocks and cap blocks.
custom hat ::custom hat
is the same as
when<custom boolean ::custom>is true ::events hat
and
custom cap ::custom cap
is the same as
custom stack ::custom
stop [this script v]
So custom hat blocks are programed as boolean blocks and custom cap blocks are programed as stack blocks.
Well, really,
custom stack::custom
stop [this script v]
is probably too easy of a workaround to a custom cap for the ST to implement, if they implement this suggestion at all. Besides, your custom hat also has a very easy workaround;
when flag clicked
wait until <custom bool::custom>
...::cap

That's not a perfect workaround because the code would only run once.

Please read my signature! It might explain some lingo that I used in my post or comment. However, not all of it shows, so you have to highlight the entire bottom of the post, from “Please read my signature!” to where it says report, and copy and paste in into a new sheet or tab or whatever.
I can't decide my signature between:
1. I'm a grammar stickler, and my pet peeve is when people use good as an adverb.
2. I have lots of [creativity]original ideas[/creativity]. [creativity]This[/creativity] is one of those ideas.
3. If I used this symbol: ⸮ in my comment, please look it up before doing anything else.
4. {Minot, North Dakota/Donald Trump parodies} “WE'RE GONNA BUILD A DAM AND MAKE CANADA PAY FOR IT!” “When Canada sends its water, they’re not sending their best drinking water…They’re bringing sleet. They’re bringing floods. The water's toxic.” (It's just a joke that I came up with.)
5. One should make his/her signature text small; that way (s)he can cram more text into the signature.
6. New [scratchblocks] idea each week! (Thanks to Bright-Idea (Read her signature.) for inspiration/the general idea.) Here's the archive:
Note: I stopped this because of signature character limits.
Week of 1-23-2017: Hat-caps tinyurl.com/htauyu2
Week of 1-16-2017: Country-colored scratchblocks tinyurl.com/z8lz6c4
Week of 1-9-2017: Drop-down booleans tinyurl.com/j5d3k6l
Week of 1-2-2017: Block->string inputs and more truth values tinyurl.com/jqu7avs

peppermintpatty5

dvargasews wrote:
Snap! has these.

We're aware of that! Just that it'd be nice if Scratch had it too

#BringBackDiscuss

HoofEMP

dvargasews wrote:
HoofEMP wrote:
space_elephant wrote:
I think there should also be custom hat blocks and cap blocks.
custom hat ::custom hat
is the same as
when<custom boolean ::custom>is true ::events hat
and
custom cap ::custom cap
is the same as
custom stack ::custom
stop [this script v]
So custom hat blocks are programed as boolean blocks and custom cap blocks are programed as stack blocks.
Well, really,
custom stack::custom
stop [this script v]
is probably too easy of a workaround to a custom cap for the ST to implement, if they implement this suggestion at all. Besides, your custom hat also has a very easy workaround;
when flag clicked
wait until <custom bool::custom>
...::cap
That's not a perfect workaround because the code would only run once.

when flag clicked
forever
wait until <custom bool::custom>
...
end

Discuss Scratch