My browser / operating system: Windows 7, Chrome 53.0.2785.143, Flash 23.0 (release 0)

https://scratch.mit.edu/projects/126895285/#player
look at the editor.
it works fine when i place the costume switcher right before the stamp, but it stamps the wrong costume if i place it before the “wait until mouse down” despite there not being anything that should change it between there.

(i read the post about making these bug reports properly but i'm not sure about how to format this in a good way - the things it says i need to have are pretty clear without needing to specify it, i think)

Let's try this in “Help With Scripts” first to see if a helpful person can see a scripting error, before we assume it's a bug. We can always move it back later.

Can you describe what you think it should do as it seems to do as expected looking at the script?

1234abcdcba4321 wrote:

My browser / operating system: Windows 7, Chrome 53.0.2785.143, Flash 23.0 (release 0)

https://scratch.mit.edu/projects/126895285/#player
look at the editor.
it works fine when i place the costume switcher right before the stamp, but it stamps the wrong costume if i place it before the “wait until mouse down” despite there not being anything that should change it between there.

(i read the post about making these bug reports properly but i'm not sure about how to format this in a good way - the things it says i need to have are pretty clear without needing to specify it, i think)

Then there isn't such bug.

I commented in the earlier topic on this and couldn't see any problem with the code but others may spot something.

Basically what should happen is that each click of the mouse should result in a new stamp and it should use alternate costumes - so one click gives a red square, the next a green square, then red and so on.

This current version uses the ‘m’ key to switch between two methods. One does the ‘next costume’ at one stage in the script and the other method does this at a different point in the script. So the question is why one method appears to work consistently whereas the other doesn't?

It does seem to lag a bit as well for me but Scratch generally doesn't seem to be behaving too well. My browser / operating system: Windows NT 10.0, Firefox 49.0, Flash 23.0 (release 0)

@1234abcdcba4321 - I suggest you add a comment to your project along the lines of the above to make it clearer what you're seeing.

Actually i do not see any bug, it just does that what has been programed.

asivi wrote:

Actually i do not see any bug, it just does that what has been programed.

So do you see alternate colour squares regardless of method or can you explain why one works and the other doesn't.

If you see it working please share your system details.

Pressing the green flag is considered a mouse click, so, the project waits till the mouse pointer leaves the green flag, still registering as mouse down, and then starts the codes. As the mouse pointer reaches leaves the green flag, the mouse is not down and hence, changes the costume. Still confused what it should do as using both methods, it prints r-y-r at start. As for changing the stage while running, it will give same costume previously stamped as you let go of the mouse (stop clicking it). You will notice that after clicking, holding mouse down, and pressing m key, and releasing the mouse will keep it consistent. This is caused because, u click, changes costume, stamps, stops clicking so not mouse down is fulfilled, runs script to see if cap is 1, which it's not, so keeps the costume, m is pressed changing cap to 1, mouse is down, but cap in not 0, so keeps costume. Same goes for when switching back.

P444 wrote:

Pressing the green flag is considered a mouse click, so, the project waits till the mouse pointer leaves the green flag, still registering as mouse down, and then starts the codes. As the mouse pointer reaches leaves the green flag, the mouse is not down and hence, changes the costume. Still confused what it should do as using both methods, it prints r-y-r at start. As for changing the stage while running, it will give same costume previously stamped as you let go of the mouse (stop clicking it). You will notice that after clicking, holding mouse down, and pressing m key, and releasing the mouse will keep it consistent. This is caused because, u click, changes costume, stamps, stops clicking so not mouse down is fulfilled, runs script to see if cap is 1, which it's not, so keeps the costume, m is pressed changing cap to 1, mouse is down, but cap in not 0, so keeps costume. Same goes for when switching back.

If you're suggesting pressing ‘m’ more than once that's not the idea. The original mode when the green flag is pressed seems to work (for me anyway). If I then press ‘m’ once to change the method subsequent mouse clicks do not give alternate square colours but as far as I can see it should work in that mode as well as the initial mode.

Sorry if I've misunderstood what you're saying.

deck26 wrote:

If you're suggesting pressing ‘m’ more than once that's not the idea. The original mode when the green flag is pressed seems to work (for me anyway). If I then press ‘m’ once to change the method subsequent mouse clicks do not give alternate square colours but as far as I can see it should work in that mode as well as the initial mode.

Sorry if I've misunderstood what you're saying.

It's ok, I am not good at explaining too well xD
As you said, it works when starting out. The problem begins when you press m. I'd try to explain myself a little better this time…

First, projects starts up by setting the variable capture2 to 0, so you have a misconception that the other method doesn't work. But it does. Try changing the value to 1 when starting and it does work perfectly fine.

Second, as the value is set from start, pressing m before will not change it when restarting.

Third, when changing while the script is running, the previous script is triggered. I'll try explaining by some pictures here. When starting, the capture2 is 0, so the first script after wait until not mouse down will ignore it.

And will wait till mouse down and continue. Now, after the mouse is down, it changes costume, stamps and immediately goes back up, where as said before, waits till not mouse down. And as it was a click, the mouse is NOT down, and so again runs the script, which is still false. Here, we press m, and change capture2 to 1. And then after we click, the “if capture2 = 0” is false, as pressing m changed it. So it will not change the costume in this round, and goes back up. As it was a click, and again, the mosue is not down, and this time, the capture2 IS 1, it will change costume and resume. Same goes when coming back to capture2 being 0.

Lastly, to avoid that, click and HOLD, then press m, and stop holding the click, and the scripts should change costume. Again, I am referring to the first part.


As you hold down mouse, the condition is not met, and when m is pressed and capture2 is changed to 1, then letting go of the mouse will keep the script running and altering costumes as intended.

So, it is not a glitch, just a flaw in the conditions.

Sorry @P444, but it still sounds to me like you're either not seeing the problem in the way I am or are pressing the m key more than necessary.

Regardless, let me simplify. If I remove the code to detect the ‘m’ key and just set the capture2 variable manually it works with alternate colours if capture2=0 but not if capture2=1.

Here's a remix which disables the ‘m’ key https://scratch.mit.edu/projects/127001098/ . So what happens for you when capture2 has value 0 and when it has value 1?

deck26 wrote:

Sorry @P444, but it still sounds to me like you're either not seeing the problem in the way I am or are pressing the m key more than necessary.

Regardless, let me simplify. If I remove the code to detect the ‘m’ key and just set the capture2 variable manually it works with alternate colours if capture2=0 but not if capture2=1.

Here's a remix which disables the ‘m’ key https://scratch.mit.edu/projects/127001098/ . So what happens for you when capture2 has value 0 and when it has value 1?

Um… I said holding the mouse click and pressing m key once….
Anyhow, both methods gave me exact same thing. Left to right.

So you're not seeing the problem which the OP and I are both seeing which makes it look like a bug to me. When capture2=1 the costume number changes as expected but what gets stamped can be the same colour of square repeatedly although if you wait a while between mouse clicks it will sometimes change colour.

So what's your system info?

My browser / operating system: Windows NT 10.0, Firefox 49.0, Flash 23.0 (release 0)

Ok so uh, I guess we have the same specs, but are having trouble? Could it in any case be related to hardware?

P444 wrote:

My browser / operating system: Windows NT 10.0, Firefox 49.0, Flash 23.0 (release 0)

Ok so uh, I guess we have the same specs, but are having trouble? Could it in any case be related to hardware?

Don't know. Anyone else any suggestions?

Checked the project with both values on chrome. Doesn't work when it's 1.
My browser / operating system: Windows NT 10.0, Chrome 53.0.2785.143, Flash 23.0 (release 0)

So I am not sure what is at fault here… Me and @deck26 have exactly same browser and operating on firefox. While I got it to work, he couldn't. I tried using chrome and then it happened… Still working fine on firefox

Fails for me in Chrome as well.

A bit more information on the bug.

1) The bug is completely unrelated to the mouse.
If you put a standard wait statement (eg. wait 0.005) after “next costume” but before “stamp”, then the costume doesn't change.

2) Even if you use you toggle the costumes explicitly (ie. with “switch costume to …”) rather than using “next costume” the bug still occurs.

