v1.12.0 Bugs Thread

[TheTalkingMeowth]

I'm getting errors which seem to be when a ship is set to auto-overhaul when it has exceeded deployment.   Right as the auto-order message would normally come up I get these two errors in succession:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

It still sets up the movement orders to the colony (only one with maintenance facilities) and the overhaul order.   Don't see a separate order for refuel/resupply (I forget if it's supposed to be there.  ) The Orders Assigned message is missing though I see the Deployment Time Exceeded message in the previous tick. 

My full orders for these ships:

• Survey Next Three System Bodies or Locations
• Move to System Requiring Gravsurvey
• if Deployment Exceeded, Refueld, Resupply, and Overhaul at Colony
• if Fuel less than 40%, Refuel from Colony or Hub

These orders seemed to work as I'd expect with no errors at first, but after a few started showing these errors.  Only thing I can think of so far is that they're now 3 jumps out from the colony instead of 1-2.

Just to double-check, are there stabilized jump points through all 3 jumps?

In my case, no, I don't think it has happened when there was a stabilized path. But the ships involved are all self jump capable.

[TheTalkingMeowth]

v1.12.0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series. It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit." So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

SJW: Yes, I encountered this myself. Fixed now.

[Droll]

v1.12.0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series. It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit." So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

+1. This issue happens once a certain amount of unit series have been created. It seems like some bug is hard capping the number of series you can have.

Adding unit series though DB editing will circumvent this issue but becomes finnicky.

[Arcturius]

The occupation strength required to force a surrender of an alien population seems implausibly high.   

• The version number - v1.  12.  0
• The function number - N/A
• The complete error text - N/A
• The window affected - N/A
• What you were doing at the time - testing
• Conventional or TN start - TN
• Random or Real Stars - Real
• Is your decimal separator a comma? - No
• Is the bug is easy to reproduce, intermittent or a one-off? - Easily reproduced
• If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - N/A

The occupation strength required to force a surrender of an alien population is very high.     For example to subdue the Martians (50 mio pop) in my test game required an occupation strength of 3803 - about 650,000 tons of PWL infantry.   

After forcing surrender the required occupation strength drops to a much more reasonable 26.     This is about 1/146 of the occupation strength that is required for surrender.   

Now this might be intended, but it looks like it may as well be an oversight in the formula.     Perhabs this is related to the fix of occupation strength and police modifiers for v1.  12.   


Edit: This seems to be the same issue:

It seems like occupation strength is very broken: I appear to need about 60 billion tons of ground troops to pacify an enemy homeworld, which has an occupation strength of 161,000.

SJW: Fixed. The code was in two places and I only fixed one of them in v1.12.

[Romalar]

Just to double-check, are there stabilized jump points through all 3 jumps?

In my case, none of the jumps would have been stabilized at first but the ships are jump-capable.     It's possible that when the bug started that it was then a mix of stabilized and non-stabilized on the path back, but I think it's always been non-stabilized at the end of the path that the ship in question is on given its nature as a exploration ship.   

[Demetrious]

(Minor) Bug: The new "SM Move Fleet to Rendezvous Waypoint" feature does not properly display the name of the waypoint in the Miscellaneous tab of the Naval Organization window: https://i.  imgur.  com/uZT7JaV.  png

The feature is otherwise working perfectly.  Reproducability steps: Slap down a rendezvous waypoint and simply use SM fleet move to see this.     

For completeness's sake: Decimal separator is a period, TN Start, Real Stars, game is only about 10-15 years in.       

SJW: Appears to be working normally for me.

[Arcturius]

v1. 12. 0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series.  It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit. " So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

+1.  This issue happens once a certain amount of unit series have been created.  It seems like some bug is hard capping the number of series you can have.

Adding unit series though DB editing will circumvent this issue but becomes finnicky.

+1.  The following steps reliably reproduce the bug:

• Create any number of ground unit series (1 suffices).
• Save+Exit Aurora.
• Open Aurora.
• Try to create another ground unit series.

[vorpal+5]

