v1.13.0 Bugs Thread

[db48x]

Plus the wealth display in the title bar is quite misleading at the best of times; it is rarely correct to rely on it to tell you whether you are gaining or losing money, or how much. The only thing you can rely on is your current wealth and maybe the yearly/quarterly/monthly summaries in the wealth tab. I reported this in the past but as far as I recall Steve never acknowledged the problem.

SJW: Replaced by a new wealth history section

[Marski]

NPR's in multi-NPR-earth-start do not follow truce countdown and WILL declare war as soon as the diplomatic relations decrease to around 500.

[jamac41]

Issue: Calendar freezes on the 1000th year of a save.
Replication: 1: Start a new save, preferably with no hostile entities or NPRs to allow you to reach 1000 years in a reasonable time.
1. 5: To save some hassle, use Spacemaster mode to delete your research labs.
2: Let the save run for 999 years and 5 months.
3: Observe the date no longer advancing past 04/05 on the 1000th year of the save.

An issue noticed on my main 1. 12 save and replicated on a 1. 13 save: starting from 2025, the date stops increasing after midnight on the 4th May 3024.  I have yet to identify any other negative effects.  1. 13 Database is attached.

[M_Gargantua]

The function number: #2186
The complete error text: 1. 13. 0 Function #2186: Attempted to divide by zero.
The window affected: Economics
What you were doing at the time: Anytime you open the window for Konor-A VIII - Moon 4 in the attached . db
Conventional or TN start: Conventional
Random or Real Stars: Random
Is your decimal separator a comma? Decimal
[snip/see below]
If this is a long campaign: 114 years

Is the bug is easy to reproduce, intermittent or a one-off?

I've been able to partially reproduce and track down the bug. 

What happened in this campaign is that continuous colonization of Konor-A VIII - Moon 4 (A massive moon with a 5. 65 colony cost) reduced the manufacturing % of population until the total number of manufacturing population dropped to zero.  Then Manufacturing goes to 0%/0mand the efficiency modifier also goes to 0%, and then the game kept ticking on until some months/years later I noticed it causing the divide by zero error only when clicking on it on the economics screen.

When I discovered the bug the planet had 230m on it, as I've left it on destination for decades and the civilian shipping keeps delivering infrastructure and people.  Using SM mode the most Manufacturing seems to be 10. 84m with a population of around 80m, and the availability drops slowly off to 0m as you get to 198. 3m

Attached is a backup from 166 without the issue, and a 169 with it to show how it developed.

I wasn't able to get a divide by zero error in a test world even with adding similar economic buildings.  But in the . db you can adjust the population such that 200m causes the divide by zero and 190m does not.  Maybe something on the maintenance or civilian side.

Expected behavior: If it does happen it should catch the error before the divide by zero.  But maybe a working as intended but i'd kinda expect manufacturing population to be a plateau of a decreasing % beyond a point, not drop off to zero entirely in the first place.

[nuclearslurpee]

I wasn't able to get a divide by zero error in a test world even with adding similar economic buildings.  But in the . db you can adjust the population such that 200m causes the divide by zero and 190m does not.  Maybe something on the maintenance or civilian side.

If you refer to the formulae in this very useful mechanics post about population efficiency, I suspect you'll be able to compute and confirm that the breaking point is just shy of 198m population. This is the point at which the sum of agricultural worker fraction (5% + 5% * colony cost) and service worker fraction (17.75% * pop in millions ^ 0.2505) exceeds 100%, which I suspect is what causes the error as this means manufacturing population fraction would be less than 0% beyond this point.

Expected behavior: If it does happen it should catch the error before the divide by zero.  But maybe a working as intended but i'd kinda expect manufacturing population to be a plateau of a decreasing % beyond a point, not drop off to zero entirely in the first place.

Yes, the bug is that no error should be thrown as this event is allowed by the game mechanics. The fix would be: either the service worker fraction should be capped at the lesser of [70%, 100% - agricultural%] or the error should be quietly discarded.

By the way, the behavior you are expecting occurs for planets with CC < 5.0, as there is a local maximum for manufacturing population (not fraction), then a decrease, then a linear increase after ~240m pop due to saturation of the service sector at 70%. For CC >= 5.0, the agricultural fraction is 30% or greater, so once the service worker fraction reaches the max of 70% (or less) no manufacturing population exists.

[nakorkren]

Very small sensor ships don't display their (fairly small) passive sensor radii correctly. Other larger ships in the same area with larger sensors display correctly. I don't know whether it's the size of the sensor or the size of the ship that causes the issue. Here is the ship displayed below. I can turn on and off the display of active sensors, passive sensors, weapons and fire controls, and all of that works as intended for nearby ships that are larger. Yes, I \tried zooming both in and out; I can see the fire control range of another ship which is smaller and the passive sensor range which is larger.

Ship design below:

FS Seventh Winter 008  (Seventh Winter class Scout Fighter)      49 tons       1 Crew       8.8 BP       TCS 1    TH 3    EM 0
3829 km/s      Armour 1-1       Shields 0-0       HTK 1      Sensors 0/0/0/0      DCR 0      PPV 0
Maint Life 12.25 Years     MSP 10    AFR 10%    IFR 0.1%    1YR 0    5YR 2    Max Repair 10 MSP
Lieutenant Commander    Control Rating 1   
Intended Deployment Time: 8 months    Morale Check Required   

Ion Drive  EP3.75 (1)    Power 3.8    Fuel Use 62.35%    Signature 2.8125    Explosion 6%
Fuel Capacity 5,000 Litres    Range 29.5 billion km (89 days at full power)

Thermal Sensor TH0.1-0.8 (1)     Sensitivity 0.8     Detect Sig Strength 1000:  7.1m km
EM Sensor EM0.1-0.8 (1)     Sensitivity 0.8     Detect Sig Strength 1000:  7.1m km

This design is classed as a Fighter for production, combat and planetary interaction
This design is classed as a a for auto-assignment purposes

SJW: Fixed for v2.0

[boolybooly]

Just adding a link to a bug report recently reported in the C# bug subforum, for convenience.

"Start build points not given to conventional non-TN player race v1130."
http://aurora2.pentarch.org/index.php?topic=12961.msg159762#msg159762

SJW: Fixed for v2.0

[Vandermeer]

Very small sensor ships don't display their (fairly small) passive sensor radii correctly. Other larger ships in the same area with larger sensors display correctly. I don't know whether it's the size of the sensor or the size of the ship that causes the issue. Here is the ship displayed below. I can turn on and off the display of active sensors, passive sensors, weapons and fire controls, and all of that works as intended for nearby ships that are larger. Yes, I \tried zooming both in and out; I can see the fire control range of another ship which is smaller and the passive sensor range which is larger.

Ship design below:

FS Seventh Winter 008  (Seventh Winter class Scout Fighter)      49 tons       1 Crew       8.8 BP       TCS 1    TH 3    EM 0
3829 km/s      Armour 1-1       Shields 0-0       HTK 1      Sensors 0/0/0/0      DCR 0      PPV 0
Maint Life 12.25 Years     MSP 10    AFR 10%    IFR 0.1%    1YR 0    5YR 2    Max Repair 10 MSP
Lieutenant Commander    Control Rating 1   
Intended Deployment Time: 8 months    Morale Check Required   

Ion Drive  EP3.75 (1)    Power 3.8    Fuel Use 62.35%    Signature 2.8125    Explosion 6%
Fuel Capacity 5,000 Litres    Range 29.5 billion km (89 days at full power)

Thermal Sensor TH0.1-0.8 (1)     Sensitivity 0.8     Detect Sig Strength 1000:  7.1m km
EM Sensor EM0.1-0.8 (1)     Sensitivity 0.8     Detect Sig Strength 1000:  7.1m km

This design is classed as a Fighter for production, combat and planetary interaction
This design is classed as a a for auto-assignment purposes

