Author Topic: v2.5.1 Bugs Thread  (Read 75335 times)

0 Members and 1 Guest are viewing this topic.

Offline Demetrious

  • Warrant Officer, Class 2
  • ****
  • D
  • Posts: 71
  • Thanked: 45 times
Re: v2.5.1 Bugs Thread
« Reply #405 on: February 02, 2025, 02:29:31 PM »
Apologies for the double-post, but I have something more to report. Ground support fighters (GSFs) are bugged:

1. There's a bug relating to GSF's being destroyed by hostile fire but the event being reported as a "catastrophic failure" from maintenance. This is visible both when they're assigned to normal ground support and when dispatched on independent operations. Conversely AA attacks against GSFs that do not destroy them are reported correctly in the combat log (see attached image; you still get a damage report for the fighter even though it was reported as a maint failure destruction event.)

2. Independent operations ("Search and Destroy" and "Flak Suppression") are completely non-functional. When fighters are ordered to conduct such operations on a system body (with and without a colony present, with and without friendly ground forces engaging present) the fighters will drop like flies from "catastrophic failures." I have actually seen an AA fire against fighter combat report generated ONCE, but this is not the norm. Then again, I also saw fighters on the system body with a "seek and destroy" mission get engaged by a 20CM railgun STO, which isn't supposed to happen... but only once. This is by far the worst bugged part; I find myself at a loss to detail all the weirdness I've seen while running tests. Most significantly, they appear to conduct no attacks against hostile ground forces at all.

3. GSFs providing ground support to ground formations seems to be working as intended.

4. The game throws a "Function #2047 : Object reference not set to an instance of an object" error when instant-designing Fighter Bombardment Pods (and ONLY fighter bombardment pods.) Probably insignificant but worth noting.

