If you use the

Group with (Sprite1 v) :: control

Block, those two sprites now share their code. So if Sprite2 moved 10 steps, Sprite1 would too. Theres

Ungroup with (Sprite1 v) :: control

Which does what you expect.

This sounds like it would be confusing, and clones are usually a better option regardless.

TheCreatorOfUnTV wrote:

This sounds like it would be confusing, and clones are usually a better option regardless.

That's assuming the sprites look the same. What if it's two different ones?

Table of contents:
1) An overview
2) Explanation of what I'm EXACTLY suggesting
3) The Purpose why
4) What can be done with this

Although there is a very specific use for the ability of uniting two sprites into 1, it can possibly alter the course of scratch.

What this would do would allocate two different sprites, and when toggled, would BEHAVE as if it is together.
For instance, this would result in both sprites:
moving together
changing size together
receiving input and output together
changing direction together
Two things to say merge into 1
etc.
But this would seem useless, since this can be easily done by broadcasting, or the block
go
to
Sprite
But there's one thing that is IMPOSSIBLE to do: graphic effects, especially FISHEYE.

So if you go to costumes editor, make a large rectangle and draw some sort of character that touches the edge of a rectangle, when the fisheye effect occurs, the character contracts, or anti-stretches. The ability of stretching sprites can be done via costumes editor, but it would be such a mission to be able to stretch by one block of code. This can be done, but only in 1 direction. If it was possible to stretch sprites in infinitely possible directions, then many projects would accomplish.

So first, if two sprites could be able to group and be both under the fisheye effect, I can displace the animated sprite anywhere along the large rectangle (second sprite) and if they are united, i can anti-stretch the animated sprite without the need of doing it manually (using costumes editor, and making infinite number of costumes is not practical) and a new project can be made: 3D Scratch.

3D Scratch would not require pen, and can be simply stretched or contracted along the imaginary z-dimension. Fortunately, this ability won't need another dimension to be created, since the Z-dimension already contracts sides along with XZ rotation.
This wouldn't violate Rejected Suggestions since it doesn't DIRECTLY ask for 3D Scratch. It can simply be made if the ability of uniting sprites is possible. As a matter of fact, 3D Scratch is already possible, it's just currently inefficient due to lots of unnecessary costumes that manually displace the animated sprite in a direction.

So, a new dimension of scratch would be made without any lag and pen, if only sprites were able to unite.

CagnusMarlsen wrote:

3D Scratch would not require pen, and can be simply stretched or contracted along the imaginary z-dimension. Fortunately, this ability won't need another dimension to be created, since the Z-dimension already contracts sides along with XZ rotation.
This wouldn't violate Rejected Suggestions since it doesn't DIRECTLY ask for 3D Scratch. It can simply be made if the ability of uniting sprites is possible. As a matter of fact, 3D Scratch is already possible, it's just currently inefficient due to lots of unnecessary costumes that manually displace the animated sprite in a direction.

This is already doable- with just fisheye and whirl, some extra large costumes, and stamping (so that you can draw multiple objects)- see https://scratch.mit.edu/projects/551396222/

If that's your only argument for this suggestion, it's also not a particularly good one- the ST only wants advanced projects to be possible, not necessarily easy or for those projects to run fast.

BigNate469 wrote:

CagnusMarlsen wrote:

3D Scratch would not require pen, and can be simply stretched or contracted along the imaginary z-dimension. Fortunately, this ability won't need another dimension to be created, since the Z-dimension already contracts sides along with XZ rotation.
This wouldn't violate Rejected Suggestions since it doesn't DIRECTLY ask for 3D Scratch. It can simply be made if the ability of uniting sprites is possible. As a matter of fact, 3D Scratch is already possible, it's just currently inefficient due to lots of unnecessary costumes that manually displace the animated sprite in a direction.

This is already doable- with just fisheye and whirl, some extra large costumes, and stamping (so that you can draw multiple objects)- see https://scratch.mit.edu/projects/551396222/

If that's your only argument for this suggestion, it's also not a particularly good one- the ST only wants advanced projects to be possible, not necessarily easy or for those projects to run fast.

There is nothing wrong with wanting certain features to become easier or faster, besides you can do more than just, “3D Scratch”, that is simply one argument

The-Sushi-Cat wrote:

There is nothing wrong with wanting certain features to become easier or faster, besides you can do more than just, “3D Scratch”, that is simply one argument

Yep

Bump