Pretty simple suggestion, and I hope it gets implemented at some point.

The idea is that you can group sprites together so that when one of them moves or rotates, every other sprite attached to it would move the same way as well. All the sprites would remain separate – perhaps groups could be color assigned. Also, when creating groups, they should be an option on whether sprites in the group would move relative to each other or not. Grouped sprites may or may not stay near each other in the sprite list.

Advantages

• This would allow the creation of more complex objects out of several sprites (for example, adding firing points and individual turrets on a battleship that have to stay attached to a certain area ofthe ship regardless of its rotation or position)
  
• This could also help with the organization of the sprite list, especially if you have tens of sprites.
  

Disadvantages

• This would make things “slightly more complicated”, however using groups is a purely optional feature and it can probably be taught in less than five minutes.
  

+support!

Duplicates I found

Just “folders” for organization (not a duplicate of this topic, but I decided to look for them, too):
https://scratch.mit.edu/discuss/topic/7073
https://scratch.mit.edu/discuss/topic/15929/
https://scratch.mit.edu/discuss/topic/23443
https://scratch.mit.edu/discuss/topic/81670/
https://scratch.mit.edu/discuss/topic/223671/
https://scratch.mit.edu/discuss/topic/235262

With “touching in group X?” code:
https://scratch.mit.edu/discuss/topic/3914
https://scratch.mit.edu/discuss/topic/86884

With more than “touching in group X?” code:
https://scratch.mit.edu/discuss/topic/25842/
https://scratch.mit.edu/discuss/topic/43821/

WindOctahedron wrote:

-snip-

Thanks, though. However since they don't really suggest having sprites in a group move relative to each other I don't think they would be called full duplicates…

ResExsention wrote:

Pretty simple suggestion, and I hope it gets implemented at some point.

The idea is that you can group sprites together so that when one of them moves or rotates, every other sprite attached to it would move the same way as well. All the sprites would remain separate – perhaps groups could be color assigned. Also, when creating groups, they should be an option on whether sprites in the group would move relative to each other or not. Grouped sprites may or may not stay near each other in the sprite list.

Advantages

• This would allow the creation of more complex objects out of several sprites (for example, adding firing points and individual turrets on a battleship that have to stay attached to a certain area ofthe ship regardless of its rotation or position)
  
• This could also help with the organization of the sprite list, especially if you have tens of sprites.
  

Disadvantages

• This would make things “slightly more complicated”, however using groups is a purely optional feature and it can probably be taught in less than five minutes.
  

highly support. we could save lots of broadcast blocks like this.

-ClearFrost- wrote:

highly support. we could save lots of broadcast blocks like this.

Actually, broadcasts would still need to be used to get the sprites to communicate to each other, but we could have like

broadcast in group [ v] :: events

Which could only be received by sprites that are in the same group.

dogeiscut wrote:

+support!

Please be constructive and explain why you support.

—

M'dude, did you just steal this from Lua? I would've expected that.

What would happen if you group sprites that already had some scripts that only work for one sprite in them and everything goes wrong? And would you be able to choose in what way the group would be organized?

good idea it could look like

group with [ v]

or

set group to [ v] with group name []

grouping could also have this block

create clone of [ group]