Due to the complexity of this I've taken the liberty of setting up a clean-sheet test game. The "Red Planet" moniker appears to have been taken the wrong way by some, as some dastardly Soviet Martians have been discovered on Mars. On a nearby asteroid you've been provided with some toys; a troop transport with ground formations that also have forward fire direction units (and a generous supply of spares in a separate detachment, with the formations generously equipped with FFDs so you needn't worry about counting as you click and drag,) and various fighters. The "weak fighters" are thinly armored but generously supplied with MSP and fuel, and already split into test and control groups to demonstrate that the catastrophic failures are definitely not from maint failure, but rather enemy action. The "tough fighters" are stronger and there's a group with both autocannon pods and bombardment pods for testing both. The Soviet Martians have ground forces, but their STO batteries are set to hold fire by default. Both parties are flagged hostile to the other.

I am aware that Steve doesn't maintain dev versions of older Aurora iterations and he strips out debug access before issuing release versions for good reasons, so he may have to recreate this in his 2.6 version to track down the issue, but maybe it will help anyway. :)

Both forum-searching and asking around on Discord indicate nobody was aware of these issues. I know nobody likes the micromanagement of setting up ground support, but unleashing a horde of cheap fighters to scour out STOs seems like a much more attractive alternative than bringing capital ships into horrible consequences range...
« Last Edit: February 02, 2025, 04:04:59 PM by Demetrious »
 

Offline Andrew

  • Registered
  • Commodore
  • **********
  • Posts: 772
  • Thanked: 157 times
Re: v2.5.1 Bugs Thread
« Reply #406 on: February 02, 2025, 05:57:24 PM »
I am fairly certain I have seen issue 2 before , and that such missions are known to not work in the distant days of the past when I struggled to use ground support fighters I knew that such missions did not work.
 

Offline Ghostly

  • Warrant Officer, Class 2
  • ****
  • G
  • Posts: 65
  • Thanked: 47 times
Re: v2.5.1 Bugs Thread
« Reply #407 on: March 08, 2025, 02:08:32 PM »
Attached are two screenshots of a fleet of two ships, one with maximum crew grade (22%), and one with minimum crew grade (conscript crew, -10%) performing a transit through a jump point blockaded by enemy forces then opening fire as soon as possible:

1. Standard transit:
Transit is performed at 22:12:37, the max crew grade is able to open fire at 22:12:42, the min crew grade ship is able to fire at 22:12:47.

2. Squadron transit:
Transit is performed at 22:51:32, both ships are able to open fire at 22:51:37.

Now, the Fire at Will post does say it will override any existing delay, but the current implementation is very broken and will trivialize any jump point assault. Maybe the order should consider whether the ship is experiencing jump shock before it gets "assigned a fire delay with a modifier of -50% vs normal", where a normal delay would include a transit-induced one when applicable?
« Last Edit: March 08, 2025, 02:53:17 PM by Steve Walmsley »
 

Offline Andrew

  • Registered
  • Commodore
  • **********
  • Posts: 772
  • Thanked: 157 times
Re: v2.5.1 Bugs Thread
« Reply #408 on: March 08, 2025, 04:31:37 PM »
Attached are two screenshots of a fleet of two ships, one with maximum crew grade (22%), and one with minimum crew grade (conscript crew, -10%) performing a transit through a jump point blockaded by enemy forces then opening fire as soon as possible:

1. Standard transit:
Transit is performed at 22:12:37, the max crew grade is able to open fire at 22:12:42, the min crew grade ship is able to fire at 22:12:47.

2. Squadron transit:
Transit is performed at 22:51:32, both ships are able to open fire at 22:51:37.

Now, the Fire at Will post does say it will override any existing delay, but the current implementation is very broken and will trivialize any jump point assault. Maybe the order should consider whether the ship is experiencing jump shock before it gets "assigned a fire delay with a modifier of -50% vs normal", where a normal delay would include a transit-induced one when applicable?
AFAIK, The fleet training percentage effects the delay on firing not the crew grade so you would need that value to tell which ship should respond faster. So probably not a bug
 

Offline Ghostly

  • Warrant Officer, Class 2
  • ****
  • G
  • Posts: 65
  • Thanked: 47 times
Re: v2.5.1 Bugs Thread
« Reply #409 on: March 08, 2025, 09:53:53 PM »
AFAIK, The fleet training percentage effects the delay on firing not the crew grade so you would need that value to tell which ship should respond faster. So probably not a bug

You can see in the screenshots that the -10% grade ship has 0% fleet training as well, I somehow neglected to mention that. In any case, being able to open fire 5 or 10 seconds after a standard transit is definitely a bug.
 

Offline mike2R

  • Lieutenant
  • *******
  • m
  • Posts: 190
  • Thanked: 121 times
Re: v2.5.1 Bugs Thread
« Reply #410 on: March 09, 2025, 12:19:15 PM »
Parasites don't seem to refuel from their carrier, if the carrier is on an order delay.

I've noticed this with carriers that are on a looped order to wait at a picket position, then come back and overhaul.  I set them to wait at the picket position with a long order delay.

If I use its fighters and land them again, they don't start to refuel until the order delay period is up and the carrier starts to actually execute the order.

I've not tested if repairs and ordinance reloads are similarly effected.
 
The following users thanked this post: skoormit

Offline Napier

  • Leading Rate
  • *
  • Posts: 13
  • Thanked: 7 times
Re: v2.5.1 Bugs Thread
« Reply #411 on: March 11, 2025, 02:38:19 PM »
The function number - 391/2397
The complete error text - Object reference not set to an instance of an object
The window affected - multiple
What you were doing at the time - see below
Conventional or TN start - Conventional
Random or Real Stars - real
Is your decimal separator a comma? - no
Is the bug is easy to reproduce, intermittent or a one-off? - reproducible in attached db
If this is a long campaign - 100+ yrs, this was a 2.  5.  0 game I upgraded to 2.  5.  1


2 bugs to report for 2.5.1, 1 larger one and a 2nd minor one

Bug 1: I encountered error conditions that arise after I capture raider ships via boarding.

Before the capture, no errors. Afterwards, this error: "Function #391: Object reference not set to an instance of an object"
occurs when opening Commanders window and clicking on a naval commander or when selecting options in the drop down like 'Fleet Commander' or 'Military ships' - and no ships appear in the display box underneath the drop down, so user is unable to assign commanders manually.

Also, after a capture, at the beginning of each increment, this error occurs: "Error Function #2397: same description as above"

I'm thinking the code is trying to find the raider ships in the commander window, and assign a CO during the increment turnover, but cannot do either, so throws errors.

The raider ships do not appear in the design window that I can see, so I cannot i.e. toggle that class as 'No officers'

The attached game (game3) has the boardings under way, just need to run through a few boarding combat cycles before the first ship is captured.


Bug 2: Appears to be a minor display issue with medals.
Using attached db, Open commanders window > Commodores dropdown > click on Bela Radacanu in middle of list > the images for two red medals have the same description in the popup text.  But if you look at the history log for the character, you see they are 2 different medals assigned at different times with different descriptions: 1. Oct 2208 and 2. July 2204. Another example of this is Atshushi, 2nd listed Commodore. I believe in both cases it is the same medal awarded for different purposes.
« Last Edit: March 15, 2025, 03:01:26 AM by Napier »
 

Offline dsedrez

  • Warrant Officer, Class 2
  • ****
  • d
  • Posts: 66
  • Thanked: 17 times
Re: v2.5.1 Bugs Thread
« Reply #412 on: March 12, 2025, 06:16:13 PM »
The function number - 391/2397
The complete error text - Object reference not set to an instance of an object
The window affected - multiple
What you were doing at the time - see below
Conventional or TN start - Conventional
Random or Real Stars - real
Is your decimal separator a comma? - no
Is the bug is easy to reproduce, intermittent or a one-off? - reproducible in attached db
If this is a long campaign - 100+ yrs, this was a 2.  5.  0 game I upgraded to 2.  5.  1


2 bugs to report for 2.5.1, 1 larger one and a 2nd minor one

Bug 1: I encountered error conditions that arise after I capture raider ships via boarding.

Before the capture, no errors. Afterwards, this error: "Function #391: Object reference not set to an instance of an object"
occurs when opening Commanders window and clicking on a naval commander or when selecting options in the drop down like 'Fleet Commander' or 'Military ships' - and no ships appear in the display box underneath the drop down, so user is unable to assign commanders manually.

Also, after a capture, at the beginning of each increment, this error occurs: "Error Function #2397: same description as above"

I'm thinking the code is trying to find the raider ships in the commander window, and assign a CO during the increment turnover, but cannot do either, so throws errors.

The raider ships do not appear in the design window that I can see, so I cannot i.e. toggle that class as 'No officers'

The attached game (game3) has the boardings under way, just need to run through a few boarding combat cycles before the first ship is captured.


I'm not sure it's the same bug, but I've met a similar one in one of my games. I was playing multiple player races and NPRs, and one player race captured a raider. When I tried capturing another raider with another player race, the design wouldn't appear in the design window. I checked the DB and there the 2nd captured ship was classed under the raider copy design attributed to the 1st race with a captured raider. For your game, maybe a NPR captured a raider before you and got the copied design.

Though I don't recall having problems with commanders.
« Last Edit: March 12, 2025, 06:17:54 PM by dsedrez »
 
The following users thanked this post: Napier

Offline dsedrez

  • Warrant Officer, Class 2
  • ****
  • d
  • Posts: 66
  • Thanked: 17 times
Re: v2.5.1 Bugs Thread
« Reply #413 on: March 12, 2025, 06:45:23 PM »
Is it bug that naval admin commanders (general or industrial) don't give any bonuses from their Production skill to stabilising lagrange point ship? Only production skill of ship commander gives bonus. Ship is in naval admin radius at this moment of course.

Are you sure they're not contributing? I use this all the time, with 3 stacked naval admins, and my construction ships regularly stabilize JPs almost twice as fast (in little more than half the time).
 

Offline skoormit

  • Vice Admiral
  • **********
  • Posts: 1002
  • Thanked: 424 times
Re: v2.5.1 Bugs Thread
« Reply #414 on: March 14, 2025, 05:24:30 PM »
Is it bug that naval admin commanders (general or industrial) don't give any bonuses from their Production skill to stabilising lagrange point ship? Only production skill of ship commander gives bonus. Ship is in naval admin radius at this moment of course.

Are you sure they're not contributing? I use this all the time, with 3 stacked naval admins, and my construction ships regularly stabilize JPs almost twice as fast (in little more than half the time).

You probably have ship commanders with ~40% bonus to Production.

NACs do not provide any bonus to stabilization.
 

Offline Inglonias

  • Lieutenant
  • *******
  • I
  • Posts: 174
  • Thanked: 69 times
Re: v2.5.1 Bugs Thread
« Reply #415 on: March 15, 2025, 08:41:32 PM »
Not sure if this is intentional or not, but I discovered what I believe is a bug when messing with the database for fun and profit.

I was nervous about my abilities compared to the NPR, and discovered that despite setting the research speed to 20%, the NPR appears to have gotten the full 160k research points to spend at the start of the game, and I got 32k. Now that I know about this, I can compensate for it, but I had no way of knowing besides literally cheating and setting the NPR to a player race for a little bit so I could peek.

EDIT: I want to clarify that setting the NPR to a player race so I could peek was the only database edit I made, and I set it back before continuing gameplay.


EDIT 2: I checked the Known Issues thread and this is working as intended.
« Last Edit: March 15, 2025, 08:57:57 PM by Inglonias »