v1.13.0 Bugs Thread

[IanD]

I don't know whether this is working as intended but my Survey Cruiser will not squadron jump when on its own. ship design shown below. I cannot see any obvious error. The jump point is stabilized both sides.

Code: [Select]

Planet class Survey Cruiser      29,076 tons       778 Crew       16,150.6 BP       TCS 582    TH 422    EM 7,110
9079 km/s    JR 3-500      Armour 7-84       Shields 237-355       HTK 174      Sensors 14/14/6/4      DCR 20      PPV 58
Maint Life 2.07 Years     MSP 6,943    AFR 338%    IFR 4.7%    1YR 2,157    5YR 32,362    Max Repair 2400 MSP
Commander    Control Rating 2   BRG   SCI   
Intended Deployment Time: 24 months    Morale Check Required   

J29250(3-500) Military Jump Drive     Max Ship Size 29250 tons    Distance 500k km     Squadron Size 3

Inertial Fusion Drive  EP880.00 (6)    Power 5280    Fuel Use 20.07%    Signature 70.40    Explosion 11%
Fuel Capacity 5,100,000 Litres    Range 157.3 billion km (200 days at full power)
Omicron S237 / R355 Shields (1)     Recharge Time 355 seconds (0.7 per second)

Particle Beam-12 (2)    Range 800,000km     TS: 9,079 km/s     Power 30-10    ROF 15       
Particle Beam-9 (2)    Range 800,000km     TS: 9,079 km/s     Power 22-11    ROF 10       
12cm Railgun V50/C6 (4x4)    Range 100,000km     TS: 9,079 km/s     Power 6-6     RM 50,000 km    ROF 5       
CIWS-320 (1x12)    Range 1000 km     TS: 32,000 km/s     ROF 5       
Beam Fire Control R800-TS6250 (2)     Max Range: 800,000 km   TS: 6,250 km/s     99 98 96 95 94 92 91 90 89 88
Beam Fire Control R100-TS8000 (2)     Max Range: 100,000 km   TS: 8,000 km/s     90 80 70 60 50 40 30 20 10 0
Solid-core Anti-matter Power Plant R67 (1)     Total Power Output 67.1    Exp 5%

Active Search Sensor AS544-R100 (1)     GPS 240000     Range 544.3m km    Resolution 100
Active Search Sensor AS37-R1 (1)     GPS 240     Range 37.1m km    MCR 3.3m km    Resolution 1
EM Sensor EM1.0-14.0 (1)     Sensitivity 14     Detect Sig Strength 1000:  29.6m km
Thermal Sensor TH1.0-14.0 (1)     Sensitivity 14     Detect Sig Strength 1000:  29.6m km
Improved Geological Sensors (2)   4 Survey Points Per Hour
Improved Gravitational Sensors (3)   6 Survey Points Per Hour

Compact ECCM-5 (2)         ECM 70

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


After building two more of the class Squadron Transits worked. Does crew training/experience affect the ability to perform Squadron Jumps?

[M_Gargantua]

I found a bug that allows for unit duplication in ground forces, and it doesn't seem to cause a DB corruption.  You can transfer more units between formations than exist.  Expected behavior is that the amount popup doesn't let you transfer more units than you have.

No mods, period decimal separator

To reproduce:
On the Ground Forces Screen:
After clicking the "Show Elements" and "Amount Popup" checkboxes to move units between formations
Move something, and when prompted set the number higher than the number of units in the formation
The remaining formation will have a negative number of those units, and the negative values will propagate to Size, HP, etc.  The formation that received the units will have the full amount transferred.  This negative number unit can be used to further transfer units.
If you transfer enough units that the result will be >0 then the issue self clears, but if you transfer exactly the number of negative units you get a "Function #1859 Attempted to divide by zero. " Error.
If you turn off "amount popup" and drag the entire negative formation to another formation it will remove the negative unit and subtract them from the formation they arrive in.

