These are for v100.
The Jump Gate Construction default order doesn't check for other gate constructors, leading to multiple vessels potentially getting assigned to build the same gate. The ideal behavior would be to mimic the survey order such that gate constructors don't get assigned to construct a gate if another vessel is assigned (even if it hasn't started construction yet).
This is a repeat of a previous report, which I can reliably reproduce. The Jump Gate Construction default order behaves oddly when queuing out-of-system jobs. When a constructor (without a jump drive, haven't tested if this matters or not) in system A has no in-system jobs left, if it has good 2-way gate connections to system B (which still has some un-built gates) it will queue up a gate in B, interrupt and report that the job is out of the system and that all orders were rescinded, but not rescind the move orders nor the default order. I don't remember how this worked in Aurora.
I think the ideal behavior to maximize the utility of the default order would be as it is, but with the message changed to a simple report that it's going out-of-system. However, I can see the argument for the current report and rescinding the orders+deleting the default order as the current message implies should happen.
This is more of a feature request, but if you learn a tech from an archaeology site and it's currently being researched or in the queue it would be really nice if those would get cancelled instead of letting me waste RP on them if I miss the report in the event log.
While the game lets you recover (via archaeology) non-racial ship components (like Advanced Cargo Handling System) above your tech level, you can't use them until you research the associated technology (or if you can, I can't figure out how). High-tech racial components like jump drives and engines work fine (by deselecting "own tech only" as expected).
I just recovered a stack of "command modules" via archaeology, I don't think these exist in Aurora 7.1 and I can't use them in the class design. I want to say these were a fighter or FAC "bridge" from a really old version (2010 timeframe).
Archaeology sites can create ship components that shouldn't exist, presumably because the tech level is too low. JC0K jump drives (0 tons allowed), Null PB-1 reactors (0 power), 0 EP Null engines, etc. I've seen it on TL0 and TL1 archaeology sites thus far.
It's nice to see some asteroids again. However, I just generated a system which has a belt of huge asteroids, many 8-9000 diameter, which gives a lot of them enough gravity to be colonized with regular infrastructure or terraformed. Is the generation of planet-sized "asteroids" intentional?
Lagrange Points often get generated in nonsensical places. As an example, this secondary star has two super-jovians which I assume are the reason for these two LPs, but they're not on the super-jovian orbits as they should be.
https://i.imgur.com/b93xDy9.pngAs a logical feature extension but a deviation from Aurora, you might consider applying LP-generation rules to secondary/etc stars in addition to just super-jovians; there are a couple scenarios involving ultra-distant secondaries/etc where having LPs on the orbiting stars would be welcome.
Assigning a leader to "unassigned" resets your search parameters, which can be annoying if you're micromanaging commanders.
Planetary hydrosphere status doesn't update with temperature, nor is there the associated albedo change. It's possible that this just isn't implemented yet but I'm "reporting" it because the (non-spacemaster) system view window otherwise seems pretty complete.
