v2.5.1 Bugs Thread

[pedter]

While hunting the remains of one of my main NPR's FAC fleets I have discovered that they are still capable of running away despite being out of fuel, out of MSP, and years beyond their intended 10-day deployment.  Clearly they don't obey maintenance or deploy rules (I imagine this is granted to them so that they stand a chance at all), but my understanding is that they should not be able to receive orders other than "search for fuel while empty" as indicated in the C# changes list.  I cannot find any indication of roll-back in the changes list so I assume that change still stands and that this is unintended behavior; https://aurora2. pentarch. org/index. php?topic=8495. msg110348#msg110348 is the latest that I can find on the subject.

Info dump:
- No function number or error text
- Conventional start
- Real stars
- US decimal and time formats (I have not reconfigured for UK standards)
- Approximately 79 years into the campaign
- Campaign started and running on v2. 5. 1

[nuclearslurpee]

The "run away" part of the NPR code tends to supersede the "find fuel" part, admittedly for obvious reasons as it would be rather silly for the NPR to barrel its FACs into the teeth of your fleet just because this is a direct path towards fuel. You can also see this sometimes with the NPR logic around jump points, as it is one reason that NPRs jump back and forth endlessly due to the circular logic of (1) "I am in System A and I need fuel, I must jump into System B!" and (2) "I am in System B and it has a high danger rating, I must escape by jumping into System A!".

[pedter]

The "run away" part of the NPR code tends to supersede the "find fuel" part, admittedly for obvious reasons as it would be rather silly for the NPR to barrel its FACs into the teeth of your fleet just because this is a direct path towards fuel.

But if they're out of fuel they shouldn't have access to the "run away" part of their code at all, at least as it's explained in the changes list: "unable to do anything except search for refuelling options." Heading home for fuel, even if it risks going directly through an enemy fleet, would still be preferred to sitting motionless for all of eternity and is how their logic would guide them if I'm reading the changes list correctly but this was a full 360 degree scatter and definitely not a refuel order.

You can also see this sometimes with the NPR logic around jump points, as it is one reason that NPRs jump back and forth endlessly due to the circular logic of (1) "I am in System A and I need fuel, I must jump into System B!" and (2) "I am in System B and it has a high danger rating, I must escape by jumping into System A!".

One of my cloaked, passive-only survey ships spent part of the evening watching a swarm medium hive mindlessly do this and those don't even have fuel tanks so I agree that there's more than just refueling logic in play there. However, given the way it's written in the changes list I'm not sure this would apply to 100% empty NPR fuel tanks.

[Steve Walmsley (OP)]

The "run away" part of the NPR code tends to supersede the "find fuel" part, admittedly for obvious reasons as it would be rather silly for the NPR to barrel its FACs into the teeth of your fleet just because this is a direct path towards fuel.

But if they're out of fuel they shouldn't have access to the "run away" part of their code at all, at least as it's explained in the changes list: "unable to do anything except search for refuelling options." Heading home for fuel, even if it risks going directly through an enemy fleet, would still be preferred to sitting motionless for all of eternity and is how their logic would guide them if I'm reading the changes list correctly but this was a full 360 degree scatter and definitely not a refuel order.

Rather than spend weeks writing AI code than uses extra processing power to assess every decision differently based on fuel state (something humans do easily, but AI does not because of the complexity of factors involved), most of which would be completely invisible to the player anyway, the AI ignores fuel until it runs out, then heads to refuel. If it is forced to run, that takes precedence. Otherwise the AI would be back to assessing fuel state constantly in case it needs to run. There is no penalty for empty tanks for the same reason.

[Oloof22]

By mistake I tried to tow a ship that was in Overhaul.  Result is the towed ship is now stuck in a random point in orbit, can't move and Deployment and maintenance timers are going up.  Also it would be nice to have a clear indicator to differentiate if a ship is actually towed or just in the same fleet.

[Steve Walmsley (OP)]

By mistake I tried to tow a ship that was in Overhaul.  Result is the towed ship is now stuck in a random point in orbit, can't move and Deployment and maintenance timers are going up.  Also it would be nice to have a clear indicator to differentiate if a ship is actually towed or just in the same fleet.

Take the ship out of overhaul - then tow it.

[pedter]

I lost track of a spoiler fleet thoroughly enough to resort to finding it in the DB. It turns out the fleet has been fleeing directly away for more than five years despite not being aware of any enemies and being fully alone in the system for approximately two of those years. I've been aware of it for awhile but wanted to see if it ever corrected its behavior; nothing has updated and there are no far-flung system bodies for it to be heading to. I've also spotted 15 single-FAC fleets from an NPR that have been fleeing for months despite being the only fleets in the system after I jump in on top of them and promptly jumped back out. Presumably a fleet that flees should periodically check to see if it still has any hostile contacts so that it doesn't render itself functionally self-destructed due to extreme range.

I've attached a screenshot of some of the DB values to showcase just how far a couple of the hostile fleets (in red) have fled from their origination location where my own fleets (in green) are now stationed. I had to add thousands separators to make some of the values readable.

Info dump:
- No function number or error text
- Conventional start
- Real stars
- US decimal and time formats (I have not reconfigured for UK standards)
- Approximately 80 years into the campaign
- Campaign started and running on v2.5.1

[Oafsalot]

