Current HP/SP Values Do Not Synchronize to Changes to Max HP/SP

[HoloGnome]

On the Main tab in the SFRPG character sheet, when a user changes the Max HP/SP values at the lower left of the sheet, the corresponding Current HP/SP should update automatically to match. And, failing that, as a workaround, giving the character an overnight rest should synchronize the Current values to the Max values.

In the first case above, the Current values do not automatically update on changes to the Max values.
In the second case above, an overnight rest only syncs Current SP to Max SP and does not sync Current HP to Max HP.

[deer_buster]

Why would an overnight rest give you max HP...that's not a function in the game...indeed, the most you gain from an overnight rest is your 1 hp/level unless you do 24 hours of bed rest to recover 2 hp/level. There's always magical and technological healing to assist.

[HoloGnome]

Yes - you are correct...and the same is true in Pathfinder, but that's not what I was trying to report. Sorry I wasn't more clear. And, I wasn't thinking when I wrote the part about fully syncing on overnight rest.

There is a bug in the HP/SP setting logic where Current doesn't sync to Max. I was just using overnight rest as a quick way to try to sync up the sheet and wasn't seeing any changes.

Users want/need to edit their character sheets and the Current fields should either be unlocked or should ideally adjust themselves when users make changes.

When changing the Max HP value, the following rules should apply:
1. On Max change, if Wounds are 0, then set Current to Max. (assume the user is editing their sheet)
2. On Max change, if Wounds are X, then set Current to Max-X.
3. If Max-X is negative, set Current to 0 and Wounds to Max.

When changing the MAX SP value, similar rules should apply with the respective Current/Fatigue fields:
1. On Max change, if Fatigue is 0, then set Current to Max. (assume the user is editing their sheet)
2. On Max change, if Fatigue is X, then set Current to Max-X.
3. If Max-X is negative, set Current to 0 and Fatigue to Max.

I checked basic HP/level recovery on overnight rest, and that seems to be OK now. I thought there was an issue in my previous test...but I guess I was mistaken. Don't know.

Finally, the work-around to the above HP/SP Max change case is that if you subsequently set Wounds or Fatigue to Max and then clear them, the Current value will be correct. But, when a user is editing, it makes sense that updates to Current values should just quickly key off of the Max values. Given the Starfinder system, there is clear value in auto-calculating the Current value. The piece that is missing is correcting for changes to Max.

Hopefully, the above makes things more clear. I can certainly use the workaround, but it would be nice if there were a small amount of extra logic to do the right thing on Max changes. It would be very helpful and make the HP/SP implementation very solid.

[deer_buster]

Simplest way to currently do what you are wanting without making a change that could potentially break the ruleset code...is what you already stated...

Set your Max HP to X, set your wounds to some value other than what it is currently, then back to what it was...so if you had 0 Wounds, set it to 5, then set it back to 0...done.
Same with your Max SP but use Fatigue instead of Wounds...

[HoloGnome]

Yep. That is the workaround I posted above. But, otherwise, the change I suggest is extremely simple and should not break the ruleset.

Maybe something like this:


[read in signed maxHP, wounds values and collect newMaxHP and/or wounds on user change]

newMaxHP = math.abs(newMaxHP); -- certify user HP entry as positive number
wounds = math.abs(wounds); -- certify user Wounds entry as positive number
if (maxHP ~= newMaxHP) then -- did the user change maxHP?
if (wounds == 0) then -- is there a value set in wounds?
currentHP = maxHP; -- if not, sync currentHP and we're done
elseif ((currentHP = (newMaxHP - wounds)) < 0) -- wounds is non-zero - is recalculated currentHP negative?
currentHP = 0; -- if so, clip at 0
wounds = newMaxHP; -- set out-of-bounds wounds to new maxHP
end
end -- the user didn't change the HP value, OK to write out certified wounds value

[write out newMaxHP, currentHP and wounds]

-- same logic for SP and fatigue.

In the majority of cases, users will be editing their sheets and the wounds and fatigue values will be 0, so direct sync of max/current values is the optimal choice.

[Samarex]

Yep. That is the workaround I posted above. But, otherwise, the change I suggest is extremely simple and should not break the ruleset.

Maybe something like this:


[read in signed maxHP, wounds values and collect newMaxHP and/or wounds on user change]

newMaxHP = math.abs(newMaxHP); -- certify user HP entry as positive number
wounds = math.abs(wounds); -- certify user Wounds entry as positive number
if (maxHP ~= newMaxHP) then -- did the user change maxHP?
if (wounds == 0) then -- is there a value set in wounds?
currentHP = maxHP; -- if not, sync currentHP and we're done
elseif ((currentHP = (newMaxHP - wounds)) < 0) -- wounds is non-zero - is recalculated currentHP negative?
currentHP = 0; -- if so, clip at 0
wounds = newMaxHP; -- set out-of-bounds wounds to new maxHP
end
end -- the user didn't change the HP value, OK to write out certified wounds value

