v1.13.0 Bugs Thread

[Ragnarsson]

I'm not certain this rises to the level of bug, but may be unintended behavior. 

When orbital motion for asteroids is disabled, it functions as expected; however, when an asteroid field is orbiting a secondary star, the star will continue along it's orbit but it's asteroids will remain exactly where they began when the system was created.   As time goes on this results in an "orphaned" asteroid field out in the middle of nowhere.   Functionally this doesn't make a huge difference, but it is visually odd (and sometimes logistically painful, if you have a use for that asteroid field). 

The reason I suspect this to be unintended behavior is due to how Trojan asteroids act; they continue to orbit along with their "anchor" planet.   It just seems in this case the asteroid field of a secondary star is anchored to the wrong star - the primary, not the secondary. 

Replication is easy; deselect "Orbital Motion for Asteroids" in the game options screen, then generate systems until you find a multi-star system where one of the non-primary stars has non-Trojan asteroids.   Progress time and you'll see the effect. 

SJW: Fixed for v2.0

[Garfunkel]

Known issue and fixed for 2.0

[Steve Walmsley (OP)]

BTW, orbital movement takes about 0.01 seconds in C#. If you have turned this off for performance reasons, you can turn it back on.

[somebody1212]

Just made a new post because I found an *actual* bug from the above situation.

So since the game log in the database won't tell me which ship was causing the increment to auto-adjust due to combat, I looked in FCT_FireControlAssignments and found that it was still showing that one Fire Control for one of my ships, Ship ID#26734 "CA Klingon" was still on Open Fire. However, looking in game at CA Klingon, both Fire Controls showed "Green" cease fire status for CA Klingon. However, the "Cease Fire All" button was still displayed, so I clicked that and it changed back to "Open Fire All."

However, when I advanced time one day, I found that it still got auto-adjusted back down to 5 seconds due to open fire controls with no targets, and "Cease Fire All" was again displayed in CA Klingon's ShipCombat screen. This repeats all the time, I can't seem to clear Fire Control status from the UI in game. I've also tried individually opening fire on each FC so they turn Orange, an then Cease Firing the again back to green, and the increment still auto adjusts back to 5 due to Open Fire Control.

One of CA Klingon's Fire Controls (a Atalskes Phaser Corporation Weapons Console R480-TS10000) was damaged during the last battle, and had been in an "Open Fire" state when it had been damaged. I can't shut it off from the UI since it was damaged, I'm wondering if that one is stuck and keeping the increments locked. I think I can fix it by editing the database to put a 0 in for "Open Fire," but wanted to report the issue first. DB attached.