3) The problem is unrelated to the loop that it is inside (ie. nothing to do with a program ceding to let other code run at the end of a loop)
If you remove the script from the loop, and execute it a few times by clicking the script, there is no change to the behaviour.

4) This bug disappears when you run the project in full screen!
(This is only additional information - it does not fix the bug).

I am just as stumped as deck26.
.

Scratch-Minion wrote:

A bit more information on the bug.

1) The bug is completely unrelated to the mouse.
If you put a standard wait statement (eg. wait 0.005) after “next costume” but before “stamp”, then the costume doesn't change.

2) Even if you use you toggle the costumes explicitly (ie. with “switch costume to …”) rather than using “next costume” the bug still occurs.

3) The problem is unrelated to the loop that it is inside (ie. nothing to do with a program ceding to let other code run at the end of a loop)
If you remove the script from the loop, and execute it a few times by clicking the script, there is no change to the behaviour.

4) This bug disappears when you run the project in full screen!
(This is only additional information - it does not fix the bug).

I am just as stumped as deck26.
.

Thanks for the input - not my problem but interested in what's happening. I do wonder about the current state of things in terms of Scratch/Flash etc but @P444's experience perhaps suggests something more than that. I'm on my Chromebook now and it still fails when the variable is 1.

My browser / operating system: ChromeOS 8530.96.0, Chrome 53.0.2785.154, Flash 23.0 (release 0)

Please, can someone to offer an step by step way to reproduce the bug?
No needed to comment about the scripts, just something like:
greenflag-nothing happens
click-stamps red-OK (or not OK)
click-stamps green-OK (or not OK)
press m
click-stamps…