RHS Feedback - USAF
View Issue Details
0006785USAFGeneralpublic2022-12-10 19:242022-12-13 08:31
NickSeafort 
reyhard 
noneminoralways
closedno change required 
 
 
No
Stable
2.10
No
RHSUSAF
0006785: AH-6M MELB variants have mis-cased duplicate config class
This was discovered while tracing down a bug report with a third-party servicing UI, and represents a simple typo in the config that appears to have generated down-stream consequences. The fix should be to capitalise three letters.

Impacted file:
======
\\rhsusf_c_melb\rhsusf\addons\rhsusf_c_melb\config.cpp

Impacted classes:
======
RHS_MELB_AH6M_L
RHS_MELB_AH6M_M
RHS_MELB_AH6M_H

Issue:
======
Within the class definitions for the above-listed variant classes, there is a mis-cased inheritance line for each:
` class components: Components `

This means the master RHS_MELB_AH6M class is fine, but each of the child classes have both "components" and "Components".

This appears within the built-in config viewer as two copies of "components", and expanding either class expands both visually. See attached picture for example.
No tags attached.
png RHS MELB Bug Report.png (317,756) 2022-12-10 19:24
https://feedback.rhsmods.org/file_download.php?file_id=2409&type=bug
Issue History
2022-12-10 19:24NickSeafortNew Issue
2022-12-10 19:24NickSeafortFile Added: RHS MELB Bug Report.png
2022-12-12 08:39reyhardNote Added: 0012275
2022-12-12 08:39reyhardAssigned To => reyhard
2022-12-12 08:39reyhardStatusnew => feedback
2022-12-12 09:58NickSeafortNote Added: 0012276
2022-12-12 09:58NickSeafortStatusfeedback => new
2022-12-13 08:31reyhardStatusnew => closed
2022-12-13 08:31reyhardResolutionopen => no change required

Notes
(0012275)
reyhard   
2022-12-12 08:39   
It doesn't cause any issue as far as I know since this is just bug of in game config viewer which is doing strict string comparison - for game itself, it doesn't matter. What kind of issue are you trying to solve?
(0012276)
NickSeafort   
2022-12-12 09:58   
Thanks for the swift pickup! Checked further this morning, and it appears that the issue is only occurring on the H & M variants during testing - it appears that a bit of logic around sanitising the pylon inputs in order to try and determine which vehicle occupant owns each pylon's turret. So while the casing is indeed an irregularity, it seems to be unrelated to the originally reported issue I was tracking down and I halted prematurely when I saw something that looked wonky!

As an aside, that vanilla functionality gap gave me so many headaches when I had to implement the above-mentioned workaround to determine (or guess) current pylon owners within the servicing GUI. If getPylonLoadout existed, it'd avoid such a faff around this stuff :/