Just had a similar event happen during one of the duels we run on the Discord - after a number of ships had their beam fire controls destroyed by microwave fire, they continued to fire normally as though their BFCs were still present. Ordering them to cease fire did nothing, but SM-repairing the fire controls and then ordering them to cease fire worked (though obviously isn't ideal since this means the fire control is no longer in the damage control queue).

The fire controls were destroyed in the increment before I saved the game and came back to it the next day - it's possible that that's involved in the bug but I've yet to find a sequence of steps that will consistently replicate the bug. This bug seems to be particularly difficult to nail down, in fact - after going back into the database where the bug originally occurred I still can't reproduce it.

[LiAlH4]

This is a bug from 1.  12 that I do not believe has been fixed.  I have not been able to produce this bug in 1.  13 as it requires specific conditions that I cannot reproduce at the outset of the game.  I am not running any mods.      Finally, this post seems to have an odd spacing issue after periods that I haven't been able to resolve, please excuse the spaces after periods.   The dropbox link works if you remove the spaces.     

Essentially, an NPR that spawns has a chance to construct an AMM that is slightly larger than the size 1 launchers needed to fire it, leading to large numbers of NPR ships that don't have the ability to fight.  In my case, the AMM designed was size 1.  005.  This may be an issue with the templates used to produce NPR ships.       

My workaround required editing the database to reduce the size of that specific missile to a flat 1.  You can download the pre-workaround version of the database here: https://www. dropbox.  com/s/5uk5up3plgz0m5q/AuroraDB. db?dl=0.       

[nuclearslurpee]

Finally, this post seems to have an odd spacing issue after periods that I haven't been able to resolve, please excuse the spaces after periods.

This is an anti-spam feature applied to posts by new members (to prevent bots spamming links and such). Once you have 10+ posts it will stop happening.

[Ragnarsson]

When the "Events" window is open, if you input a decimal number (for example, 0. 1) into the "Event Days" field and process an increment you will get the following error:

"1. 13. 0 Function #647: Input string was not in the correct format. "

That would normally not be a big deal, as you could simply change the number.  However, if you have automated turns on this becomes impossible.  You click the "OK" button to acknowledge the error, but can't change the offending decimal as the next increment processes immediately, throwing another error.  I ended up having to force-close Aurora (I was unable to simply close or force-close the Events screen).  Luckily, I'd saved a few moments earlier.

This was reliably replicable simply by inputting any decimal into the Event Days field and processing an increment.

SJW: Fixed for v2.0

[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


[Migi]

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


I'm not certain, but my guess is that the engines aren't military. The stabilised jump point is hiding the fact that it can't jump normally either.
(Also I note it can only cope with 2 maintenance failures if they both use the max MSP, given the IFR it seems unlikely to last 2 full years without needing to be restocked with MSP)

[IanD]

The engines are military, but they are 10% boosted. This game is one I am playing without maintenance as I got tired of chasing minerals and couldn't get the size of fleet I wanted or deploy small squadrons many jumps out as my universes never have sufficient minerals anywhere remotely useful and never in sufficient quantities. If I could use the VB6 maintenance mechanic I would use it in a heartbeat

Code: [Select]

Inertial Fusion Drive  EP880.00
Engine Power 880    Fuel Use Per Hour 176.6 litres    Fuel per EPH 0.2
Thermal Signature 70.40    Explosion Chance 11%
Military Engine
Cost 1210   Size 1,250 tons   Crew 28   HTK 5
Base Chance to hit 100%
Materials Required: Gallicite  1,210   

[Migi]

The engines are military, but they are 10% boosted. This game is one I am playing without maintenance as I got tired of chasing minerals and couldn't get the size of fleet I wanted or deploy small squadrons many jumps out as my universes never have sufficient minerals anywhere remotely useful and never in sufficient quantities. If I could use the VB6 maintenance mechanic I would use it in a heartbeat

Fair enough on the maintenance.
I'm stumped about the jumping.

I have seen this happen on occasion, usually the research project seems to be found under an incorrect research category. However, I do not trust a bugged research project so my usual workaround is to just design the same component/missile again and it will usually be filed correctly the second time around.

It seems to "fix" itself if you shut down Aurora and restart the entire game. But yeah, i wouldnt trust that either.

I have experienced a bug similar to the one above.
In my case I designed an STO, and the research project appeared in the Power and Propulsion category.
This persisted after I closed and re-opened the economics window.
When I designed the same STO again (I had left the ground unit window open), the new one ended up in the Ground Combat category.
However restarting Aurora did not cause the PP project to change to the GC category, both of them were still in different research categories.

Edit: Attached DB which I inexplicably forgot to do at the time.
For complete record:
Conventional or TN start: Conventional Start
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 think I might have seen it on a previous version.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~50 years after campaign start

[boolybooly]

I have noticed a stabilised lagrange point initially locates about 90° further retrograde than it should (seen this twice now so is reproducible).

On the first transit it snaps to its correct location which can bamboozle the AI navigation under some circumstances as it seems to treat the erroneous location as literal.

I include a screeny of a recently stabilised LP3 in Sol which is further away from its parent body (Uranus) on its orbit than it ought to be, also the save at that moment.

If you use Pendragon to chart a path to Orcus it will try to use LP3 but ends up in the wrong place entirely when it snaps to the correct location.

[Ragnarsson]

Ships with order delays that are subsequently put into a refit do not have their orders removed.  Instead, they merrily go about their queued orders when the time delay expires, despite the fact they're in the midst of a refit.  Admittedly, this is more odd and amusing than troublesome.  This was tested with a tanker, stationed at the same world as the shipyard used to refit it, and ordered to refuel from a fuel harvesting station and return every ~180 days.  The refit was ~60% done when the tanker departed for the fuel harvester, tanked up and returned.  The refit ended up completing as usual, with no interruptions or errors.

SJW: Fixed for v2.0

[Garfunkel]

Ships with order delays that are subsequently put into a refit do not have their orders removed.  Instead, they merrily go about their queued orders when the time delay expires, despite the fact they're in the midst of a refit.  Admittedly, this is more odd and amusing than troublesome.  This was tested with a tanker, stationed at the same world as the shipyard used to refit it, and ordered to refuel from a fuel harvesting station and return every ~180 days.  The refit was ~60% done when the tanker departed for the fuel harvester, tanked up and returned.  The refit ended up completing as usual, with no interruptions or errors.

Hahaha that's a really dedicated crew! 

[nuclearslurpee]

I have noticed a stabilised lagrange point initially locates about 90° further retrograde than it should (seen this twice now so is reproducible).

On the first transit it snaps to its correct location which can bamboozle the AI navigation under some circumstances as it seems to treat the erroneous location as literal.

I include a screeny of a recently stabilised LP3 in Sol which is further away from its parent body (Uranus) on its orbit than it ought to be, also the save at that moment.

If you use Pendragon to chart a path to Orcus it will try to use LP3 but ends up in the wrong place entirely when it snaps to the correct location.

Can confirm. I tested this in Sol, and per a bit of old-fashioned trigonometry (see attachments) I can say it is exactly 90° retrograde from where it should be, within the limits of pixel precision. The LP snaps to the correct orbital position on the next construction increment.

Based on this my guess is that the bug is using a sin/cos where a cos/sin should be in the LP stabilization code, should be an easy fix if so.