the scratch team should add a New motion block it will make coding better and easier for beginners when moving in a custom way

aklejandrios

I think it would be better to use this block than making a code to move in a certain direction/speed.

move (10) steps in [direction v] (90)::motion

This moves you in the direction chosen.

move (10) steps in [speed v] (90)::motion

This changes the speed in the steps the sprite takes.
Speed 90 is 90sps(steps per second)
1 speed = 1sps

Last edited by aklejandrios (April 18, 2025 18:43:34)

Yellowsheep43

The move 10 steps in direction can already be done with

point in direction ( v)
move () steps

As for speed, I'm not sure what you mean. Is it the time taken to get to the destination, like below?

move () steps in () seconds :: motion

aklejandrios

Yellowsheep43 wrote:
The move 10 steps in direction can already be done with
point in direction ( v)
move () steps
As for speed, I'm not sure what you mean. Is it the time taken to get to the destination, like below?
move () steps in () seconds :: motion

For speed, translation is 1 speed is 1 step per second
The move steps in direction is optimized to take only one block instead of two and it’s a drop-down menu so speed and direction is in there

CeskoII

Workaround (for speed):

repeat (x)
wait ((1) / (speed)) secs
move (1) steps
end

Pretty simple, but I think it is just complex enough that it doesn't kill it's chances of becoming a new feature. But direction has a 2 block workaround that a new scratcher could easily figure out so I don't think that direction is necessary. Remember that x and speed do not have to be variables. You can put whatever numbers you want in there. Workaround does not work. I will come up with a true one later.

Last edited by CeskoII (April 17, 2025 20:20:19)

aklejandrios

CeskoII wrote:
Workaround (for speed):
repeat (x)
wait ((1) / (speed)) secs
move (1) steps
end
Pretty simple, but I think it is just complex enough that it doesn't kill it's chances of becoming a new feature. But direction has a 2 block workaround that a new scratcher could easily figure out so I don't think that direction is necessary. Remember that x and speed do not have to be variables. You can put whatever numbers you want in there. Workaround does not work. I will come up with a true one later.

I said the speed is a drop-down and it has a ingame value set. 1 speed = 1 sps(steps per second)

CeskoII

Workaround 2: This has been tested and works. 1 speed - 1sps. It only goes up to a millisecond, and has a precision so if you want very high speeds, increase the precision, but if you are moving a short distance, decrease. Now, this is complex and does not take away from the value of your suggestion.

repeat ((x) / (precision))
set [OLD v] to (days since 2000)
wait until <(((days since 2000) - (OLD)) * (86400)) > ((1) / (speed))>
move ((x) * (precision)) steps
end

aklejandrios

CeskoII wrote:
Workaround 2: This has been tested and works. 1 speed - 1sps. It only goes up to a millisecond, and has a precision so if you want very high speeds, increase the precision, but if you are moving a short distance, decrease. Now, this is complex and does not take away from the value of your suggestion.
repeat ((x) / (precision))
set [OLD v] to (days since 2000)
wait until <(((days since 2000) - (OLD)) * (86400)) > ((1) / (speed))>
move ((x) * (precision)) steps
end

Good workaround, most likely people would prefer my motion blocks than this but good job!

CeskoII

aklejandrios wrote:
CeskoII wrote:
Workaround 2: This has been tested and works. 1 speed - 1sps. It only goes up to a millisecond, and has a precision so if you want very high speeds, increase the precision, but if you are moving a short distance, decrease. Now, this is complex and does not take away from the value of your suggestion.
repeat ((x) / (precision))
set [OLD v] to (days since 2000)
wait until <(((days since 2000) - (OLD)) * (86400)) > ((1) / (speed))>
move ((x) * (precision)) steps
end
Good workaround, most likely people would prefer my motion blocks than this but good job!

