Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The sensing_of block doesn't work with the stage in an obscured shadow input #4112

Open
adazem009 opened this issue Oct 19, 2023 · 3 comments

Comments

@adazem009
Copy link

Expected Behavior

When using the sensing_of block to get a property of a sprite or the stage, it should work for the stage even if the target (not sprite) name is in an obscured shadow input.

Actual Behavior

The block returns zero for all properties.

Steps to Reproduce

See the screenshot.

Steps to reproduce the behavior:

  1. Drag the "of" sensing block into the code area.
  2. Put a join block into the second dropdown menu button.
  3. Type Stage into the first input of the join block and make sure the second input is empty.
  4. Observe the return value of the "of" block.

System Details

(I don't think this is relevant for this issue)

Screenshots
image

@mxmou
Copy link

mxmou commented Oct 20, 2023

_stage_ works:
image

In Scratch 2, both Stage and _stage_ could be used:
image
image

@adazem009
Copy link
Author

_stage_ works: image

In Scratch 2, both Stage and _stage_ could be used: image image

Oh ok, I think I now understand why there's a reserved name for the stage. Stage isn't reserved which means sprites can be named Stage and that would cause problems if the Stage name were used to get a property of the stage.

I think this should be closed then. What do you think?

@mxmou
Copy link

mxmou commented Oct 21, 2023

Oh ok, I think I now understand why there's a reserved name for the stage. Stage isn't reserved which means sprites can be named Stage and that would cause problems if the Stage name were used to get a property of the stage.

I think this should be closed then. What do you think?

It's technically a 2.0 compatibility issue, but any 2.0 project relying on this has already been broken for a long time. I think it can stay open so that the ST can decide if they want to change the behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants