Option to remove screen borders- IMPORTANT

stickfiregames

AndersBillLinden wrote:
I got an idea, why not update the file format to sb3 where there is an added property in the “info” section of the json file: scratchVersion.
Then we do not have to create new file formats because we can always increase that number.

If a file is of a certain version or newer, the stage is without limits. No option to make it limited is needed. At least not because we want backwards compatibility. We are free to choose then.

That wouldn't really be needed, it could just have a property for the stage mode and if it isn't there, assume it was made with an old version and default to limited. Also, .sb3 implies this is Scratch 3.0

If you can read this, my signature cubeupload has been eaten by an evil kumquat!

or you just used Inspect Element, you hacker

;

ChocolatePi

stickfiregames wrote:
AndersBillLinden wrote:
I got an idea, why not update the file format to sb3 where there is an added property in the “info” section of the json file: scratchVersion.
Then we do not have to create new file formats because we can always increase that number.

If a file is of a certain version or newer, the stage is without limits. No option to make it limited is needed. At least not because we want backwards compatibility. We are free to choose then.
That wouldn't really be needed, it could just have a property for the stage mode and if it isn't there, assume it was made with an old version and default to limited. Also, .sb3 implies this is Scratch 3.0

what does the ‘b’ stand for anyway?

Rex208

Support.

AndersBillLinden

Well, we can add a scratch version number/build number etc to the current sb2 json file format meaning that files without such will assume limited stage.

AndersBillLinden

If you start a new scratch project (from scratch), unlimited stage will then be assumed and a version number will be included in the json data.

shaymin88

(I know this topic is a tad bit old, but I want to put my input in) Would the wrapping work the way wrapping works in Pac-man? Would you go off screen onto the other side, or would it be like when you touch the side of the screen the part that was off screen is now showing on the opposite side? Anyways I do support the idea.

ChocolatePi wrote:
stickfiregames wrote:
AndersBillLinden wrote:
I got an idea, why not update the file format to sb3 where there is an added property in the “info” section of the json file: scratchVersion.
Then we do not have to create new file formats because we can always increase that number.

If a file is of a certain version or newer, the stage is without limits. No option to make it limited is needed. At least not because we want backwards compatibility. We are free to choose then.
That wouldn't really be needed, it could just have a property for the stage mode and if it isn't there, assume it was made with an old version and default to limited. Also, .sb3 implies this is Scratch 3.0
what does the ‘b’ stand for anyway?

I think the b stands for build. Scratch Build 3. I don't exactly know what the b stands for, but I can always guess at it. = D

Rex208

TheHockeyist wrote:
I support allowing sprites to go off screen as an option. But by default have them stay on screen for the convenience of New Scratchers and Scratchers who are still inexperienced.

^ this

Failord

Bump… ?

Oh, and by the way, I still live!

Thanks for the ride, Scratch Team and community! Unfortunately, the time has come for me to move on from Scratch, so I'll no longer be using the forums. Thanks again, and farewell!
Invisible text! This will show you if a profile I claim to be mine IS mine. Just remember to visit the profile and see if I confirmed in the comments.
For old time's sake, see the revolutionary Laser Battle 2.0! Also see Unstoppable Game!

And no, the evil kumquats didn't alter my signature…

Penguin9090_new

Support, this will make scrolling much easier.

CLICK PLZ: Games Art Particles Animations Others

There could be invisible text but probably not –>am i wasting your time? Don't click this link. Really. Don't. Click. It.
Click here to dislike my posts!

TimothyLawyer

Would it work to allow sprites that are hidden to go off-stage and then when shown they could pop back to the nearest stage position?

hide // can go off stage

show // cannot go off stage; if already off stage, pop back on stage

Last edited by TimothyLawyer (March 27, 2015 19:05:13)

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

Prinseskat

TimothyLawyer wrote:
Would it work to allow sprites that are hidden to go off-stage and then when shown they could pop back to the nearest stage position?
hide // can go off stage

show // cannot go off stage; if already off stage, pop back on stage

But… that means you have to do what is sometimes already done, to hide a sprite when x is < 170 or something. Problem is one moment there's a good part of the sprite still on the screen, then the next moment it disappears. Going back to the stage when showing would just cause too many bugs.

Although this could work with new scratchers not “losing” their sprites, it doesn't sound too good.

haha funny kumquat meme

TimothyLawyer

Prinseskat wrote:
But… that means you have to do what is sometimes already done, to hide a sprite when x is < 170 or something. Problem is one moment there's a good part of the sprite still on the screen, then the next moment it disappears. Going back to the stage when showing would just cause too many bugs.

Yeah, for visible sprites it would not help.

Prinseskat wrote:
Although this could work with new scratchers not “losing” their sprites, it doesn't sound too good.

How about for pen projects?

BeetleBlocks, WatercolorBot, and Turtle Art
Hover over a name or label to translate into current language
When Earth was… Purple ?

☂️

CodeLegend

mres wrote:
…
* wrapping (so that sprites moving off one side reappear at the other side)
…

This might have some problems…
For instance, if a sprite's size was increased so that its width exceeded 480 (or a wider costume was created in vector), it would overlap itself.

And, would the [point towards ] block use the shortest possible distance through the edges of the screen?

I think it would be best if each sprite had its own ‘allow off screen’ checkbox underneath the ‘can drag in player’ option. This way, if someone imports sprites from another project that expects the borders to be finite, they wouldn't have to reprogram it to manually stay on screen.

“… your beard people are crazier than my hat people.”

IronBit_Studios

TheHockeyist wrote:
I support allowing sprites to go off screen as an option. But by default have them stay on screen for the convenience of New Scratchers and Scratchers who are still inexperienced.

Crimson19

Wrap seems good for one of those arcade games. The only problem would be the touching edge block in infinite. Would it expand to the size of the screen? or will it simply stay in the same place. It'd make a few things easier and a few things harder so I say go for it and fix any smaller problems later. Maybe for the touching edge you can choose if it selects how far your farthest sprite is or the normal screen size.

__init__

mres wrote:
We had a meeting of the Scratch Programming Editor team yesterday, and we discussed this issue.

Here's one idea we discussed: Instead of adding a special mode for each sprite (allowing it to leave the stage), what if we allowed programmers to choose from three different modes for the Scratch “stage”:
* finite (as it is now)
* infinite (sprites can move outside the boundaries)
* wrapping (so that sprites moving off one side reappear at the other side)

So if you wanted sprites to move off the stage entirely, you could set the stage to “infinite”.

If we added this capability, do you think it would address the issues raised in this discussion thread?

(Note: We are just brainstorming at this point, and would love to get feedback. If we decide to go with this idea, there would still be a lot of design and development work to do.)

I like that idea…

thisandagain pls explain

Andrew_Rodebaugh

PLZ One of my programs https://scratch.mit.edu/projects/92258781 needs it!

Modr

Suppoooooooooort!

WO997

I also support this idea. I was thinking about many options and probably the best one is to add a checkbox in the information box about sprite (where we can set direction, visibility, allow to drag in player, set rotation style) which can keep sprite on screen. When creating sprite this option can be selected. Beginners would have no problem with this and the reason why it would help me is that it actually slows projects a little, especially for big bitmap sprites. Hope it's not hard to do, thanks for reading!

https://scratch.mit.edu/projects/58287862/ game based on World of Tanks

RobFarley74

Hello all… Apologies for resurrecting an ancient thread, but has this been resolved or are we still waiting… I had a click around and I couldn't see any mention of infinite stages etc, but it's perfectly possible I'm looking in the wrong place.

Cheers, Rob

My Scratch Profile

Discuss Scratch