Improvement: Moved Faction Standing Ultimatum Data into YAML Format #7302
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #7302 +/- ##
============================================
+ Coverage 12.68% 12.70% +0.01%
- Complexity 7572 7585 +13
============================================
Files 1171 1173 +2
Lines 149175 149225 +50
Branches 22890 22894 +4
============================================
+ Hits 18923 18959 +36
- Misses 128223 128242 +19
+ Partials 2029 2024 -5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| * @author Illiani | ||
| * @since 0.50.07 | ||
| */ | ||
| public Map<LocalDate, FactionStandingUltimatumData> getUltimatums() { |
There was a problem hiding this comment.
This will only support one ultimatum per given date; do you think we will ever want to have multiple events on the same date?
There was a problem hiding this comment.
Yeah, that occurred to me. I'm torn, because by using dates as keys we can very cheaply and reliably confirm whether an ultimatum is occurring in a given day for a given faction without using a loop.
If you don't mind taking a look at the ultimatum code in src/campaign/universe/faction standing I'd welcome your thoughts on alternative models.
The key thing is that I have a method that just checks whether an ultimatum is occurring before we call the class constructor. As that allows us to avoid passing in Campaign unnecessarily. It's all fully commented, so if you have the time to look I would appreciate your insight.
There was a problem hiding this comment.
I think I've got a workable solution.
|
So, I employed my brain noodles and managed to fathom a workable solution without too much labor. Previously, we structured the ultimatums library as I shifted the library to be structured as an embedded map: The main benefit here - and the big thing I wanted to avoid, resulting in the original implementation - is that this is accomplished without needing to use a loop: |
# Conflicts: # MekHQ/src/mekhq/campaign/Campaign.java
This was based on a suggestion from @Sleet01 requesting that we move the ultimatum data from hardcoded values and into the data folder.