Stop movement

[AstghikM]

Hi there
Please help me with movement problem So, the button is moving to mouseloc() and i need to stop it when the button touch to the border of a barrier, but the movement stops only when the button is on barrier. And i need to move it again after next click . Here is the livecode file.
I hope you can help me
Thanks:)

[newtronsols]

Have you looked at:

https://sites.google.com/a/pgcps.org/li ... collisions

[dunbarx]

Hi.

I am learning about the "move" command just like you are. It seems to be blocking, in that no messages are sent while a move is underway. So the conditional you set is not executed until the move is complete, and that is no help at all. On another note, you might have set it up this way, though, no?

Code: Select all

on mouseUp
 move button"player" to mouseloc()
  if intersect(button"player", graphic"barrier") is false then
end mouseUp

At least this reads sensibly, even though it will not work. Your original had the two lines reversed. This would allow the button to move only if it did not intersect the graphic. It would not have stopped the graphic at an intersect event.

All that said, I see no messages are sent at all during a move, and there seems to be no "moveMove" message, something akin to the "mouseMove" message, which is sent continuously when the cursor is in motion. It is true that a "stop moving" command can be issued during a move, but only from a control, not from the card, where you placed your handler. I started another thread based on your post. It is called "Starting and stopping the move command". It is of interest, but of no help at all here.

Someone may tell us both a simple and direct way to do this with the "move" command. It seems impossible that there is none. But if not, I will open a feature request for just such a thing: a "moveMove" message.

Craig Newman

[Simon]

This is what I came up with

Code: Select all

global moveMe
on mouseUp
   put true into moveMe
   if intersect(button"player", graphic"barrier") is false then
      move button"player" to mouseloc()
   end if
   aniLoop
end mouseUp

on mouseDoubleUp
   put false into moveMe
end mouseDoubleUp

on aniLoop
   if moveMe = true then
      put the loc of btn "player" into tLoc
      if intersect (btn "player", grc "barrier", "opaque pixels") then
         stop moving btn "player"
         set the right of btn "player" to the left of grc "barrier" --this line stinks because it does not cover all the sides
      end if
      wait 1 millisec
      send aniLoop to me in 50 millisec
   end if
end aniLoop

not the best.

Simon

[sefrojones]

Hi all,

To make move non-blocking, you can use "without waiting". I think this example covers it:

1. create a new stack with 1 button named "player", 1 graphic named "barrier" and a checkbox named run.

2. Add this to the stack script:

Code: Select all

on gameloop
   if the hilited of btn "run" is true then
      if intersect(btn"player",grc"barrier","pixels") then
         stop moving btn "player"
      end if
   end if
   if the hilited of btn "run" is true then
      send gameloop to me in 2 ticks
      end if
end gameloop

on mouseup
   put the mouseloc into tMove
   move btn "player" to tMove without waiting
end mouseup

3. add this to the checkbox button "run"'s script:

Code: Select all

on mouseUp
   if the hilited of me is true then
      gameloop
      end if
end mouseUp

4. check the "run" button, and click around the card.


Hope this was helpful

[dunbarx]

Try this.

Make a button and a graphic. Put this into the card script.

Code: Select all

on mouseup
   collision
   move btn 1 to the clickLoc in 2 seconds
end mouseup

on collision
   if intersect( btn 1,grc 1) then
      stop moving btn 1
      exit to top
   end if
   send "collision" to this cd in 1
end collision

Now there will be a little housekeeping required here, but you should be able to make it work the way you want it to.

To the others. "Blocking" is not quite accurate, as other processes can run alongside the move, as seen in the above example. I started this whole thing, and though some of the story is odd and interesting, much is fluff. My bad. I still want to know if there is a way to implement a "moveMove" message while the move is underway, so that another handler is not required to test the state of the IDE while a control is in motion.

Craig

Craig

[sefrojones]

Craig,

Apologies if "blocking" was not the proper terminology. I have to admit, I'm in a bit over my head here. As far as I've known you will need a "game loop" if you want to check for intersections(etc) during a move. I discovered, quite by accident while making this stack https://www.youtube.com/watch?v=tgZiUR7Uq-E that I needed to use "without messages" in order to make it work. Once it was working, I never looked for another way to do it, as I assumed this was the way. Beyond that, I do not know. If it turns out there is nothing like this "moveMove" that you speak of, and you do file a feature request, I'd gladly support it.

--Sefro

[dunbarx]

Sefro.

I was the one who first misused the term "blocking", so no apologies needed. I now prefer the term "recalcitrant"

Craig