This bug then creates an exploit on the ground unit screen to infinitely duplicate units, and from my testing as long as you delete any formations with a negative unit count before advancing time I haven't yet found any errors that propagate from this.  Should be an easy fix in 1. 14 I hope?

SJW: Fixed for v2.0

[Ragnarsson]

EDITED: While this happened in one game, I couldn't reproduce it in the future, so I'll retract it unless / until I can find a reliable reproduction.

When disassembling a piece of technology more advanced than your own in order to gain research points into the fields associated with the technology, the points do not seem to apply if you are actively researching the relevant technology.   

For example, in my current game I was researching Salvage Module 500.   I had 402 research points remaining when I dug up 2 abandoned Salvage Module 500's from a ruin.   I disassembled the modules, receiving event notifications that 250 and 50 research points, respectively, were gained from the disassembled modules.   However, my RP remaining to complete the research project stayed at 402 and appeared to gain me nothing. 

[Rince Wind]

Maybe I am overlooking something, but it seems I have "lost" a few ships to a bug.
I am using survey parasites and I tried to cut on the micromanagement by detaching 1 and then putting 2 others from the carrier in the same fleet, then set the standing and conditional orders and have the fleet split.
That does not create the new fleets for the ones still technically in the hangar, but does removes them from the parent fleet. They aren't in the carriers fleet anymore either. The ships still exist, I can see them in the ship designer and they still generate maintenance reports. But as they aren't in a fleet I can't access them, tell them to land or anything else. They aren't on the system map, of course.
The OOB shows their names in the correct system, but says 2 of the type are there and lists 4 names (I gave different orders to the 4th ship on the carrier).

Reproduce: Drag and drop ships from carrier into another fleet, then have that fleet split.

No mods, period decimal separator

[Ragnarsson]

When attempting to save, I received the following error:

1. 13. 0 Function #3239: Object reference not set to an instance of an object.

This repeated 11 times, then appeared to save.  No previous attempts to save have had this issue.  Rolling back to the previous save file (which saved just fine) then attempting to save again immediately without changing a single thing still results in the errors.  All future save attempts include the same 11 errors until the game is closed.  Once the game is closed after that spate of errors and relaunched the errors do not appear to manifest again when loading from the save file created at the time the errors were thrown - the faulty (for lack of a better word) save file will still throw the errors when loaded from, then saved.

[Migi]

I have attached a DB to my previous report here: http://aurora2.pentarch.org/index.php?topic=12522.msg158782#msg158782
(I copied the DB at the time to preserve it, but forgot to zip and attach it to the report.) 

I also have a new bug:

The function number: N/A
The complete error text: N/A
The window affected: main window and fleet screen
What you were doing at the time: At first contact I had tug which was attacked by some aliens (precursors). The tug was destroyed by the alien ships, using beam weaponry. The payload it was tugging was not.
In case it affects reproduction, I had the fleet window open when the tug was destroyed.
The surviving payload is now travelling at 300,000 km/s, without any engines.
This is probably not intended behaviour.
The surviving payload can be given orders to move around, even standing orders.
If I detach the payload then both the empty fleet and new fleet have a correct speed of 1 km/s.
I have attached 2 DBs, one was saved 1 or 2 increments after this occurred. The other is the autosave from before it occurs, which wasn't long before the encounter occurred and might help if it needs to be reproduced au naturale. Look for the Delta Camelopardalis system and fleet EX 001 Geo.

Conventional or TN start: Conventional
Random or Real Stars: Known Stars enabled
Is your decimal separator a comma? Period
Is the bug is easy to reproduce, intermittent or a one-off? I have not seen this occur before, but the essential elements should be easy to reproduce for testing. I am not certain if it will re-occur naturally as it depends on AI targeting. My ship design philosophy for this campaign makes it very likely that the essential elements will be present in future encounters.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: Approximately 59 years after game start.
DB Purity: Database has never been edited. I have used some mods from the Approved mods section and some helpers from the Utilities section, AFIK none of these affect the DB.

SJW: Fixed for v2.0

[Zook]

