v1.13.0 Bugs Thread

[skoormit]

Max Repair value seems to account for armor cost.

Here is a small orbital defense platform of mine:

Code: [Select]

Spit class Orbital Defence Platform      478 tons       3 Crew       46.8 BP       TCS 10    TH 0    EM 0
1 km/s      Armour 1-5       Shields 0-0       HTK 0      Sensors 0/0/0/0      DCR 0      PPV 7.5
Maint Life 7.54 Years     MSP 6    AFR 18%    IFR 0.3%    1YR 0    5YR 3    Max Repair 6 MSP
Magazine 50   
Lieutenant Commander    Control Rating 1   
Intended Deployment Time: 8.7 days    Morale Check Required   


Size 1 Box Launcher (50)     Missile Size: 1    Hangar Reload 50 minutes    MF Reload 8 hours
Missile Fire Control FC5.6-R1 (2)     Range 5.6m km    Resolution 1
AdderB AMM 4.18mkm 18.7% (50)    Speed: 10,400 km/s    End: 6.7m     Range: 4.2m km    WH: 1    Size: 1    TH: 62/37/18
Here is the exact same design after an armor upgrade from High Density Duranium to Ceramic Composite:

Code: [Select]

Spit - Copy class Orbital Defence Platform      466 tons       3 Crew       46.7 BP       TCS 9    TH 0    EM 0
1 km/s      Armour 1-5       Shields 0-0       HTK 0      Sensors 0/0/0/0      DCR 0      PPV 7.5
Maint Life 7.75 Years     MSP 6    AFR 17%    IFR 0.2%    1YR 0    5YR 3   Max Repair 8 MSP
Magazine 50   
Lieutenant Commander    Control Rating 1   
Intended Deployment Time: 8.7 days    Morale Check Required   


Size 1 Box Launcher (50)     Missile Size: 1    Hangar Reload 50 minutes    MF Reload 8 hours
Missile Fire Control FC5.6-R1 (2)     Range 5.6m km    Resolution 1
AdderB AMM 4.18mkm 18.7% (50)    Speed: 10,400 km/s    End: 6.7m     Range: 4.2m km    WH: 1    Size: 1    TH: 62/37/18

The Max Repair value on the first one is 6MSP, but on the second one is 8MSP.
The components are the same on both designs, and there is no component with a cost of 6 or 8.
However, the armor on the first one costs 6 MSP per HS, while the armor on the first one costs 8 MSP per HS.
Neither design actually contains a full HS of armor. The first one has 0.91HS, the second has 0.67HS.
But that shouldn't matter, since a ship can't repair its own armor with MSP anyway.

SJW: Fixed for v.2.0

[Steve Walmsley (OP)]

It was posted here relatively recently, so maybe this was fixed already, but I have also come across the 'misnamed salvage gains' bug. In this bug you disassemble a component that is at least 2 tech levels beyond your current standard, and it will display tech point gain towards the highest level, while actually giving it to the current one. E.g.: If you have ECM-1 technology but get to pick apart a ECM-3 device, it will say "120 tech points to ECM-3", but you actually get 120 towards ECM-2.

I've changed the text so you are informed which tech you gain points toward and, if different, the tech from which those points originated.

[dlathro1]

The 1.25x size, 1.25x range option on the beam fire control acts like a 0.25x size, 0.25x range option.

[xenoscepter]

The 1.25x size, 1.25x range option on the beam fire control acts like a 0.25x size, 0.25x range option.

 --- What version are you on? That's listed int he 1.13 Changes List under fixes and I just booted up to test this and my 1,25 x / 1.25x FCS gives the advertised 125% increase...

[xenoscepter]

--- This is from a 1.13 game; a fighter sized Colony Ship:


--- The ship prior to a simple load at Terra, Unload at Luna Order:


--- After unloading at Luna.





--- After 10 more Load / Unload orders:



 --- It seems Fighter Colonist Load / Unload orders are still quite bugged. I'd appreciate them being fxed.

[dlathro1]

The 1.25x size, 1.25x range option on the beam fire control acts like a 0.25x size, 0.25x range option.

 --- What version are you on? That's listed in the 1.13 Changes List under fixes and I just booted up to test this and my 1,25 x / 1.25x FCS gives the advertised 125% increase...

I must have missed that particular fix in the list.

[skoormit]

I have constructed 13 of the following design in my game:

Code: [Select]

Tote2 class Carrier      2,136 tons       39 Crew       245.8 BP       TCS 43    TH 0    EM 0
1 km/s      Armour 1-14       Shields 0-0       HTK 12      Sensors 0/0/0/0      DCR 2      PPV 0
Maint Life 10.41 Years     MSP 179    AFR 15%    IFR 0.2%    1YR 3    5YR 45    Max Repair 25 MSP
Hangar Deck Capacity 1,650 tons     
Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Flight Crew Berths 33    Morale Check Required   


This design is classed as a Military Vessel for maintenance purposes
This design is classed as a b for auto-assignment purposes

The first one was built 23 years ago.
The design was obsoleted 10 years ago.
So I built roughly one per year during that window.

