Convert planetary system data to yaml + general planetary system overhaul

[AaronGullickson]

The primary goal of this PR is to convert the current xml encoding of planetary systems into a yaml format that is read in through Jackson. In the process of doing so, this PR cleans up a lot of the planetary system code, organizes the data in an easier fashion for editing, and adds a few new features. In addition to changing the overall format from xlm to yaml, the PR also changes the file structure so that each planetary system's data is held in a separate file within data/universe/planetary_systems in two separate subfolders labeled canon_systems and connector_systems (the latter being used for fake systems, we use to connect far-flung periphery locations and the Clan Homeworlds). Thus, the large number of files being touched here is very misleading, about the scale of the actual changes (which are still substantial).

Rationale

The rationale for changing to yaml is twofold. First, when it is necessary to edit planetary system data by hand the current set up is unwieldy. Base planet data is in a single systems.xml file and planetary events like population, faction change, and SICS code are in a separate system_events.xml. Finding the correct planet is thus a chore and these files are huge making it difficult to edit, especially for less technically inclined volunteers. In fact, you can't even edit the files in Intellij because they are too big. The new set up puts all the data for a single planetary system in separate files in a format that is easier to read and more intuitive for most people.

However, our ultimate goal is to avoid as much hand editing as possible. In that sense, this PR is a precursory to some other projects I have to create backend web-based Shiny apps that will make it possible to load and edit planetary system files via a browser. The yaml format will be much easier to work with for those projects than the current xml.

Data Conversion Process

I used R scripts in this repository to convert from the old xml code to the new yaml code. In doing so I made

• Added source information where it was non-canon using a source: value: pairing for all entries.
• Cleaned up the underlying data for connector systems which wasn't working properly. We had no icons for the planets in these systems and satellites were coded in XML using the wrong system so they all ended up null. Connector systems all look great now.
• In the previous XML transition, we included some canon population data, but we never properly indicated the source for this data in the XML data. So, I added that source information to the new yaml data.
• Where we are using enums, I replaced the raw text data to the correct enum value. For example, in atmosphere I changed Toxic (Poisonous) to TOXICPOISON.

We also wanted to better capture the source information for each entry which was entered into XML as an attribute. We handle this by breaking every entry into a source: value: pair. For example here is the entry for Terra's gravity:

gravity:
  source: canon
  value: 1.0

Ideally, as we enter stuff in the future, we can be more specific than just "canon" but that is what we have for most canon entries right now. For cases, where do not have a canon entry, we just leave out the source part entirely, for example:

pressure:
  value: HIGH

This makes the files a little longer and less easy to read, but is critically important to ensuring proper sourcing of all data whenever possible. I create a SourceableValue class in java discussed below to capture this data structure from the yaml.

Code Improvements

To read the new data structure in smoothly using Jackson, I had to make some changes to the planetary system data that have been long overdue. These changes are:

• Create a StarType class to track information about a given star, including calculating internally things like time to jump point and solar charging time. To do this I moved a bunch of stuff out of StarUtil. Most of the stuff left in StarUtil is currently unused but I decided to leave it rather than try to get it all sorted for this PR. If the reviewers would prefer I do that now, I can.
• Create proper enums for HPG rating and planetary type. The old HPG rating code relied on EquipmentType integers which was ugly and not a great fit because HPGs only go from A to D. Plus equipment type integers are reverse ordered. Planetary type was just a string.
• Created a LandMass class to record information about each landmass on a planet.
• Cleaned out a lot of unused out of date classes and methods. I was pretty ruthless here. I think we have a tendency to leave this stuff in which then makes the code harder to read, especially for newbies to the project. Its all saved in git if we need it again.
• Made quite a few changes to the loading procedure to simplify it. One nice benefit of reading in individual planet files, is we can catch IO errors and not break the whole thing, just lose that planet (with the error reported to the log).
• Added the SourceableValue class which I disuss below.

SourceableValue

Probably one of the biggest changes is the use of the SourceableValue class. This is a generic class which records both the source (as a string) and value (as a generic type) for any possible entry. I then use this to record any base planetary data or event that we consider sourceable, which is almost everything. the source value is null for non-canon entries.

Currently, we are not doing anything with this information in MekHQ, but a later PR goal will be to provide this information to users in some way through the PlanetViewPanel (I am thinking maybe as a mouseover popup). However, this information is critical in our yaml data for external backend editor development. So, I needed some way to load the data structure using Jackson and this is works very smoothly.

Custom User Data

Most of the stuff in this PR is backend and will not affect users, but there will be one nice new user feature. If users have a custom data directory defined in the mmconf file, they can include a data/universe/planetary_systems directory. Any yaml file they drop in there will be read as a custom planetary system that will be loaded when MekHQ launches.

We did have some relic code in there for reading in custom planetary system events. However, since the last big XML makeover, we have not provided users a way to add or edit events, so there shouldn't actually be anything there. A future PR will build in a custom events editor that will allow players to add custom events to a given planetary system that will get saved in the campaign file. So if players take over a planet for the Dracs, they can record that, or if they totally nuke a planet from orbit, they can also record that. But for now, I just removed all the legacy code for custom planetary events since there is no more XML code to load/save. If, for some reason, players have this in their campaign files, it will be ignored and not cause any errors in loading.

The last possibility is that some users may have created entire AUs by either writing their own systems.xml or adding in other xml files. These will no longer work. I would like to at some point offer up a Shiny app for converting old xml files like this to the new yaml format, but my guess is there are relatively few players in this category.

Refactoring

It might be a good idea to refactor all of the planetary stuff in the universe directory into a planetary_system subfolder. I did not do that here because I thought it might make it harder for reviewers to review the work and might cause a lot of chaos with other PRs people are working on, but if that is a desire of reviewers I can do so.

EDIT: One more thing I forgot to mention is that I would like to add something to the gradle packaging scripts that zips up the planet files for distribution, just like mekfiles in MegaMek. They can be read directly from a zip file. @rjhancock is working on some gradle code to do that because I don't have a lot of gradle experience.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 10.29%. Comparing base (643b078) to head (b94aa60).
Report is 1 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #6031      +/-   ##
============================================
- Coverage     10.36%   10.29%   -0.08%     
+ Complexity     6153     6084      -69     
============================================
  Files          1040     1032       -8     
  Lines        139434   138596     -838     
  Branches      20683    20540     -143     
============================================
- Hits          14458    14274     -184     
+ Misses       123522   122876     -646     
+ Partials       1454     1446       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.