I had created a Senet Game and simply wanted to drag the counter to the Square 30 and when it is touching the “Afterlife” it is jumped off the board and scored.

Prior to the fix when it landed on the “Afterlife” and required more than one click to be recognised.

What I was doing wrong? Nothing I could see!

https://scratch.mit.edu/projects/767971535 <<< Now working

Fix: Scratch needs to have Draggability set to False at initiation for Dragging and Touching to work later in the game.
It makes no difference if Draggability set it to False later in the code.
I hold this to be a bug, while Deck26 sees it as unexpected behaviour.

Deck26’s work around gratefully received!

Don't really understnd how to play the game. I can see how to throw the sticks but don't understand how to read them. But that may not matter - can we just grab a counter and move it to square 30 regardless of what the sticks are showing (or is that an easy way to set it up so that would be allowed)? Where are the scripts you think should be detecting landing on square 30?

Sorry ignore the rest of this - I was testing in the editor.

OK, think I see what's happening.

Blue1 works because you have a wait until touching afterlife block. The ones that don't work are missing this.

The counters are draggable , you can cheat and drag them straight to Square 30 to test the code.
Each counter has the code to check if it is touching the “Afterlife” the circular element in Square 30

I have tried lots of variants including the Wait until touching the afterlife. None seemed to work consistently.

Strange one. Not sure why it was happening but try changing the wait until touching afterlife to wait until touching afterlife and not mouse down.

You might later want to just wait until not mouse down since the script would be best not stuck in a wait until state if the player has placed the piece elsewhere.

You also have a problem if the player just places a piece on their own score area - it will not be moveable after that. You may be better handling the movement yourself - getting the sprite to follow the mouse if the mouse button is down but only within the board area.

I suspect the code has run prior to the counter being placed, thus while the counter was “in flight” the code decided it was not touching the Afterlife

What I really want to do is for the code to run when the counter is placed.
The best way I came up with was the wait until code block.

Perhaps the issue is once 10 counters have been clicked, they are all in wait mode, and Scratch doesn’t like the load??

I am starting to consider an alternative that has the afterlife continuously trying to detect the 10 inbound counters and then sending them a message to bounce them into the afterlife.

I always find these Scratch timing issues more complex than I feel they need to be! Maybe I am over complicating the problem?

Is there an easier way?

Personally I'd make your project handle the movement - the player just clicks on the counter they want moved and your project moves it for them. Saves doing a lot of checking that the move they make is valid.

Our messages crossed!

I will work on your not Mouse Down idea

Thank you

PS I have no idea how to restrict the action to the board area do you have any coding examples for that?

Part of the reason for the counter movement is for my Grandchildren to learn to add numbers to be able to jump to the correct square straight away rather than count each time. It also allows for cheating, which is always useful, to encourage fair play, rather than enforce fair play!! Each player then has the Motivation to check the moves of their opponents…. Double the Maths!!

Just use the x and y position of the mouse. So only go to the mouse-pointer if mouse down and mouse x > -200 and mouse x < 200 for example.

If you centre the board it makes it easier as you can look for abs (mouse-x) < 100 to detect being within 100 of the screen centre as far as x is concerned.

I've created a demo project that replicates your issue and will post in Bugs & Glitches to see if anyone can explain it. I suspect some sort of odd interaction between draggability and ‘when sprite clicked’.

https://scratch.mit.edu/projects/769049497/ - actually works as you intended but ONLY if the sprite is initially set to not-draggable. If testing it make sure you click the green flag if you change the draggability state in the green flag script.

Still think you're better not just using draggability - most people avoid it if they want any sort of control over what the player can do - but it perhaps explains what's happening.

So if the sprite is draggable I suspect Scratch differentiates between a click and starting a drag.

Weird! I love how you found a work around.

I foolishly assumed that the Sprite was not draggable by default! Note I had thought to switch it back to not draggable after each move.

So there is some higher level issue at play…

I still can’t see how you thought to force it to not draggable in the start up Flag, and I certainly can’t see the difference between me setting it to not draggable after the click and the initial system state of the Sprite.

However, my code now works!! THANK YOU

Sadly I pity any 7 year old trying to fathom that!!!


It’s a BUG!

There's not much in Scratch that has a default setting. So draggability, rotation style etc will keep the setting they had when the project was saved in the same way as variables just keep values, sprites remember costumes etc.

I'd agree this is not behaviour I'd have expected but not sure I'd consider it a bug.

Hmm.. I think we have to agree to differ having set the draggability to False having moved it on the board, I would not have expected that the setting to false at the start of the game could or would make a difference?

Unexpected /unexplainable behaviour in coding designed for kids is for me a bug.

They will have enough problem getting their own code working without Scratch tripping them up!!

It’s things like this that puts kids off coding…

Either way thanks for tracking down the “glitch” and finding the work around. Still in awe of your mental jump to get there!

I was imaganing you were the person that had coded the draggability feature! ;-)

Adrius42 wrote:

Hmm.. I think we have to agree to differ having set the draggability to False having moved it on the board, I would not have expected that the setting to false at the start of the game could or would make a difference?

Unexpected /unexplainable behaviour in coding designed for kids is for me a bug.

They will have enough problem getting their own code working without Scratch tripping them up!!

It’s things like this that puts kids off coding…

Either way thanks for tracking down the “glitch” and finding the work around. Still in awe of your mental jump to get there!

I was imaganing you were the person that had coded the draggability feature! ;-)

I'm just a normal Scratcher and have no connection to Scratch beyond that.

deck26 wrote:

Adrius42 wrote:

Hmm.. I think we have to agree to differ having set the draggability to False having moved it on the board, I would not have expected that the setting to false at the start of the game could or would make a difference?

Unexpected /unexplainable behaviour in coding designed for kids is for me a bug.

They will have enough problem getting their own code working without Scratch tripping them up!!

It’s things like this that puts kids off coding…

Either way thanks for tracking down the “glitch” and finding the work around. Still in awe of your mental jump to get there!

I was imaganing you were the person that had coded the draggability feature! ;-)

I'm just a normal Scratcher and have no connection to Scratch beyond that.

I’d go for Above Average!!