Three of the 13 ships suffered catastrophic failure and exploded.
Does anyone have any idea why?

The most recent ship exploded when its maint clock was at 0.5 years.
It had 100% MSP on board at the time (179, with a Max Repair of 25), and no damaged components.

The components:
Amt  Component                                DAC%
6      Boat Bay                                    74.4
3      Boat Bay - Small                         9.3
2      Engineering Spaces                   4.7
2      Crew Quarters                           4.7
1      Engineering Spaces - Small       2.3
1      Crew Quarters - Tiny                 2.3
1      Bridge                                        2.3
2.46 High Density Duranium Armor      -


EDIT:
Could it be this bug?
The bridge and the boat bays are marked as NoMaintFailure in the DB.
That's 86% of the DAC.
Which means hitting one of those 20 times in a row would be a ~4.9% chance.
Given a nominal AFR of 15%, and approximately 13 * 16 = 208 ship years the design has been in use, one would expect approx 208 * 15% = ~31 maint failures, multiplied by the average maint life of the ships over time (to account for AFR being multiplied by years since overhaul).
31 maint failures at 4.9% chance to cause catastrophic failure yields about 1.5 expected explosions.
These ships often spend several years between overhauls. Of the current ships, the average maint time at present is about 2.5 years. So 3 explosions would seem to just represent an AFR multiple of 2. A perfectly cromulent expectation.

SJW: Fixed for v2.0

[somebody1212]

I have constructed 13 of the following design in my game:

Code: [Select]

Tote2 class Carrier      2,136 tons       39 Crew       245.8 BP       TCS 43    TH 0    EM 0
1 km/s      Armour 1-14       Shields 0-0       HTK 12      Sensors 0/0/0/0      DCR 2      PPV 0
Maint Life 10.41 Years     MSP 179    AFR 15%    IFR 0.2%    1YR 3    5YR 45    Max Repair 25 MSP
Hangar Deck Capacity 1,650 tons     
Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Flight Crew Berths 33    Morale Check Required   


This design is classed as a Military Vessel for maintenance purposes
This design is classed as a b for auto-assignment purposes

The first one was built 23 years ago.
The design was obsoleted 10 years ago.
So I built roughly one per year during that window.

Three of the 13 ships suffered catastrophic failure and exploded.
Does anyone have any idea why?

The most recent ship exploded when its maint clock was at 0.5 years.
It had 100% MSP on board at the time (179, with a Max Repair of 25), and no damaged components.

The components:
Amt  Component                                DAC%
6      Boat Bay                                    74.4
3      Boat Bay - Small                         9.3
2      Engineering Spaces                   4.7
2      Crew Quarters                           4.7
1      Engineering Spaces - Small       2.3
1      Crew Quarters - Tiny                 2.3
1      Bridge                                        2.3
2.46 High Density Duranium Armor      -


EDIT:
Could it be this bug?
The bridge and the boat bays are marked as NoMaintFailure in the DB.
That's 86% of the DAC.
Which means hitting one of those 20 times in a row would be a ~4.9% chance.
Given a nominal AFR of 15%, and approximately 13 * 16 = 208 ship years the design has been in use, one would expect approx 208 * 15% = ~31 maint failures, multiplied by the average maint life of the ships over time (to account for AFR being multiplied by years since overhaul).
31 maint failures at 4.9% chance to cause catastrophic failure yields about 1.5 expected explosions.
These ships often spend several years between overhauls. Of the current ships, the average maint time at present is about 2.5 years. So 3 explosions would seem to just represent an AFR multiple of 2. A perfectly cromulent expectation.

The Discord's got together and done some testing on this - appears to be the same bug as in 1.11, being applied to fuel tanks, hangars and bridges since these cannot suffer maintenance failures. It'd also apply to anything I've missed which also does not suffer maintenance failures.

Testing with 1000 ships with 19.4% IFR and 95.4% fuel storage on the DAC, these are the failures per increment:
2 regular, 5 catastrophic
5 regular, 3 catastrophic
3 regular, 4 catastrophic
9 regular, 3 catastrophic
9 regular, 5 catastrophic
5 regular, 5 catastrophic
13 regular, 10 catastrophic
10 regular, 12 catastrophic
16 regular, 9 catastrophic
17 regular, 6 catastrophic

SJW: Fixed for v2.0

[skoormit]

No line for Forced Labour Mining Camp in Mining Modifiers panel.

The colony in the attached screenshot has 7 Forced Labour Mining Camps.
The Mineral Data shows that the camps are mining correctly, and appear to be receiving appropriate bonuses (e.g. 12 base * 1.05 governor * 0.9 acc = 79.38).
However, the Mining Modifiers panel lists no mining sources.

SJW: Fixed for v2.0

[somebody1212]

Looks like the VB6 tug trains bug is back:

Two of these tugs:

Code: [Select]

Righteous Fist class Ammunition Transport      2 755 tons       65 Crew       426.5 BP       TCS 55    TH 400    EM 0
7261 km/s      Armour 1-17       Shields 0-0       HTK 27      Sensors 0/0/0/0      DCR 5      PPV 0
Maint Life 7.90 Years     MSP 483    AFR 12%    IFR 0.2%    1YR 14    5YR 206    Max Repair 200.00 MSP
Tractor Beam     
Squire    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