I ordered a Mistral gunboat using available components on the planet, one engine and one damage control. Then I realized I had ordered a Mistral type, not a Mistral 1A1, so I canceled the order immediately (before construction began). I ended up with no engine in the stockpile, and two damage controls.

SJW: This is WAI

[nuclearslurpee]

I ordered a Mistral gunboat using available components on the planet, one engine and one damage control. Then I realized I had ordered a Mistral type, not a Mistral 1A1, so I canceled the order immediately (before construction began). I ended up with no engine in the stockpile, and two damage controls.

Not a bug. If you use components and then cancel the construction order, the components not returned to the stockpile. In simple terms, if components are used they are immediately consumed, and then there is nowhere in the DB where this information is kept to return such components in case you cancel the build order. Of course it would be ideal for this behavior to occur, but it is currently WAD/WAI so this would be a feature in the Suggestions thread instead.

Meanwhile if you do this again the workaround is probably to finish the original build and then do a refit, bit more expensive but will save your resources.

[bankshot]

EDITED: While this happened in one game, I couldn't reproduce it in the future, so I'll retract it unless / until I can find a reliable reproduction.

I had this issue in an earlier version but I haven't tried to reproduce in 1.13.  As I recall it happened when you disassemble the device on a different planet from the one where you are researching the tech.  So the workaround was to ship the parts to the planet where you are doing the research or if you are in a hurry - to the nearest planet with a research facility and research the tech there for 1 update before disassembly. 

[Migi]

I ordered a Mistral gunboat using available components on the planet, one engine and one damage control. Then I realized I had ordered a Mistral type, not a Mistral 1A1, so I canceled the order immediately (before construction began). I ended up with no engine in the stockpile, and two damage controls.

Not a bug. If you use components and then cancel the construction order, the components not returned to the stockpile. In simple terms, if components are used they are immediately consumed, and then there is nowhere in the DB where this information is kept to return such components in case you cancel the build order. Of course it would be ideal for this behavior to occur, but it is currently WAD/WAI so this would be a feature in the Suggestions thread instead.

Meanwhile if you do this again the workaround is probably to finish the original build and then do a refit, bit more expensive but will save your resources.

I think a better workaround would be to let the ship finish, then use SM to delete the wrong design and add the new one. That way you don't waste shipyard time with refitting.
Unfortunately this doesn't help retroactively, you can add minerals to compensate for the loss of the components and rebuild them with industry.

Unless Steve has commented on this previously, I don't see how you can say it isn't a bug.
Production hasn't started because time hasn't passed, and it isn't consistent with the change to loading and unloading in C#.
http://aurora2.pentarch.org/index.php?topic=8495.msg97517#msg97517

[nuclearslurpee]

Unless Steve has commented on this previously, I don't see how you can say it isn't a bug.

I believe he has but I don't have the post as a reference. But, it is not a bug because the game works exactly as designed. When you put a ship into production and tick the "Use Components" box, the components are immediately consumed (not after a construction tick) - this is by design. The information that components were used is not stored anywhere, so canceling the build order does not return the components because they have already been removed from the game state. The mechanical effect of using components is basically just to reduce the mineral and BP cost of the ship by the component values - in a sense this behavior is actually consistent with what happens if you cancel a build order made without using components, as the minerals and BPs already spent are lost.

Personally I would also like if the components would return to the stockpile, but it is properly a suggestion and not a bug report for this reason - it may be working in a confusing an unintuitive way, but it is working as intended nevertheless.

[Marski]

Has Steve updated the A.I for multi-faction earth starts? A.I tends to bankrupt itself within 50 years and then remain mostly inert up until it gets wind of player terraforming a planet.

[alamoes]

Orbital Population Capacity is currently set to use Int32 data type, which has a maximum value of 2,147,483,647.   This means you can have a maximum orbital population capacity of 2,147,483,647 people on your orbital stations before it overflows.   I suggest changing it to match whatever the planet uses, whether it's WAD or not.   "Should" be easy, though I don't know what the code looks like.   