[write out newMaxHP, currentHP and wounds]

-- same logic for SP and fatigue.

In the majority of cases, users will be editing their sheets and the wounds and fatigue values will be 0, so direct sync of max/current values is the optimal choice.

Current is not editable as it is a calulation of Max HP - Wounds, if we unlock Current and players start changing this value we will get a effect I call Chrismas tree effect the code gose crazy between Character sheet and CT, this happened early in the SFRPG development.
Why would players need to change current value. I can look to see if change in Max HP is triggering a update, but current will not be unlocked.

[HoloGnome]

I understand, but I don't think players need the restriction and hand-holding. However, if it's a big issue, then put a lock icon in the upper-left corner of the bottom panel of the main tab (default to locked) so that users can unlock all the fields for editing and character-building. But, failing that, please synchronize based on changes to MaxHP and MaxSP, for example, as in above code.

Also, MaxRP has the same problem and is not correctly recalculating based on changes to ability stats. I just applied a personal upgrade to bump the primary stat by +2 and the RP never changed. MaxRP should not be locked.

[msbranin]

Resolve points are calculated correctly just not updated. After you modify ability points, do a Long rest and the resolve points will display correctly. It is not idea but every situation I have had including adding an ability upgrade as you just did, resolve and max resolve was corrected with a Long rest.

EDITED because its a long rest that resets and syncs then. Not a short.

[deer_buster]

It's a fine line between just giving the players a blank character sheet, expecting them to add/calculate everything and giving them some automation to allow them to just drop some data and expect that it is correct. As the "bugs" mentioned in several of your other posts would indicate, the automation that you "expect" isn't there.

This is still a fairly new ruleset in FG, and has had 2 different "owners" working on it. I've added my development help when I can but it can take a lot of time to "correct" things that previous developers have done that make things a lot harder to work properly, or extend functionality of existing systems.

Add that to the fact that the ruleset "owner" is the one that also has to create the content for the additional rulebooks (Alien Archive 3 and COM being the most recent) and there are (sometimes not insignificant) ruleset changes that must be made to accommodate those books (and the unrealistic expectations of some of the community that as soon as Paizo releases a book that it should be in FG) and you can begin to understand why it can take so long to get things going as smoothly as it does for rulesets like 5e.

[HoloGnome]

Sure - I understand that people are busy. I am just putting stuff out there so that you can capture all the feedback, since there is no public-facing bug database (a long-standing issue).

That being said, as above, I have provided a basic code snippet to try to help resolve the (simple) Current HP/SP issue and there's no reason for RP Max to be locked, although I didn't try a long rest as a workaround.

I think the best solution may be to simply provide a lock or magnifying glass UI element. For users who want to edit, they can unlock. Otherwise, they can live with the automation. Personally, I prefer the ability to directly edit when building characters, where there isn't really any editing of Max values after handing the sheet off to a GM for a game.

It's important that things like MaxSP work in real time with manual editing, because if the player has an in-game CON change, they may need to edit the Max value.

[Samarex]

Sure - I understand that people are busy. I am just putting stuff out there so that you can capture all the feedback, since there is no public-facing bug database (a long-standing issue).

That being said, as above, I have provided a basic code snippet to try to help resolve the (simple) Current HP/SP issue and there's no reason for RP Max to be locked, although I didn't try a long rest as a workaround.

I think the best solution may be to simply provide a lock or magnifying glass UI element. For users who want to edit, they can unlock. Otherwise, they can live with the automation. Personally, I prefer the ability to directly edit when building characters, where there isn't really any editing of Max values after handing the sheet off to a GM for a game.

It's important that things like MaxSP work in real time with manual editing, because if the player has an in-game CON change, they may need to edit the Max value.

HPMax/SPMax was not triggering a update, That has been fixed so when you change the Max, Current will update.

RP Max is a Calculated field which is why its locked, it would do no good to unlock it as if it was manually changed the next full rest would re-calulate it and your change would be gone.
RP Mod was not triggering the update. [Fixed] It will now update MaxRP when the value is changed.

Next is not New it already works.
MaxSP with CON Change, There is no need for them to have to change the MaxSP when they take CON damage. If you apply damage to the Dmg field in CON, every 2 point of Dmg will automatically adjust the MaxSP.

[HoloGnome]

>HPMax/SPMax was not triggering a update, That has been fixed so when you change the Max, Current will update.
Great!

>RPMax

It should probably update on stat change when change dstat = primary stat. Will that work now?

>MaxSP

If a player gets a CON boost (not damage), I guess you could use negative damage to mod the MaxSP. A little unintuitive, but it works. Ah, never mind, the Bonus field will boost the MaxSP. Good!

Thanks for looking into these issues.

I saw that garbled effect text again, but did not find the reproducible case yet. However, it's still there. I'll post when I figure it out.