Closed AaronGullickson closed 5 years ago
Ok, I have gone back and done some checking on the star data to get some more solid numbers. Here is what I have. I was looking for three things.
First, I was looking for cases where the star information was incorrectly formatted. I am already kicking these out of MHQ but I didn't know how many I had. It turns out there are five cases:
id star
1 Betelgeuse M2I
2 Mallory's World G2I
3 Pesht F7v
4 Proserpina K2v
5 Tigress ?7V
The first two need an a or b subclass on I. The 3rd and 4th are just not properly capitalized. That should be easy to fix. The last one is missing a main star type.
With the new system rules, planets beyond position 7 are not in the life zone for any main sequence stars. You can get them out to position 8 if you assume non-main sequence, but the generator assumes main sequence. There are 16 cases here:
id sys_pos
1 Acamar 8
2 Alula Australis 8
3 Ares 8
4 Bell (CC) 10
5 Cartago 13
6 Dark Nebula 15
7 Denbar 8
8 Elissa 9
9 Goshen 9
10 Layover 12
11 Lushann 8
12 Necromo 10
13 New Damascus 8
14 Novo Franklin 8
15 Sabik 9
16 Tall Trees 8
In all of these cases, I have just moved system position to 7.
This is by far the biggest problem. For a given star only a few system positions are in the habitable zone. In our data, we have a total of 480 cases with a mismatch here. An excel file with the cases is attached. We only have 737 cases of a star type being provided so 65% of our cases are invalid. At the moment, I am handling this by ignoring the canon star position and just generating one that fits the system position.
However, I question how many of these are actually canon. At some point, someone put in star types for every single planet. We have no definitive way of determining what is supposed to be canon, so i went off the suggestion that if a system position was also provided the star type would also likely be canon. The question is whether there are cases where we have a canon system position and not a star type.
All of those positions should be canon as it lines up with my numbers for worlds with canon data. We can either screw with canon and change them or accept that FASA and the lot didn't care much about the habitable zone and make exceptions.
The answer for the Star Types is a lot harder other than that I can provide you a list of the planets with canon data and you can at least use that to determine which are not necessarily canon.
Additionally, Betelgeuse and Mallory's World M/G2I are what was reported in canon. They did not have the a or b at the end. I don't know the difference the a or b makes but I suppose we can add one or the other if it screws with the calculations.
Tigress should be G7V
We basically have three choices
If we did (3) the easiest approach would be just to generate a system with out paying attention to system position and just enforcing a minimum number of planets. Then just swap the position of two planets.
If we don't do (3), then I think (1) is preferable to (2) as system position has more game impact plus we want to have names like Carver V make sense.
Commit 1d7167d should address the bad formatting for all cases except Tigress. I force case to upper on star type in the code to address the first two and edited the planets.xml input for Betelgeuse and Mallory's world to make them Ib types.
The bigger project is doing solution (3) above to keep canon position for planets with mismatched stars and planet positions.
I put a warning in for invalid star type and I coming up with a few more cases now:
2: In eval(ei, envir) : Invalid star information provided for Betelgeuse
3: In eval(ei, envir) : Invalid star information provided for Cassias
4: In eval(ei, envir) : Invalid star information provided for Circe
5: In eval(ei, envir) : Invalid star information provided for Eden
6: In eval(ei, envir) : Invalid star information provided for Hellgate
8: In eval(ei, envir) : Invalid star information provided for Kalidasa
9: In eval(ei, envir) : Invalid star information provided for Mallory's World
10: In eval(ei, envir) : Invalid star information provided for Rasalgethi
11: In eval(ei, envir) : Invalid star information provided for Shady Palms
12: In eval(ei, envir) : Invalid star information provided for Suda Bay
14: In eval(ei, envir) : Invalid star information provided for Tigress
16: In eval(ei, envir) : Invalid star information provided for Ziliang
Commit 36e6d1ed7c42738530d231c5f3c3c763f3ebf428 should implement solution 3 above - swapping planets to maintain system position. It should also obey all of the rules about things like swept zones out to the canon position.
I will merge this branch back to the master once I figure out the remaining cases of invalid star information listed above.
Looking through the example cases, I am not sure why they triggered invalid star information as they are all coming up clean. I made some changes to that check and put it in a function to make sure it is applied the same everywhere and I am re-running to see if it goes away.
It turned out the problem was that I turned all the star information to upper case which is wrong for Ia and Ib. Sigh. Changed back and corrected the two cases of wrong casing manually.
With the merge of the system mismatch branch, this issue is now resolved.
There seem to be a lot of planets with system positions in the data because we are getting a lot of warnings about star/system position mismatch. I am suspicious that most of these are not canon but were added at some point.