Though I am not entirely sure, it could be that the real sensor value always gets rounded down to the next natural number. I faced this recently as well and only got a workable design with a 1.1, thus larger than 1 sensor value.

[skoormit]

Possible bug with missile to-hit chances against tiny unarmored station.

I had a fleet with one small ship (2250t) tugging a tiny unarmored station (121t) at 1678 km/s.
I received incoming fire from missiles moving 71.4k km/s.
Each wave was two salvos of five missiles each, with one salvo targeting each ship.
Each time, the tug was hit five times, while the tiny station was not hit ("...attacked by missiles. Damage per Hit 1    No hits") until the eighth wave.

The tug was destroyed by the fifth wave.

The tiny station was not hit until the eighth wave, which scored one hit.
Overall, that's a 2.5% hit rate against a 1km/s target with no countermeasures.

I saved the game at this point, because I plan to self-destruct the tiny station.
Save attached below.

SJW: Fixed for v2.0

[nuclearslurpee]

I believe this is a known bug about tugged ships, as for some reason tugged ships have their speed set to the maximum value which makes them almost impossible to hit with weapons, and this doesn't seem to be reset properly in such cases.

[Marv]

I have an individual ship which reports having 0. 4 of a cargo shuttle station in the transported items tab, but when I look at the fleet, it reports only having 0. 2 of a cargo shuttle station.  This should be impossible, obviously, since an individual ship can't carry more than the fleet is carrying as a whole, unless another ship is carrying negative cargo, but setting aside the silliness of negative cargo, this is the only ship in the fleet.

I've noticed a few times that the Transported tab reports stuff twice.

Also for me (1. 13, no mods, good ole' british separators) the "Transported items" tab for a ship reports twice the values as the "Transported items" in the fleet tabs.
Please, is this logged already for correction?

SJW: Fixed for v2.20

[boolybooly]

Noticed today that setting an amount to unload colonists does not apply. It registers in the order text but all the colonists are unloaded.

Only load colonist applies the number set with the order.

e.g. Freighter fleet carrying 300,000 in cryo ordered to unload 120,000 unloads all 300,000. When ordered to load 185,000 it does so just fine and leaves 115,000 behind.

Not sure if this is intended/bug or already reported but thought it better to report it.

SJW: Not really a bug - I just haven't got around to adding this function yet.

[dlathro1]

The missile designer allows you to enter negative values for warhead strength, fuel, etc.

This can be abused by setting one of the sensors to a ridiculous negative value (say -1000), packing the missile with a ridiculous sized warhead, engine, and fuel tank and still get a missile of size 1.

The game then allows you to research the missile (often at a negative RP value to boot!), but unfortunately, or fortunately, depending on your point of view, when you try and build them in the Industry tab, no progress is made.

SJW: Fixed for v2.0

[Droll]

The missile designer allows you to enter negative values for warhead strength, fuel, etc.

This can be abused by setting one of the sensors to a ridiculous negative value (say -1000), packing the missile with a ridiculous sized warhead, engine, and fuel tank and still get a missile of size 1.

The game then allows you to research the missile (often at a negative RP value to boot!), but unfortunately, or fortunately, depending on your point of view, when you try and build them in the Industry tab, no progress is made.

The bug, in its confusion, fixed itself.

It's probably because the missile had negative cost, at which point the game didn't know how to finish the industry project. You might be able to balance it in a way that still lets you make scuffed and broken missiles.

[Vandermeer]

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.

Visual proofs:
1. Gained 30cm laser and soft-xray technology, but registered as 20cm laser, and not sure about the spectrum gains, since this was researched somewhere else at the time.


2. Even better to see. Picked apart magnetic fusion I found in Invaders but you can easily calculate that it all went to stellerator goofball-yuppi fusion.


Practically it makes no difference, so this is blending the line to a mere typo bug. Maybe it isn't even that, since you could also read the line as "gained xx research points towards [end-direction tech]", though that is straining the intuitive speech understanding, which is why I would vote to change this in some way nonetheless.

SJW: Fixed for v2.0