I'm not going to post the error codes, because I don't feel like recreating the problem.   Something something Int32.   Something something divide by zero.   Pretty sure it's a simple cause.   If you overflow, your population gets set to zero, and that causes the error log to yell at you for having 0 population in the construction phase.   

Kind of a problem for me though, because I'm at capacity for people on Earth, and I need to run my stupidly large shipyards somehow.   Gonna have to tug some of them to Venus I guess.   

How to reproduce:
Build a combination of stations that supports more than 2,147,483,647 people and put them in orbit of a single planet.   

[skoormit]

CMC not spawning on highest scoring body.

A CMC just spawned on Eabler-A IV - Moon 11.
The minerals on that moon:

Code: [Select]

Duranium:   1,248,199   0.80
Boronide:   672,399   0.80
Vendarite:   409,599   0.70
Gallicite:   828,099   0.60
All the minerals have 0.5+ accessibility.
The total quantity, counting Duranium twice, is ~4.4M.

A better body is present in the system.
Eabler-B VI - Moon 1 has no colony, and has these minerals:

Code: [Select]

Duranium:   720,000   1.00
Neutronium:   2,175,625   0.80
Mercassium:   4,730,625   0.50
Vendarite:   1,625,625   0.20
All but Vendarite have 0.5+ accessibility.
The total quantity of those, counting Duranium twice, is ~8.3M.

Eabler-B orbits the primary at 26.7bkm, which exceeds the 80AU (~12bkm) limit.
But each star has a Lagrange Point within the 80AU limit.

Eabler-B VI orbits Eabler-B at 3.73bkm and has a stable LP (which remains a constant distance of 3.73bkm from the planet).
The moon orbits the planet at just 25kkm.
So the moon is always within 80AU of the LP.

Eabler-A IV orbits Eabler-A at 3.67bkm and has a stable LP.
So that LP is within 80AU of the primary.

Two possible errors come to mind:
1) The check is only counting accessibility > 0.5 (rather than >= 0.5).
2) The check is ignoring the LP at Eabler-A IV, because I stabilized that LP myself. (The other LP was already present.)


DB is attached.

[Steve Walmsley (OP)]

CMC not spawning on highest scoring body.

A CMC just spawned on Eabler-A IV - Moon 11.
The minerals on that moon:

Code: [Select]

Duranium:   1,248,199   0.80
Boronide:   672,399   0.80
Vendarite:   409,599   0.70
Gallicite:   828,099   0.60
All the minerals have 0.5+ accessibility.
The total quantity, counting Duranium twice, is ~4.4M.

A better body is present in the system.
Eabler-B VI - Moon 1 has no colony, and has these minerals:

Code: [Select]

Duranium:   720,000   1.00
Neutronium:   2,175,625   0.80
Mercassium:   4,730,625   0.50
Vendarite:   1,625,625   0.20
All but Vendarite have 0.5+ accessibility.
The total quantity of those, counting Duranium twice, is ~8.3M.

Eabler-B orbits the primary at 26.7bkm, which exceeds the 80AU (~12bkm) limit.
But each star has a Lagrange Point within the 80AU limit.

Eabler-B VI orbits Eabler-B at 3.73bkm and has a stable LP (which remains a constant distance of 3.73bkm from the planet).
The moon orbits the planet at just 25kkm.
So the moon is always within 80AU of the LP.

Eabler-A IV orbits Eabler-A at 3.67bkm and has a stable LP.
So that LP is within 80AU of the primary.

Two possible errors come to mind:
1) The check is only counting accessibility > 0.5 (rather than >= 0.5).
2) The check is ignoring the LP at Eabler-A IV, because I stabilized that LP myself. (The other LP was already present.)


DB is attached.

Its WAI. The program orders the list of potential CMC sites by score and then goes through the list with a 1/3rd chance for each to be selected. Therefore the best option is not always selected and in a system with only a small number of possible sites, none of them may be selected. You are more likely to see CMC appear in a system with more potential options.