Please do not support because of a workaround, like most of these posts are workarounds, and it's just being unconstructive and changing X and Y exist or the move steps block, basically of making the workaround useless depending on what you need the block for.

This block offsets the sprite and can help make scrolling games. This includes the hitbox.

offset by: x: (35) y: (13) :: motion
(X offset :: motion)
(Y offset :: motion)

I have no idea what you mean by offset, do you mean like the center of the sprite gets offset from where it should be? If what I said is the case, support, even if you could just make a billion costumes this would make it really easy and quick to have any type of off-centered sprite.

well what's the difference with this suggestion and

go to x: () y: ()

qwerty_wasd_gone wrote:

(#3)
well what's the difference with this suggestion and

go to x: () y: ()

if you go to like x: 20 and your x offset is 5 then you will go to x 25.

qwerty_wasd_gone wrote:

well what's the difference with this suggestion and

go to x: () y: ()

I presume OP wants a block that works similar to

change [ v] by (0)

but for X/Y, so instead of completely redefining X/Y it instead edits the current X/Y value by the written value.

still, with that being said, No Support as this is workaroundable. Try to define an X and Y variable. Make the sprite in question set their X and Y to the variable X/Y via a forever loop, then change the X/Y Variable. This may sound overcomplicated, but if you ever want to make scrolling games you're going to need to learn this mechanic now.

Alternatively, use the already-existing

change x by ()

and

change y by ()

blocks which do the same thing.

randomguy3513 wrote:

qwerty_wasd_gone wrote:

(#3)
well what's the difference with this suggestion and

go to x: () y: ()

if you go to like x: 20 and your x offset is 5 then you will go to x 25.

just do

go to x: (current x + (offset)) y: (current y + (offset))

(not in scratchblocks form cuz im lazy)

???

Why can't you do this?

Or:

medians wrote:

(#7)
Why can't you do this?

Yeah but what about this block, is there a offset workaround for this??

change x by ()
change y by ()

medians wrote:

???
Why can't you do this?

Workarounds aren’t a reason the ST won’t add something. Every block is highly work aroundable.

Another idea is this:

go to x: ((x position) + [some value]) y: ((y position) + [some value])

You all don’t understand (I think)

It visually offsets the sprite from it’s actual position, so the sprite is visually at a different location than it’s hitbox and everything else is

So for example if a touching block where to run it would only work if it’s touching the sprite’s position without the offset, this would be extremely useful for many many things, scrolling, cameras, animations, overlays, etc
So I support, but putting it in the looks category would probably help make the functionality be more obvious

randomguy3513 wrote:

This block offsets the sprite and can help a lot with making scrolling games.

Offset by: x: (12) y: (-15) :: motion

No support. There is no point to this block when this can be achieved in 2 seconds with simple addition and subtraction.

cookieclickerer33 wrote:

You all don’t understand (I think)

It visually offsets the sprite from it’s actual position, so the sprite is visually at a different location than it’s hitbox and everything else is

So for example if a touching block where to run it would only work if it’s touching the sprite’s position without the offset, this would be extremely useful for many many things, scrolling, cameras, animations, overlays, etc
So I support, but putting it in the looks category would probably help make the functionality be more obvious

that makes sense, I just didn't know what it did, support because of reasons above
I can think of a workaround, but this should be added anyways

qwerty_wasd_gone wrote:

cookieclickerer33 wrote:

You all don’t understand (I think)

It visually offsets the sprite from it’s actual position, so the sprite is visually at a different location than it’s hitbox and everything else is

So for example if a touching block where to run it would only work if it’s touching the sprite’s position without the offset, this would be extremely useful for many many things, scrolling, cameras, animations, overlays, etc
So I support, but putting it in the looks category would probably help make the functionality be more obvious

that makes sense, I just didn't know what it did, support because of reasons above
I can think of a workaround, but this should be added anyways

It’s because it’s in the motion category I’m sure of it

If it was in looks and placed after the graphic effect blocks it’s use would be a lot more obvious

Also maybe “visually offset” could work? But I feel like that’s a bit much

The workaround is very easy, it wouldn't be used as much as “change x/y by ( )”, and the language is complicated.
If there's somehow a situation where you can't

change x by ()
change y by ()

then use the Make A Block feature.

cookieclickerer33 wrote:

You all don’t understand (I think)

It visually offsets the sprite from it’s actual position, so the sprite is visually at a different location than it’s hitbox and everything else is

So for example if a touching block where to run it would only work if it’s touching the sprite’s position without the offset, this would be extremely useful for many many things, scrolling, cameras, animations, overlays, etc
So I support, but putting it in the looks category would probably help make the functionality be more obvious

I believe you understood it wrong, but if you didn't then thats even less support, as I believe most scratchers would be confused when introduced to the block: “hey scratch is glitching it says its touching when it isn't”

edward789121 wrote:

The workaround is very easy, it wouldn't be used as much as “change x/y by ( )”, and the language is complicated.
If there's somehow a situation where you can't

change x by ()
change y by ()

then use the Make A Block feature.

Yeah, it seems like the change x and y feature. You can just make this:

If you don't understand lists you can just use variables to achieve the same effect or use the change x and change y blocks.

blablablahello wrote:

I believe you understood it wrong, but if you didn't then thats even less support, as I believe most scratchers would be confused when introduced to the block: “hey scratch is glitching it says its touching when it isn't”

This seems a bit too easy plus I think people might be confused if they accidentally clicked this block or forgot they had it, or stuff like that.

blablablahello wrote:

cookieclickerer33 wrote:

You all don’t understand (I think)

It visually offsets the sprite from it’s actual position, so the sprite is visually at a different location than it’s hitbox and everything else is

So for example if a touching block where to run it would only work if it’s touching the sprite’s position without the offset, this would be extremely useful for many many things, scrolling, cameras, animations, overlays, etc
So I support, but putting it in the looks category would probably help make the functionality be more obvious

I believe you understood it wrong, but if you didn't then thats even less support, as I believe most scratchers would be confused when introduced to the block: “hey scratch is glitching it says its touching when it isn't”

That’s why it would be in the looks category

visually offset x:()y:()::looks

Doesn’t that make more sense?

Having it be listed after the graphic effect blocks would also make its use more obvious
It all depends on context, without context it doesn’t make much sense, but with it, the blocks use becomes more obvious

A do also “what if you accidentally clicked it” well the default value would be 0 so it wouldn’t be an issue


If the blocks doesn’t do that I don’t know what it would do otherwise,

bump and I clarified what I meant.

Half support. The only way I will support it is if it's a camera extension like the one on TurboWarp. Simply being able to offset is not enough to be worthy.

Here are some example blocks:

set camera position to x: () y: () :: #55bbdd

change camera x by ():: #55bbdd

change camera y by ():: #55bbdd

set camera x to ():: #55bbdd

set camera y to ():: #55bbdd

(camera x:: #55bbdd

(camera y:: #55bbdd

set camera direction to ():: #55bbdd

turn camera @turnRight () degrees:: #55bbdd

turn camera @turnLeft () degrees:: #55bbdd

(camera direction:: #55bbdd

set camera zoom to ():: #55bbdd

change camera zoom by ():: #55bbdd

(camera zoom:: #55bbdd

If you don't include these blocks then there is pretty much no point to your suggestion.