Temp Hit Point Question

[Nickademus]

Some sources of temporary hit point stack. Some don't. Some add to the total regardless of the other sources, up to a cap.

From what I see in FG, the temp hit point only applies a generic temp hp amount that doesn't stack and uses the highest value (current or new). A rolled/scaled amount can be capped, but it doesn't interact with the current temp hit point amount. There is no way to add temp hit points or cap the addition.

Is there more functionality that I'm not seeing? Is there a way to represent more of the situations that utilize temporary hit points in FG?

[Nylanfs]

? I was unaware that temp hitpoints stack.

[Moon Wizard]

The temporary hit points in FG use the largest value at time of application (existing vs applied). This is consistent with the temporary hit point rules in 3.5E and PFRPG.

If there is something that creates an exception to the standard temporary hit points rules, it will have to be adjusted manually.

Regards,
JPG

[Nickademus]

The temporary hit points in FG use the largest value at time of application (existing vs applied). This is consistent with the temporary hit point rules in 3.5E and PFRPG.

I am not seeing this in the rules for 3.5E or Pathfinder. It is a common belief, but what I see from the rules and FAQs are that same sources don't stack but different sources do. And sometimes same sources stack when explicitly stated. Emphasis below added by me.

Pathfinder

Temporary Hit Points: Do temporary hit point from the same source stack?
No. Generally, effects do not stack if they are from the same source (Core Rulebook page 208, Combining Magical Effects). Although temporary hit points are not a "bonus," the principle still applies.

This prevents a creature with energy drain (which grants the creature 5 temporary hit points when used) from draining an entire village of 100 people in order to gain 500 temporary hit points before the PCs arrive to fight it.

Temporary hit points from different sources (such as an aid spell, a use of energy drain, and a vampiric touch spell) still stack with each other.

Source: https://paizo.com/paizo/faq/v5748nruor1fm#v5748eaic9r43

A vampire can suck blood from a grappled opponent; if the vampire establishes or maintains a pin, it drains blood, dealing 1d4 points of Constitution damage. The vampire heals 5 hit points or gains 5 temporary hit points for 1 hour (up to a maximum number of temporary hit points equal to its full normal hit points) each round it drains blood.

Source: https://www.d20pfsrd.com/bestiary/mo...plates/vampire

D&D 3.* FAQ

Temporary hit points from two applications of the same effect don’t stack; instead, the highest number of temporary hit points applies in place of all others. Temporary hit points from different sources stack, but you must keep track of them separately.

Source: D&D FAQ Version 3.5, p 113

If FG doesn't operate this way due to a lack of design, I can accept that. What I was wondering was if there was a way I did not know of to implement it. Seems not.

[Moon Wizard]

Definitely not then, since the source of each temporary hit point boost would have to be tracked separately.

Perhaps it's a carry over from the way 4E temporary hit points worked, which is probably the source of the current behavior. I'd have to review 4E to be sure.

Seems like temp hp should always be additive only in 3.5E /PFRPG for best support. Agree?

Thanks,
JPG

[Nickademus]

Since I think the coding to make all the sources for temp hit points their own 'type' for stacking reasons (like AC bonuses) would be immense, I agree. Just make them additive and the players will have to know they can't cast the same spell multiple times. This would make it easier for GMs using some of the creatures that can continually gain temporary hit points.

[Mgrancey]

Even in 4e, there was only one way for Temp HP to stack (at least as of last time I dealt with it) and that was a particular Fighter Build, which specifically stated so. One would have to somehow mark the source of the temp HP to be able to stack it properly then, which honestly seems a bit of a waste. Maybe not as hard as it seems, but would probably require both spells, tags, and automation code to be changed.