NPR ship handle (like RUS, CHI, USA prefixing the NPR ship name on the tactical screen) does not correspond to what you have entered in race creation as the race short name, but always correspond to the three first letters of the race long name.

100% reproducible in all settings

SJW: Not a bug. The 3 letter code is generated using the name of a race but is intended to be manually set in the Intelligence window.

[vorpal+5]

I'm unsure if this is a bug or a 'feature' although I'm not too sure this one would have any positive aspects if a feature. Using (the default) 'real ship / class names', upon detecting my fellow others nations block on Earth, most if not all of their ships are named alphabetically, so they mostly start with a 'A'.

For example the US ships classes are Aberdeen and Abilene (they are the first two entries in their list, which is about US cities and states').
Russia ships classes are ... Aleksandrovsk and Akmolinsk and for the Japanese, this is Abukuma and Agano ...

I would tend to say that's a bug, because it feels rather suboptimal to me. I would have imagined that AI races picked a name at random in the list and not alphabetically.

SJW: It's not a bug as it is working as intended. However, I think changing it to random order is a good idea.

[replicant2699]

Yep, it just happened again. I have the system set to alien controlled and no auto route, the ship is flagged to ignore alien controlled systems and it definitely had no orders queued. I had sent him back to refuel and on to a system far away from here last time this happened. He has actually passed through another alien controlled, no autoroute system to get where I just found him.

I have tested this again today and it seems that if you set that alien race as hostile, your ships will not jump to those systems, though they ignore those orders if it's set to neutral.

[TheTalkingMeowth]

NPR ship handle (like RUS, CHI, USA prefixing the NPR ship name on the tactical screen) does not correspond to what you have entered in race creation as the race short name, but always correspond to the three first letters of the race long name.

100% reproducible in all settings

You have to set the "reporting" abbreviation in the Diplomacy window. Otherwise it takes the default as described.

[Demetrious]

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.

[Droll]

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. 

Yeah this is a problem that renders CAS less than useless. An easy solution would be to make all craft flagged as "fighters" immune to STO targeting and let AA be their exclusive ground-based threat.
On a related note, how does AA damage translate to CAS fighters - damage and armor pen wise?

[Demetrious]

Yeah this is a problem that renders CAS less than useless.  An easy solution would be to make all craft flagged as "fighters" immune to STO targeting and let AA be their exclusive ground-based threat.
On a related note, how does AA damage translate to CAS fighters - damage and armor pen wise?

Probably the same scaling rule that Steve uses for translating capital weaponry to ground scale damage for purposes of calculating collateral damage:

"The damage in ground combat for an energy weapon is equal to 20x the square root of its point blank damage in ship-to-ship combat.  Armour penetration is equal to half the damage.  Fractions are retained.  For example, the AP/Damage ratings would be 10/20 for a 10cm railgun round or gauss cannon, 17. 3/34. 6 for a 10cm laser, 40/80 for a 25cm laser.  Weapons roll for failure in the same way as in naval combat. "

I wouldn't know about armor, though, that's a good question. 

[Droll]

Yeah this is a problem that renders CAS less than useless.  An easy solution would be to make all craft flagged as "fighters" immune to STO targeting and let AA be their exclusive ground-based threat.
On a related note, how does AA damage translate to CAS fighters - damage and armor pen wise?

Probably the same scaling rule that Steve uses for translating capital weaponry to ground scale damage for purposes of calculating collateral damage:

"The damage in ground combat for an energy weapon is equal to 20x the square root of its point blank damage in ship-to-ship combat.  Armour penetration is equal to half the damage.  Fractions are retained.  For example, the AP/Damage ratings would be 10/20 for a 10cm railgun round or gauss cannon, 17. 3/34. 6 for a 10cm laser, 40/80 for a 25cm laser.  Weapons roll for failure in the same way as in naval combat. "

I wouldn't know about armor, though, that's a good question.

That answers capital to ground but I'm asking the reverse. In my case it seems like precursor AA Decurions can one shot (or two shot) fighters with 4 layers of armor