Two (related?) bugs, one test game - STO surface-to-surface fire throws an error and Ground Support Fighters receive no protection from STO fire while executing ground support orders at a system body.
1. STO's throw error "1. 12. 0 Function #311: Object reference not set to an instance of an object" when attempting to fire on civilian populations, shipyards, ground forces and STO ground forces contacts, (located on another system body that is in-range, of course, such as a moon. ) The fire seems to resolve normally, but no combat report is received in the "events" window; only the energy weapon impacts as normal for a third party. Off-board sensors (such as on a starship) do not affect this in any way.
2a. Ground Support Fighters cannot be given a "free-ranging" (e. g. Search And Destroy) order with just a system body as a target, as documented; a friendly colony must be created. This may only amount to outdated documentation, but it should be confirmed.
2b. Ground Support Fighter "protection" is non-functional against STO units in every applicable context. I have tested this on "free-range" missions (Search And Destroy, Flak Suppression, etc. ) with a friendly (empty) colony on the planet, and with friendly ground troops on the planet, with FFD capacity, with the support relationships set up. In every case the STOs cheerfully engage the ground support fighters with active ground support orders that are on top of the system body. This is not AA fire as the message is identical to the STO message (someship has been engaged by ground-based energy weapons on Planet,) fire happens every 5 second tick instead of the 8 hour ground combat tick and the fighters themselves never resolve their own ground combat fire.
For ease of reproducability I have provided a test game with everything already set up. See attached file "AuroraDB_STO_and_fighter_bug_testing. zip. " Game name is "New Game Doot," (as renaming saved games seems nonfunctional at the moment. ) Test subject is NPR Race [AL1] on Alpha Centauri II. A-II Moon 1 hosts four STO units (TESTING STO 1, 2 3 and 4) pre-set to target shipyards, populations, ground forces and STO ground forces, respectively. Active sensors are initially off. ELINT is in the system to keep population contacts live and some missile fighters + sensor ship are in range to verify off-board sensor interaction and/or stimulate defenses to reveal NPR STO units. The Naval Admin Command "TESTING FLEET" contains prepared assets (clearly named for clarity) for further testing, including Ground Attack Fighters, a loaded troop ship (SM it over A-II and order a drop immediately, it'll resolve that before it gets blown up,) and a conventional particle beam/carrier fleet. No Rendezvous Waypoints are active so any you create for SM fleet move purposes will be the first in the list.
Final Note: There are actually two NPR populations on Alpha Centauri A-II; they spawned this way. Since this itself may be a bug I've included a second save file from immediately after discovering this; before both civs started blowing the hell out of each other. This may be of interest to Steve, just to compare both files and see how the (unintentional?) NPR multi-race start played out. Filename is "AuroraDB(early alpha centarui rumble 1. 12). db. zip. "
Technical details: TN start, period decimal separator, easily reproducible (see attached test game) and relatively short games.
Files: Since I don't have enough posts yet the forum software is treating me with suspicion, so unfortunately you will have to untangle these Mediafire links yourselves:
hxxp: www. mediafire. com/file/zvlit41zaj1fqea/AuroraDB_STO_and_fighter_bug_testing. zip/file
hxxp: www. mediafire. com/file/7g5q8mxclsfzzpn/AuroraDB(early+alpha+centarui+rumble+1. 12). db. zip/file
SJW: 1, 2a and 2b all fixed. Multiple NPRs on same planet is working as intended.