An object being "moved" is not where it appears to be

[rumplestiltskin]

Doing a fairly simple game demonstration for some neophytes. I have a square graphic on the screen named "theGold" and a button that initiates a loop moving the object from where it is to another loc (a few inches away) and then back again. Each half of the trip takes 2 seconds. In the square I have a mouseDown handler and the user is supposed to click on the square to exit the loop. It all works fine -except- it only works when the user clicks about 1/4-3/8" in front of the square (as in "before the square arrives at that location on screen"), not on the square. So my thought is that the location on the screen is, somehow, lagging behind the square's real location. I'm having a tough time wrapping my head around this as I'm running the stack on a 4GHZ Core i7 iMac with 16GB of RAM and SSD.

My two scripts are:

in the button that triggers the movement:

Code: Select all

on mouseUp
   global gotcha
   put false into gotcha
   repeat until gotcha is true
      move graphic "theGold" to 457,90 in 2 second
      move graphic "theGold" to 0,90 in 2 second
   end repeat
end mouseUp

...and in the square that is moving:

Code: Select all

on mouseDown
   global gotcha
   put true into gotcha
   answer "Ya got me, pardner!"
end mouseDown

Obviously, I can't lock the screen as the movement is part of the game.

Advice welcomed. Thanks!

[dunbarx]

Hi.

The "move" command, though smooth and easy to use, is sort of an internal stand-alone process in LC, and can be difficult in which to insert your own gadgetry once it gets going.

I could be completely wrong about that poor command, and have maligned it unforgivably. someone will chime in.

Anyway, just to try a completely different approach. In just the button script:

Code: Select all

on mouseUp
   set the loc of grc "theGold" to 200,100
    set the direction of this cd to "left"
   backAndForth
end mouseUp

on backAndForth
   if the optionkey is down then exit to top --always a safety to get out
   switch  the direction of this cd
      case "left"
         set the left of grc "theGold" to the left of grc "theGold"  - 1
         break
      case "right"
         set the left of grc "theGold" to the left of grc "theGold" + 1
         break
   end switch
   if the left of grc "theGold" < 100 then set the direction of this cd to "right"
   else if the right of grc "theGold" > 300 then set the direction of this cd to "left"
   
   if the mouse is down and the mouseLoc is within the rect of grc "theGold" then exit to top
   else send "backAndForth" to me in 1 millisec
end backAndForth

Not as fast or smooth. But less baggage. If you make the grc small, you can probably live with the crawl.

And so, you others out there, how pliable is the "move" command if you want to slip something by? Messages are live while it, er, moves, but it does seem a little stubborn and uncaring.

Craig Newman

[bogs]

Hm. I haven't experimented extensively with move, least not in the way your asking about it.

Some things I *might* try off the top of my head (not near my dev systems at the moment, so take with grain of salt) -
.. you might add "with messages" on the move, i.e. move graphic "theGold" to 457,90 in 2 seconds with messages"
.. instead of two points (move to x,y), you might instead use say, 10 points to move along, which will let you refine the distance a click can hit the box.

Craig's method is a sure fire way to do it.

[dunbarx]

Bogs.

There is no "with messages" allowed with the "move" command. I had the same idea, that I thought I might test, thinking along those lines about the "wait" command.

But i am in fact in front of LC at the moment, so I know these things.

You can say "without messages", though. But that goes against what we both had in mind.

Craig

[bogs]

But i am in fact in front of LC at the moment, so I know these things.

Heh, I really need to wait till I'm in front of my dev machine before submitting theories I can't test out

Did you also test the move along multiple points path? Or should I

[jmburnod]

Hi,
Craig's way work like a charm for me.
@rumplestiltskin
You may stop pending message with this

Code: Select all

--••stop one pending pMessage
on doStopPending pMessage
   repeat for each line aLine in the pendingmessages
      if pMessage = item 3 of aLine then
         cancel item 1 of aLine
      end if
   end repeat
end doStopPending

Best regards
Jean-Marc

[rumplestiltskin]

Hi.

The "move" command, though smooth and easy to use, is sort of an internal stand-alone process in LC, and can be difficult in which to insert your own gadgetry once it gets going.
...{snip}...
Craig Newman

Craig,

