Author Topic: Detecting when player is damaged/health increases  (Read 2501 times)

But you can read what I type.
Why on earth are you so hostile. It was an exclamation in order to iterate on the suggestion he was making, an important one. Can you stop derailing the thread now, please.

edit:
but seriously, I'm not as annoyed as I might sound, (communicating through text, hooray: add one word of profanity to make an honest question sound furious) I just get a bit peeved with this sort of thing
Why are you derailing this thread with something so irrelevant though.

Why on earth are you so hostile. It was an exclamation in order to iterate on the suggestion he was making, an important one. Can you stop derailing the thread now, please.
but seriously, I'm not as annoyed as I might sound, (communicating through text, hooray: add one word of profanity to make an honest question sound furious) I just get a bit peeved with this sort of thing

So, yeah, you'll have to parent setDamageLevel if anything you use uses that (and maybe this old "medipack" (not the TF2 medipack, clearly) is the only thing that uses that, so maybe it won't be applicable) as well as addHealth in order to pick up on when players' health is increased

but Dannu this was kind of already figured out, you can't derail a train that's already in the station


so irrelevant

I also need to get the value of the damage/health increased.
The medipack ... uses setDamageLevel ... so onDamage wouldn't pick that up.
medipacks have been using addhealth

it's very relevant

If you have something that uses setDamageLevel, you need to parent it to figure out when damage level is set lower so that you can indicate becoming healthier has happened. Whether setDamageLevel exists is actually kind of important for the purposes of this thread. Getting annoyed that someone suggests I'm making it up isn't the same as intentionally trying to send the subject somewhere else. From my perspective, this thread was right on target until Kyuande assumed I didn't know how to read code.
« Last Edit: November 19, 2015, 09:44:24 AM by Teneksi »

Parenting a default function is a terrible idea. I remember when I released my custom health mod that uses getHealth and getMaxHealth, which is better than detecting datablock health, but it returns datablock health if they don't have custom health on that player. Mind as well use that support file and rewrite every mod that uses datablock health and damage level.

Parenting a default function is a terrible idea.
only if you don't know what you're doing

better than making, for example, a mod that requires other mods to be rewritten to make it work properly

Setdamagelevel is just.. a terrible way to package.

Setdamagelevel is just.. a terrible way to package.
a terrible way to package? ... do you mean a terrible way to increase health? I can agree with that, it's kind of the reverse of what you'd expect to do.

How is this harsh? And he explained what you said, he's just trying to explain how you should package stuff. Not everyone knows how to script stuff properly because they are learning.

Uh.. medipacks have been using addhealth not setdamagelevel

It does find the health by getdamagelevel, though
And guess what addhealth calls? setdamagelevel.

Parenting a default function is a terrible idea.
And when was this ever a thing?
The entire purpose of packaging/parenting is to avoid breaking default functions. Many, many mods package default functions, including engine functions.

Many, many mods package default functions, including engine functions.

How do you plan to do that? When looking up called functions, engine functions are prioritized over anything defined in TorqueScript.

How do you plan to do that? When looking up called functions, engine functions are prioritized over anything defined in TorqueScript.
Just the number of the ones exposed to TS anyways.

And guess what addhealth calls? setdamagelevel.
And when was this ever a thing?
The entire purpose of packaging/parenting is to avoid breaking default functions. Many, many mods package default functions, including engine functions.
1. Duh
2. It's always been a thing as long as it's a torquescript function (meaning it's public from the c++ source), unless badspot decides to make them private such as GameConnection::setBLID and lots more.
3. This is a default function you don't want to package.

And guess what addhealth calls? setdamagelevel.

Oh.

Would that mean that, if one parented setDamageLevel in one function, and addHealth in another, the functions parenting them would both be called if addHealth is used?

3. This is a default function you don't want to package.
Why?

Oh.

Would that mean that, if one parented setDamageLevel in one function, and addHealth in another, the functions parenting them would both be called if addHealth is used?
If anything is modifying a player's health, it's using setDamageLevel.

If anything is modifying a player's health, it's using setDamageLevel.
If you tried to setDamageLevel to a negative number, would it effectively be extra health, or can it only go down to 0?

If you tried to setDamageLevel to a negative number, would it effectively be extra health, or can it only go down to 0?
Pretty sure it only goes down to 0.

Pretty sure it only goes down to 0.
Yep

If you set the number higher than the datablock's max damage, your player will glitch out.