I am working on a puzzle project where the individual pieces are different costumes of the same sprite.My strategy is to treat the pieces as clones of the same sprite. My project works great in the normal and small stage displays but is inconsistent in the full screen mode. That is when you click the blue square in the upper left corner of the display. The problem seems to be in the motion blocks that deal with x,y coordinates. I experience this both in the on-line and off line versions of Scratch. My off-line version is 488, and I am on a Mac with OS 10.10.5.

Is there something about the full screen display mode that is different than the other two display modes? What am I missing?

Hi, can you share your project?, we want to click that nice blue square.

poppanona wrote:

I am working on a puzzle project where the individual pieces are different costumes of the same sprite.My strategy is to treat the pieces as clones of the same sprite. My project works great in the normal and small stage displays but is inconsistent in the full screen mode. That is when you click the blue square in the upper left corner of the display. The problem seems to be in the motion blocks that deal with x,y coordinates. I experience this both in the on-line and off line versions of Scratch. My off-line version is 488, and I am on a Mac with OS 10.10.5.

Is there something about the full screen display mode that is different than the other two display modes? What am I missing?

Maybe seeing it full screen is just magnifying what is also at small screen, only you don't notice it because it is small and not big?

Thanks for both of your responses. I have shared “Weird dog puzzle”, so that you can see the problem. This is a work in progress with other issues, but I know how to handle them. Be aware that when you drag the pieces, there are spurious drag points off of the pieces. This is due to a poor erasure of the grids when I made the pieces. I have worked through the shake module, but haven't touched explode yet

For me, the project works the same in both small screen and big screen, however there is no “snap in” function in either mode that you imply exists.

Be sure you always test in the project window, not the editor window. And if you have access to another computer, test it there.

Thank you footsocktoe,

I see what you mean. Why does it work ( it really does) in the editor window, but not the project window? I am developing this project on my home Mac using the offline version of Scratch. The snap in feature works as I implied in all windows except full screen there too.

I have a counter in my code to keep track of pieces as they are fitted to the work panel. It works (counts to 16). The same code that advances the counter, causes the piece to snap into the work panel with the go to statement block. All pieces, including the work panel have X/Y =0/0 as their rotation center.

Thanks

poppanona wrote:

Thank you footsocktoe,

I see what you mean. Why does it work ( it really does) in the editor window, but not the project window? I am developing this project on my home Mac using the offline version of Scratch. The snap in feature works as I implied in all windows except full screen there too.

I have a counter in my code to keep track of pieces as they are fitted to the work panel. It works (counts to 16). The same code that advances the counter, causes the piece to snap into the work panel with the go to statement block. All pieces, including the work panel have X/Y =0/0 as their rotation center.

Thanks

The editor window has drag and drop enabled in a way that the project window does not. So anytime you are coding something involving dragging with the mouse, you have to be sure it works in the project window.

As far as snap in goes, when a piece gets a GoTo command, how does it know where to go? What puts the x and y in the GoTo?

Wow! Do you know of any plans to fix this? It makes if very difficult to design a project if you can't plan on things being the same in the editor as it is in the project window. Is there any place we can go to find out what things are different?

As far as the snap in feature goes, there are code blocks that seemed to have this in mind. There is one block that gives you the DISTANCE to the center of a selectable sprite, and another that has a GO TO two the same sprite or another sprite. I used both of these in my BUILD module . You use the down arrow on them to select the chosen sprite.

(distance to [ v])
go to [ v]

I am going to try to find a work around. If I do, I'll post it here.

Thank you footsocktoe for your assistance.

poppanona wrote:

Wow! Do you know of any plans to fix this? It makes if very difficult to design a project if you can't plan on things being the same in the editor as it is in the project window. Is there any place we can go to find out what things are different?

As far as the snap in feature goes, there are code blocks that seemed to have this in mind. There is one block that gives you the DISTANCE to the center of a selectable sprite, and another that has a GO TO two the same sprite or another sprite. I used both of these in my BUILD module . You use the down arrow on them to select the chosen sprite.

(distance to [ v])
go to [ v]

I am going to try to find a work around. If I do, I'll post it here.

Thank you footsocktoe for your assistance.

Most people creating a project would expect to be able to place the sprite in the editor by dragging and dropping it but don't necessarily want the sprite to be movable when actually running the project. So there will be no plans to fix this as it wouldn't make sense for most people. Just remember to test in the project page, not the editor.

Thanks for your explanation of the reasoning behind this. However, there are many of us who like the diversity of building jigsaw puzzles on Scratch. In these cases, you definitely want to drag a piece in the project and full screen windows. The snap in feature would be handy to have, especially if you have a puzzle with a large number of pieces.

Thanks deck26

poppanona wrote:

Thanks for your explanation of the reasoning behind this. However, there are many of us who like the diversity of building jigsaw puzzles on Scratch. In these cases, you definitely want to drag a piece in the project and full screen windows. The snap in feature would be handy to have, especially if you have a puzzle with a large number of pieces.

Thanks deck26

Coding a snap in isn't difficult. If each piece knows where it should go - perhaps accessed from lists of x and y positions - you could, for example, set a global variable to the item number in the lists and broadcast to get a ghosted sprite to go the correct position for the current piece. You can then snap into place if the piece is released within a certain distance of that sprite. That has the advantage that you don't need a regular grid so can have different shaped pieces.

After close observation of what is happening in my program, I came to the conclusion that you can't execute a GO TO statement when the mouse is down. If the mouse is down, then the GO TO block is ignored and skipped over during code execution.This is not true in the editor window, it only occurs in the project window displays.

When I put this code block in front of my GO TO block, happiness abounds.

wait until <not <mouse down?>

This will give you time to lift your finger off the mouse before the following code executes.
Now puzzle makers can put a snap in feature into their projects.

Thanks to all responders for participating in this discussion with me.

https://scratch.mit.edu/projects/117541126/ shows there's no problem moving with go to when the mouse button is down. Perhaps you have another script causing the problem.

Or it's a browser/other issue - My browser / operating system: Windows NT 10.0, Firefox 47.0, Flash 22.0 (release 0)

I went to your link, and the mouse down doesn't indeed affect the code execution. However, you need to be dragging the sprite to see the mouse down affect. Try to catch the sprite on yours.

I remixed your project as “Mouse down holds action” and shared it, but I don't know how to share it as a link. I did two things to your project. In the editor, I made your sprite draggable. I then added code to make it necessary to drag the sprite off of X=0 to execute. Note that it doesn't execute the random moves until the mouse button is released.

Earlier in this discussion thread, it was mentioned that Scratch was deliberately made to perform differently between the editor and project windows when executing the drag and drop function. This comment is what led me to examining the mouse function.

I think that from my point of view, it is fair to say that if you drag a particular sprite, the code for that particular sprite will skip over any GO TO statements while the mouse is down. It has nothing to do with my browser (remember, my off line version behaves the same) or with other sprites or scrips (Yours has only one).

Thanks again for your comments, they are providing a better understanding of Scratch for me.

Not surprising in the least! When you make the sprite draggable and click on it the mouse is in control of the sprite until you release it.

Either the draggability or the movement blocks have to take priority and the mouse is probably the obvious one to give control.

Avoid using draggability as much as you can - use code to move the sprite and to allow it to be moved by the mouse.