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

mres wrote:

…
* 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)
…

Wow, interesting!

I'm not clear how the last one would work in terms of ‘immediate’ placement with x,y values…? Do you mean it would place within bounds using “mod”? So “go to 10000 10000” would end up at something like (10000+240) mod 480 - 240, (10000+180) mod 360 - 180 ? (I guess it would also need to take into account actual costume bitmap centre & extents, etc.)

I'm sure there will be many who enjoy the usefulness of having a sprite wrap like this as it's moving, but I'm a bit wary of the confusion that could arise when directly using ‘go to’ with large values like above, if that's what you mean…

(What would be really great in ‘wrap mode’ would be if a costume that's part off one edge showed the missing part of its costume on the opposite edge - so the costume is ‘split’ between edges. That would save a fair bit of work for Scratchers creating wraparound games. )

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

Certainly a step in the right direction. Having written a compiler that allows the sprites to go off stage then the only “issue” I had was how to treat the

<touching [edge v] ?>

In the end I decided that the edge constituted a pixel wide frame around the stage and so only a sprite touching that edge would return true for that test but consequently a sprite way off stage would return false.

Not sure if this was said before, but I support, IF, there is a confirmation that sais “You are now allowing sprites to go off the sprites. Would you like to continue?” And then have two buttons, one sais allow, one said cancel

Support!

mres wrote:

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

I definitely think this would be a welcome addition and would solve all of the above problems. I think you should try releasing an update with these features enabled and if you start to see an influx in Scratchers who report losing sprites offscreen you can revert things back.

Support.

Support!

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

Interesting… my favorite one is probably

mres wrote:

*wrapping (so that sprites moving off one side reappear on the other side.

mres wrote:

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?

I really like these ideas, and wrapping is an interesting one.

To answer your question, yes, I do think it would address these issues. I still think we should add the “recover sprite” option I mentioned above, as well as:

ShamelessSnores wrote:

Not sure if this was said before, but I support, IF, there is a confirmation that sais “You are now allowing sprites to go off the sprites. Would you like to continue?” And then have two buttons, one sais allow, one said cancel

I think I need to rephrase that quote, though. There is a notification widow for New Scratchers creating Cloud data, and I think the same type of thing could apply here.

Thanks so much for responding!

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

Yes, that sounds cool! I don't know if the wrapping feature's necessary, because it could easily be done anyway, but it won't hurt to add it. I really hope this happens!

Support.

Hi,

The stage settings would solve the issue in most cases, however you wouldn't be able to set this per sprite, i.e. one sprite can go off stage, and another cannot.

Anyway, I support any idea that allow us to to put sprites off screen! :-)

Thanks,
– LBMCompany

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

Support for this, although as LBMCompany said it might be better to have it for each sprite separately.

There could also be a block:

set wrap style [infinite v] :: motion

stickfiregames wrote:

Support for this, although as LBMCompany said it might be better to have it for each sprite separately.

There could also be a block:

set wrap style [infinite v] :: motion

Agreed. Although I think the block should be

set border interaction [infinite v] :: motion

…or something like that.

I do support all modes. I did not even think I would need wrap… and then I thought of a situation where I might want to use it.

The wrapping feature seems complicated. Finite and infinite seems best, having finite stage as default!

But maybe a wrapping mode will be a good thing…

I think the idea is great. When you said about the infinite stage it reminded me of the purposes idea that originally was mentioned back in the scratch 2 beta that you were going to have some kind of scrolling stage offset feature…? That would okay well with the infinite stage

I was kinda curious about the ‘wrapping’ idea… I realised I was actually not sure what was meant!

Some possibilities that come to mind…

1. When a part of a sprite gets, for example, to the right edge of the screen, it carries on going partly off-screen, until it reaches beyond x=240, at which point it ‘flips’ to the other side (i.e. subtracts 480 from its x-position).

2. When a sprite reaches the far right of the screen, it only starts to partly reappear on the left side once it has completely disappeared off the right side (i.e. similar to above, except that it also takes costume width/height into account).

3. When a sprite starts to go off one edge of the screen, it also becomes visible on the opposite edge, simultaneously (this means it's possible to have the sprite split into four if it goes off a corner). Here's a wraparound demo project I made that shows what I mean.

Any thoughts? I'm curious which people would prefer…?

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.