I know that this has been suggested before, but I have more ideas than “add block that can remove border”.

The border is very important, as it helps beginners not instantly lose their sprites after running certain scripts. The issue is, it hinders basically everyone else due to the fact that objects can still be slightly seen on the edge of the screen. So, I have a few suggestions (do note that the blocks say edge due to the <touching edge> boolean found in the Sensing tab):

set edge to [default v] :: sensing
set edge to [larger v] :: sensing
set edge to [window v] :: sensing
set edge to [off v] :: sensing

Default: This would set the border to the way it currently is. It will also be the default when creating a new Scratch project.
Larger (better name suggestions available): This would make the border larger and let sprites go fully off screen, but there would still be a border to prevent sprites from going too far.
Window (better name suggestions available): This would set the border to be the confines of the project window.
Off: By far the most requested one by the scratch community, this would disable the border.

This could be beneficial for users who:
a. Want to have unused stuff off screen for a movie or game
b. Want a sprite to appear from the edge of the screen without having it suddenly appear halfway in the screen

This could also help with the educational value of Scratch, because this change could:
a. Teach people about object pooling, which is when you reuse already created objects without having to make clones every time. Object pooling is used to optimize games, and optimization is very important.
b. Teach people how to strategically hide objects outside the screen and have them appear when needed. Many games hide unused objects off screen as a way to optimize their games without having to create the object every time. In the case of Scratch, it can get rid of needing to hide/show objects or use the ghost effect to hide unused objects.

Workarounds
There are workarounds to the border, usually people say to increase the size of the sprite for a fraction of a second to allow it to be off screen. But,
a. Nobody is figuring this out. Not many people know that the border size dynamically changes with sprite size, and 8 year olds (the main target demographic) definitely don't know about this.
b. This change will make code more readable (“increase border size” sounds more readable than “make sprite larger, move it to edge, and make it smaller again”)

I achieved this here.

It's kind of unintuitive, in my opinion, so I'd like to see this added. Even if it's workaroundable, that doesn't really beat making the border actually customizable… because, one, the workaround causes rendering issues, and 2, it's… really finicky. Making the border larger or turning it off in general would probably make it function much more nicely.

People could do

Set border to [window v]::sensing
go to x: (X of report button) y: (y of report button)
when this sprite clicked
forever
create clone of [Myself v]
end

when I start as a clone
create clone of [Myself v]

And then put inappropriate stuff in there project

purplebunny63 wrote:

People could do

Set border to [window v]::sensing
go to x: (X of report button) y: (y of report button)
when this sprite clicked
forever
create clone of [Myself v]
end

when I start as a clone
create clone of [Myself v]

And then put inappropriate stuff in there project

Not a good point. Just report it after refreshing the page.

purplebunny63 wrote:

People could do

Set border to [window v]::sensing
go to x: (X of report button) y: (y of report button)
when this sprite clicked
forever
create clone of [Myself v]
end

when I start as a clone
create clone of [Myself v]

And then put inappropriate stuff in there project

I don't think this would even work in this case because I think scratch sprites are below every other layer
Besides, if it wasn't, you would have to account for every single possible resolution that affects the position of the report button, and layering Scratch sprites under everything else would instantly fix this issue
Also the stop button deletes all clones anyways

bump

oh no my sprites fell out of the project window and are having an average alan becker fight /j

you know you can use a “big” costume right?

I_wantasheep wrote:

oh no my sprites fell out of the project window and are having an average alan becker fight /j

you know you can use a “big” costume right?

(#4) Already said that.

I_wantasheep wrote:

oh no my sprites fell out of the project window and are having an average alan becker fight /j

you know you can use a “big” costume right?

Yes, you can increase the size of a sprite for a fraction of a second, but:
1. Most people would not be able to figure this out (most people might not think that the border resizes based on sprite size)
2. This only increases the border size, and it doesn't do any of the other things mentioned (shrink/remove it)
3. This border block would make code more readable (“increase border size than move object out of view” sounds a lot simpler than “make sprite bigger, move the sprite, and make it smaller again”)

(edit: I updated the op to include this workaround and why its not that good)

ploppiedog wrote:

I_wantasheep wrote:

oh no my sprites fell out of the project window and are having an average alan becker fight /j

you know you can use a “big” costume right?

Yes, you can increase the size of a sprite for a fraction of a second, but:
1. Most people would not be able to figure this out (most people might not think that the border resizes based on sprite size)
2. This only increases the border size, and it doesn't do any of the other things mentioned (shrink/remove it)
3. This border block would make code more readable (“increase border size than move object out of view” sounds a lot simpler than “make sprite bigger, move the sprite, and make it smaller again”)

Technically, you don't have to do do that, but that's just another workaround. I'm kind of tired of custom blocks or big costumes/costumes with a transparent square being needed just to squeeze past the border. It's not good practice, like a lot of other workarounds. Being able to clip to the stage itself instead of on the edge, or just plainly letting it go past, is a much better idea to me.

“Just use a big costume” what about the rendering issues, or trying to replace the size block or go to x: y: block? It kind of just sucks, so it'd be much better to just add it natively…

Also, I'm only linking that because it requires no custom blocks and is kind of useful. If someone can link a better way of doing it, let me know.

bump

bump

bump

bump

bump

bump

One concern I have regarding this is that, even if you use workarounds to have sprites go off-screen, all blocks sensing if sprites are touching do not function off-screen. The idea itself is great, the whole corralling system feels rather restrictive, especially for certain types of projects.

BoyoolHarita wrote:

One concern I have regarding this is that, even if you use workarounds to have sprites go off-screen, all blocks sensing if sprites are touching do not function off-screen. The idea itself is great, the whole corralling system feels rather restrictive, especially for certain types of projects.

I mean, there aren't really many cases in which you need to check if something is touching something else off-screen, and besides, if you really need to check, just move them back on screen by an equal fixed amount, check if they are touching, teleport them back, and then run the necessary logic. You can do this in a custom block with “Run without screen refresh” enabled so that it runs in 1 frame and thus is unnoticeable.

Besides, if it's too much of an issue, ST could just change it so that it detects if the hitboxes are touching instead of the sprites themselves (it could even be a hybrid of “if outside bounds, set detection mode to hitbox, otherwise set detection mode to sprite”).

Support! I think Codubee showed interest in custom stage sizes and resolutions, so may not be too far-fetched!

bump