I think a mouse direction block would be useful for creators making projects that would detect the direction the mouse is moving, it could help with 3d pen games where you move the mouse to turn the camera. It could go with a ‘lock mouse’ block and ‘mouse speed’ blocks for x and y respectively they could look like this:

(mouse direction) // Goes with a variable containing the direction of the mouse.
lock mouse [on v]
(mouse speed x)
(mouse speed y)

All of these would be in the sensing category

Full support for the reporters. However, there might be a problem with the “lock mouse” feature. Perhaps something like this could work (also, I'm using “lock mouse” and “unlock mouse” because I think it would make more sense):

when flag clicked
[lock v] mouse ::sensing // Scratch says: Allow this project to lock your mouse? You can use Esc to quit.
if <mouse locked? :: sensing> then {
...
} else {
say [Sorry, you can only play this project with the mouse locked.]
stop [all v]
} :: control

when mouse unlocked manually :: sensing hat 
...

// If the player presses Esc, the project can now handle this. 
// (It can't re-lock the mouse, as this would cause the same prompt, and the user can just cancel again.)

Also, I think to go with the mouse direction block, we should probably also have a block that simply is:

mouse speed :: reporter sensing // this simply returns the speed of the mouse in the direction specified by mouse direction

No support for the “mouse direction” block, because there exists a workaround:

when green flag clicked // I recommend placing this script in another sprite, because some sprites might need to move around.
go to x: (0) y: (0)
forever
point towards [mouse-pointer v]
set [mouse direction v] to (direction)
end

And I think that there exists a workaround for “x/y mouse speed”, but I don't know what it is…
Also, for the

lock mouse [on v]

you can use variables instead.

WindOctahedron wrote:

Also, for the

lock mouse [on v]

you can use variables instead.

How can you use variables? As far as I understand, the block prevents the mouse from moving.

(Note: for strong understanding, read up on vectors/trigonometry)

find the delta y and delta x of the cursor position. (delta means “change in”; greek symbol: Δ)

To find the direction of the vector (You can just treat these as coordinates it makes no difference)
we must use arctangent on the value (dy/dx) (Rise over run formula to find the slope)
however, this only works when x is positive, so we must add 180 degrees to the returned value if x<0 (Won't matter if you use <= or <)
you will now get the direction of the vector (in degrees), and to get the “speed” (A.K.A vector magnitude) you can use a variant of the Pythagorean Theorem (sqrt(dx^2 + dy^2)).

NOTE: Scratch has a very odd way of representing degrees, so if you use built-in Scratch function to represent this angle, add 90 degrees to the result.

If you want this represented in code (tl;dr), here it is:

set [xCursorPrev v] to (mouse x)
set [yPrev v] to (mouse y)
say [To prevent any bugs with the mouse suddenly changing position in-between play sessions]
forever
 set [dx v] to ((mouse x) - (xPrev))
 set [dy v] to ((mouse y) - (yPrev))
 say [Divider]
 set [xPrev v] to [(mouse x)]
 set [yPrev v] to [(mouse y)]
 say [The section above is never going to be utilized until 1 frame delay, because we need the mouse to move within a certain time frame!]
 set [Direction v] to ([atan v] of ((dy) / (dx)))
 if <(dx) < [0]> then 
  change [Direction v] by (180)
 end
 set [Magnitude v] to ([sqrt v] of (((dx) * (dx)) + ((dy) * (dy)))) 
end

Magnitude is how far the mouse has traveled within the 1 frame time window, if you want to get the real-time speed, you will have to calculate delta time. This is not going to be explained within the scope of this post (As it is not requested).

SadNoob wrote:

WindOctahedron wrote:

Also, for the

lock mouse [on v]

you can use variables instead.

How can you use variables? As far as I understand, the block prevents the mouse from moving.

I meant that if you put the

if <(Mouse lock?) = [off]> then
...
end

then the program would let the sprites react to this only if the mouse lock is off* (you can still move your mouse, though).
*This setting can be turned on or off in the project by, for example, pressing a certain key.

TL1882 wrote:

I think a mouse direction block would be useful for creators making projects that would detect the direction the mouse is moving, it could help with 3d pen games where you move the mouse to turn the camera. It could go with a ‘lock mouse’ block and ‘mouse speed’ blocks for x and y respectively they could look like this:

(mouse direction) // Goes with a variable containing the direction of the mouse.
lock mouse [on v]
(mouse speed x)
(mouse speed y)

All of these would be in the sensing category

Mouse direction?Maybe the direction of the mouse?

Scratcher402 wrote:

TL1882 wrote:

I think a mouse direction block would be useful for creators making projects that would detect the direction the mouse is moving, it could help with 3d pen games where you move the mouse to turn the camera. It could go with a ‘lock mouse’ block and ‘mouse speed’ blocks for x and y respectively they could look like this:

(mouse direction) // Goes with a variable containing the direction of the mouse.
lock mouse [on v]
(mouse speed x)
(mouse speed y)

All of these would be in the sensing category

Mouse direction?Maybe the direction of the mouse?

What's the difference? “Mouse direction” sound even better than “Direction of the mouse”.

Botcho_Otkho wrote:

Scratcher402 wrote:

TL1882 wrote:

I think a mouse direction block would be useful for creators making projects that would detect the direction the mouse is moving, it could help with 3d pen games where you move the mouse to turn the camera. It could go with a ‘lock mouse’ block and ‘mouse speed’ blocks for x and y respectively they could look like this:

(mouse direction) // Goes with a variable containing the direction of the mouse.
lock mouse [on v]
(mouse speed x)
(mouse speed y)

All of these would be in the sensing category

Mouse direction?Maybe the direction of the mouse?

What's the difference? “Mouse direction” sound even better than “Direction of the mouse”.

I meant the direction of the mouse movement.

WindOctahedron wrote:

SadNoob wrote:

-snip-

I meant that if you put the

if <(Mouse lock?) = [off]> then
...
end

then the program would let the sprites react to this only if the mouse lock is off* (you can still move your mouse, though).
*This setting can be turned on or off in the project by, for example, pressing a certain key.

Again, as I understand, the whole point of the block is to not allow the mouse to move. OP is suggesting this to be something like 3D games, where your mouse is always locked in the middle, and you can move it to rotate the camera.

SadNoob wrote:

WindOctahedron wrote:

SadNoob wrote:

-snip-

I meant that if you put the

if <(Mouse lock?) = [off]> then
...
end

then the program would let the sprites react to this only if the mouse lock is off* (you can still move your mouse, though).
*This setting can be turned on or off in the project by, for example, pressing a certain key.

Again, as I understand, the whole point of the block is to not allow the mouse to move. OP is suggesting this to be something like 3D games, where your mouse is always locked in the middle, and you can move it to rotate the camera.

Wait, you said the mouse would be locked (so it can't move), but then you said that you can move it!
(I still understand that you can move the mouse externally… or what?)
Anyway, I just wanted to say that the program just won't react if the mouse lock variable is set to a certain value that denotes that it is on/off, and would react if the variable is set to another certain value that denotes that it is off/on.

I don't think that web browsers allow web sites to lock the mouse in one spot so that won't work very well.

imfh wrote:

I don't think that web browsers allow web sites to lock the mouse in one spot so that won't work very well.

The Pointer Lock API exists. It's a bit finicky to prevent its abuse and requires the user to click on the web page for it to work, so instead of a block that enables it, there should be a checkbox allowing the project to request to lock the mouse pointer when the user clicks the green flag

Sheep_maker wrote:

imfh wrote:

I don't think that web browsers allow web sites to lock the mouse in one spot so that won't work very well.

The Pointer Lock API exists. It's a bit finicky to prevent its abuse and requires the user to click on the web page for it to work, so instead of a block that enables it, there should be a checkbox allowing the project to request to lock the mouse pointer when the user clicks the green flag

It's been done on Classic Minecraft too.
I reported my other accidental post and replaced it with a single line so it doesn't clutter up the thread

SadNoob wrote:

Also, I think to go with the mouse direction block, we should probably also have a block that simply is:

mouse speed :: reporter sensing // this simply returns the speed of the mouse in the direction specified by mouse direction

Good idea lol.

One idea is you have a Sprite that follows the Mouse when the Variable “Lock Mouse?” is False, then all your additional code will pretend this Sprite is the Mouse

I have a similar issue, but to figure out if the mouse ISN'T moving