[SOLVED]How do I do this right? (health mechanics w/HUD)

Hey guys!

Not so long I was asking here mostly the 50% of this.

Actually, in my game, I solved the health damage recived already; but never find a way to to show it on the HUD. Basicly I have this 100px width bar, that I need to represent the player's health, which starts at 100, and then increases to 200 HP, by an upgrading mechanic.

On start it looks like:

And when the player gets hitted:

Now, since the last topic, I kind of get that the best way to discuss this things is with a capx. So, I tried to emulate the problem here: Capx

But here I realize, that I didn't understand well the whole thing, and I'm repeting this, since I really want to learn º^º. As you'll see, when the player gets hitted, the health does not respond. Of course, this make the capx unable to show the health bar width on action, but I'm pretty sure it will fail, since it's the exact same thing that I had on my game :1

I know there are some RPG's health bars mechanism that are similar to this thing, but I found myself troubling with the variables that have influence on the whole thing (platting, hull, shield). But, if I missed some useful topic, please link me there (:

Thanks for reading~

PS: Oh! and please excuse my english.

You are calling on collision twice for no reason so the second isn't running if you move you actions from the second call to the first on collision event call it should work as you want. (I tested and each time the plane was hit the health bar went down)

[attachment=0:24gwc1s1][/attachment:24gwc1s1]

Side note:: This is just my personal opinion but the 'on start of layout' should be the first event on the eventsheet.

Thank PhoenixNightly !

I didn't knew that we couldn't have the on collision trigger repeated, I'm going to start keeping an eye on that. I changed the same way you (updated the capx link too) show it and it started to half-work. But before starting going that far away, do you know if it's ok to apply the on collision trigger, on a different event sheet? Because, I believe I've done it before in the past, and if I'm not wrong it worked; but I may had some errors that I can attribute to that. Oõ

Moving on. I don't know if you played with the hull value while running the thing, the health bar goes crazy. Do you have any idea to keep its width on 100px ? I've tried changing the formula again but ... :1

Again, thanks you ~

[quote:3mvr49t6]But before starting going that far away, do you know if it's ok to apply the on collision trigger, on a different event sheet? Because, I believe I've done it before in the past, and if I'm not wrong it worked; but I may had some errors that I can attribute to that.

In theory there is nothing wrong with having several of them.

So whether it causes bugs is hard to say, depends on the code and the problem

[quote:3mvr49t6]Moving on. I don't know if you played with the hull value while running the thing, the health bar goes crazy. Do you have any idea to keep its width on 100px ?

You have to divide Health_bar.width with the max health to get 1% of the total and then multiply that with the current health.

So:

Health_bar.width / Max_health * Current_health = health_bar.width in %

100 / 200 * 200 = 100 px width (Full health)

100 / 200 * 100 = 50 px width (Half health)

100 / 200 * 50 = 25 px width (Quarter health)

nimos100

Since he called it one time the second time would not run being that the bullet was destroyed in the first event called the second call with not trigger cause the bullet was destroyed so the collision does not exist. Hence the reason I said there shouldn't be a reason to make the same call twice. 1 thing you can change one thing to make a bug. Besides it would be inefficient to keep making the same collision calls/checks on the same thing using unnecessary process usage. A bad habit that shouldn't be started or encouraged. If you called it once then that one time should do everything that needs to be done.

Frame Matt

I will look at it again. It was more of a drive by look. The reason the second time didn't trigger was cause the bullet was destroyed in the first trigger call so that would make the second trigger called false. But it doesn't make logical sense to not do everything in that one call. As your game gets bigger you have chances of using more processing because you are calling the same events 4-5 times which is unnecessary. If there are certain thing you want done at certain times of the trigger event then that is when you should be making sub-events of that one trigger. Besides if you have the same event call here and there when you are trying to debug it would take more work cause you would have to sit there and find ever same trigger event call that you made instead of having it all sub-evented under that one call.

I think this should work... well it appears to work for me

[attachment=0:3twz8fou][/attachment:3twz8fou]

Thanks you guys; nimos100 , PhoenixNightly . I just got internet acces after complainning to my ISP :1, sorry for the delayed reply.

Oh I see, it's a very tricky thing to keep the eye on. I actually believed that the whole event sheet would be read by the bullets; but, if I got right what you're saying, if you indicate to destroy it before reaching the full length and the instance, actually gets destroyed, it would just ignore the rest. So... if it wasn't destroyed, it would read another on collision trigger, right? Oo

As for the health bar, both ways of doing it worked. But nimos100 formula, when hull's value got changed, made the bar's width jump back and forth between 100 px and some crazy value, as on the pictures I first posted. PhonexNightly formula worked great with the hull's changing value.

Again, thanks you so much guys (:

Well I saw that the first trigger event destroyed the bullet so when it ran the test again it would be false cause the bullet was destroyed in the first call. Trigger events run when theyactually happen that is why it doesn't matter where in the code they are when a trigger event runs unlike the standard events that run as in the order they are placed to run in that tick. So you have chances of the second time possible trigger 50/50 which would give you unexpected results.

Whoa, that was very clear. I didn't knew it. I'm going to start keeping an eye on those.

Thanks you a lot, PhoenixNightly . (: !