Thanks for your example script. I tried it and it seems to work but it is, as you indicate, very slow. I tried using a button instead of a graphic (changed your code "grc" to "button") and left the button's auto-hilite on. Surprise! I can click on the button and see it hilite yet it doesn't always stop the button from moving. That is troubling. Is this more LC overhead interfering with things?

Thanks,
Barry

[rumplestiltskin]

Hi,
Craig's way work like a charm for me.
@rumplestiltskin
You may stop pending message with this

Code: Select all

--••stop one pending pMessage
on doStopPending pMessage
   repeat for each line aLine in the pendingmessages
      if pMessage = item 3 of aLine then
         cancel item 1 of aLine
      end if
   end repeat
end doStopPending

Best regards
Jean-Marc

I don't quite follow the logic of your code. I looked in the dictionary but I don't understand what you are testing; just the existence of any message?

[rumplestiltskin]

I should note that I'm not married to any particular method to get this done. Craig's code does provide accuracy but at the cost of speed.

I remember doing a game some years ago where I had 8-10 objects flying around a window and bouncing off the walls in a geometrically(?) correct bounce. I did not seem to have any sort of inaccuracy in clicking on the flying objects. IIRC, each object had all the code necessary to move them, change the direction of motion when they touched the walls, and react to the mouseDown. (Now where did I store that stack????)

Barry

[jacque]

The default behavior of the move command is to allow messages, which is why there is only the option to ignore them. In the original handler, I believe each move will complete before the engine checks for any messages. That means that by the time of the check, the square will be at, or at least near, its destination.

The way around that is to control the move yourself as Craig has done, but increments of one pixel are too jerky. You can smooth that out a bit by using larger increments along with the move command. In this case you could probably use an increment that is half the width of the square, on the assumption that the user will tap near the middle of it. The other trick is to use the move command rather than the set command so that the incremental positioning is smoother.

You'll have to experiment a bit to get the right timing and incremental values but it should get you close. I'm not at my Mac right now to test but that's the general idea.

[dunbarx]

Jacque raises an interesting idea. Set up successive small moves and play in the interims. But as she points out, the user may have to click near the center for the thing to work, and with small targets, that may be difficult..

Craig

[jmburnod]

Hi Barry,

I don't quite follow the logic of your code. I looked in the dictionary but I don't understand what you are testing; just the existence of any message?

from Craig's script:

Code: Select all

send "backAndForth" to me in 1 millisec

"backAndForth" is a pending message you can stop with

Code: Select all

doStopPending backAndForth

Jean-Marc

[rumplestiltskin]

I found my old game stack (from 2003, no less!) and, sure enough, it was using Craig's suggestion of incrementing the "set location" rather than "move". I'll have to find the rest of the resources (as I used pictures in the objects and they're missing - probably just have to put them in the proper folder). These objects didn't move around the screen very fast and they were about an inch square in size on-screen as the stack was for children.

I think I now have enough info to proceed. Thanks very much to everyone for their guidance!

[*sigh] - Would have been nice if LC didn't have so much in the way of overhead. The move command would have been so easy.

Regards,
Barry

[[-hh]]

The move command would have been so easy.

The move command can be easy: Here is just another option to show this.

Script your card with the following, no script in the moving graphic. Start with a click on the (stopped) graphic.

Code: Select all

local gotcha=true

on moveIt
  -- if "moveIt" is in the pendingmessages then exit moveIt -- for testing
  if (the shiftkey is down and the cmdkey is down) then put true into gotcha
  if gotcha then exit moveIt
  move graphic "theGold" to (457,90),(0,90),(457,90) in 4 seconds without waiting
  send "moveIt" to me in 4 seconds
  -- put the pending messages -- for testing
end moveIt

on mouseDown
  if not gotcha and the clickloc is within the rect of grc "theGold" then
    put true into gotcha
    move graphic "theGold" to (the clickH,90) -- stops moving
    answer "Ya got me, pardner!"
  end if
end mouseDown

on mouseUp
  if gotcha and the short name of target is "theGold" then 
    put false into gotcha
    set loc of grc "theGold" to (457,90)
    send "moveIt" to me in 1 tick -- start move
  end if
end mouseUp

[bogs]

move graphic "theGold" to (457,90),(0,90),(457,90) in 4 seconds...

Hmmm, I guess I wasn't too far off in my thinking then. Btw, nice and smooth, here at least.