my mouse keeps freezing, so i have to do this in a new post: scratch 0.6-1.4 are the main versions with that block. (king of the page no edit!)

Support! I use these all the time in python so why not have them easily accessible in scratch.

bump ig

sapourt

ninjaMAR wrote:

Support! I use these all the time in python so why not have them easily accessible in scratch.

This suggestion is not “easily accessible”. Putting them directly into the palette is.

fdreerf wrote:

ninjaMAR wrote:

Support! I use these all the time in python so why not have them easily accessible in scratch.

This suggestion is not “easily accessible”. Putting them directly into the palette is.

It's easily accessible for those who would need them

the2000 wrote:

fdreerf wrote:

ninjaMAR wrote:

Support! I use these all the time in python so why not have them easily accessible in scratch.

This suggestion is not “easily accessible”. Putting them directly into the palette is.

It's easily accessible for those who would need them

Why not make it easily accessible for everyone? I will guarantee that if this were added the majority of people will not know, including lots who would need those blocks.

The “when this sprite touches” is both a sensing and an events block:

How would that be in the Scratch editor? As a sensing-events block, or an events block.

I do like this idea, though.

216138 wrote:

sapourt

Please be constructive.

Unless scratch actually intended to hide these blocks instead of removing them, I don't see why they would add them back just for the purpose of them being “hidden”. Semi-support

Zoomer_X wrote:

The “when this sprite touches” is both a sensing and an events block. How would that be in the Scratch editor? As a sensing-events block, or an events block.

Out of curiosity, did you get that from my project? If not, then I'll know that the weird behavior isn't just a result of me hacking it in improperly. If so, then it's a small world I guess Anyway I don't think that the weird coloration is intentional. I've said this in the past but it seems like this block was added hurriedly with very little testing, which is strange for a block that never existed in any previous versions but whatever.

scratchastroLOL wrote:

Unless scratch actually intended to hide these blocks instead of removing them, I don't see why they would add them back just for the purpose of them being “hidden”. Semi-support

It wouldn't be hard for them to remove these. The Scratch 3 source code is publicly available and it's not like they're hard to find. They won't have to “add them back” because they already function perfectly (with the sorta exception of that block above), this will just be putting them in a place that's easier to find.

the2000 wrote:

this will just be putting them in a place that's easier to find.

There are people that don't even know about Turbo Mode, what makes you think that Ctrl+Shift+R would be the easiest place to find these blocks?

fdreerf wrote:

the2000 wrote:

this will just be putting them in a place that's easier to find.

There are people that don't even know about Turbo Mode, what makes you think that Ctrl+Shift+R would be the easiest place to find these blocks

Again, not easiest, just more convenient for people who do know about this already. As I've stated they seem to be opposed to adding these to the traditional block palette, so making them toggleable in an obscure way that's still quick enough if you know what you're doing seems like a decent compromise to me.

Yeah, even I, a dedicated searcher of the wiki, never even knew about the hidden blocks in the first place. I would simply just put them into the block pool. This was my 100th post!

ThatExplosivePigeon wrote:

Yeah, even I, a dedicated searcher of the wiki, never even knew about the hidden blocks in the first place. I would simply just put them into the block pool.

I guess I'm a better dedicated searcher of the wiki than you are then I think that this trick would probably circulate more than the current hidden blocks just because it would be pretty easy to pull off.

That reminds me, I promised to write a bookmarklet which could detect when the user shift+clicks the R in the logo. I was too bored to finish that. Maybe I could work on it tomorrow. I got most of it done already

I don't even know so I just do the “Random Page” button over and over again. Hehheheh

the2000 wrote:

If not, then I'll know that the weird behavior isn't just a result of me hacking it in improperly.

It is. The correct opcode for the sprite menu is event_touchingobjectmenu.

Maximouse wrote:

the2000 wrote:

If not, then I'll know that the weird behavior isn't just a result of me hacking it in improperly.

It is. The correct opcode for the sprite menu is event_touchingobjectmenu.

Okay, thanks. I'll go fix that… eventually

the2000 wrote:

Again, not easiest, just more convenient for people who do know about this already. As I've stated they seem to be opposed to adding these to the traditional block palette, so making them toggleable in an obscure way that's still quick enough if you know what you're doing seems like a decent compromise to me.

I think it would be best to maybe put them in an extension.

fdreerf wrote:

the2000 wrote:

Again, not easiest, just more convenient for people who do know about this already. As I've stated they seem to be opposed to adding these to the traditional block palette, so making them toggleable in an obscure way that's still quick enough if you know what you're doing seems like a decent compromise to me.

I think it would be best to maybe put them in an extension.

Extensions are meant to provide additional features that most projects don't need, not to add advanced versions of existing blocks.

Bump