PrincessFlowerTV

I'm pretty confident isn't a duplicate, but if it is, feel free to link to the original suggestion.

Personally, the thought of working with rotating blocks for anything gives me a headache. Unless timed and rotated perfectly, the project could be really wacky. Too fast, too slow, too far, etc… You get the point.

Because of this, I propose a new block, similar to it's gliding counterpart:
glide () secs to x: (0) y: (0)

It would look something like this:
rotate cw () secs to (90 v) degrees ::motion
rotate ccw () secs to (90 v) degrees ::motion
(replacing the “cw” and “ccw” with the arrows used in the rotation blocks)

This would allow people to choose exactly how long the sprite would take and how far it will go when rotating, instead of calculating or using trial and error. Not everyone has the time, mental capacity, and sanity to use these methods all the time.
I seriously think a lot of people would be very happy to see this block added, me included.

Thoughts?

latin_gamerX

repeat until <(direction) = [90]>
turn cw (whatever number) degrees
end

the number in the whatever has to be changed depending on how fast you want it

mybearworld

latin_gamerX wrote:

repeat until <(direction) = [90]>
turn cw (whatever number) degrees
end

the number in the whatever has to be changed depending on how fast you want it

PrincessFlowerTV wrote:

instead of […] using trial and error

Overall, I support, I'd really use that!

awesome_guy6856

No support. You can use math.
And it's not clear how this would work. Would it take the long route? The short route? Clockwise? Counterclockwise?

repeat (num)
turn cw (((original_direction) - (direction)) / (num)) degrees
end

Replacing the num variable with the amt of frames you want the animation to be

dimayajonelcid

Support! This would be much more convenient than using math.

awesome_guy6856 wrote:

No support. You can use math.
And it's not clear how this would work. Would it take the long route? The short route? Clockwise? Counterclockwise?

repeat (num)
turn cw (((original_direction) - (direction)) / (num)) degrees
end

Replacing the num variable with the amt of frames you want the animation to be
Taking note that Scratch runs at 30FPS, this WOULD be num * 30, as the petition is by seconds, not frames.
However, to make it clear, we should put a second dropdown arrow in the block.

rotate (10) secs to (90 v) degrees (clockwise v)::motion

Super_Scratch_Bros20

PrincessFlowerTV wrote:

Not sure if this is a duplicate, but I'm pretty confident it's an original suggestion.

I searched for a little while, but the closest I could find is this. However, it appears to be much different, so you're in the clear (unless @fdreerf comes crawling over).

I don't see any cons other than the fact that I'd never use it. However, that's just me, and others might think differently. So, I won't negatively judge this suggestion.

Vanilla2011

Semi-support. Personally, I like math. So I would take the mathematical alternative:

awesome_guy6856 wrote:

repeat(num of frames)
turn cw(((original direction)-(direction))/(num of frames))degrees
Though I would take this alternative because it uses seconds:
repeat(num of frames)
turn cw(((original direction)-(direction))/((num of frames)*[30]))degrees
That aside, I semi-support because I understand why some people don't like math.

awesome_guy6856

Vanilla2011 wrote:

Semi-support. Personally, I like math. So I would take the mathematical alternative:

awesome_guy6856 wrote:

repeat(num of frames)
turn cw(((original direction)-(direction))/(num of frames))degrees
Though I would take this alternative because it uses seconds:
repeat(num of frames)
turn cw(((original direction)-(direction))/((num of frames)*[30]))degrees
That aside, I semi-support because I understand why some people don't like math.
The thing is, I feel like forcing people to do math (in this situation) is actually good since it forces people to find a clever way to make the computer do all the work for them, instead of perfectly calculating the right amount. Which is a really great thing to do.

2546354163521

So when the sprite is facing upwards and you use that block to rotate so the sprite is facing right, sure it would be first upwards, then up and right, and then right. But why shouldn't it go the other way around, like up, left, down, right? In this case you could just do that by using interpolation with the angle, but what if you rotate from -180° to 179°? It wouldn't just rotate that tiny bit, it would go all the way around. Could you please tell us how exactly the block would know what to do?

2546354163521

Vanilla2011 wrote:

repeat(num of frames)
turn cw(((original direction)-(direction))/((num of frames)*[30]))degrees
Uh … I guess that's wrong, it should be
repeat((num of secs) * (30))
turn cw(((original direction)-(direction))/((num of secs)*(30)))degrees
(also, use () instead of [] for number inputs. Just looks better)

