Closed jmonty42 closed 1 year ago
Hmm OK, thanks for the report, I will look at this when I have time.
Hi @jmonty42, I have pushed a fix in the fix-base-detection branch. The fix is a simple one relating to how base objects are detected. Previously, for example, br02_04
would have been erroneously identified as a generic Object
, meaning it was present in .contents()
but not .bases()
, and this has been fixed:
>>> fl.systems['br02'].bases()['br02_04']
BaseSolar(nickname='br02_04', ids_name=196669, ids_info=65693, pos=pos(x=63489.6, y=-55862.5, z=-7596.8), rotate=rot(x=0, y=0, z=0), archetype='invisible_base', reputation='br_p_grp', base='br02_04_base')
However because I don't use the library or play the game anymore, I need you to check that this change hasn't resulted in any weirdness where things are now being classified as bases when they aren't. So please get back to me on that.
Actually, yes, I can already see this is happening, and the space_costume
option was quite helpful previously in discriminating against asteroid miners.
Thanks for taking a look at this! I'll pull that branch and test it out soon.
Planet New Berlin and possible some others fixed in d271a513395bc797dcdbc6284761e337c899d21c
OK, the current logic in the branch uses a somewhat hacky heuristic but it works. Now, out of your list, the only solars that are not classified as bases are those with archetype = invisible_base
(the two in ew13
differ slightly but are equivalent to this).
Using a fresh copy of Discovery 4.91.0, there are several bases that do not show up in the
EntitySet
when calling thebases
method of their respective system. Each missing base is present in the appropriate system ini file and each base object retrieved by flint has the correct system identified by itssystem
string attribute.Here is the list of missing bases I've found: