-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change xml recording of hiring halls #6019
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #6019 +/- ##
=========================================
Coverage 10.33% 10.34%
- Complexity 6130 6135 +5
=========================================
Files 1039 1039
Lines 139399 139412 +13
Branches 20675 20677 +2
=========================================
+ Hits 14409 14420 +11
- Misses 123542 123549 +7
+ Partials 1448 1443 -5 ☔ View full report in Codecov by Sentry. |
Ok, I have now made the changes on the Java side. Hiring halls are now recorded at the planet level and general in system events rather than the base system (where the default to NONE). Everything is reading in and displaying as expected. This PR is ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels really weird doing a code review for the guy who literally wrote mhq. Couple of very minor points of feedback, otherwise this looks great.
The change I suggested regarding using valueOf
instead of a switch isn't vital, given how few cases there are in that enum, but I've found it saves a lot of time and headache when working with enums that have large definition counts.
I'm marking this as 'request changes' just because of the legal statement stuff. It's not me being petty, I just know how much work went into fixing the legal statements earlier in 2024 and I really don't want Tex (or anyone else) having to redo it all.
@@ -55967,6 +55971,10 @@ | |||
<date>3050-01-01</date> | |||
<population source="noncanon">2049886673</population> | |||
</event> | |||
<event> | |||
<date>3057-01-01</date> | |||
<hiringHall source="Mercenary FM revised">STANDARD</hiringHall> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that we're now tracking source, too. This is a good addition. Effectively resolved any future conversations about why x
was rated as y
@@ -0,0 +1,35 @@ | |||
/* | |||
* Copyright (c) 2019-2022 - The MegaMek Team. All Rights Reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this read 2025, or has this class just been copied from somewhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, copy pasta error. Fixed now.
GREAT; | ||
|
||
public static HiringHallLevel parseHiringHallLevel(String val) { | ||
return switch (val.toLowerCase()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we convert the string to all uppercase I believe we'll be able to use HiringHallLevel.valueOf(val)
inside a try-catch. We then we can add a logger message saying 'hey this failed to parse, using 'NONE' inside the catch that will return NONE. This will mean that in the event more enums are added (for whatever reason) we don't need to maintain this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent idea and it works perfectly. As I work on the bigger YAML conversion project, I should be able to use this approach to clean some other enum parse methods up that do this as well.
if (getPopulation(when) == null || getPopulation(when) == 0) { | ||
return HiringHallLevel.NONE; | ||
} | ||
for (Faction faction : getFactionSet(when)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we use getFactionSet()
is it possible for the method to return null
in the event that no faction is present (for example, empty systems / dead planets)? I'm not 100% if it can, or not, and if it does return null whether the loop will just fail gracefully.
This might not be a valid concern, so ignore this entire message if it isn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code starting on 748 is actually not new, but rather got ported over from PlanetarySystem
to Planet
so it hasn't been breaking anything yet. I am pretty sure that the factions
object is set to an empty set so can never be null.
import mekhq.adapter.PressureAdapter; | ||
import mekhq.adapter.SocioIndustrialDataAdapter; | ||
import mekhq.adapter.StringListAdapter; | ||
import mekhq.adapter.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GitHub won't let me leave this comment any higher. This might seem incredibly petty, but don't forget to update the license statements to 2025 whenever you edit a class. Tex put in a lot of effort to bring all our legal stuff up to date, so we're trying to be really vigilant to make sure that work doesn't have to be redone in 5 years.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through an updated copyrights on all of the touched files.
@@ -336,8 +336,7 @@ private JPanel getPlanetPanel(Planet planet) { | |||
gbcLabel.gridy = infoRow; | |||
panel.add(lblHiringHall, gbcLabel); | |||
JLabel textHiringHall = new JLabel(StringUtils.capitalize( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't believe I've gone this long without knowing this utility existed. This will make my life a lot easier!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for handling the copyrights :)
Hi @IllianiCBT. I think I addressed all your concerns. Let me know if it looks good now. |
Currently a WIP. When hiring halls were added, they were set up using an xml syntax that is not consistent with how we want xml to work for planetary systems. They were placed within the overall planetary system with this code:
All we really need to know is the value for the variable
staticHall
which is tracked in planetary systems and then overrides the dynamic determination of hiring halls. Since levels can change dynamically over time, as given by thestart
field above (and sometimes anend
field), this value should just be tracked in thesystem_events.xml
like so:This is consistent with how the XML has been set up to use. Furthermore, these events should be associate with specific planets not the planetary system at large. This PR will make those changes. The first commit changes the underlying XML files. I also have to make some changes on the Java side to read this in properly.