[RESOLVED] IsCollidingWithObject problem: not all code is executing

[elegantmechanic]

I am using the following code to track damage to a character if they touch a hostile object.  I want the character's health bar to decrease and the object to disappear.

Code: AGS

if (cEgo.IsCollidingWithObject (object[0]) == 1) {
health-=10;
HealthBar.Width=health;
object[0].Visible=false;
}

The problem I have is that, with the above code, the object disappears but the health value does not change.  If I leave out the object line, then the health does change for as long as the character and object are colliding. So both lines work if used by themselves but not if used together.

I feel I must be missing something very obvious but can't find the solution in the many other collision threads in the forum.

[Slasher]

Game.DoOnceOnly should help

[elegantmechanic]

Could you be more specific? Where do I need to apply that function?  Applying it to either the health change or the object line seems to produce the same result as not using it.

[Slasher]

I use PPCollision Module for doing collisions.

Anyhow, example (I believe this is correct):

Code: AGS

if (cEgo.IsCollidingWithObject (object[0]) == 1 && Game.DoOnceOnly("Object"))
{
health-=10;
HealthBar.Width=health;
object[0].Visible=false;
}

Amend to suit.

[elegantmechanic]

That's still causing the same outcome: the object disappears but the health doesn't change.

EDIT: Ah, yes it seems to sort of be working but the health modifier doesn't seem to be changing the health bar length enough.  I'll see if I can figure that out, thanks for your help!

[elegantmechanic]

Just to wrap this up: I have found that the problem was the health bar itself; for some reason the image for a button with a width of 100 needs to be 200 pixels wide.  So the first 100 points removed were not visible on the bar because the image was only 100 wide and changed only when health fell below 50.

I don't know why the bar image has to be 200 wide but now that I've made it that wide, everything else is working as it should, even without Game.DoOnceOnly.

Sorry for the confusion, and thanks again for the help.

[Slasher]

As a matter of interest, did set 'clip' the health bar to true in game_start in the Global, so the width of bar alters to show Health score?

Example:
Bhealth.ClipImage =true;

The length of the health bar should be in relation to the 'health' points.

[Khris]

slasher, what does Game.DoOnceOnly have to do with the problem or the solution...?
And without clipping being set to true, the image would never be clipped at all, no matter how wide the button is, but elegantmechanic already told you that the image is clipped at some point, so obviously, clipping is true.
Also, the very first property of a button is ClipImage, so there's no need to set it in script unless it's supposed to change mid-game.
If you don't understand the problem, don't throw out random guesses at the solution.

elegantmechanic:
AGS used to use lowres coordinates internally for 640 or 800 games, but this shouldn't be the case any longer. I opened my 800 test game and assigned an image with a width of 200 pixels to a new button. Both the button and the image appear 200 pixels wide in-game, which is also the width of the button as shown in the GUI editor.
This is how it should be, and if your game uses lowres GUI coordinates, something's up.
Are you using an old game template? Did you convert your game from lowres to highres?
Afaik, if you convert a GUI to highres, the pictures are scaled up; try recreating the GUI from scratch.

[elegantmechanic]

Yes, it is from an updated "old" template but the gui was made from scratch in the latest version of AGS.  I suppose the thing to do, then, is to make a new blank template game and copy all the scripts etc. over to solve the problem.

UPDATE: I did exactly that, recreated the game by copy-pasting the scripts to a new blank game. This highlighted a bunch of obsolete code that needed to be replaced which I eventually did and now all is working as it should have done.  I didn't realise that updating an old template to a newer version of AGS could cause so much trouble and will be more careful in future. Thanks for pointing me in the right direction, Khris.

[Khris]

Glad you got it to work correctly.
Unfortunately, updating older scripts is a nightmare for the most part, yeah. So much has changed, even after the big code transition from 2.6 to 2.7.

If you look at the Backwards compatibility section of the General settings, it should be 5 times true, then two falses. Your game probably had a few compatibility switches enabled and most likely it would have been enough to change them, then alter the game accordingly.
But doing what you did is of course much cleaner and was probably a much better idea in the long run.