Code Bugs

[Mark]

Hi,

I'll look into that tomorrow.

Kind regards,

Mark

[endernafi]

The button doesn't return to it's first location (myLoc variable).

itay1023 hi,

Since you didn't send a sample stack, which is a very good thing to get better solutions by the way,
I'm guessing that you want that button return to the location of mouseDown moment, right?

If it's so, then you have to store that first location.
But I've noticed some other things.
For example, you put an if clause inside the mouseDown handler, but it doesn't serve a purpose.
You don't check that _startTheGame variable anywhere else and you put true into the lMouseClicked anyways.
It's either a mistake or I didn't understand your game's structure.

Try this change:

Code: Select all

on mouseDown
   if _startTheGame is true then
      put true into lMouseClicked
      put mouseLoc() into myLoc -- store the initial position, first location in your words
   else
      put false into lMouseClicked
      put empty into myLoc
   end if
end mouseDown

on mouseMove pX, pY
   if lMouseClicked then
      set the loc of me to pX,pY
      theButtonVar
   end if
end mouseMove

on mouseUp
   if lMouseClicked then
      set the loc of me to myLoc -- return to the initial position which we've stored in the mouseDown handler
      put false into lMouseClicked
      put empty into myLoc
      cancel tMessageID
   end if
end mouseUp

Hope it helps...

Best,

~ Ender Nafi

[Mark]

If I understand you correctly, the problem is not that the collision is wrong but that the control doesn't return to its original location. To solve this, you need to put the location into a local variable before moving and set the control's location to that variable when you finish.
Don't declare myLoc outside a handler. It messes up everything. Variables that start with "my" are for inside single handlers only.

Code: Select all

global _life
global _startTheGame
global _score
global blackVar

local LocVar
local lMouseClicked
local tMessageID
local lOriginalLoc

on mouseDown
   put true into lMouseClicked
   put the loc of me into lOriginalLoc
 end mouseDown

I have noticed that in your theButtonVar handler, you're still using a visual effect, even though someone already told you that you shouldn't do this. Why don't you accept someone's advice and do as s/he says? You should do that before you ask for help again. The if statement with the exit mouseDown doesn't make any sense whatsoever.

Every time the mouseMove handler runs, which could be 20 times per second, you setthe loc of button "blueBubble" to -100,-100. This takes time but doesn't make any sense. Move that to the mouseDown handler.

Code: Select all

on mouseMove
   if lMouseClicked is true then
      put the mouseLoc into myLoc
      set the loc of me to myLoc
      theButtonVar
      end if
end mouseMove

Note that on tablets, you can't check if the mouse is up. Therefore, the comments related to checking if the mouse is up make no sense. That is also why we put false into the lMouseClicked variable in the mouseUp handler.

Code: Select all

on mouseUp
   put false into lMouseClicked
   set the loc of me to lOriginalLoc
end mouseUp

Btw theButtonVar is a really weird name for a handler. It is very weird to start a handler with "the" and even weirder to give a handler the name that you'd normally assign to a variable. Why do you do this?

I haven't included the theButtonVar# handlers here. Why do you finish each handler with the next handler? This makes your script less understandable and more verbose. Just write one long theButtonVar handler.

You shouldn't use the send command. The mouseMove message fires theButtonVar1, which in turn fires theButtonVar2 and all following handlers. Remove the send command. You also need to remove the cancel command, because if you don't use the send command, you don't need the cancel command anymore.

So, I hope that you understand that porting the script to iOS and Android takes a complete rewrite of the entire script. Therefore, you should start with my example and adjust that until you have something that does what you want. That will be much easier than adjusting your old script.

Kind regards,

Mark

[Mark]

Ender Nafi,

You forgot to declare the local variable lMouseClicked and there is no need to put empty into myLoc. Also, using the cancel command is unnecessary.

Kind regards,

Mark

[endernafi]

Mark hi,

Actually, I didn't declare any of the script variables.
I've written that code snippet of mine as a patch to the script which Itay has sent in the previous post.
That's why I've put the cancel command, for example.
I have no idea what it does

Another thing is that the structure of Itay isn't effective in many ways.
Calling handlers in a chain from each other?

Games must contain an update screen routine;
to achieve a reasonable fps value and for many other benefits.

Game Academy has a sample for this.
Itay, I strongly advise it to you.


Best,

~ Ender Nafi

[itay1023]

Thank you very much- all of you!!!
You helped me very much

Best,
Itay

[Mark]

Hi Ender Nafi,

Game Academi and LC University etc. are not for me. They are interesting to look at to see the learning approach, but I don't use them as a source for programming concepts and ideas.

I fully agree that the chain of handlers makes no sense. I wrote this in my previous message and I hope that Itay will rewrite his script.

Sometimes an updateScreen handler is useful, but sometimes games will be much faster if all objects have their own updating routine, independently from everything else in the game. I made a simple arcade game this way and it is surprisingly fast.

Kind regards,

Mark

[jacque]

Variables that start with "my" are for inside single handlers only.

Just a note for future forum readers to clarify: this is a developer preference, not a LiveCode requirement. LiveCode doesn't care what you name your variables or handlers, use whatever makes sense to you. It has become customary among some of us to follow certain guidelines in naming conventions, but except for restrictions on some forbidden characters, the LiveCode engine doesn't care.

[Mark]

And yet, Jacque, it seems to me that my suggestion is very useful for OP while in this particular case a relativisation of this advice doesn't seem appropriate.

Mark