Perfecting `bh_player_healthcross_inset.res`

[PeanutKarver]

This is a continuation of the discussion from #520 which is related to #519

Currently, bh_player_healthcross_inset.res has an issue where status effects don't align properly with the health cross.

(Bullet Resistance Should Be Above Health Cross)

This issue was caused by changing the position of PlayerStatusHealthImage through the added pin_to_sibling element. In general, changing the position or the wide value of PlayerStatusHealthImage affects the position of bh_PlayerStatusPin, which was something I wasn't aware of beforehand. The pin_to_sibling element was added in an attempt to keep the health cross elements aligned together on every resolution.

The easiest solutions would be to use the edit outlined in #514/#519 or moving bh_PlayerStatusPin. I'm somewhat against the second option because the main intention that caused this issue was to keep the edits between the health cross elements and not the pin.

However, in trying to find another solution that will keep the health cross elements aligned together on every resolution, I did some of my own testing regarding the use of rs and p as part of the solution.

TL;DR: I couldn't find a solution, but I at least had interesting finds.

To preface, PlayerStatusHealthImageBG and PlayerStatusHealthBonusImage are perfect together on every resolution as long as they have the exact same position and size. Also, despite PlayerStatusHealthImage affecting bh_PlayerStatusPin, using rs and p to change the position/size of PlayerStatusHealthImage works fine because the pin realigns itself as rs and p start to match their standard positioning/sizing counterparts.

To try to find the best solution for the health cross, I first tried finding all the rs and p values that could be future candidates for use. I also found o which can be used as long as o is used for one sizing value (wide/tall) while p, or a normal number, is used for the other. It seems like o cannot be paired with another o for sizing, but I didn't test it enough to be certain. I also found the values while PlayerStatusHealthImage and PlayerStatusHealthImageBG had proporionaltoparent set to 1 added to them. It should be noted that adding proportionaltoparent ties the accuracy of the values to the HudPlayerHealth element, and that proportionaltoparent will henceforth be denoted as ptp. Here are all the values I found under a 1600x900 resolution:

Found Value Results

Note: `o` is the same with or without `ptp` | PlayerStatusHealthImage |||||| |--------|--------|--------|--------|--------|--------| | xpos | 95 | rs12.705 | (ptp)rs2.59 | | ypos | 46 | rs7.27 | (ptp)rs1.742 | | wide | 60 | p0.07 | o1.02 | (ptp)p0.24 | (ptp)o1.02 | | tall | 60 | p0.125 | o1.02 | (ptp)p0.4 | (ptp)o1.02 | | PlayerStatusHealthImageBG/BonusImage |||||| |--------|--------|--------|--------|--------|--------| | xpos | 93 | rs11.888 | (ptp)rs2.45 | | ypos | 44 | rs6.817 | (ptp)rs1.66 | | wide | 64 | p0.075 | o1 | (ptp)p0.257 | (ptp)o1 | | tall | 64 | p0.134 | o1 | (ptp)p0.43 | (ptp)o1 |

Afterwards, I tested and ranked different combinations of these values to see which looked the best on a 1366x768 resolution. All of these ranking have PlayerStatusHealthImage and PlayerStatusHealthImageBG use the different types of values in the same places:

Combination Rankings

| Key | = | |--------|--------| | Standard Positioning (just number) | n | | rs Positioning | rs | | p Sizing | p | | o Sizing | o | | While element has `proportionaltoparent` | (ptp) | | Ranking | xpos | ypos | wide | tall | Notes | |--------|--------|--------|--------|--------|--------| | 1 | Current | Current | Current | Current | This denotes the current sizing/positioning | | 2 | n | n | p | p || | 3 | n | n | p | o || | 4 | n | n | n | n || | 5 | n | n | (ptp)p | (ptp)p | Positioning also has `ptp` but is unaffected by it | | 6 | n | n | (ptp)o | (ptp)p || | 7 | n | n | (ptp)p | (ptp)o || | 8 | (ptp)rs | (ptp)rs | (ptp)p | (ptp)p || | 9 | (ptp)rs | (ptp)rs | n | n | Sizing also has `ptp` but is unaffected by it. Identical to above. | | 10 | n | n | o | p || | 11 | n | n | o | n | Identical to above | | 12 | (ptp)rs | (ptp)rs | (ptp)p | (ptp)o || | 13 | (ptp)rs | (ptp)rs | n | (ptp)o | Identical to above | | 14 | n | n | n | (ptp)o || | 15 | n | n | n | o | Identical to above | | 16 | n | n | (ptp)o | n || | 17 | (ptp)rs | (ptp)rs | (ptp)o | (ptp)p | Everything under looks really bad | | 18 | (ptp)rs | (ptp)rs | (ptp)o | (ptp)n || | 19 | rs | rs | p | p || | 20 | rs | rs | n | n || | 21 | rs | rs | p | o || | 22 | rs | rs | n | o || | 23 | rs | rs | o | p || | 24 | rs | rs | o | n | Identical to above | Bonus: I noticed the combinations ranked highest after the first one were always slightly offset horizontally, so I decided to try combinations based off this, where `PlayerStatusHealthImage` and `PlayerStatusHealthImageBG` were different: | PlayerStatusHealthImage | xpos | ypos | wide | tall | PlayerStatusHealthImageBG | xpos | ypos | wide | tall | Notes | |--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------| || n | n | (ptp)p | (ptp)p || n | n | p | p | It was ok but not any better | || (ptp)rs | n | (ptp)p | (ptp)p || n | n | p | p | Exactly like above | || n | n | p | p || n | n | (ptp)p | (ptp)p | `PlayerStatusHealthImageBG` `tall` becomes slightly bigger and lower | || n | n | p | p || (ptp)rs | n | (ptp)p | (ptp)p | Not good | || n | n | p | p || rs | n | p | p | Very bad | || rs | n | p | p || n | n | p | p | Very bad | I also tried other variations with wide using `o` and normal values. I don't want to document all the permutations, so I'll state here that none of them produced anything perfect.

I went ahead and tested the best custom result ( n n p p ) against the other resolutions, and it turns out it doesn't really work on any of them. Not only that, but the 16:10 and 4:3 aspect ratios have issues where the health cross starts to misalign with the value, and the p sizing causes the health cross to compress horizontally. This is fixed by using o for wide (using o for tall causes the cross to shrink proportionately), but even then it's worse than using standard sizing. It seems like using rs and p/o values won't be an easy solution.

Something to note, I found out on a whim that starting up the game while PlayerStatusHealthImage or PlayerStatusHealthImageBG is using ptp p sizing causes the elements to display with an unintended size. This is fixed by hud_reloadscheme.

I've looked into xhud for ideas, and there were two things that stood out. One, it used the value rs1-195 to define some xpos. Its use of rs paired with something other than a positive or negative value is something I've never seen before. Two, there are multiple overrides.res files made for HUD elements to work in different resolutions. This solution probably can't be lifted for this one issue.