Magneto-plasma Drive  EP400.00 (1)    Power 400.0    Fuel Use 63.25%    Signature 400.00    Explosion 10%
Fuel Capacity 500 000 Litres    Range 51.7 billion km (82 days at full power)

This design is classed as a Military Vessel for maintenance purposes
can tug one of these cargo pods:

Code: [Select]

Glorious Heritage class Ammunition Transport      10 028 942 tons       2 010 Crew       24 754.7 BP       TCS 200 579    TH 0    EM 0
1 km/s      Armour 1-4142       Shields 0-0       HTK 460      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 1    Max Repair 50 MSP
Cargo 10 000 000   
Squire    Control Rating 1   BRG   
Intended Deployment Time: 3 months   

Fuel Capacity 50 000 Litres    Range N/A

This design is classed as a Commercial Vessel for maintenance purposes
at their full speed of 7261 km/s.

Steps to reproduce:

1. Build or SM-spawn two tugs and a payload ship.
2. Split them into separate fleets.
3. Order one of the tugs to tractor the payload.
4. Order the other tug to tractor the first tug.
5. Give the combined fleet a move order.
6. Observe that the fleet moves at the full speed of the tugs, without being slowed down by the payload.

More generally, with Ship A tractoring Ship B tractoring Ship C, etc, the fleet moves at the speed of Ship A tractoring Ship B and ignores ships C and below. If both A and B are high-engine-fraction tugs, this allows you to move large, engineless cargo pods significantly faster than you would otherwise be able to.

Additional bug discovered while testing this: If a tug is destroyed while tractoring an engineless ship, the ship being tractored will now move at 300k km/s.

Final bonus bug discovered while verifying the previous bug: If you SM-damage a ship and destroy it, and then continue to SM-damage it (easy to do since the screen does not update after doing damage so if you're not rigorous about hitting the Refresh button after every damage step it'll happen eventually), it will spawn multiple wrecks. If the ship is tugging another ship at the time, the payload ship will be deleted.

[nuclearslurpee]

Weird little bug here, with hopefully an easy fix.

I had a pair of heavily-shielded ships which were attacked by a wave of missiles during a 20-minute increment. Each ship is a battlecruiser with six size-20 Delta shield generators, total strength 426 with recharge rate 2.5 (total 300 recharge per 5 min). The missiles did 162 damage to one of the battlecruisers, reducing its shields to 62%, however the ship showed 100% shields in the naval organization window in both the ship and fleet views.

I believe what happened is that the missiles did damage, and then the shields recharged based on the length of the sub-increment. I'm not sure what the sub-pulse length is for 20-minute increments, but with the shields I have on these ships 162 damage could be regenerated in 2m 45s, so I'd guess at least a four-minute sub-pulse. For what it's worth, in the ensuing battle with 5-second increments the shield damage displayed as expected, albeit often with 1% less damage than shown in the combat events due to the few points of recharge during a 5-second increment.

If I am correct, my suggested fix would be to have shield recharge occur prior to damage allocation rather than after, so that damage displayed after a sub-pulse matches the combat logs. This shouldn't have any impact on combat balance, since either way a recharge cycle will occur between weapon/missile damage resolution steps. On the other hand, if it doesn't affect balance this is hardly an urgent bug to fix, as it is just reconciling the visual information more consistently.

SJW: Fixed for v2.0

[nakorkren]

Small passive sensors (EM or thermal) with sensitivity <1.0 do not display on the map. I was able to prove this by spacemastering in a sensor with 1.1 sensitivity and the sensor range now shows, with no other change. Spacemaster it out, sensor range disappears from the map despite still having a sensor with 0.8 sensitivity. Doesn't seem to matter if it's thermal or EM, haven't tried with an active sensor.

EDIT 2022-05-21: updated to note that the issue was observed with EM and thermal sensors.

SJW: Fixed for v2.0

[skoormit]

...Doesn't seem to matter if it's thermal or EM, haven't tried with an active sensor.

Active sensors with less than 1.0 sensitivity are not possible (without modding the db). The smallest possible active sensor with the starting tech has sensitivity 1.0.

[Youngbloodclaw]

Heyo, Just Came back to the game after a year away and Trying 1. 13. 0
Trying to create a new game and getting a Error on the "Create new race" screen. 

Function #2574: Value was either too large or too small for an Int32

Tried various Option, checked and made sure i didnt have Comma's in stead of full stops any where and no luck. 

Any one have any suggestions?

SJW: Changed it to a decimal to avoid issue in future.

[Youngbloodclaw]

Heyo, Just Came back to the game after a year away and Trying 1.  13.  0
Trying to create a new game and getting a Error on the "Create new race" screen.   

Function #2574: Value was either too large or too small for an Int32

Tried various Option, checked and made sure i didnt have Comma's in stead of full stops any where and no luck.   

Any one have any suggestions?

Never mind, the Fuel amount had too many zero's, Was my own fault.