[Feature request] Add toggle to show stages when exceeding not reaching a certain point

[gsterling]

To be more clear: My system actually uses stages for health levels. Your module is wonderful in showing my players these.

The only problem I have is, if you have 50 MaxLP and your LP reach 40, it should still still display the state form 40-49. Currently the state is shown from 41-49.

Since a certain state means certain resctrictions (or even lack thereof) it would be nicer, to acurately display the players the state as they represent the targets actual and obvious wellbeing.

I have set up the following 7 stages (the names don't really matter):

Bewusstlos, Todgeweiht, Schwer verletzt, Verletzt, Angeschlagen, Unverletzt,

The last stage has an empty name because I need to have it display nothing on 50, but still display something else on 40-49.

Ideally the toggle would enable the following (assuming 5 = number of stati minus 2):

Status	Range
Bewusstlos	LP == 0
Todgeweiht	0 < LP < MaxLP/5*1
Schwer verletzt	MaxLP/5*1 <= LP < MaxLP/5*2
Verletzt	MaxLP/5*2 <= LP < MaxLP/5*3
Angeschlagen	MaxLP/5*3 <= LP < MaxLP/5*4
Unverletzt	MaxLP/5*4 <= LP < MaxLP/5*5
\<emtpy string>	LP == MaxLP

Or easier expressed as pseudo code:

states = [ "Bewusstlos", "Todgeweiht", "Schwer verletzt", "Verletzt", "Angeschlagen", "Unverletzt", "" ]

if LP == 0:
    currentState = states[0]
else:
    currentState = states[ roundDown( LP / MaxLP * ( length(states) -2 ) + 1 ]

Hope this makes sense.

[mclemente]

It makes sense, I quite enjoyed you've designed the algorithm already.

You just made me realize the change to the Best Stage Display setting (the addition of a third choice) hasn't solved the need for having the empty state for some people.

The issue

I've recently fixed a similar issue for the non-smooth gradient and I came to the conclusion the whole Stages logic is flawed since it is based on D&D 4e's Bloodied condition and that design clashes with every other system, like your case.

Another similar issue is when estimates have uneven ranges (e.g. [1-20, 21-80, 81-99, 100]), which requires users to repeat Stage names to get a similar effect.

The Fix

The quickest fix is to enable custom stage calculations, but then there's like 40 system-specific files that might need a pass to work as intended. Even though most should work just fine, it's still a lot of work and still might have its own issues.

I'm planning on changing the way estimates are made to solve all these issues once and for all, letting people set their own ranges in a more intuitive way and avoiding bad UX like the "leave a , after the last stage" trick. It still needs a lot of work, specially that I'm testing on V11 already and I'm running into issues from the Prototype (specifically the Array setting issue that will be fixed on the next update), but it should work on V10 seamlessly once it's done.

[gsterling]

Thanks, that looks really good.

Is there maybe a chance, that you also could make the number of stages dependend on something like an item? Some crearures are weak (only 3 stages) or even frail (only 1 stage), which is determined by a certain trait, which is added as an item to their sheet.

I'd imagine something like "if the token has an item of type TRAIT with the name WEAK use these stages instead".

So have the table in your image with another button which doesn't add another estimation, but another table with a way of configuring an extra condition.

You could even achieve the ability to make distinct stages for different kinds of tokens with this approach. So cargo, vehicles, animals, players, npcs, bosses could each have their specific sets.

[mclemente]

Does your system have Active Effects? That could be a way of doing it.

I guess I'd have to add more tables for actor types anyway. But allowing for custom tabs and letting users input their own JS logic might be a better solution, there's already something similar for a "create your own system" system. The only tricky thing would by making the extra condition user-friendly. I can think of adding a "name an item or effect to trigger this set" so it's easier than "learn JS just to use this module".

[mclemente]

Updates

It'll need some more tinkering later on, but it seems good for now.

Now I need to setup the logic and then change the system files to be as seamless as possible.

Custom Stages need a complete change too.

[gsterling]

Does your system have Active Effects?

It does not unfortunately.

Thank you for your work. I am really looking forward to it!

[mclemente]

Would you be willing to test it? It shouldn't harm your world, but I suggest you try it on a brand new world just to be sure.

Latest version: https://github.com/mclemente/healthEstimate/archive/bfd456e812f5f4df4830db5c6d889675aed9a796.zip

Currently, the Stages setting does nothing and will be removed later. Go into the Estimation Settings menu and change it as you like.

Here's some examples of how to set up like your request.

And here is a way to set the Weak/Frail table: token.actor.items.find((item) => item.name == "ITEM NAME HERE")

Also, what is the system you are playing? Is it DSA5? Last time I saw an issue from you it was related to that system.

[gsterling]

Would you be willing to test it? It shouldn't harm your world, but I suggest you try it on a brand new world just to be sure.

Will do!

Here's some examples of how to set up like your request.

Yes it works, but I wonder if it's obvious for new users to use 99 for the highest state. Maybe add a little checkbox below with "Hide estimate when at full health"? That would also help with the problem, that maybe a creature has >200 hp and it will only use the highest estimate when losing at least 3 health. (It's not really a game breaker, I just think it'd look neat :D)

This actually applies to all states. I had to change all % for it to work as I wanted. Meaning only changing the estimate below the threshold:

So another button could say "Only show estimates below the threshold" or something like that and have it in addition to the "Hide estimate when at full health" to not fuel the confusion. That would mean, that you'd have to make the exception, if one wanted to use it below thresholds, but still show when at full health, that it overwrites it for 100% specifically. A bit more complex logic, but better understandable for most I assume.

And here is a way to set the Weak/Frail table

This works really well! Awesome! I really like the complexity you can achieve with "raw" javascript. This is something even new users can easily understand with an example like the one you provided above (it actually helped me, since my javascript is so bad, I'd have had to google it :D).

Also, what is the system you are playing? Is it DSA5?

No, it's Splittermond which is exclusively in german.

Additionally, as far as I can tell, the "Ignore Color" isn't working right now for additional tables. Or does it something else?

All in all it works really well. Thank you for your work :)

[mclemente]

Yes it works, but I wonder if it's obvious for new users to use 99 for the highest state. Maybe add a little checkbox below with "Hide estimate when at full health"?

Agreed. That was my brain trying to avoid checkboxes unless completely necessary, to the point I overengineered around not having them. Your suggestion is a better UX.

That would also help with the problem, that maybe a creature has >200 hp and it will only use the highest estimate when losing at least 3 health. (It's not really a game breaker, I just think it'd look neat :D)

Now that you mention it, that's an issue with the way the logic is set and my testing being limited to 100/100 HP tokens.

199/200 = 0.995 x 100 = 99.5

The logic then looks for 99.5 >= 99 and it'll skip to the next stage because of that. I'll just set it to round the fraction to 2 decimals instead to solve this.

So another button could say "Only show estimates below the threshold" or something like that and have it in addition to the "Hide estimate when at full health" to not fuel the confusion. That would mean, that you'd have to make the exception, if one wanted to use it below thresholds, but still show when at full health, that it overwrites it for 100% specifically. A bit more complex logic, but better understandable for most I assume.

Agreed.

Additionally, as far as I can tell, the "Ignore Color" isn't working right now for additional tables. Or does it something else?

That was the latest thing I've added. Earlier it was labeled "Is Special" which was even worse.

It is meant for (mostly) single-line estimations whose label is meant to overwrite the current condition but shouldn't care about the color. So it uses the color scheme from the next valid estimation table. It avoids duplication of tables.

For example, when a token is under a certain condition, like Stunned, Staggered, etc, it'll show up that condition but use the color of the normal estimation.

Earlier I noticed I had to set those conditions to 100%, but then the estimation would always be green. I couldn't find a better way to make it simple, so that checkbox came in.

[mclemente]

After some testing, I have concluded it would be too complicated to add those checkboxes. Considering setting the estimations is pretty much a "one and done" deal, I'd rather be telling people to adjust their estimates like you did over complicating things.

[gsterling]

That's understandable and totally fine by me.

[mclemente]

I'm not sure if your module will update automatically (I don't recall when I changed the module.json's version), so if it doesn't update, reinstall it so you get the last changes I did.

That said, may I consider this issue solved?

[gsterling]

Yes, thank you very much. It works flawlessly.