Script: print amount of damage dealt?

[TimeOfDeath]

Do you guys know how I can print a message in the top right corner of the screen that shows how much damage I caused to a monster? So like, I shoot a cyberdemon once with a bfg, and I want to show how much health he lost. I know how to print messages, but I'm not sure how to base the message off of a monster's health.

[FLYBAT]

Maybe it's better to make the damage numbers fly to the ceiling from the attacked monster's head (like in Torchlight)?

[TimeOfDeath]

Well that's even more too complicated for me to do (I'm a script newbie), but it sounds nice.

[Blue Shadow]

All I can do is direct you to [wiki=hudmessageonactor]this[/wiki] ACS function.

[Matt]

Would anyone know how to get that number though? At least without having to constantly track the actor's health as of the immediately preceding tic?

[Gez]

The way I'd do it would be this:

1. Add a user_prevhealth variable.
2. In spawn state, init user_prevhealth to health, using [wiki]A_SetUserVar[/wiki]
3. In pain state, compare health to user_prevhealth and print that with [wiki]A_LogInt[/wiki], then set user_prevhealth to health.

Advantage: DECORATE only.
Drawback: doesn't work when monsters aren't pained by the hit, potentially generates multiple logs from shotgun blasts.

[Enjay]

doesn't work when monsters aren't pained by the hit

Possible solution: Make pain chance 255. Alter the pain state to have no obvious effect (ie immediately return to the see state after activating the checks) but also have a jump in there so that the monster will still sometimes jump to a more normal pain state with roughly the same frequency as its original pain chance would cause.

[FDARI]

Still guaranteed to interrupt whatever was going on (such as an attack). I, not being afraid of adding some acs libraries to my project, would probably opt for the constant tracking of health. (Script would execute every tick, and perhaps many instances would be running, but they would perform very few instructions. I think it should be fine for most normal cases.)

The script needs to end if the activator has ceased to exist.

It doesn't mess with pain, so even if it requires acs, I prefer it.

It has issues too, though:
It could be possible to start multiple instances of the script. (Use an idle-state to avoid reexecuting spawn-state, and let the first state under the spawn-label contain A_JumpIf(true, "idle") in case you get back there anyway.)
It could be possible to start 0 instances of the script. (If something disruptive happens inbetween spawn and the first active tick for the new actor.)

---

- I have dynamic temporary tid systems that should be able to handle this
- They add complexity, but any function that can spawn an actor with a tid, will allow you to start an actor with a unique tid (dynamic), set it up with running scripts and everything, and assign its lasting tid (dynamic or predetermined).
- There is a shortage of tid-power in decorate spawning. Code has been submitted for a_spawnitemex, but as of now that's not an option.
- There are some functions that give you a handle on the spawned actor, but that's quite hacky (A_VileTarget). Probably as well to build an acs-based spawning system for that special needs. (Initial spawn function generates actor and returns its unique tid, letting you follow up with other calls if the 3 first parameters are not enough, as well as giving you a chance to store it in pointers.)

No existing feature goes as far as to let you track individual occurences of actual damage. (Health changes can vary in nature, and the ACS solution gets you an aggregate value, not individual occurences. If individual occurences are required, the pain-solution might be the most viable approach.)

[amv2k9]

doesn't work when monsters aren't pained by the hit

Possible solution: Make pain chance 255.

Doesn't 256, not 255, cause 100% chance of pain?

[VGA]

PainChance value
Probability of entering the pain state (256 = always, 0 = never). You can also specify PainChance per damage type. Sources of damage that have the FORCEPAIN flag ignore this property.
Default is 0.

http://zdoom.org/wiki/Actor_properties

[SFJake]

Heh, everybody knows that. But the discussion of 256 vs 255 has been seen before. The idea of "is 255 -actually- 100%" or not.

I've seen the proper answer with explanation before but I've frankly forgotten.

[Gez]

It depends on whether the operator used is < or <=.

The idea is that a random number generator will be used to generate a number between 0 and 255. The edge case is if 255 is generated.

If <= is used, then it's alright. 255<=255 is true.

But if < is used, then it'll fail in that one case. 255<255 is false. With 256, you should be safe in all cases, except if the comparison number is stored on a single byte, because is 1 00000000b is cropped to a 8-bit value, it turns into 00000000b, which is zero.