Thank you! I would prefer to have a block for that. Support (if I haven't already said it). The purpose of workaround is just to have a solution until if/when the suggested block comes out.

aklejandrios

CeskoII wrote:
aklejandrios wrote:
CeskoII wrote:
Workaround 2: This has been tested and works. 1 speed - 1sps. It only goes up to a millisecond, and has a precision so if you want very high speeds, increase the precision, but if you are moving a short distance, decrease. Now, this is complex and does not take away from the value of your suggestion.
repeat ((x) / (precision))
set [OLD v] to (days since 2000)
wait until <(((days since 2000) - (OLD)) * (86400)) > ((1) / (speed))>
move ((x) * (precision)) steps
end
Good workaround, most likely people would prefer my motion blocks than this but good job!
Thank you! I would prefer to have a block for that. Support (if I haven't already said it). The purpose of workaround is just to have a solution until if/when the suggested block comes out.

One question, what is x and precision set to?

aklejandrios

aklejandrios wrote:
CeskoII wrote:
aklejandrios wrote:
CeskoII wrote:
Workaround 2: This has been tested and works. 1 speed - 1sps. It only goes up to a millisecond, and has a precision so if you want very high speeds, increase the precision, but if you are moving a short distance, decrease. Now, this is complex and does not take away from the value of your suggestion.
repeat ((x) / (precision))
set [OLD v] to (days since 2000)
wait until <(((days since 2000) - (OLD)) * (86400)) > ((1) / (speed))>
move ((x) * (precision)) steps
end
Good workaround, most likely people would prefer my motion blocks than this but good job!
Thank you! I would prefer to have a block for that. Support (if I haven't already said it). The purpose of workaround is just to have a solution until if/when the suggested block comes out.
Snip!✂️
I tested the workaround but it instantly teleported the sprite, I will keep testing diff values

CeskoII

aklejandrios wrote:
aklejandrios wrote:
CeskoII wrote:
aklejandrios wrote:
CeskoII wrote:
Workaround 2: This has been tested and works. 1 speed - 1sps. It only goes up to a millisecond, and has a precision so if you want very high speeds, increase the precision, but if you are moving a short distance, decrease. Now, this is complex and does not take away from the value of your suggestion.
repeat ((x) / (precision))
set [OLD v] to (days since 2000)
wait until <(((days since 2000) - (OLD)) * (86400)) > ((1) / (speed))>
move ((x) * (precision)) steps
end
Good workaround, most likely people would prefer my motion blocks than this but good job!
Thank you! I would prefer to have a block for that. Support (if I haven't already said it). The purpose of workaround is just to have a solution until if/when the suggested block comes out.
Snip!✂️
I tested the workaround but it instantly teleported the sprite, I will keep testing diff values
X is the amount of total steps. Precision is backwards - Higher precision mean that speed can be higher, but it is less precise.

jmb1293634

aklejandrios wrote:

move (10) steps in ([speed v]::motion) (90)::motion

don't put the () round the dropdown
use this

[scratchblocks]
move (10) steps in [speed v] (90)::motion
[/scratchblocks]

to make

move (10) steps in [speed v] (90)::motion

or if you want an insertable dropdown

[scratchblocks]
move (10) steps in (speed v) (90)::motion
[/scratchblocks]

to make

move (10) steps in (speed v) (90)::motion

still I can think of no reason anyone would use this

aklejandrios

CeskoII wrote:
aklejandrios wrote:
aklejandrios wrote:
CeskoII wrote:
aklejandrios wrote:
CeskoII wrote:
Workaround 2: This has been tested and works. 1 speed - 1sps. It only goes up to a millisecond, and has a precision so if you want very high speeds, increase the precision, but if you are moving a short distance, decrease. Now, this is complex and does not take away from the value of your suggestion.
repeat ((x) / (precision))
set [OLD v] to (days since 2000)
wait until <(((days since 2000) - (OLD)) * (86400)) > ((1) / (speed))>
move ((x) * (precision)) steps
end
Good workaround, most likely people would prefer my motion blocks than this but good job!
Thank you! I would prefer to have a block for that. Support (if I haven't already said it). The purpose of workaround is just to have a solution until if/when the suggested block comes out.
Snip!✂️
I tested the workaround but it instantly teleported the sprite, I will keep testing diff values
X is the amount of total steps. Precision is backwards - Higher precision mean that speed can be higher, but it is less precise.
Ohhh I get it now, thanks for the explanation

BigNate469

The

move () steps

block (and similar) have no concept of time; the speed is however far the sprite moves per frame, and if you're only using that block, then it's just the sum of all of the values of those blocks you use in a frame.

TL;DR: To make the sprite go faster, use higher values.

aklejandrios

BigNate469 wrote:
The
move () steps
block (and similar) have no concept of time; the speed is however far the sprite moves per frame, and if you're only using that block, then it's just the sum of all of the values of those blocks you use in a frame.

TL;DR: To make the sprite go faster, use higher values.

you still don’t get it, one step per second is you take one step every second, 60 speed is like 60fps but 60sps(steps per second)

ThisIsTemp1

Grammatical nit-pick: for the second block it should be “at” instead of “in”. Otherwise this seems like a good suggestion, as I can see the use for this in games where speed is important(racing game, for example.)

jmdzti_0-0

workaround for direction

define move (a) steps in direction (b)°
change x by (([cos v] of ((b)+(90)))*(a))
change y by (([sin v] of ((b)+(90)))*(a))

plus 90 degrees because of scratch’s weird way to handle degrees

jmdzti_0-0

aklejandrios wrote:
BigNate469 wrote:
The
move () steps
block (and similar) have no concept of time; the speed is however far the sprite moves per frame, and if you're only using that block, then it's just the sum of all of the values of those blocks you use in a frame.

TL;DR: To make the sprite go faster, use higher values.
you still don’t get it, one step per second is you take one step every second, 60 speed is like 60fps but 60sps(steps per second)

you can use deltatime, but that’d be too complex.

hotcrystal

when I see this topic:: events hat
bump
wait until <someone posts:: sensing>

Last edited by hotcrystal (April 28, 2025 17:52:02)

Discuss Scratch