The Standing Order: Build Jumpgate at Nearest Jump Point still overrides the Exclude Alien Controlled tick box. Stabilization Ships will enter flagged systems.

I thought this one was fixed already, but apparently not.

[pedter]

Sorting ships of a class by fuel within the Class Design window does not sort ships by fuel amount; it appears to update nothing. I suspect it is attempting to sort by maximum fuel capacity instead of current fuel in tanks, resulting in no change of vessel order regardless of current order as all vessels of a given class have identical capacity by definition unless damaged. The attached screenshot has a blue border around the Fuel button (as it has most recently been clicked) but retains the prior System Name sort anyway.

All other sorts appear to be working as intended, as least as tested by alternating with a System Name sort to provide a pseudo-randomized vessel order before each test.

Info dump
- No function number or error text
- Class Design window, Ships in Class tab
- Conventional start
- Real stars
- US decimal and time formats (I have not reconfigured for UK standards)
- Approximately 80 years into the campaign
- Campaign started and running on v2.5.1

[paolot]

In the Commanders window, after some assignments, in the dropdown at the left high corner of the window, I selected again the "Player Race" to update the names of the available officers.
The names (in the lists on the left and on the right of the window) updated.
But, even if the four dropdowns of the abilities all turned into "Crew Training", I think the shown numbers are related to the previous selection of the abilities.
I don't know if this is WIA (and I don't remember if it was already noted): I feel it as misleading.
Thanks!!

[pedter]

Plasma Carronade tech appears to contain as least one bug with the RP cost of the final research level (it costs 12m RP instead of what I imagine was intended as 1200k RP) and I'll drop it here in bugs because it changes gameplay rather than just readability. There are two other potential errors worth mentioning just in case they require correction but at least one of them may be better suited in the typos thread.

The final five tech levels and costs for v2.5.1 are as follows:
"50cm" at 125,000 RP
"60cm" at 250,000 RP
"70cm" at 300,000 RP
"80cm" at 600,000 RP
"100 cm" at 12,000,000 RP

I presume 12,000,000 RP for the final level is an error from an intended cost of 1,200,000 RP.

For what it's worth, the step up from 60cm to 70cm only increases in cost from 250k to 300k; I would have guessed that this step would have gone from 250k to 500k, leading to costs of 1m for 80cm and 2m for 100cm, but the lower costs may be by design. Additionally, the final tech level is named "100 cm" with a space rather than "100cm" without a space to keep with convention.

SJW: Fixed for v2.6.0

[pbhead]

I would like to confirm the bug report about CWIS not hitting properly.  Save game attached.

I quadruple checked I was on 2. 5. 1   EXE file was created on jan 25.  the day the 2. 5. 1 update was posted.

The function number -none
The complete error text -none
The window affected -event log?
What you were doing at the time - getting my ass kicked by NPRs
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? Other guy in the thread had it too.
If this is a long campaign - say 75 years or longer  ~60 years so far.

[pedter]

Ran into an error with the "Autoroute by System" option within the Naval Organization window that appears to be repeatable as many times as I try it. It does not appear to break anything else further.

Steps to reproduce:
- Select the "Autoroute by System" option with a fleet selected and double-click any destination to add the route to the fleet's orders
- With the route to the destination still set as the fleet's orders, select "Autoroute by System" again
- "Remove All" orders from the fleet; this resets the available order selection to "System Locations" but leaves "Autoroute by System" selected
- Double-click any jump-point option with "Autoroute by System" still selected to attempt to add a standard transit order to the fleet's order list; this throws the error

Info dump:
- 2.5.1 Function #3210: Unable to cast object of type 'hg' to type 'jh'.
- Naval Organization window
- Conventional start
- Real stars
- US decimal and time formats (I have not reconfigured for UK standards)
- Approximately 80 years into the campaign
- Campaign started and running on v2.5.1

[nuclearslurpee]

Ran into an error with the "Autoroute by System" option within the Naval Organization window that appears to be repeatable as many times as I try it. It does not appear to break anything else further.

Steps to reproduce:
- Select the "Autoroute by System" option with a fleet selected and double-click any destination to add the route to the fleet's orders
- With the route to the destination still set as the fleet's orders, select "Autoroute by System" again
- "Remove All" orders from the fleet; this resets the available order selection to "System Locations" but leaves "Autoroute by System" selected
- Double-click any jump-point option with "Autoroute by System" still selected to attempt to add a standard transit order to the fleet's order list; this throws the error

Info dump:
- 2.5.1 Function #3210: Unable to cast object of type 'hg' to type 'jh'.
- Naval Organization window
- Conventional start
- Real stars
- US decimal and time formats (I have not reconfigured for UK standards)
- Approximately 80 years into the campaign
- Campaign started and running on v2.5.1

I think this happens because the Orders pane doesn't correctly update the fleet location for order-giving purposes when orders are removed. You see something similar happen in other cases when orders are removed but the game still thinks the fleet is or will be in that system. Fix is usually to refresh that window somehow to force an update, so I'd imagine that the bug fix is simply to force that update after removing orders.

[AlStar]

Not a major issue, but the tonnage displayed by wrecks doesn't seem to use the same rounding logic that the ship design screen uses.

You can see it on my post here: https://aurora2.pentarch.org/index.php?topic=11100.msg168848#msg168848, where a number of my ships are listed as #,999 tons.

SJW: Fixed for v2.6.0