FloatingMuffins

Support. Would get little use but definitely easier than the workaround.

Catie623

I haven't used rotation blocks* in a super long time, but for those who frequently use them, this would be extremely useful. In the old days** I remember being so, so, so, so frustrated over how my Scratch Cat would spin too fast and then the speech would come in earlier than when it was supposed to in my old, bad animations.

So, yes, a definite support!


*Yes, this is literally what I call them.
**3 years ago

PrincessFlowerTV

awesome_guy6856 wrote:

No support. You can use math.
And it's not clear how this would work. Would it take the long route? The short route? Clockwise? Counterclockwise?

repeat (num)
turn cw (((original_direction) - (direction)) / (num)) degrees
end

Replacing the num variable with the amt of frames you want the animation to be
The reason I'm suggesting this block is for people who aren't so good at calculating how to make a workaround. Also, you bring up a good point; maybe you choose which way it rotates. I'll edit the OP.

gosoccerboy5

This seems very interesting and I can see how it would be used; however there is a workaround and this might clutter up the space a bit so I 75% support

Super_Scratch_Bros20

gosoccerboy5 wrote:

This seems very interesting and I can see how it would be used; however there is a workaround and this might clutter up the space a bit so I 75% support

You do realize that everything has a workaround, right? However, not everyone knows it.

And adding anything clutters up space. By this logic, the Scratch Team should reject every suggestion since they'd all take up space, and delete all posts since they take up server space.

gosoccerboy5

You're attacking my argument in a very simplistic manner by saying “by that logic ST should delete all comments”. What I'm doing is comparing the costs and benefits of this block, and one of the costs (specifically opportunity cost) is that it takes up space. Most comments and suggestions have a positive cost-benefit relationship, and it would take unnecessary resources (which could be allocated elsewhere) to remove these suggestions and comments. On the other hand I don't necessarily see the extreme need for this block, and those who do need it can use the workaround. Obviously costs and benefits are subjective and fuzzy, so while I see the costs and benefits not largely differing, I don't necessarily firmly see this as “Support” or “no support”.

Super_Scratch_Bros20

gosoccerboy5 wrote:

You're attacking my argument in a very simplistic manner by saying “by that logic ST should delete all comments”. What I'm doing is comparing the costs and benefits of this block, and one of the costs (specifically opportunity cost) is that it takes up space. Most comments and suggestions have a positive cost-benefit relationship, and it would take unnecessary resources (which could be allocated elsewhere) to remove these suggestions and comments. On the other hand I don't necessarily see the extreme need for this block, and those who do need it can use the workaround. Obviously costs and benefits are subjective and fuzzy, so while I see the costs and benefits not largely differing, I don't necessarily firmly see this as “Support” or “no support”.

Not everyone knows the workaround. Truth be told, I wouldn't even think about it within my first year of Scratch, even. Not everyone who uses Scratch is good with math.

Why not remove every effect? Add literally hundreds of costumes to add ghost, fisheye, mosiac, etc. Clearly, it helps the user become more patient.

Why not remove the pen extension? Make a ridiculously long amount of costumes. It will obviously improve your patience with art.

Why not remove the rules on no blood, swearing, dating, and brutal violence? Of course, it will help your child grow up and be more mature a lot easier.

Why not remove the Google Translate extension? Go into the project, and type in every translation imaginable. Evidently, it helps with your language skills.

Don't you see what I'm saying?

gosoccerboy5

Ok, all I was saying was that I could see how this would take up space that could have been used for better blocks. That wasn't really what I thought, but I was just making the point.

Hamuni

PrincessFlowerTV wrote:

It would look something like this:
rotate cw () secs to (90 v) degrees ::motion
rotate ccw () secs to (90 v) degrees ::motion

I'd say that a better block would be

rotate (2) degrees per (frame v) to (90) degrees :: motion
rotate (2) degrees per (second v) to (90) degrees :: motion
There is almost that kind of block in the Gdevelop 5 game engine. This block could also easily be used in a simple workaround for that block.

awesome_guy6856

Now that I think about it, I guess I wouldn't be too opposed.

We do have this block.

glide () secs to x: (0) y: (0)

which can be worked around in a similar manner.

repeat (frames)
change x by (((desired x position) - (original x)) / (frames))
change y by (((desired y position) - (original y)) / (frames))
end