I bet some people may have pondered about what the “least used” or the “most limited” or the flat-out “worst” block in Scratch, one of these blocks that I feel are frequently discussed when this question is brought up is the infamous “glide to” block.

The concept of this block is simple: it moves said sprite to a selected coordinate point in a selected amount of time, rather than teleporting itself to a selected coordinate point. The problem I found with this block, however, is how it proposes itself to be used by newcomers to Scratch, and how you can’t really use it wholeheartedly when trying to make more technical and complicated projects.

The solution?

Simple: apply the “glide" effect with not just a mere motion block, but with essentially any block with the use of advancing a variable.

advance [my variable v] to (x :: grey) in (y :: grey) secs :: variables

Overview

Advancing a variable basically “glides” the variable to a value in a select amount of time by using math, imitating how the “glide to” block glides a sprite to a specific coordinate point. This makes it so you can apply motion to practically any block using a fairly straight-forward set of scripts:

broadcast [message v]
repeat until <(my variable) = (x :: grey)>
set thing to (my variable) :: grey
end

when I receive [message v]
advance [my variable v] to (x :: grey) in (y :: grey) secs :: variables

Nonetheless, I feel that there should be some “easing functions” to accommodate more experienced Scratchers on the website. In simpler terms, it would determine the value of a variable after a certain amount of time is allotted.

For some examples, see this project.

advance [my variable v] to (x :: grey) in (y :: grey) secs with [quad in out v]:: variables 

set advancing variable ease to [sine out v]:: variables

1. It allows for more uses for more sophisticated Scratchers.

Because of how the “glide to” block serves itself as an introduction to movement, it doesn’t allow for much customization, so implementing something with more potential in the “variables” section, which poses itself as being a bit more complex, could possibly introduce some smoother transitions (e. g. movement, fading), while not posing itself as a “main element” in coding. Although, people will inevitably get confused by it.



2. Smooth movement, fading, and so forth, seem to be very sought-after.

A project by the name of Smooth Movement Engine was featured some time ago and successfully reached Scratch’s Popular page. (which is a ridiculous feat in its own right) With this project nearing 12,000 favorites, it’s safe to say that the demand for smoother movement and versatility is somewhat high.

If your proposed blocks were implemented, I still think we should keep the existing “glide to” block, just so newcomers can still easily use the block to move a sprite without necessarily knowing what a variable is.

waitwhat2288 wrote:

advance [my variable v] to (x :: grey) in (y :: grey) secs with [sine v]:: variables 

set advancing variable ease to [sine v]:: variables

I'm uncertain as to what precisely these blocks do. What is the workaround?

Za-Chary wrote:

If your proposed blocks were implemented, I still think we should keep the existing “glide to” block, just so newcomers can still easily use the block to move a sprite.

I agree! The current glide block should stay because new scratchers won’t be able to glide a sprite to a sprite.

Za-Chary wrote:

If your proposed blocks were implemented, I still think we should keep the existing “glide to” block, just so newcomers can still easily use the block to move a sprite without necessarily knowing what a variable is.

Yeah, I'm not expecting these blocks to completely overhaul the “glide to” block, it's just going to be a substitute for it.

Za-Chary wrote:

waitwhat2288 wrote:

advance [my variable v] to (x :: grey) in (y :: grey) secs with [sine v]:: variables 

set advancing variable ease to [sine v]:: variables

I'm uncertain as to what precisely these blocks do. What is the workaround?

The first one of these blocks would behave exactly like the unmodified “advance variable to” block, only it would advance to x in a kind of non-proportional growth. (e. g. ease, sine, exponential)

I hope I'm explaining this right.

The second one would just set the growth of all the unmodified “advance variable to” block in that non-proportional kind of growth. (or have no kind non-proportional growth)

waitwhat2288 wrote:

The first one of these blocks would behave exactly like the unmodified “advance variable to” block, only it would advance to x in a kind of non-proportional growth. (e. g. ease, sine, exponential)

I hope I'm explaining this right.

The best way to explain it is to write, using Scratchblocks, an exact workaround for your suggestion, so users can try it out to see what kind of motion you are envisioning.

nevermind

Bump.

Bump

PaperMarioFan2022 wrote:

Za-Chary wrote:

If your proposed blocks were implemented, I still think we should keep the existing “glide to” block, just so newcomers can still easily use the block to move a sprite.

I agree! The current glide block should stay because new scratchers won’t be able to glide a sprite to a sprite.

They could do this:

glide (number ::grey) secs to x: ([x position v] of [sprite v]) y: ([y position v] of [sprite v])

The current glide block should probably still exist, and the original poster said it would be a substitute for it.

medians wrote:

PaperMarioFan2022 wrote:

Za-Chary wrote:

If your proposed blocks were implemented, I still think we should keep the existing “glide to” block, just so newcomers can still easily use the block to move a sprite.

I agree! The current glide block should stay because new scratchers won’t be able to glide a sprite to a sprite.

They could do this:

glide (number ::grey) secs to x: ([x position v] of [sprite v]) y: ([y position v] of [sprite v])

The current glide block should probably still exist, and the original poster said it would be a substitute for it.

There's also this block:

glide (x :: grey) secs to [sprite v] :: motion

Though I'm unsure if this even existed in 2.0 so…

Bump

waitwhat2288 wrote:

medians wrote:

PaperMarioFan2022 wrote:

Za-Chary wrote:

If your proposed blocks were implemented, I still think we should keep the existing “glide to” block, just so newcomers can still easily use the block to move a sprite.

I agree! The current glide block should stay because new scratchers won’t be able to glide a sprite to a sprite.

They could do this:

glide (number ::grey) secs to x: ([x position v] of [sprite v]) y: ([y position v] of [sprite v])

The current glide block should probably still exist, and the original poster said it would be a substitute for it.

There's also this block:

glide (x :: grey) secs to [sprite v] :: motion

Though I'm unsure if this even existed in 2.0 so…

Oh I forgot about that existing, that didn't exist in 2.0:

Bump

Also, looks like a good suggestion. even if there is a workaround this would definitely help.

Sounds similar to tweening in roblox lua, pretty useful feature!
slightly confusing tho, maybe it'd be better as a extension?

I think the glide to block is mostly for new scratchers because workarounds are complicated. It's what I used and I don't think me back then would have coped with the blocks in this suggestion. So no support.

unmissable wrote:

I think the glide to block is mostly for new scratchers because workarounds are complicated. It's what I used and I don't think me back then would have coped with the blocks in this suggestion. So no support.

I dont think they want to replace the original, they just want to add a better version while keeping the old one, like how they added the move () steps block and the change X by block

MagicCoder330 wrote:

unmissable wrote:

I think the glide to block is mostly for new scratchers because workarounds are complicated. It's what I used and I don't think me back then would have coped with the blocks in this suggestion. So no support.

I dont think they want to replace the original, they just want to add a better version while keeping the old one, like how they added the move () steps block and the change X by block

Well then I misread OP mb

yadayadayadagoodbye wrote:

slightly confusing tho, maybe it'd be better as a extension?

Possibly, though I'm not really that inclined to make this a whole separate extension. The extensions are pretty much just a miscellaneous section, but with these blocks, they're extremely related to the other variable blocks, so it wouldn't necessarily make sense if we created a whole entire extension to isolate from the other blocks.

MagicCoder330 wrote:

unmissable wrote:

I think the glide to block is mostly for new scratchers because workarounds are complicated. It's what I used and I don't think me back then would have coped with the blocks in this suggestion. So no support.

I dont think they want to replace the original, they just want to add a better version while keeping the old one, like how they added the move () steps block and the change X by block

Yep, the original block is here to stay. This will only be a substitute for the glide block.

No support. I think.

I'm not sure how well I'm going to word this, but here goes:
I feel conflicted about this, because although I can see people using and appreciating a block like this, it also sort of defeats the point of learning to actually code out something like this– and although it can be a bit of a difficult workaround, I do think semi-complicated coding workarounds like this are actually a good thing to learn. Adding the block feels almost like going too far from regular text-based coding languages; although its good to have some ways for non-coders to use the site, it is, you know, a coding site, and should, i think, stay somewhat within the bounds of regular coding languages.

I don't know if that makes sense. I can also understand why people would want to add it, i just think not adding it is better.

1-o-v-e wrote:

I feel conflicted about this, because although I can see people using and appreciating a block like this, it also sort of defeats the point of learning to actually code out something like this– and although it can be a bit of a difficult workaround, I do think semi-complicated coding workarounds like this are actually a good thing to learn.

Scratch encourages finding creative solutions and such, but they don't enforce it.

Besides, if you want to learn how to code something similar to this, just don't use the blocks, and try to find clever workarounds at your disposal.

1-o-v-e wrote:

Adding the block feels almost like going too far from regular text-based coding languages

I think this actually correlates very well with other programming languages — it's just using math functions in a creative way.