Aurora 4x

C# Aurora => C# Bug Reports => Topic started by: Steve Walmsley on April 24, 2021, 04:12:11 AM

Title: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 24, 2021, 04:12:11 AM
Please post potential bugs in this thread for v1.13.0.

Please check the Known Issues post before posting so see if the problem has already been identified or is working as intended.
http://aurora2.pentarch.org/index.php?topic=10637.0

'Me too' posts for unresolved bugs are fine as it shows they are affecting more than one person. Any extra information you can provide in 'me too' posts is very welcome.

Please do not post bugs from previous versions unless you confirm they are still present in v1.13.0

When you post, please post as much information as possible, including:
The function number
The complete error text
The window affected
What you were doing at the time
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?
Is the bug is easy to reproduce, intermittent or a one-off?
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
Title: Re: v1.13.0 Bugs Thread
Post by: Black on April 24, 2021, 08:08:03 AM
Small thing only.

Use Constellation Names has no tooltip.

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Black on April 24, 2021, 10:18:54 AM
Class Design - Components list.

Damage Control category is missing Obso Comp button, so it is not possible to obsolete older types of Damage Control systems.

Same for Salvage Module.

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Iceranger on April 24, 2021, 10:20:25 AM
Class Design - Components list.

Damage Control category is missing Obso Comp button, so it is not possible to obsolete older types of Damage Control systems.

Same for Salvage Module.
Obsolete Component only applies to designed components, these 2 categories are not among them.
Title: Re: v1.13.0 Bugs Thread
Post by: Black on April 24, 2021, 10:31:08 AM
Class Design - Components list.

Damage Control category is missing Obso Comp button, so it is not possible to obsolete older types of Damage Control systems.

Same for Salvage Module.
Obsolete Component only applies to designed components, these 2 categories are not among them.

Ah, I forgot that changed for 1.13. but it is somewhat inconsistent as you can still obsolete ECCM and ECM components. I wonder if it is intentional for Damage Control as there is not really reason to use older versions (only cost, same as with ECCM and ECM).
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 24, 2021, 10:34:24 AM
Ah, I forgot that change for 1.13. but it is somewhat inconsistent as you can still obsolete ECCM and ECM components. I wonder if it is intentional for Damage Control as there is not really reason to use older versions (only cost, same as with ECCM and ECM).

It is a bug. You should be able to obsolete non-designed components when there are older versions. I've corrected damage control and salvage modules for v1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: IdleChatterer on April 24, 2021, 11:01:20 AM
Something wrong with auto-assignment designations? Designing my first civilian ship, and it's classed as 'a' for auto-assignment purposes:

---
Corelian class Colony Ship (P)      3,062 tons       36 Crew       105.  3 BP       TCS 61    TH 102    EM 0
1672 km/s      Armour 1-18       Shields 0-0       HTK 11      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 21    Max Repair 20.  48 MSP
Cargo Shuttle Multiplier 1   
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months   

Commercial Improved Nuclear Thermal Engine  EP102.  40 (1)    Power 102.  4    Fuel Use 4.  05%    Signature 102.  4    Explosion 4%
Fuel Capacity 250,000 Litres    Range 363.  1 billion km (2513 days at full power)

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

The function number: n/a
The complete error text: n/a
The window affected: Class Design
What you were doing at the time: designing a freighter, my first commercial vessel
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? I can reproduce it in my game.   When I create a new design, it is classed as 'a' for auto-assignment purposes.   If I add a geosurvey sensor, it becomes correctly classified as a 'Survey Ship'.   If I instead add a cargo hold, it gets classed as 'i'

Database attached. 

(P. S.  thanks for the great game!)

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 24, 2021, 11:14:25 AM
Something wrong with auto-assignment designations? Designing my first civilian ship, and it's classed as 'a' for auto-assignment purposes:

Well, that at least confirms that obfuscation is working :)

I forgot to tell the compiler not to obfuscate the enum that tracks class primary functions. Fixed for v.1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: IdleChatterer on April 24, 2021, 12:18:23 PM
And another possible minor bug: the pop-up to select which field you want to retrain a scientist to has a check box with no explanatory text.  I couldn't see any effect of checking/unchecking the box.   

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Black on April 24, 2021, 12:56:52 PM
And another possible minor bug: the pop-up to select which field you want to retrain a scientist to has a check box with no explanatory text.  I couldn't see any effect of checking/unchecking the box.

Similar issue when you choose what kind of shipyard you want to add in SM mode, there is also check box without text.

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Fray on April 24, 2021, 01:47:39 PM
When you post, please post as much information as possible, including:
The function number: n/a
The complete error text: No error
The window affected: Economics/GU Training
What you were doing at the time: Creating ground units
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: n/a

In the ground unit training window, if you delete the active task, the task queue will not correctly advance. To reproduce:
1) Queue up a set of ground units.
2) Delete the active task. You'll see that the queue is unaffected by this.
3) Run a few construction cycles. You'll see that the queue does not advance. The first queued task will not begin.

You can create a new task, and it will become the new active task, jumping to the front of the queue. Otherwise, the queue remains frozen.

This issue persists in V1.13. One thing I should add is that this bug only occurs if you delete ALL the active tasks. If you have multiple active asks, and only delete some of them, the queue advances correctly.

SJW: For v1.14, the ground construction code will now check to see if anything should be moved from the queue before the 5-day construction cycle commences.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 24, 2021, 05:21:17 PM
I've removed the empty checkbox that was appearing on user selection popup windows.
Title: Re: v1.13.0 Bugs Thread
Post by: Nori on April 24, 2021, 10:39:25 PM
1.13.0 Function #2939: Object Reference not set to an instance of an object.
Just started a new game and this is a few autoturn years into the game. It's a custom random star start and I haven't even designed a ship yet.
TN Start, Random stars, decimal separator.

The error is causing the game to lock up, I'll upload the DB from a the last save, autoturn a bit and it should error out.

Bughunter: Failed to reproduce, ran several times autoturn and manually.
Title: Re: v1.13.0 Bugs Thread
Post by: DeMatt on April 24, 2021, 10:44:25 PM
In the Research screen, instead of selecting a research project before hitting "Add to Queue", it is possible to select the "Technology" title or the blank line between the title and the actual projects.  Clicking "Add to Queue" in this state results in an error popup:
Code: [Select]
1.13.0 Function #2169: Object reference not set to an instance of an object.
Opening or closing the Economics window after this point causes the error popup to reappear, as does properly queuing a research project.
Then, hitting the "Save" button causes a different error popup before actually saving:
Code: [Select]
1.13.0 Function #1429: Object reference not set to an instance of an object.
Then, closing and reopening Aurora will load the game, apparently without ill effect... until you realize that Aaron Aardvark is taking over your game because your Race Name Themes setting somehow got erased.

Code: [Select]
The function number:  See above
The complete error text:  See above
The window affected:  See above
What you were doing at the time:  Passing time while waiting for terraformers
Conventional or TN start:  Conventional
Random or Real Stars:  Real Stars
Is your decimal separator a comma?  N
Is the bug is easy to reproduce, intermittent or a one-off?  Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well:  Started at the default 2025, it is now 2103 - but I haven't left Sol system yet.

Let me know if you need more information or my DB.

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 24, 2021, 11:18:48 PM
Obfuscation strikes again in the Ancient Constructs screen:

(https://i.imgur.com/FdA1RAg.png)

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: skarlathamon on April 25, 2021, 12:34:15 AM
Missile launchers do not check the size of the missiles.   A Size 1 missile launcher can launch a size 60.  5 missile with no problem. 

Steps to reproduce:

Load any size missile that is larger than a launcher on a vessel. 
Drag the missile onto the launcher in the ship combat section.   
Select a target and fire. 

Tested in BOTH v1. 13. 0 AND v1. 12. 1

https://imgur. com/a/t1GtMVy

(https://i. imgur. com/QeDSxXe. png)

(https://i. imgur. com/0bBoC3S. png)

(https://i. imgur. com/F7XSx3L. png)

(https://i. imgur. com/rSj6lVE. png)

SJW: I am amazed the game has been out for a year and this wasn't spotted before :)  Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 25, 2021, 04:19:02 AM
1.13.0 Function #2939: Object Reference not set to an instance of an object.
Just started a new game and this is a few autoturn years into the game. It's a custom random star start and I haven't even designed a ship yet.
TN Start, Random stars, decimal separator.

The error is causing the game to lock up, I'll upload the DB from a the last save, autoturn a bit and it should error out.

Bughunter: Failed to reproduce, ran several times autoturn and manually.

Its an error in Orbital Movement for stars. The only way I can see that specific error happening is if a non-primary star somehow didn't have a parent star. Have you made any changes to the starting system or are you running any mods?
Title: Re: v1.13.0 Bugs Thread
Post by: Kristover on April 25, 2021, 06:00:00 AM
Minor bug:

On the Commander screen, all of my scientists have a generic research specialty and percentage next to their names - no indication of their research field. (Image 1).

On the Research screen, all of my scientists are showing their research specialty and it is the same as the research specialty on the Commander screen.

------

The function number: n/a
The complete error text: n/a
The window affected: Commander Screen
What you were doing at the time: Just started game; no time advanced yet - evaluating Commanders
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent or a one-off? I can reproduce it in my game.   Started new game and same issue immediately crops up.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on April 25, 2021, 06:59:57 AM
Geo Survey Ships Do Not Use Commander Bonus

The survey rate of geological survey ships is increased by Admin Command bonuses, but not by ship commander bonuses.

I am attaching my db.

In my game, I have nested admin command leaders at the following ranks and bonuses:
RADM   20.0%
RADL   20.0%
CAPT   10.0%
CDR    15.0%

Each level provides 25% of the leader's bonus, and the levels apply multiplicatively.
That gives a net bonus of ~17%.

My game has a survey rate of 10%.

Therefore a ship with a single geo sensor and no commander bonus should produce ~0.117 points per hour, or ~2.8 per day.
My ship GE ProSpect 002 produces just that, no matter the survey bonus of the assigned ship commander.

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 25, 2021, 07:20:46 AM
Minor bug:

On the Commander screen, all of my scientists have a generic research specialty and percentage next to their names - no indication of their research field. (Image 1).

On the Research screen, all of my scientists are showing their research specialty and it is the same as the research specialty on the Commander screen.

I'm not sure understand the problem here. The scientists are grouped by their research specialty on the treeview. You have a ground combat scientist selected for example.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 25, 2021, 07:31:38 AM
The survey rate of geological survey ships is increased by Admin Command bonuses, but not by ship commander bonuses.

Can you confirm the survey ship has a bridge or other control station.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on April 25, 2021, 07:42:18 AM
The survey rate of geological survey ships is increased by Admin Command bonuses, but not by ship commander bonuses.

Can you confirm the survey ship has a bridge or other control station.

Negative. These are fighter-sized--no bridge.
If that's a requirement for getting the commander bonus, I must have missed it.
My apologies.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 25, 2021, 07:54:29 AM
The survey rate of geological survey ships is increased by Admin Command bonuses, but not by ship commander bonuses.

Can you confirm the survey ship has a bridge or other control station.

Negative. These are fighter-sized--no bridge.
If that's a requirement for getting the commander bonus, I must have missed it.
My apologies.

It's still a bug. A FAC or smaller doesn't need a bridge, but the commander bonus code checks for a control station. I will change that code so it assumes a control station is present on FACs or smaller.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 25, 2021, 10:26:47 AM
Miscellaneous components cannot be researched, because they don't appear on any of the research tabs after you create them in the Tech Window.

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: dr125 on April 25, 2021, 10:27:05 AM
In the class design screen, on "Race Components", when a component is selected opening and closing a category (ex. Engine) will add that component to the ship.

SJW: Cannot reproduce
Title: Re: v1.13.0 Bugs Thread
Post by: Kristover on April 25, 2021, 10:44:50 AM
Miscellaneous components cannot be researched, because they don't appear on any of the research tabs after you create them in the Tech Window.

I can confirm this one.  Just tried it in my game and the misc. component doesn't appear in the research screen.
Title: Re: v1.13.0 Bugs Thread
Post by: Nori on April 25, 2021, 10:52:25 AM
1.13.0 Function #2939: Object Reference not set to an instance of an object.
Just started a new game and this is a few autoturn years into the game. It's a custom random star start and I haven't even designed a ship yet.
TN Start, Random stars, decimal separator.

The error is causing the game to lock up, I'll upload the DB from a the last save, autoturn a bit and it should error out.

Bughunter: Failed to reproduce, ran several times autoturn and manually.

Its an error in Orbital Movement for stars. The only way I can see that specific error happening is if a non-primary star somehow didn't have a parent star. Have you made any changes to the starting system or are you running any mods?
No mods, just downloaded the fresh 1.13 and did a new install. I started the game, created a new star system and I moved two planets a few million km and adjusted their properties to make them suitable for habitation and that's about it. No new stars or planets, no changing who orbits who (at least I don't think so).
I'm not attached to this save at all so I can for sure do a new game, just not sure what I could have done to break Orbital Movement.
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on April 25, 2021, 10:53:37 AM
If a game starts with 'New Tech from Conquest' ticked , and then has it unticked and saved, then when a population is conquered the conqueror still gains technologies

SJW: Fixed for 1.14.0
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on April 25, 2021, 03:21:05 PM
flag0393 is hardcoded as a default flag of the player empire. Deleting it completely breaks creation of new games.
Tested in 1,13 but I encountered it in 1,12

Scenario 1:
1) Use a fresh install
2) Delete flag0393 from Flags folder
3) Open the game
4) Try to create a new game (default settings)
Result: errors from (presumably) race creation window (https://imgur. com/a/LFtYn9N) and a broken game

Scenario 2:
1) Use a fresh install
2) Delete every flag icon BUT flag0393 from Flags folder
3) Open the game
3,5) Click through a few harmless "No image found for flag" errors because Example Game has some of them in use already. Shouldn't affect the overall result.   
4) Try to create a new game (default settings)
Result: game created successfully, no errors

Can circumvent the issue by renaming some other flag to it, but it is still a bug. The game should only use icons that are available.   

race327 is also hardcoded as a default race picture of player empire, but deleting it doesn't break the game.
flag0000 seems to be softcoded as a default flag, but removing it doesn't break the game. Only an occasional "No image found for flag".

Accidentally discovered by changing my pool of icons. My goal was to remove all real and Earth-related flags so I wouldn't have to fight Italian or Brazilian aliens again. Got a bunch of "No image found for flag" errors along the way, but they don't seem to do anything and they do not occur after creating new game with a new set of icons.

Also, if you turn Invaders and Precursors off in the settings of the new game, their races are still generated in the database. Kind of makes sense because they are toggleable, but maybe it should be handled on settings change instead of being created by default?

EDT: also forum keeps adding more and more spaces after periods with each edits. One is enough.

SJW: Flag issue fixed for 1.14.0. Invaders and Precursors are working as intended.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on April 25, 2021, 03:52:14 PM
EDT: also forum keeps adding more and more spaces after periods with each edits. One is enough.

This will cease being a problem once you reach 10 posts, anti-spam measure of the forum prevents new accounts from posting links that way.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 25, 2021, 11:39:51 PM
Also, if you turn Invaders and Precursors off in the settings of the new game, their races are still generated in the database. Kind of makes sense because they are toggleable, but maybe it should be handled on settings change instead of being created by default?

These races are actually needed for the (not uncommon) case where players turn those races on or off while a game is in progress. As long as they are not toggled there is no effect on the game anyways so it is not a problem.
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on April 26, 2021, 12:37:18 AM
Firecontrol states a weight of 100 tons, on ship it weights 127 tons, the same is for "Single weapon only" 100/127 that is, it's not halfweight... Testing a little more, a FC, no changes says 25 tons but weights 31 tons, so it seems to be around 24-27% more weights... Or I am missing something?? Seems to be the same in 1:12
Title: Re: v1.13.0 Bugs Thread
Post by: Kiero on April 26, 2021, 12:51:19 AM
Researched cloaking components are not showing in the "view tech" window.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on April 26, 2021, 12:53:21 AM
Firecontrol states a weight of 100 tons, on ship it weights 127 tons, the same is for "Single weapon only" 100/127 that is, it's not halfweight... Testing a little more, a FC, no changes says 25 tons but weights 31 tons, so it seems to be around 24-27% more weights... Or I am missing something?? Seems to be the same in 1:12

 - Have you accounted for the extra mass of armor and crew that come with adding components?

 - EDIT: It seems to be WAI for me, when taking into account the crew and the armor, the size adds up rightly.
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on April 26, 2021, 01:13:08 AM
Firecontrol states a weight of 100 tons, on ship it weights 127 tons, the same is for "Single weapon only" 100/127 that is, it's not halfweight... Testing a little more, a FC, no changes says 25 tons but weights 31 tons, so it seems to be around 24-27% more weights... Or I am missing something?? Seems to be the same in 1:12

 - Have you accounted for the extra mass of armor and crew that come with adding components?

 - EDIT: It seems to be WAI for me, when taking into account the crew and the armor, the size adds up rightly.

Ah no  ::) , have not and after restarting the game it now give half weight for singel weapon FC
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 26, 2021, 03:17:51 AM
Miscellaneous components cannot be researched, because they don't appear on any of the research tabs after you create them in the Tech Window.

Fixed for v1.14. These components will appears in the Logistics category. The workaround is to use Instant in SM Mode.

You can apply the fix to v1.13 by making a small change to the database. Open DIM_TechType and go to the last row, which should have "Miscellaneous Components" in the Description Field. Change the FieldID on that row from 10 to 6.
Title: Re: v1.13.0 Bugs Thread
Post by: idefelipe on April 26, 2021, 05:31:04 AM
This is not a bug, but a question I have noticed. Seteve, did you change the parameters that a new officer is recruited? In 1.12 I saw from time to time some exceptional naval officers with promotion points over 1200 (and one time I saw one at 2000). For the Ground officers I saw even 10.000 points (because of the ground amount of troops that can manage, something that has gone... and I like it).

But in my current game, the best navy officer has reached 900 promotion points and one thing I noticed is that the crew training value is not over 50. Did you change it? is it just a matter of coincidence in my game?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 26, 2021, 05:43:49 AM
This is not a bug, but a question I have noticed. Seteve, did you change the parameters that a new officer is recruited? In 1.12 I saw from time to time some exceptional naval officers with promotion points over 1200 (and one time I saw one at 2000). For the Ground officers I saw even 10.000 points (because of the ground amount of troops that can manage, something that has gone... and I like it).

But in my current game, the best navy officer has reached 900 promotion points and one thing I noticed is that the crew training value is not over 50. Did you change it? is it just a matter of coincidence in my game?

Nothing has changed for officer generation
Title: Re: v1.13.0 Bugs Thread
Post by: idefelipe on April 26, 2021, 05:50:33 AM
Thank you for the quick reply. Then it is just a coincidence in my game. I use to create a medal for those officers that are created with more than 1500 points (and make them history characters), so because of that I realized it.

I guess I have to wait a bit more to see my first exceptional officer  ;D
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on April 26, 2021, 06:13:37 AM
There is some inconsistency with cargo shuttles, supply ship designations and maintenance modules.

The basic rules as I understand them are:
It it impossible to move MSP from ship to ship without cargo shuttles.
If no ship in target fleet is designated as Supply ship, then you don't even get an option to order to "Resuply from a stationary supply ship".
If a ship is designated as Supply ship but has no cargo shuttles, then the order will be present but it will do nothing because MSP transfer is impossible.

If a maintenance fleet (with maint modules, no shuttles) has no designated supply ships, then for both maintenance and overhauls (M\O for short) the others fleets will use their own MSP supply. If they run out, then M\O stops, even if the maintenance fleet has spare MSP
If a maintenance fleet (with maint modules, no shuttles) has designated supply ships (with no shuttles), then other fleets will use maintenance fleet's MSP for M\O
If a maintenance fleet has no designated supply ships, but a separate supply fleet with designated supply ships (with no shuttles) happens to be in the same location, then other fleets will use supply fleet's MSP for M\O

Designation alone allows supply ship's MSP to be used for M\O of other fleets, even though MSP transfer should be impossible due to lack of shuttles.


Edit:
Quote
The ship being maintained will use up MSP from any racial populations in the same location, in descending order of MSP stockpile. If no populations are available, or have no MSP, the maintained ship will use MSP from any Supply Ships in the same location, in descending order of available MSP. Finally, if no other option is available, the maintained ship will consume its own MSP. A ship can use a combination of the above to locate sufficient MSP.
It is consistent with this logic, but still weird that loading\unloading MSP requires shuttles but M\O does not

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on April 26, 2021, 10:58:49 AM
"Show Next Tech" in component designer uses fractional values of capacitor recharge tech as the next step. So with race tech at level 2, next tech will only show 2. 25.
I assume it should show both next level tech and fractions up to it, just like it does with engine sizes.

EDT: Next engine power techs are not shown either, but I assume that's because higher and lower power are on different "techlines"

SJW: Fractional capacitor values fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: idefelipe on April 26, 2021, 01:23:44 PM
Oh.. I removed the message because it was that. Didn't remember the racial wealth cap  ;D
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on April 26, 2021, 02:17:48 PM
 - Oh boy, my first 1.13 bug! :P

 --- When cueing up Naval Shipyards, it acts strangely. I'll cue up 3 and it'll only build two, I'll cue up 10 and it'll only build three, I'll cue up two and it'll only build one. I haven't looked into whether or not it's actually charging me for the ones it doesn't build, but it's surely not building them. The behavior is consistently wrong, but not wrong according to a consistent manner... if that makes any sense.

...I'll attach a DB... Just build a number of Naval Shipyards greater than one and viola! bug du jour. Currently I'm working around this by building them one at a time.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on April 26, 2021, 02:30:55 PM
- Oh boy, my first 1.13 bug! :P

 --- When cueing up Naval Shipyards, it acts strangely. I'll cue up 3 and it'll only build two, I'll cue up 10 and it'll only build three, I'll cue up two and it'll only build one. I haven't looked into whether or not it's actually charging me for the ones it doesn't build, but it's surely not building them. The behavior is consistently wrong, but not wrong according to a consistent manner... if that makes any sense.

...I'll attach a DB... Just build a number of Naval Shipyards greater than one and viola! bug du jour. Currently I'm working around this by building them one at a time.

I have had this same problem since 1.12, I think it becomes a problem with high levels of construction industry. The shipyards get finished too quickly and the game loses count of how many it needs to add.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on April 26, 2021, 02:56:55 PM
- Oh boy, my first 1.13 bug! :P

 --- When cueing up Naval Shipyards, it acts strangely. I'll cue up 3 and it'll only build two, I'll cue up 10 and it'll only build three, I'll cue up two and it'll only build one. I haven't looked into whether or not it's actually charging me for the ones it doesn't build, but it's surely not building them. The behavior is consistently wrong, but not wrong according to a consistent manner... if that makes any sense.

...I'll attach a DB... Just build a number of Naval Shipyards greater than one and viola! bug du jour. Currently I'm working around this by building them one at a time.

I have had this same problem since 1.12, I think it becomes a problem with high levels of construction industry. The shipyards get finished too quickly and the game loses count of how many it needs to add.

 - I'll assume 7,500 Construction Factories counts as a "high level of construction industry"?
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on April 26, 2021, 03:15:12 PM
That does sound like quite a lot. Is it possible that more than 1 shipyard (from the same construction order) completed in the same production cycle?
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on April 26, 2021, 03:15:45 PM
That does sound like quite a lot. Is it possible that more than 1 shipyard (from the same construction order) completed in the same production cycle?

 - Possibly, though I have no way to check for that AFAIK.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 26, 2021, 03:28:38 PM
That does sound like quite a lot. Is it possible that more than 1 shipyard (from the same construction order) completed in the same production cycle?

 - Possibly, though I have no way to check for that AFAIK.

A naval shipyard costs 2400 BP, so to build two in a single production cycle would take 4800 BP over that 5-day (default) period. If you're a minimax player who uses 100% of construction capacity for a single build at a time, with 7500 factories this could happen if you have Construction Rate 50 BP or better, in fact you can probably pull this off with one or two levels lower tech if you have bonuses from colony and sector governors. It could also be possible to have overrun occur with a lower amount of BP, for example in a single construction cycle you might need 10 BP to finish the first shipyard and 2400 BP to build the next one from scratch, a total of 2410 which is obviously possible at a much lower level of tech/bonuses.

If these conditions sound like a match for your current game state (and 7500 factories is pretty late game, unless you're starting with something like 10 billion pop, so I wouldn't be surprised if you also have a high Construction Rate tech), this may be what is happening - multiple yards are completed and only one gets added to the SYs list.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on April 26, 2021, 03:31:56 PM
That does sound like quite a lot. Is it possible that more than 1 shipyard (from the same construction order) completed in the same production cycle?

 - Possibly, though I have no way to check for that AFAIK.

A naval shipyard costs 2400 BP, so to build two in a single production cycle would take 4800 BP over that 5-day (default) period. If you're a minimax player who uses 100% of construction capacity for a single build at a time, with 7500 factories this could happen if you have Construction Rate 50 BP or better, in fact you can probably pull this off with one or two levels lower tech if you have bonuses from colony and sector governors. It could also be possible to have overrun occur with a lower amount of BP, for example in a single construction cycle you might need 10 BP to finish the first shipyard and 2400 BP to build the next one from scratch, a total of 2410 which is obviously possible at a much lower level of tech/bonuses.

If these conditions sound like a match for your current game state (and 7500 factories is pretty late game, unless you're starting with something like 10 billion pop, so I wouldn't be surprised if you also have a high Construction Rate tech), this may be what is happening - multiple yards are completed and only one gets added to the SYs list.

 - I've started with 12 Billion Pop, and my CON Rate is currently... 10? Whatever the base is for a TN start. I suppose that is the issue then, cheers!
Title: Re: v1.13.0 Bugs Thread
Post by: Nori on April 26, 2021, 07:56:44 PM
So I played several hours yesterday and much to my chagrin I could not reproduce my error either. Before I posted I saved, closed and was able to reproduce the error twice, so it's crazy that I couldn't again. Anyway, I played at least a decade with no issues, so really not sure what happened.
Title: Re: v1.13.0 Bugs Thread
Post by: whollaborg on April 27, 2021, 11:18:27 AM
This obfuscation discourages me.  Also poor old eyes are not able to deal with the blue wavelengths, woe.  Otherwise good job.
The attachment is a picture of a design which, "is classed as a i for auto-assignment purposes"
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on April 27, 2021, 11:57:51 AM
This obfuscation discourages me.  Also poor old eyes are not able to deal with the blue wavelengths, woe.  Otherwise good job.
The attachment is a picture of a design which, "is classed as a i for auto-assignment purposes"

The obfuscation is fixed in 1.14 so don't worry about it as it seems to be quite localized to the auto-assignment prompts.
But yeah I keep hearing that the blue color scheme really does a number on peoples eyes which is a big problem.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 27, 2021, 12:27:42 PM
But yeah I keep hearing that the blue color scheme really does a number on peoples eyes which is a big problem.

If nothing else with the end of AuroraMod releases it would be nice if Steve would move the colors into a DB table, that way at least the average Aurora veteran who is fairly tech-savvy and can load a DB to change a few color codes has some recourse short of hex editing.
Title: Re: v1.13.0 Bugs Thread
Post by: Zincat on April 27, 2021, 02:25:11 PM
I can't really play it either. The blue color kills me  :'(
Title: Re: v1.13.0 Bugs Thread
Post by: bupro on April 27, 2021, 02:27:17 PM
Code: [Select]
1.13.0 Function #2092: Value was too large or too small for a Decimal.
Started after installing orbital habitat on Venus.   
Happens whenever advancing time, persists after restart.   

Conventional start, real stars, 63yrs into game, no comma separator.   

Could be due to very small/large values in Venus economy, will reply if it stabilizes.   

My first bug report, thanks for the game.   
-----------
Update, did some fiddling:
Error message was appearing anytime Venus was selected in the economy tab as well.   Thought it might have been my preemptive setting of a CO2 target for Venus for decades ahead when I got to terraforming it. 
Putting a TF station in orbit solved reduced the frequency of the issue it seems. 
Title: Re: v1.13.0 Bugs Thread
Post by: Desdinova on April 27, 2021, 03:47:59 PM
There's a bug with the reduced shot railguns. The component design shows a reduced power requirement for reduced shot weapons, but in the ship design screen, it appears they require the same amount of power as a full-size railgun. For example, a single shot C3 10cm railgun requires .75 power per the component design screen, but according to the ship design screen it requires 3 power.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on April 27, 2021, 03:56:04 PM
I can't really play it either. The blue color kills me  :'(

 - A friendly reminder that Steve is colorblind. :)
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on April 27, 2021, 04:18:59 PM
I can't really play it either. The blue color kills me  :'(

90% of the time is Nvidia settings that make the blue super bright to an extent that is disturbing. I noticed because I play on multiple stations, and some had the nice dark blue as it was in Aurora VB6.

In a couple, as I did not want to change the settings only for aurora, I have sorted launching the application in 8bit colors. Try that. It's not 100%, but worth a try.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on April 27, 2021, 04:22:23 PM
I can't really play it either. The blue color kills me  :'(

 - A friendly reminder that Steve is colorblind. :)

Wait for real? That does I suppose explain much of the issues that people have. I imagine its quite comfortable for him.
Title: Re: v1.13.0 Bugs Thread
Post by: Exultant on April 28, 2021, 08:35:12 AM
The function number: 1951, 1943, 478
The complete error text An item with the same key has already been added Object reference not set to an instance of an object
The window affected main screen
What you were doing at the time Finishing a battle at the NPR homeworld (though there was some NPR-NPR fighting somewhere else in the galaxy just before the error)
Conventional or TN start TN
Random or Real Stars Real
Is your decimal separator a comma? No. US Layout
Is the bug is easy to reproduce, intermittent or a one-off? Second time it happened, but since I suspect it's NPR related, I don't think I can reproduce on command.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well 65 years into a game.

The only other "unusual" thing happening is I have some ships massively overloaded with survivors I picked up from destroying the NPRs commercial shipping.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on April 28, 2021, 03:01:11 PM
On the Naval Organization window, if you drag a Naval Admin Command into one of its own children, the game locks up (likely from an infinite loop as it tries to build the new hierarchy).

Probably the game should check to see if the dragged NAC is an ancestor of the target NAC, and either ignore the attempted change or remove the dragged NAC from the list prior to building the new hierarchy.

SJW: Can't reproduce. This is working fine for me.
Title: Re: v1.13.0 Bugs Thread
Post by: Stryker on April 28, 2021, 03:58:56 PM
There is a bug with use for replacement of ground forces.  I created a training battalion with an assortment of units, and set them to use for replacement.  The training battalion included a divisional hq, 2 brigade hqs and battalion hqs.  Use for replacement added the divisional hq and the bridge hq as well as supply vehicles to the battalion.  I don't use supply vehicles in my battalions but rather infantry supply dumps.  It also added artillery, construction vehicle, etc.

Note that none of these units are in the formation template.  Additionally, these units were not assigned to the unit series.

SJW: As noted in the posts below, this is working as intended
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on April 28, 2021, 04:31:54 PM
Additionally, these units were not assigned to the unit series.

This is your problem. Unit replacement does not work if the units that your trying to replace do not belong in a unit series.

Though now that I reread your post, is the game just adding random units to the wrong formations? Can your please post the affected formations, both the replacer and the replacee.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on April 28, 2021, 05:41:30 PM
Additionally, these units were not assigned to the unit series.

This is your problem. Unit replacement does not work if the units that your trying to replace do not belong in a unit series.

Though now that I reread your post, is the game just adding random units to the wrong formations? Can your please post the affected formations, both the replacer and the replacee.

Replacements work only if every designed unit has a series counterpart. When designing a unit, you MUST also set up the series in the relative window after such a unit has been researched. It was highlighted in many other posts. I hope this helps.
Title: Re: v1.13.0 Bugs Thread
Post by: Stryker on April 28, 2021, 06:40:29 PM
Additionally, these units were not assigned to the unit series.

This is your problem. Unit replacement does not work if the units that your trying to replace do not belong in a unit series.

Though now that I reread your post, is the game just adding random units to the wrong formations? Can your please post the affected formations, both the replacer and the replacee.

Replacements work only if every designed unit has a series counterpart. When designing a unit, you MUST also set up the series in the relative window after such a unit has been researched. It was highlighted in many other posts. I hope this helps.

I know this.  I have the unit series set.  Read the post, replacement is adding units from other series that are not in the battalion formation.  Example: divisional hq.  The divisional hq is in it's own series.  It is used in the division formation and the division formation alone.  Yet it is being added to the battalion formation.  This is just an example.  The same thing is happening with main battle tank, brigade hqs, supply vehicles, etc.
Title: Re: v1.13.0 Bugs Thread
Post by: Stryker on April 28, 2021, 07:12:02 PM
Here are 4 screen shots, the unit series, infantry battalion formation, training battalion formation and an infantry battalion after replacement.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 28, 2021, 07:15:56 PM
Here are 4 screen shots, the unit series, infantry battalion formation, training battalion formation and an infantry battalion after replacement.

Your 1st Infantry Battalion has its replacement template set as Training Battalion. Change this back to Infantry Battalion and it should behave correctly.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on April 28, 2021, 07:17:29 PM
Here are 4 screen shots, the unit series, infantry battalion formation, training battalion formation and an infantry battalion after replacement.

Your 1st Infantry Battalion has its replacement template set as Training Battalion. Change this back to Infantry Battalion and it should behave correctly.

Yep, that is the only thing out of place atm.
Title: Re: v1.13.0 Bugs Thread
Post by: Stryker on April 28, 2021, 07:48:36 PM
Here are 4 screen shots, the unit series, infantry battalion formation, training battalion formation and an infantry battalion after replacement.

Your 1st Infantry Battalion has its replacement template set as Training Battalion. Change this back to Infantry Battalion and it should behave correctly.

Yep, that is the only thing out of place atm.

I see.  It's using the whole template, rather than the series.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on April 28, 2021, 09:16:14 PM
Here are 4 screen shots, the unit series, infantry battalion formation, training battalion formation and an infantry battalion after replacement.

Your 1st Infantry Battalion has its replacement template set as Training Battalion. Change this back to Infantry Battalion and it should behave correctly.

Yep, that is the only thing out of place atm.

I see.  It's using the whole template, rather than the series.

Think of the replacement template of a formation as the "target" template that formation is trying to achieve. It's going to get as close to the replacement template as it can by drawing units from relevant unit series from formations where you have checked "use for replacements".

Also worth noting that when placing units inside a unit series, place your most modern units of that series at the top of the corresponding list. When replacing units, the game will work from top-to-bottom for any given unit series.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 28, 2021, 09:20:27 PM
I see.  It's using the whole template, rather than the series.

To be precise: the "Replacement Template" is the template which the formation will try to pull replacement elements to match (from formations marked for use as replacements). If your infantry battalion has the "Training Battalion" as its replacement template, it will try to pull replacement elements from other formations to match the OOB of a Training Battalion.

The "Replacement Template" is not the type of formation from which reinforcements will be drawn. Understandable confusion.

The Unit Series system defines types of elements, not formations, and is really intended to be used to replace units of the same type which might have multiple versions. For example, your first Infantry Rifle might be researched with racial attack and armor of 8, and later you may research Infantry Rifle Mk II with attack/armor 10 and place it in the same series. This allows replacements to be pulled from the older mark if the newer mark is not available, or allows formations composed of older units to be replenished with newer models. This aside, the important thing is that while Series and Templates work together they are two different systems not to be confused.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 29, 2021, 04:41:18 AM
In the class design screen, on "Race Components", when a component is selected opening and closing a category (ex. Engine) will add that component to the ship.

I can't reproduce this one - anyone else have a similar problem?
Title: Re: v1.13.0 Bugs Thread
Post by: DeMatt on April 29, 2021, 06:08:45 AM
In the class design screen, on "Race Components", when a component is selected opening and closing a category (ex. Engine) will add that component to the ship.

I can't reproduce this one - anyone else have a similar problem?
I was able to reproduce - select a component in one category (e.g. Fuel Storage - Small), then open and close a different category (e.g. Crew Quarters), and the selected component will get added.  The category-clicking needs to be on the +/- icon in the tree, and the clicking needs to be fairly quick - a double-click, as it were.

Continuing, if you switch to the "Class Components" tab and do the same process, the component will be removed from the ship.  The crew/armor recalculation/refresh will deselect the component in between each removal.  You can switch to "Wide View" to view both the Race and Class Components simultaneously, but it doesn't work cross-panel - Race component + Race category, or Class + Class, not Race + Class.
Title: Re: v1.13.0 Bugs Thread
Post by: stabliser on April 29, 2021, 07:20:22 AM
Aliens attacked Earth and reduced one of the shipyards to -13 slipways.  Its not a big problem but I think they intended to stop destroying slipways at zero.    That was 30+ years into the Eample game in the database, I didnt save.   :-[ ::)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 29, 2021, 09:16:09 AM
There's a bug with the reduced shot railguns. The component design shows a reduced power requirement for reduced shot weapons, but in the ship design screen, it appears they require the same amount of power as a full-size railgun. For example, a single shot C3 10cm railgun requires .75 power per the component design screen, but according to the ship design screen it requires 3 power.

Seems to be working fine on the ship design for me. Could you post a screenshot of the problem?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 29, 2021, 09:19:39 AM
I can't really play it either. The blue color kills me  :'(

 - A friendly reminder that Steve is colorblind. :)

Wait for real? That does I suppose explain much of the issues that people have. I imagine its quite comfortable for him.

To be honest, I forget about that as it doesn't affect daily life. I can see normal colours, but I struggle with shades. There is a book test with lots of dots in a circle and a number that is in different shades. I can do the first one and then I can't see any of the other numbers. I found out when I applied to join the RAF at 18 :)
Title: Re: v1.13.0 Bugs Thread
Post by: Bubbaisagod on April 29, 2021, 11:14:18 AM
The function number: n/a
The complete error text: n/a
The window affected: Economics ==> Shipyard
What you were doing at the time: n/a
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 16Y


I don't know if it's wai or a bug but obsolete ship designs stay available until retooling of the shipyard.

If you obsolete a ship design but do not retool your shipyard to the revised design, you can keep building the old design.
In my case a tug 50kt without a tractor beam and the new tug 51kt with tractor beam and some extra fuel.
Both can be build from the same shipyard. I obsoleted the first tug but that did not change the build options in the shipyard.
Only after retooling did the build option go away.

SJW: That is working as intended
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on April 29, 2021, 11:23:48 AM
The function number: n/a
The complete error text: n/a
The window affected: Economics ==> Shipyard
What you were doing at the time: n/a
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 16Y


I don't know if it's wai or a bug but obsolete ship designs stay available until retooling of the shipyard.

If you obsolete a ship design but do not retool your shipyard to the revised design, you can keep building the old design.
In my case a tug 50kt without a tractor beam and the new tug 51kt with tractor beam and some extra fuel.
Both can be build from the same shipyard. I obsoleted the first tug but that did not change the build options in the shipyard.
Only after retooling did the build option go away.

I believe that is WAI.
Obsoleting a design has no mechanical effect, it just declutters the ship design list.
Title: Re: v1.13.0 Bugs Thread
Post by: Bremen on April 29, 2021, 12:35:24 PM
I can't really play it either. The blue color kills me  :'(

 - A friendly reminder that Steve is colorblind. :)

Wait for real? That does I suppose explain much of the issues that people have. I imagine its quite comfortable for him.

To be honest, I forget about that as it doesn't affect daily life. I can see normal colours, but I struggle with shades. There is a book test with lots of dots in a circle and a number that is in different shades. I can do the first one and then I can't see any of the other numbers. I found out when I applied to join the RAF at 18 :)

Just to add in, I think someone else has something to it also being a monitor/graphics card issue; I'm not color blind and to me it's nicely distinct white/light green text on a dark blue background, even in screenshots, so it's always kind of weirded me out why some people say it's unreadable (and, truth be told, I admit I kind of wondered if it was just being used as a justification for 3rd party versions). If it really does show up as white text on bright blue background on some computers that would make more sense, and it would even fit with the screenshots - if it's not the game itself working differently, the screenshots themselves might look different on different computers.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 29, 2021, 12:46:04 PM
In the class design screen, on "Race Components", when a component is selected opening and closing a category (ex. Engine) will add that component to the ship.

I can't reproduce this one - anyone else have a similar problem?
I was able to reproduce - select a component in one category (e.g. Fuel Storage - Small), then open and close a different category (e.g. Crew Quarters), and the selected component will get added.  The category-clicking needs to be on the +/- icon in the tree, and the clicking needs to be fairly quick - a double-click, as it were.

Continuing, if you switch to the "Class Components" tab and do the same process, the component will be removed from the ship.  The crew/armor recalculation/refresh will deselect the component in between each removal.  You can switch to "Wide View" to view both the Race and Class Components simultaneously, but it doesn't work cross-panel - Race component + Race category, or Class + Class, not Race + Class.

Reproduced now thanks - a very specific bug. This happens because the double-click event is associated with the treeview control and uses the currently selected node as the target. It can only happen by double-clicking on the +/- icon while another node is selected, which is a very unusual thing to do (as this is the first time this has been reported). I could do some checking around location of mouse when the double-click happens, but that could lead to other bugs. Given the rarity and minimal impact, I think this is one I am going to live with :)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 29, 2021, 12:47:44 PM
I can't really play it either. The blue color kills me  :'(

 - A friendly reminder that Steve is colorblind. :)

Wait for real? That does I suppose explain much of the issues that people have. I imagine its quite comfortable for him.

To be honest, I forget about that as it doesn't affect daily life. I can see normal colours, but I struggle with shades. There is a book test with lots of dots in a circle and a number that is in different shades. I can do the first one and then I can't see any of the other numbers. I found out when I applied to join the RAF at 18 :)

Just to add in, I think someone else has something to it also being a monitor/graphics card issue; I'm not color blind and to me it's nicely distinct white/light green text on a dark blue background, even in screenshots, so it's always kind of weirded me out why some people say it's unreadable (and, truth be told, I admit I kind of wondered if it was just being used as a justification for 3rd party versions). If it really does show up as white text on bright blue background on some computers that would make more sense, and it would even fit with the screenshots - if it's not the game itself working differently, the screenshots themselves might look different on different computers.

That is a good point. The blue is noticeably different on the two different monitors I use (and that from someone who is colour blind).
Title: Re: v1.13.0 Bugs Thread
Post by: Zap0 on April 29, 2021, 01:31:28 PM
In the class design screen, on "Race Components", when a component is selected opening and closing a category (ex. Engine) will add that component to the ship.

I can't reproduce this one - anyone else have a similar problem?
I was able to reproduce - select a component in one category (e.g. Fuel Storage - Small), then open and close a different category (e.g. Crew Quarters), and the selected component will get added.  The category-clicking needs to be on the +/- icon in the tree, and the clicking needs to be fairly quick - a double-click, as it were.

Continuing, if you switch to the "Class Components" tab and do the same process, the component will be removed from the ship.  The crew/armor recalculation/refresh will deselect the component in between each removal.  You can switch to "Wide View" to view both the Race and Class Components simultaneously, but it doesn't work cross-panel - Race component + Race category, or Class + Class, not Race + Class.

Reproduced now thanks - a very specific bug. This happens because the double-click event is associated with the treeview control and uses the currently selected node as the target. It can only happen by double-clicking on the +/- icon while another node is selected, which is a very unusual thing to do (as this is the first time this has been reported). I could do some checking around location of mouse when the double-click happens, but that could lead to other bugs. Given the rarity and minimal impact, I think this is one I am going to live with :)

I'm getting the same behavior of added modules if I double click anywhere in the list while a component is selected. Just anywhere to the right of the components in empty space will do. Happens to me frequently that I add/remove something I didn't want when I misclick.
Title: Re: v1.13.0 Bugs Thread
Post by: DFNewb on April 29, 2021, 11:13:04 PM
Quote
Ground Support Fighters

Fleets with this order that are at their target population cannot be targeted in normal naval combat or by STO weapons.

Quote
Search and Destroy involves sending fighters to a planet with enemy ground forces (with or without friendly forces present) to attack targets of opportunity. This is similar to a ground support mission with the following differences:
The fighters do not need to be assigned to a friendly ground formation and do not require fire direction
The fighters will select any hostile formation, regardless of field position
The chance to hit is 33% of normal
Hostile AA will fire as if this is a ground support mission directed against the selected formation

From these two posts I would assume search and destroy fighters could not be targeted / shot at by regular fleets but my search and destroy fighters were destroyed by an invader's ship while attacking a Rakha planet.

Is this a bug? Or are search and destroy fighters open to be hit by ship weapons?

Also same with flak suppression.

SJW: That is a bug. I've removed fighters on above missions from potential targets list on Naval Org window and also from AI fire decision code.
Title: Re: v1.13.0 Bugs Thread
Post by: mike2R on April 30, 2021, 01:39:38 AM
Spacestations built with alien tech do not seem to either check you have any/enough of that alien tech to build them, or to decrease the amount you have available in stock.

To reproduce, acquire something you haven't researched from a ruin and add it to a spacestation design (I tested with Terraforming Modules).  You can then build as many spacestations as you want without using up your component stock, even if you scrap all of the components.

SJW: Fixed for v.1.14. Also fixed for prototype components.
Title: Re: v1.13.0 Bugs Thread
Post by: Density on April 30, 2021, 04:02:28 AM
Quote from: Steve Walmsley link=topic=12522. msg150834#msg150834 date=1619705769
Quote from: Desdinova link=topic=12522. msg150770#msg150770 date=1619556479
There's a bug with the reduced shot railguns.  The component design shows a reduced power requirement for reduced shot weapons, but in the ship design screen, it appears they require the same amount of power as a full-size railgun.  For example, a single shot C3 10cm railgun requires . 75 power per the component design screen, but according to the ship design screen it requires 3 power.

Seems to be working fine on the ship design for me.  Could you post a screenshot of the problem?

Long time lurker, first time poster.

If it's a C3, then I believe this is WAI.  That is, AFAIK the ship design screen checks the capacitor of the weapon, not the power it needs.  Which is great when you have a weapon that needs more power than your best capacitor rate; not so much when you forget to scale back the capacitor when designing a smaller weapon.
So that screen will check for three power on a C3 single-shot 10cm railgun, but only checks for 1 power on a C1 single-shot.  (Of course, I keep looking for and not finding a C0. 75 option when designing these. )
Title: Re: v1.13.0 Bugs Thread
Post by: Zap0 on April 30, 2021, 04:46:15 AM
The 0.75 capacitor recharge, or other odd small numbers, happens when you select reduced size lasers/railguns.

edit: screenshot of component design screen. Imagine the guy just confused the power requirement as shown and the capacitor which, as you say, seems to determine the real maximum power draw.
Title: Re: v1.13.0 Bugs Thread
Post by: Density on April 30, 2021, 05:10:23 AM
Quote from: Zap0 link=topic=12522. msg150878#msg150878 date=1619775975
The 0. 75 capacitor recharge, or other odd small numbers, happens when you select reduced size lasers/railguns.

No, 0. 75 is the power requirement, not the capacitor.  I meant I wish there was a C0. 75 option to put on a weapon with a 0. 75 power requirement, but the minimum seems to be C1.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on April 30, 2021, 07:55:19 AM
Long time lurker, first time poster.

Welcome, and thanks for jumping in.  :)
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on April 30, 2021, 11:50:18 AM
Admin Command Bonuses for Fleet Training do not stack.

It appears that Training NACs do not benefit from ancestor bonuses like other NACs do.

I have a stack of five Training NACs, commanded by officers of appropriate rank (VADM, RADM, RADL, CAPT, CDR).

I placed a brand new fighter (with no commander) under the lowest NAC (CDR), whose leader has a Crew Training rating of 150.
After 37 days, the fleet training bonus of the ship was 4%.

I then placed another brand new fighter (with no commander) under the highest NAC (VADM), whose leader has a Crew Training rating of 275.
If the NACs are benefiting from parent bonuses, then this fighter should get less fleet training in 37 days than the first fighter, because this one is missing out on four levels of hierarchy.
Instead, after 37 days, the fleet training bonus of this ship was 6%.

SJW: Fixed for v1.14. See this post: http://aurora2.pentarch.org/index.php?topic=12523.msg151011#msg151011
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 12:37:39 PM
There is no event log message when your Xenosurvey Crew unearths special fun things. They just appear and start shooting. It would be nice if there were a short, flavor game log message describing what happened.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 12:42:23 PM
Choosing to build a ship using pre-fabricated components, and then canceling the ship construction, does not return the pre-fabricated components to you. I found out when I canceled construction very early on (fixing a minor design issue) and reissued the construction commands, and suddenly had to wait 3 extra years for them to build. I feel like this is less than ideal.

SJW: This is WAI. If you are halfway through a normal ship construction and cancel it, nothing is returned either.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 30, 2021, 12:50:17 PM
Choosing to build a ship using pre-fabricated components, and then canceling the ship construction, does not return the pre-fabricated components to you. I found out when I canceled construction very early on (fixing a minor design issue) and reissued the construction commands, and suddenly had to wait 3 extra years for them to build. I feel like this is less than ideal.

It's unfortunate, but not a bug. The information that the ship was built with XYZ components is simply not stored once the construction begins. The components are consumed, the construction time and resources adjusted as needed, and that's the end of it. WAD, though perhaps not exactly WAI.

As I don't believe you can SM components to a planetary stockpile it may be a suitable workaround to re-build the components from factories and use SM to add the materials back to your stockpiles.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 01:08:58 PM
Choosing to build a ship using pre-fabricated components, and then canceling the ship construction, does not return the pre-fabricated components to you. I found out when I canceled construction very early on (fixing a minor design issue) and reissued the construction commands, and suddenly had to wait 3 extra years for them to build. I feel like this is less than ideal.

It's unfortunate, but not a bug. The information that the ship was built with XYZ components is simply not stored once the construction begins. The components are consumed, the construction time and resources adjusted as needed, and that's the end of it. WAD, though perhaps not exactly WAI.

As I don't believe you can SM components to a planetary stockpile it may be a suitable workaround to re-build the components from factories and use SM to add the materials back to your stockpiles.

That's why I reported it.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 01:10:59 PM
I'm 100+ years into a game, and the past few years I have been getting this error box once per construction cycle:

(https://i.imgur.com/IGIJcZF.png)

What is this error signifying?

Edit: This is an Earth in-spiral 0.01 AU/year game.

Edit Edit: It looks like this error is probably caused after the Earth/moon system is destroyed. The disaster appears to still be "enabled", but there is no longer an Earth to move closer to the sun. Disabling the disaster in the settings seems to have fixed the #1552 error.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Black on April 30, 2021, 01:35:51 PM
Ground Combat Command is still presend in Commanders window as parameter in right-down part where you can sort commander.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 04:18:37 PM
I got two or three #2939 errors while processing the turn (I was expecting a new system to be jumped into and generated), and then the game froze for 10 minutes. I don't think it's going to recover, so I had to force-close it and resume from my last save a few minutes prior.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 06:22:44 PM
There does not seem to be any place in C# to flag a system as having a "Suspected Dormant Jump Point" like there was in VB6. There is no place to set this flag on the Galaxy Map, System Map, or in the System Bodies Window.
Title: Re: v1.13.0 Bugs Thread
Post by: Zap0 on April 30, 2021, 06:37:07 PM
There does not seem to be any place in C# to flag a system as having a "Suspected Dormant Jump Point" like there was in VB6. There is no place to set this flag on the Galaxy Map, System Map, or in the System Bodies Window.

There is, not sure if it has any function though. Toggling it didn't seem to make it stick active for that system.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 07:13:34 PM
There does not seem to be any place in C# to flag a system as having a "Suspected Dormant Jump Point" like there was in VB6. There is no place to set this flag on the Galaxy Map, System Map, or in the System Bodies Window.

There is, not sure if it has any function though. Toggling it didn't seem to make it stick active for that system.

That is just for display. There is no way to toggle the flag for the system (that anyone can find).
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on April 30, 2021, 07:14:49 PM
Obfuscation strikes again! When my active search sensor passed over the hidden jump gate, it was detected. The game log displayed it thusly:

(https://i.imgur.com/tvVl2eQ.png)

"New jump point detected in i4"

SJW: Fixed for v1.14. This will only affect the specific situation of detecting a transit through an unknown jump point.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 01, 2021, 06:42:14 AM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; scrapping ships, exploring, systems missing comets,
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? scrapping easy, missing comets intermittent, few warp points?
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 43 years


Potential bug 1: After you mark a ship design as obsolete those ships of that design no longer show up in shipyard lists for scrapping. Un-obsolete  them and they show up.

Potential bug 2; I set minimum number of comets per system as 10. However a number of systems appear cometless. This may be working as intended.

Potential bug 3; In setup I changed local system generation spread from 15 to 7 or 8 (tried both). I found that warp points were very sparse. that 7 local system generation spread game ran out of warp points at 15-20 systems (game deleted). The 8 local system generation spread found a maximum of 2 systems with 3 warp points the rest had 1 or 2 warp points for a total of 23 systems. With only 1 unexplored warp point left I changed local system generation spread to 15. I now have 55 systems explored with 10 systems having more than 2 warp points plus 6 systems not yet fully explored. However this may be working as intended.

SJW: #1 Can't reproduce. #2 Fixed. #3 Number of JP and Local Generation not related.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 01, 2021, 08:26:46 AM
A user on the discord playing a very small galaxy of 25 stars found a natural jump point that led to the same system it was in.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 01, 2021, 09:03:07 AM
Fleet history is greatly slowing down the save speed of my 100+ year game. For the first time since reinstalling 1.13 from scratch, I opened up the database in an SQL editor and deleted all but the most recent fleet history, which amounted to around 240,000 entries. There were also an inordinate number of GameLog messages about NPR fleets running out of fuel.

Once I deleted all log entries of those two types, saving my game went from 13 seconds before, to just 6 seconds after cleaning the database. (On an SSD, with a top-tier CPU)

I would recommend wiping Fleet History for civilian shipping lines after some number of years (10? 20?) and same with NPRs. Player naval fleet histories should be kept forever.

SJW: Suggestions rather than Bugs. However, I have removed NPR and Shipping Line fleet histories beyond five years.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 01, 2021, 09:12:08 AM
It can be a bit of a hassle to maximize your FAC design (quite frustratingly so!), because each time you go over 1,000 tons a bridge is automatically added, and in 1.13 it is still possible that you can't remove a bridge even though it would take you back under 1,000 tons when it is very, very close to the 1,000-ton limit. I assume this is because it isn't taking into account the armor or crew quarters that would also be removed when the bridge is taken off.

If there were something like a toggleable checkbox on the right side of the ship design window that says "SJW: Suggestion rather than Bug. However, I have changed the automatic bridge code in a different way: http://aurora2.pentarch.org/index.php?topic=12523.msg151016#msg151016
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 01, 2021, 09:45:11 AM
It can be a bit of a hassle to maximize your FAC design (quite frustratingly so!), because each time you go over 1,000 tons a bridge is automatically added, and in 1.13 it is still possible that you can't remove a bridge even though it would take you back under 1,000 tons when it is very, very close to the 1,000-ton limit. I assume this is because it isn't taking into account the armor or crew quarters that would also be removed when the bridge is taken off.

If there were something like a toggleable checkbox on the right side of the ship design window that says "
  • No Bridge" and simply prevents a bridge from being automatically added to your ship design, that would solve this annoyance in a pretty reasonable way.
This really belongs in the suggestions thread but I support it anyways.
Title: Re: v1.13.0 Bugs Thread
Post by: ZimRathbone on May 01, 2021, 11:17:15 AM
A user on the discord playing a very small galaxy of 25 stars found a natural jump point that led to the same system it was in.

I don't think that's a bug.   I have had that happen a number of times (including my recent 1.12 game) but its fairly rare and occasionally tactically useful as happened in an old VB game.

In my latest game the only effect was to shorten some distances within the system like LPs do
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 01, 2021, 11:23:58 AM
Potential bug 2; I set minimum number of comets per system as 10. However a number of systems appear cometless. This may be working as intended.

Not WAI according to the tooltip, thus is a bug.

Quote
Potential bug 3; In setup I changed local system generation spread from 15 to 7 or 8 (tried both). I found that warp points were very sparse. that 7 local system generation spread game ran out of warp points at 15-20 systems (game deleted). The 8 local system generation spread found a maximum of 2 systems with 3 warp points the rest had 1 or 2 warp points for a total of 23 systems. With only 1 unexplored warp point left I changed local system generation spread to 15. I now have 55 systems explored with 10 systems having more than 2 warp points plus 6 systems not yet fully explored. However this may be working as intended.

Running out of JPs does happen occasionally, I remember a post where a player had I think 8 systems and ran out of new JPs. Usually the fix is to SM a few new JPs in frontier systems, and a workaround is to increase the minimum number of JPs in Sol to make such an event far less probable.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 01, 2021, 11:44:39 AM
Potential bug 2; I set minimum number of comets per system as 10. However a number of systems appear cometless. This may be working as intended.

Not WAI according to the tooltip, thus is a bug.

Quote
Potential bug 3; In setup I changed local system generation spread from 15 to 7 or 8 (tried both). I found that warp points were very sparse. that 7 local system generation spread game ran out of warp points at 15-20 systems (game deleted). The 8 local system generation spread found a maximum of 2 systems with 3 warp points the rest had 1 or 2 warp points for a total of 23 systems. With only 1 unexplored warp point left I changed local system generation spread to 15. I now have 55 systems explored with 10 systems having more than 2 warp points plus 6 systems not yet fully explored. However this may be working as intended.

Running out of JPs does happen occasionally, I remember a post where a player had I think 8 systems and ran out of new JPs. Usually the fix is to SM a few new JPs in frontier systems, and a workaround is to increase the minimum number of JPs in Sol to make such an event far less probable.

Potential bug 3; This error then has been present since VB6! When I first noticed it, but appears to have become worse.


Potential bug 2; I did it for the first game but then was doing it every time I wanted to explore. The second game was to see if it was repeatable and what effect changing the value to 15 would have.

SJW: #2 is Fixed. #3 WAI.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 01, 2021, 03:24:02 PM
Just to add to the obfuscation pile - On the "ancient constructs" tab on the economy/industry screen, the names of the research fields are obfuscated, showing up as:

a (this one I know is supposed to be power & propulsion)
b
c
d
e
f
g
h
i
10

SJW: Already raised and fixed earlier in the thread
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 01, 2021, 03:58:12 PM
Also I noticed that the DB has an entry for a ground component called "Super-Heavy Bombardment", which lacks its associated technology - rendering it unusable without DB editing to add its tech.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 01, 2021, 05:32:38 PM
The button to turn on Active Sensors at the bottom of the Naval Organization window only appears when you select individual ships. There doesn't seem to be any "single click" button to turn on active sensors for the entire fleet, like there was in VB6. Instead, right now the workaround is to use movement orders (and juggle waypoints/point of interest) to turn on or off the entire fleet's active sensors.

SJW: Suggestion, not bug. I've added anyway, but in future please use suggestion thread.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 01, 2021, 11:21:51 PM
I was conducting an orbital drop against the Rakhas. Some of the troop drop pod components got damaged by STO immediately prior to dropping, which may or may not be relevant.

Then, on each subsequent combat phase, I got a single "Function #1793: Attempted to divide by zero" error box every turn.

SJW: #1793 is the breakthrough code. Only way for this bug to happen would be a formation with no units managing a breakthrough. I've added code to handle that situation.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on May 02, 2021, 04:31:36 AM
I was conducting an orbital drop against the Rakhas. Some of the troop drop pod components got damaged by STO immediately prior to dropping, which may or may not be relevant.

Then, on each subsequent combat phase, I got a single "Function #1793: Attempted to divide by zero" error box every turn.

I think it does that when a formation in the ground unit tree remains without any units and get cancelled. I remember seeing and noticing that every ground combat. It was unclear at the beginning but then I tested and I verified it. As far as I know, it does not cause any issue.

SJW: Yes, that is the issue. Fixed now.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 02, 2021, 10:35:50 AM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; Research
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? Finding engine tech easy.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 48 years

I was researching engine tech and was OK up to Magneto-plasma Drive Technology cost 45,000 RP, I seemed to miss Inertial confinement fusion Drive Technology (40,000 RP) but to get to the  next engine tech I have to research Plasma-core anti-matter power plant RP 750,000. I have researched all power plant techs up to this one but no new engine tech. Is this WAI?

SJW: As noted later in thread, this is not a bug. However, I have modified engine tech naming to avoid confusion in future.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 02, 2021, 10:38:04 AM
"Exclude Surveyed" checkbox excludes ALL moons.

I have a system with 42 moons, all orbiting a single planet.
In the System Generation and Display window, I can see that 14 moons are not yet surveyed.

In Naval Organization -> Movement Orders, with a fleet in this system selected, and System Locations selected:
If "Exclude Surveyed" is unchecked, all 42 moons are listed.
If "Exclude Surveyed" is checked, zero moons are listed.

SJW: I think the parent planet for the unsurveyed moons was surveyed and that is what stopped them appearing. Fixed for v1.14.

Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 02, 2021, 10:47:20 AM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; Research
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? Finding engine tech easy.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 48 years

I was researching engine tech and was OK up to Magneto-plasma Drive Technology cost 45,000 RP, I seemed to miss Inertial confinement fusion Drive Technology (40,000 RP) but to get to the  next engine tech I have to research Plasma-core anti-matter power plant RP 750,000. I have researched all power plant techs up to this one but no new engine tech. Is this WAI?

Definitely not WAI.
Cost of Inertial Confinement Fusion Reactor should be 90k.
Cost of Plasma-core is correct, but there are two more techs before this one, after Inertial Confinement:
Solid-core Anti-matter Power Plant (180k)
Gas-core Anti-matter Power Plant (375k)

Did you happen to get those for free somehow?
Title: One Jump Drive Per Ship
Post by: josh wood on May 02, 2021, 11:58:03 AM
You are only allowed 1 Jump drive per ship

Since Military jump drives are a commercial component it would make sense that you would be able to make a Commercial ship capable of jumping military engines ships, right? This is currently not the case because you need a SECOND jump drive for the commercial ship, which isn't possible

The current situation Requires 2 ships:

Ship A has a Military jump drive capable of jumping your military ships
Ship B has a commercial jump drive capable of jumping your commercial ships

This provides another problem, A fleet requiring multiple jump drives for their multiple types of ships is not possible.  This means using commercial ships for military jump engines is an almost pointless feature without being able to add 2 drives to the same ship. 

SJW: This is WAI. See my reply later in thread.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 02, 2021, 12:59:15 PM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; Research
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? Finding engine tech easy.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 48 years

I was researching engine tech and was OK up to Magneto-plasma Drive Technology cost 45,000 RP, I seemed to miss Inertial confinement fusion Drive Technology (40,000 RP) but to get to the  next engine tech I have to research Plasma-core anti-matter power plant RP 750,000. I have researched all power plant techs up to this one but no new engine tech. Is this WAI?

Definitely not WAI.
Cost of Inertial Confinement Fusion Reactor should be 90k.
Cost of Plasma-core is correct, but there are two more techs before this one, after Inertial Confinement:
Solid-core Anti-matter Power Plant (180k)
Gas-core Anti-matter Power Plant (375k)

Did you happen to get those for free somehow?

No I researched all the previous power plants but didn't work out that Inertial confinement fusion Drive  followed Magneto-plasma Drive Technology, It cost less so I thought it must precede it - wrong!
Title: Re: One Jump Drive Per Ship
Post by: Droll on May 02, 2021, 01:00:21 PM
You are only allowed 1 Jump drive per ship

Since Military jump drives are a commercial component it would make sense that you would be able to make a Commercial ship capable of jumping military engines ships, right? This is currently not the case because you need a SECOND jump drive for the commercial ship, which isn't possible

The current situation Requires 2 ships:

Ship A has a Military jump drive capable of jumping your military ships
Ship B has a commercial jump drive capable of jumping your commercial ships

This provides another problem, A fleet requiring multiple jump drives for their multiple types of ships is not possible.  This means using commercial ships for military jump engines is an almost pointless feature without being able to add 2 drives to the same ship.

Idk how it happened but when the post that I'm quoting got posted, the entire thread was renamed to "One Jump Drive Per Ship", which I'm pretty sure should not happen.
Edit: Quoting it also renamed the bug thread through this post.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 02, 2021, 01:42:29 PM
No I researched all the previous power plants but didn't work out that Inertial confinement fusion Drive  followed Magneto-plasma Drive Technology, It cost less so I thought it must precede it - wrong!

Perhaps you are confusing "Inertial" with "Internal"?

Internal Confinement Fusion Drive Technology costs 40k.
Inertial Confinement Fusion Drive Technology costs 150k.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 02, 2021, 01:44:52 PM
Fleet history is greatly slowing down the save speed of my 100+ year game. For the first time since reinstalling 1.13 from scratch, I opened up the database in an SQL editor and deleted all but the most recent fleet history, which amounted to around 240,000 entries. There were also an inordinate number of GameLog messages about NPR fleets running out of fuel.

Once I deleted all log entries of those two types, saving my game went from 13 seconds before, to just 6 seconds after cleaning the database. (On an SSD, with a top-tier CPU)

I would recommend wiping Fleet History for civilian shipping lines after some number of years (10? 20?) and same with NPRs. Player naval fleet histories should be kept forever.

I'm attaching my unedited AuroraDB.db file that I backed up right before I made the above changes, just in case Steve wants to investigate 1) The reported issue above regarding "Saving" slowdown due to Fleet History and Game Log record spam; and 2) The more general issue of late-game turn generation slowdown.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 02, 2021, 01:45:51 PM
No I researched all the previous power plants but didn't work out that Inertial confinement fusion Drive  followed Magneto-plasma Drive Technology, It cost less so I thought it must precede it - wrong!

Perhaps you are confusing "Inertial" with "Internal"?

Internal Confinement Fusion Drive Technology costs 40k.
Inertial Confinement Fusion Drive Technology costs 150k.

I do wish one of these technologies would get renamed. They're so hard to distinguish in-game, and easy to get confused by :)
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 02, 2021, 02:12:57 PM
No I researched all the previous power plants but didn't work out that Inertial confinement fusion Drive  followed Magneto-plasma Drive Technology, It cost less so I thought it must precede it - wrong!

Perhaps you are confusing "Inertial" with "Internal"?

Internal Confinement Fusion Drive Technology costs 40k.
Inertial Confinement Fusion Drive Technology costs 150k.

Guilty as charged! I was confusing power plant techs with engine techs, sorry!

 
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 02, 2021, 03:20:58 PM
No I researched all the previous power plants but didn't work out that Inertial confinement fusion Drive  followed Magneto-plasma Drive Technology, It cost less so I thought it must precede it - wrong!

Perhaps you are confusing "Inertial" with "Internal"?

Internal Confinement Fusion Drive Technology costs 40k.
Inertial Confinement Fusion Drive Technology costs 150k.

I do wish one of these technologies would get renamed. They're so hard to distinguish in-game, and easy to get confused by :)

"Internal" really should be something like "Electrostatic" to imply the sort of confinement devices that basically preceded the tokamak. Not quite accurate but closer and less confusing.
Title: Re: v1.13.0 Bugs Thread
Post by: Exultant on May 02, 2021, 09:37:31 PM
The function number: 3 numbers, forgot 2 of them (didn't write them down like an idiot) but one of them was 222
The complete error Object reference not set to an instance of an object was one of them
The window affected main screen
What you were doing at the time System exploration spawning an NPR
Conventional or TN start TN
Random or Real Stars Real
Is your decimal separator a comma? No. US Layout
Is the bug is easy to reproduce, intermittent or a one-off? Not sure if this is a database corruption issue - if it's reproducible it will be if I get another NPR spawn - I may have just been unlucky
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well 81 years into a game.

This is the same game as my post 5 days ago when I had other errors. On system exploration, an NPR spawned and I had a sequence of errors that I had to hold the enter key down for ~20 seconds before they stopped occurring. My system survey craft did not detect any ships, and it was able to explore the system unmolested save for the massive EM and TH sig from 86 Ophiuchi-A III

Despite attempting communications, I never got a roll for deciphering their language - I had ships in orbit over their homeworld collecting IP. I ended up invading, and found that they had no ground forces at all. 8 hour increments were not causing ground combat to occur, so after 4 of them I hit "5 days" and the population was conquered. The NPR has 6b pop and no installations, no ground forces and no ships.

DB attached should be a save from just before sending my troop transports through the JP from Pi-3 Orionis to 86 Ophiuchi to conquer the pop.

After finishing grav survey, the system is a dead-end. Not at all sure if this info is related, because errors occurred on system generation, and this is the first time I've ever encountered an NPR homeworld in VB6 or C# with one JP.
Title: Re: v1.13.0 Bugs Thread
Post by: Exultant on May 02, 2021, 11:40:37 PM
Addon to my last bug report - I sat for an hour exploring the same  JP over and over to spawn a new NPR  to see if I could replicate the error and I could not. I've attached the DB with this NPR in it, perhaps the contrast between the failed NPR spawn and this one might help?

New NPR spawned in 83 Ophiuchi.

Edit: Went hostile, and my fleet is sitting 80kkm out from their homeworld systematically destroying millions of tons of shipping without them ever firing a shot back at me
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 03, 2021, 05:40:06 AM
There is no event log message when your Xenosurvey Crew unearths special fun things. They just appear and start shooting. It would be nice if there were a short, flavor game log message describing what happened.

C# doesn't have anything that appears from ruins and starts shooting.
Title: Re: v1.13.0 Bugs Thread
Post by: Caesar on May 03, 2021, 06:12:51 AM
If you delete or otherwise lose the population that houses your main naval admin command, it is impossible to relocate your naval admin command, even if you have another planet with the appropriate building. Since no systems are in range of the old HQ (which now has no location at all), and it cannot be deleted or somehow reset, it is impossible to do anything involving fleets anymore. Even creating fleets throws up an error (since it doesn't know where to create them):

Code: [Select]
1.13.0 function #930: Object reference not set to an instance of an object.
The situation in which this occurred is the following: I created a game as normal, then generated a new system by jumping through a jump point. I added a colony there, set that up with stuff similar to my starting colony on Earth, then deleted the Sol system. I recreated it by generating a new race (which did work normally) and deleting their population. I also recreated it by generating a new race and deleting their entire homeworld. In all cases, it is impossible to move the naval admin command.

SJW: Deleting a population that contains the top-level admin command will now result in that admin command moving to a new population. A naval HQ will be created if no pops with existing HQs are available.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 03, 2021, 08:07:23 AM
I got two or three #2939 errors while processing the turn (I was expecting a new system to be jumped into and generated), and then the game froze for 10 minutes. I don't think it's going to recover, so I had to force-close it and resume from my last save a few minutes prior.

What was the text of the errors?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 03, 2021, 08:25:10 AM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; scrapping ships, exploring, systems missing comets,
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? scrapping easy, missing comets intermittent, few warp points?
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 43 years


Potential bug 1: After you mark a ship design as obsolete those ships of that design no longer show up in shipyard lists for scrapping. Un-obsolete  them and they show up.

Potential bug 2; I set minimum number of comets per system as 10. However a number of systems appear cometless. This may be working as intended.

Potential bug 3; In setup I changed local system generation spread from 15 to 7 or 8 (tried both). I found that warp points were very sparse. that 7 local system generation spread game ran out of warp points at 15-20 systems (game deleted). The 8 local system generation spread found a maximum of 2 systems with 3 warp points the rest had 1 or 2 warp points for a total of 23 systems. With only 1 unexplored warp point left I changed local system generation spread to 15. I now have 55 systems explored with 10 systems having more than 2 warp points plus 6 systems not yet fully explored. However this may be working as intended.

I can't reproduce #1 as obsolete ships show up for scrapping in my test game.

#2 is now fixed.

For #3, the local system generation chance is not connected to jump point generation. it is only used to determine the system to which you connect. Jump points are generated during system generation. Its sounds like you were just unlucky with the RNG.

Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 03, 2021, 09:03:02 AM
Fleet history is greatly slowing down the save speed of my 100+ year game. For the first time since reinstalling 1.13 from scratch, I opened up the database in an SQL editor and deleted all but the most recent fleet history, which amounted to around 240,000 entries. There were also an inordinate number of GameLog messages about NPR fleets running out of fuel.

Once I deleted all log entries of those two types, saving my game went from 13 seconds before, to just 6 seconds after cleaning the database. (On an SSD, with a top-tier CPU)

I would recommend wiping Fleet History for civilian shipping lines after some number of years (10? 20?) and same with NPRs. Player naval fleet histories should be kept forever.

These are suggestions rather than bugs, so in future would be better in the Suggestions thread. However, I've added some code to only retain five years of fleet histories for NPRs and shipping lines. I've also stopped NPRs generating the fuel event messages, although they will still act on them.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 03, 2021, 09:16:16 AM
Potential bug 3; This error then has been present since VB6! When I first noticed it, but appears to have become worse.

This isn't a bug. You were just unlucky on jump points.
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on May 03, 2021, 10:13:25 AM
I created 4 NPR's via the race creation button on the System Generation and Display screen I did manually adjust all 4 races to be human but then clicked create as NPR. None of these 4 races has created any ground forces at game start this seems likely to be a bug
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 03, 2021, 12:44:58 PM
The button to turn on Active Sensors at the bottom of the Naval Organization window only appears when you select individual ships. There doesn't seem to be any "single click" button to turn on active sensors for the entire fleet, like there was in VB6. Instead, right now the workaround is to use movement orders (and juggle waypoints/point of interest) to turn on or off the entire fleet's active sensors.

This is a suggestion rather than a bug. In future, please post in suggestion thread.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 03, 2021, 02:27:43 PM
No I researched all the previous power plants but didn't work out that Inertial confinement fusion Drive  followed Magneto-plasma Drive Technology, It cost less so I thought it must precede it - wrong!

Perhaps you are confusing "Inertial" with "Internal"?

Internal Confinement Fusion Drive Technology costs 40k.
Inertial Confinement Fusion Drive Technology costs 150k.

Guilty as charged! I was confusing power plant techs with engine techs, sorry!

I've modified the naming to avoid any similar confusion in future
http://aurora2.pentarch.org/index.php?topic=12523.msg151032#msg151032
Title: Re: One Jump Drive Per Ship
Post by: Steve Walmsley on May 03, 2021, 02:42:21 PM
You are only allowed 1 Jump drive per ship

Since Military jump drives are a commercial component it would make sense that you would be able to make a Commercial ship capable of jumping military engines ships, right? This is currently not the case because you need a SECOND jump drive for the commercial ship, which isn't possible

The current situation Requires 2 ships:

Ship A has a Military jump drive capable of jumping your military ships
Ship B has a commercial jump drive capable of jumping your commercial ships

This provides another problem, A fleet requiring multiple jump drives for their multiple types of ships is not possible.  This means using commercial ships for military jump engines is an almost pointless feature without being able to add 2 drives to the same ship.

Jump drives work on the matching engine type, not the matching ship category for maintenance purposes. A military jump drive can jump ships with military engines. A commercial jump drive can jump ships with commercial engines (even if they are military ships). Military jump drives are a commercial system to allow commercial ships to act as jump tenders.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 03, 2021, 03:23:18 PM
There is no event log message when your Xenosurvey Crew unearths special fun things. They just appear and start shooting. It would be nice if there were a short, flavor game log message describing what happened.

C# doesn't have anything that appears from ruins and starts shooting.

Ah, I went back and looked at my archived save file from right before I thought they "awoke"... there were Precursor ground forces that I didn't detect, just chilling on a planet. No precursor ships in system.

The Precursor ground forces didn't attack my Geosurvey troops for months, but as soon as I landed my Xenosurvey troops and some colonial defense brigades, they instantly attacked. So I thought they were awoken robotic defenders.

And I will take care to put items that are more of suggestions in the right thread! Thank you Steve
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 03, 2021, 03:32:23 PM
When making custom systems through SM mode, moons do not seem to receive a placeholder name and instead have the name "No name". Unfortunately this means that when opening the system view for every such moon, function 3060 throws an "Object reference not set to an instance of an object". This same error is also thrown when the economy screen is opened for each colony on these "No name" bodies.

Also worth noting that I like to add empty spaces in front of important systems in order to game the alphabetic sorting.

Edit: I'm also getting one instance of function 1170 "The given key was not present in the dictionary" throwing whenever I first launch the game. (I had discovered some other systems, because of the previous error the bodies in these systems did not load in, but their entries in FCT_SystemBodies were still present, throwing the key error)

SJW: Cannot reproduce.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 03, 2021, 04:47:31 PM
The Ancient construct tab on the economy screen shows both the field type and bonus of an unsurveyed Dormant Construct.

I'm fairly certain I'm not supposed to know that much about a construct before I've scanned and surveyed it.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: whollaborg on May 04, 2021, 02:59:22 AM
Conventional start, real stars, decimal separator = period, Another New system Discovered

I received these errors on advancing time:
Function #2608: object reference not set
Function #222: object reference not set
Function #224: object reference not set
Function #2339: object reference not set

These 4 errors repeated around 16 to 20 times but I was eventually able to click through them. 

Database attached.   Noticed that exactly the same sequence has been reported in bugs thread 1.  9.  3. 

P. S.  on Saturday 15 january 2084 the game starts to callculate something and well, wont stop :(
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 04, 2021, 08:49:44 AM
Double clicking on a "Mineral Shortage" event in the event log correctly opens the Economics window to the Industry tab, but it always selects the first colony, not the colony at which the event occurred.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 04, 2021, 08:59:57 AM
When making custom systems through SM mode, moons do not seem to receive a placeholder name and instead have the name "No name". Unfortunately this means that when opening the system view for every such moon, function 3060 throws an "Object reference not set to an instance of an object". This same error is also thrown when the economy screen is opened for each colony on these "No name" bodies.

Also worth noting that I like to add empty spaces in front of important systems in order to game the alphabetic sorting.

Edit: I'm also getting one instance of function 1170 "The given key was not present in the dictionary" throwing whenever I first launch the game. (I had discovered some other systems, because of the previous error the bodies in these systems did not load in, but their entries in FCT_SystemBodies were still present, throwing the key error)

I can't reproduce this. Creating moons either individually or automatically still generates the placeholder names. I also tried adding a space to the system name first.

Does this happen for every system or only some? Could you also guide me though the exact steps you took.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 04, 2021, 09:27:15 AM
Conventional start, real stars, decimal separator = period, Another New system Discovered

I received these errors on advancing time:
Function #2608: object reference not set
Function #222: object reference not set
Function #224: object reference not set
Function #2339: object reference not set

These 4 errors repeated around 16 to 20 times but I was eventually able to click through them. 

Database attached.   Noticed that exactly the same sequence has been reported in bugs thread 1.  9.  3. 

P. S.  on Saturday 15 january 2084 the game starts to callculate something and well, wont stop :(

It looks like an error in ground force creation, but I suspect not happening every time or there would be a lot more errors reported. I plan to start a new test campaign soon, so I will try to reproduce then. Thanks for DB attachment but my code has moved on now, so I am at the point where I can't load v1.13 games.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 04, 2021, 09:49:48 AM
When making custom systems through SM mode, moons do not seem to receive a placeholder name and instead have the name "No name". Unfortunately this means that when opening the system view for every such moon, function 3060 throws an "Object reference not set to an instance of an object". This same error is also thrown when the economy screen is opened for each colony on these "No name" bodies.

Also worth noting that I like to add empty spaces in front of important systems in order to game the alphabetic sorting.

Edit: I'm also getting one instance of function 1170 "The given key was not present in the dictionary" throwing whenever I first launch the game. (I had discovered some other systems, because of the previous error the bodies in these systems did not load in, but their entries in FCT_SystemBodies were still present, throwing the key error)

SJW: Cannot reproduce.

Follow up to this post, I think the problem happened because of a combination of me changing the Star systems name as well as the name of some system bodies which confused the game when naming moons. I've made more custom systems now without problems since I've been more careful with order in which I've been doing things.

Unfortunately I don't remember the exact order that I did. I just remember naming certain moons and their parent bodies (terrestrial), changed the name of the star a couple times and the next time I loaded the game all the moons were throwing the error and the 3 surrounding systems weren't loading.

The good news is that I have fixed the problem and rescued the save. I renamed every single moon (80+...) and then "fixed" the other 3 systems by just making them custom myself, being careful about the order of operations and have had no issues.

Something I forgot to mention that is actually important: I wasn't just renaming the stars, I actually changed their spectral class, and moved the secondary component (binary system) further away than it originally was, while it had bodies orbiting it. In addition, I deleted the Sol system once I had created the new one.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 11:36:55 AM
"Earth" and "Luna" reappear after they have been destroyed due to the disaster.

(https://i.imgur.com/cSp6DMs.png)

Steps to reproduce:

1) Let Earth be destroyed by the disaster (download attached save file, and skip time forward 30 days)
2) Save game
3) Close game
4) Reopen game, and zoom in on the sun to see Sol-A III and its moon suddenly in close orbit around the sun.
5) Sol III will be destroyed in a couple months again if you leave the disaster enabled. If you disable the disaster, Sol III will survive forever close to the sun.

The attached save file has not been modified in any way using database tools. It's a vanilla game db.
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on May 04, 2021, 12:54:55 PM
Quote
SJW: Deleting a population that contains the top-level admin command will now result in that admin command moving to a new population.  A naval HQ will be created if no pops with existing HQs are available.
With the installation scrapping introduction, there is a potential for infinite dupe for wealth, boronide, mercassium and uridium (resources from scrapping Naval HQs) with intentional HQ moving and pop deletion, depending on how exactly these 2 features were implemented.
Might want to rethink the system a bit if this has not been accounted for already.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 04, 2021, 01:04:26 PM
Quote
SJW: Deleting a population that contains the top-level admin command will now result in that admin command moving to a new population.  A naval HQ will be created if no pops with existing HQs are available.
With the installation scrapping introduction, there is a potential for infinite dupe for wealth, boronide, mercassium and uridium (resources from scrapping Naval HQs) with intentional HQ moving and pop deletion, depending on how exactly these 2 features were implemented.
Might want to rethink the system a bit if this has not been accounted for already.

Seems like the easy fix is to tie this check (or a second parallel check) to the presence of a NHQ on the planet, that way you cannot scrap the NHQ installation but keep the admin command on the planet to trigger this feature in an exploity fashion.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 03:12:14 PM
(https://i.imgur.com/ZLtX3pm.png)

"Select on Map" doesn't recenter the map to the current fleet when you first check the checkbox. Instead, you have to click away to a different fleet, then back to the fleet you had selected.

Expected behavior would be to recenter the map immediately onto the currently selected fleet right when you check the "Select on Map" checkbox.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 03:21:25 PM
(https://i.imgur.com/qro1JxU.png)

These two red-box time estimates should be the same number, but for some reason they are not. Please note that the move order is a "Follow at 1,000 mil km" order. (The task force has not yet reached its 1,000 mil km standoff point)

It looks like the map ETA is correctly taking into account the stand-off distance I've ordered, but the Travel Time in the fleet window is incorrectly calculating based on distance to the center of the body targeted.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on May 04, 2021, 04:42:02 PM
(https://i.imgur.com/qro1JxU.png)

These two red-box time estimates should be the same number, but for some reason they are not. Please note that the move order is a "Follow at 1,000 mil km" order. (The task force has not yet reached its 1,000 mil km standoff point)

It looks like the map ETA is correctly taking into account the stand-off distance I've ordered, but the Travel Time in the fleet window is incorrectly calculating based on distance to the center of the body targeted.

when I had these errors usually was because my Naval Screen was open and because while the Tactical map is refreshed real-time while the screens are not (you must close and reopen) that caused the issue. Have you tried that?

DISCLAIMER: My problem was during setting different speeds so it may not be related to yours.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 04:52:15 PM

These two red-box time estimates should be the same number, but for some reason they are not. Please note that the move order is a "Follow at 1,000 mil km" order. (The task force has not yet reached its 1,000 mil km standoff point)

It looks like the map ETA is correctly taking into account the stand-off distance I've ordered, but the Travel Time in the fleet window is incorrectly calculating based on distance to the center of the body targeted.

when I had these errors usually was because my Naval Screen was open and because while the Tactical map is refreshed real-time while the screens are not (you must close and reopen) that caused the issue. Have you tried that?

DISCLAIMER: My problem was during setting different speeds so it may not be related to yours.

Unfortunately, it's not an issue regarding the Naval Organization window not auto-refreshing. Also if you look at the difference between the Tactical Map distance remaining and the Naval Organization distance remaining, it's exactly 1 billion km which is the distance of the desired stand-off.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 05:16:19 PM
With 5-minute subpulses and a 3-hour turn, how did these two fleets slip so far past each other? I would have thought there would have been 36 sub-pulse sensor interrupt checks during those 3 hours of travel. All my sensor sizes and resolutions are shown. Shouldn't the turn have been interrupted with a new hostile sensor detection about 1.5 hours through the 3-hour turn?

(https://i.imgur.com/Occjk2P.png)
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 04, 2021, 05:18:36 PM
With 5-minute subpulses and a 3-hour turn, how did these two fleets slip so far past each other? I would have thought there would have been 36 sub-pulse sensor interrupt checks during those 3 hours of travel. All my sensor sizes and resolutions are shown. Shouldn't the turn have been interrupted with a new hostile sensor detection about 1.5 hours through the 3-hour turn?

Could be cloaked?
A cloaked ship's signature shows its full size, not the effective size for sensor detection purposes.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 05:31:25 PM
If I fire an overkill number of missiles targeted at a single target in a multi-ship fleet, and my missiles have active sensor seekerheads, shouldn't the "extra" missiles after my target dies, retarget to other nearby enemy ships? Because right now they all explode as if they hit something, but only the originally targeted ship is damaged/killed.

I fired 294 missiles at a single ship belonging to a precursor fleet of 3 enemy ships, all same speed and size. 167x missiles ended up having successful intercepts according to the log. However, only one ship was hit (32 times) and was destroyed. The remaining extra "overkill" missiles exploded, doing no damage to the other two ships:

(https://i.imgur.com/YDHFOq9.png)

I have a save if you would like to experiment. As you can see, this missile design does indeed have 0.25 active sensors (range of 4.4mil km against 5000-ton)

(https://i.imgur.com/btiYCWJ.png)

SJW: Working as intended. See my reply.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 05:37:55 PM
With 5-minute subpulses and a 3-hour turn, how did these two fleets slip so far past each other? I would have thought there would have been 36 sub-pulse sensor interrupt checks during those 3 hours of travel. All my sensor sizes and resolutions are shown. Shouldn't the turn have been interrupted with a new hostile sensor detection about 1.5 hours through the 3-hour turn?

Could be cloaked?
A cloaked ship's signature shows its full size, not the effective size for sensor detection purposes.

Unfortunately, that doesn't seem to be the case here. Here is the result if I manually go forward in 5-minute turns. (Same map scale as the previous image for this bug). I detected them at the edge of my sensor distance. It seems for some reason, active sensor interrupts aren't happening during sub-pulses. Shouldn't this interrupt the turn generation? Or is this not part of sub-pulse resolution?

(https://i.imgur.com/bvgLXf2.png)
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 04, 2021, 06:24:53 PM
With 5-minute subpulses and a 3-hour turn, how did these two fleets slip so far past each other? I would have thought there would have been 36 sub-pulse sensor interrupt checks during those 3 hours of travel. All my sensor sizes and resolutions are shown. Shouldn't the turn have been interrupted with a new hostile sensor detection about 1.5 hours through the 3-hour turn?

Not necessarily. The turn interrupt is tied to the firing of events, and the firing of hostile contact events is tied to updating of a hostile contact.

If a hostile ship leaves your sensor range at, say, 4000 km/s with its active sensor on, and then later reappears at 4000 km/s with its active sensor on, there is no change in the hostile contact and no event is fired. This is not a bug, but rather is a quirk of the contacts system interacting with the events system - which is frequently brought up in the suggestions thread.

If I fire an overkill number of missiles targeted at a single target in a multi-ship fleet, and my missiles have active sensor seekerheads, shouldn't the "extra" missiles after my target dies, retarget to other nearby enemy ships? Because right now they all explode as if they hit something, but only the originally targeted ship is damaged/killed.

I fired 294 missiles at a single ship belonging to a precursor fleet of 3 enemy ships, all same speed and size. 167x missiles ended up having successful intercepts according to the log. However, only one ship was hit (32 times) and was destroyed. The remaining extra "overkill" missiles exploded, doing no damage to the other two ships:

I recall that in the 1.12 period there was discussion that active sensors on missiles did not allow them to retarget, and ultimately a change was made in 1.13 to allow second-stage missiles to auto-target but no change that I recall was made for standard missiles with active sensors. Presently active sensors on missiles are designed to allow retargeting if a target was destroyed in the previous increment - with how salvo motion and missile impacts work missiles will not retarget after the target has been precisely killed. I'm not sure if this is the design intention or simply the way it is, but either way it isn't a bug and is another popular subject of discussion in the suggestions threads.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 06:35:28 PM
With 5-minute subpulses and a 3-hour turn, how did these two fleets slip so far past each other? I would have thought there would have been 36 sub-pulse sensor interrupt checks during those 3 hours of travel. All my sensor sizes and resolutions are shown. Shouldn't the turn have been interrupted with a new hostile sensor detection about 1.5 hours through the 3-hour turn?

Not necessarily. The turn interrupt is tied to the firing of events, and the firing of hostile contact events is tied to updating of a hostile contact.

If a hostile ship leaves your sensor range at, say, 4000 km/s with its active sensor on, and then later reappears at 4000 km/s with its active sensor on, there is no change in the hostile contact and no event is fired. This is not a bug, but rather is a quirk of the contacts system interacting with the events system - which is frequently brought up in the suggestions thread.

So you're saying if I hadn't ever had a sensor contact with these Precursor ships before, then I would have gotten a proper sub-pulse interrupt?    But because I've seen them once before, decades earlier, now they don't ever interrupt sub-pulses when they appear again with the same stats?

If I fire an overkill number of missiles targeted at a single target in a multi-ship fleet, and my missiles have active sensor seekerheads, shouldn't the "extra" missiles after my target dies, retarget to other nearby enemy ships? Because right now they all explode as if they hit something, but only the originally targeted ship is damaged/killed.

I fired 294 missiles at a single ship belonging to a precursor fleet of 3 enemy ships, all same speed and size. 167x missiles ended up having successful intercepts according to the log. However, only one ship was hit (32 times) and was destroyed. The remaining extra "overkill" missiles exploded, doing no damage to the other two ships:

I recall that in the 1.12 period there was discussion that active sensors on missiles did not allow them to retarget, and ultimately a change was made in 1.13 to allow second-stage missiles to auto-target but no change that I recall was made for standard missiles with active sensors. Presently active sensors on missiles are designed to allow retargeting if a target was destroyed in the previous increment - with how salvo motion and missile impacts work missiles will not retarget after the target has been precisely killed. I'm not sure if this is the design intention or simply the way it is, but either way it isn't a bug and is another popular subject of discussion in the suggestions threads.

I didn't realize that's how it was supposed to work. Other people on the discord thought it was bugged, too.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 04, 2021, 07:31:41 PM
So you're saying if I hadn't ever had a sensor contact with these Precursor ships before, then I would have gotten a proper sub-pulse interrupt?    But because I've seen them once before, decades earlier, now they don't ever interrupt sub-pulses when they appear again with the same stats?

Yes. It's really weird, and not the behavior most players desire nor expect, but it is WAD although the volume of complaints suggests the D could use some adjustments (which, again, is a suggestions thread topic of some frequency).

I didn't realize that's how it was supposed to work. Other people on the discord thought it was bugged, too.

It's definitely not intuitive, but it seems to be intended as the last time we had this discussion we got the second-stage fix/change but no change to active sensor missile behavior for single stages. I believe the rationale is that (1) the missiles impact so quickly that they don't have time to register the destruction of the ship and change course, and (2) gameplay balance, to preserve the mechanic of carefully weighing the size of a missile volley instead of fire-and-forget. Folks have argued that the requirement to allocate MSP to sensors makes this a viable tradeoff, but that seems to either not be a view shared by Steve, or else it's just not important enough to get changed. I don't know which.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 07:40:14 PM
When my missiles are targeted against Precursors, they aren't causing sub-pulse interrupts when they get within AMM range. I saved the game, set sub-pulse interrupts to 5sec, and clicked the "5 min" button to watch the turn move forward. There should have been 60 sub-pulses.

My missiles struck the Precursor fleet with only PD firing, and not their AMMs.

Then I reloaded the game and moved forward in 5-second increments manually instead of relying on the sub-pulse setting. Their AMMs started engaging my missiles almost a minute prior to the missiles arriving at the Precursor fleet.

Isn't there a sub-pulse interrupt that should be be happening when the Precursors detect my missiles inbound? I'm worried that this isn't working right, and that there might not be an interrupt for when they shoot missiles at me, either. Perhaps there's something about turn resolution that I'm missing.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 04, 2021, 08:05:27 PM
When my missiles are targeted against Precursors, they aren't causing sub-pulse interrupts when they get within AMM range. I saved the game, set sub-pulse interrupts to 5sec, and clicked the "5 min" button to watch the turn move forward. There should have been 60 sub-pulses.

My missiles struck the Precursor fleet with only PD firing, and not their AMMs.

Then I reloaded the game and moved forward in 5-second increments manually instead of relying on the sub-pulse setting. Their AMMs started engaging my missiles almost a minute prior to the missiles arriving at the Precursor fleet.

Isn't there a sub-pulse interrupt that should be be happening when the Precursors detect my missiles inbound? I'm worried that this isn't working right, and that there might not be an interrupt for when they shoot missiles at me, either. Perhaps there's something about turn resolution that I'm missing.

Hard to say. Steve has in the past said that the event interrupts are necessary for the AI to handle certain things, and I suspect missile launches are one of those things. This might then be a bug which has gone unreported since most players default to short turns in combat.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 04, 2021, 08:47:26 PM
"Create Colony" from the Naval Organization window used to work previously, but now that I have two species to choose from, it no longer creates a colony on the chosen body. I had to go to System Body View to create a colony (which defaulted to Human, and didn't ask me to choose a species).

(https://i.imgur.com/U0qTlU2.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 04, 2021, 08:58:45 PM
"Create Colony" from the Naval Organization window used to work previously, but now that I have two species to choose from, it no longer creates a colony on the chosen body. I had to go to System Body View to create a colony (which defaulted to Human, and didn't ask me to choose a species).

(https://i.imgur.com/U0qTlU2.png)

Can confirm that this happens to me as well. The workaround is to create colonies through the system view screen, which allows you to choose which species.

It feels like this is partially implemented functionality that has been forgotten.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 04, 2021, 09:22:51 PM
So you're saying if I hadn't ever had a sensor contact with these Precursor ships before, then I would have gotten a proper sub-pulse interrupt?    But because I've seen them once before, decades earlier, now they don't ever interrupt sub-pulses when they appear again with the same stats?

Yes. It's really weird, and not the behavior most players desire nor expect, but it is WAD although the volume of complaints suggests the D could use some adjustments (which, again, is a suggestions thread topic of some frequency).


This bothers me so much that I'm going to write a db script that will auto-purge old contacts, just to force the game to throw an interrupt at the next sighting.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 04, 2021, 09:39:14 PM
So you're saying if I hadn't ever had a sensor contact with these Precursor ships before, then I would have gotten a proper sub-pulse interrupt?    But because I've seen them once before, decades earlier, now they don't ever interrupt sub-pulses when they appear again with the same stats?

Yes. It's really weird, and not the behavior most players desire nor expect, but it is WAD although the volume of complaints suggests the D could use some adjustments (which, again, is a suggestions thread topic of some frequency).


This bothers me so much that I'm going to write a db script that will auto-purge old contacts, just to force the game to throw an interrupt at the next sighting.

I'd suggest tuning it to not delete contacts which have just been sighted on the last increment, for obvious reasons. This is also likely to cause a bug if you go into the events list to click an old contact which was deleted, since the event is not deleted along with the contact - but you're not likely to do that, so it should not be a problem.

Otherwise this seems like it would be useful QoL as a player loading a save would want to be reminded of old contacts anyways.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2021, 03:04:36 AM
Quote
SJW: Deleting a population that contains the top-level admin command will now result in that admin command moving to a new population.  A naval HQ will be created if no pops with existing HQs are available.
With the installation scrapping introduction, there is a potential for infinite dupe for wealth, boronide, mercassium and uridium (resources from scrapping Naval HQs) with intentional HQ moving and pop deletion, depending on how exactly these 2 features were implemented.
Might want to rethink the system a bit if this has not been accounted for already.

If people are that desperate to cheat at solitaire, there are many better ways already in the game :)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2021, 05:00:15 AM
If I fire an overkill number of missiles targeted at a single target in a multi-ship fleet, and my missiles have active sensor seekerheads, shouldn't the "extra" missiles after my target dies, retarget to other nearby enemy ships? Because right now they all explode as if they hit something, but only the originally targeted ship is damaged/killed.

I fired 294 missiles at a single ship belonging to a precursor fleet of 3 enemy ships, all same speed and size. 167x missiles ended up having successful intercepts according to the log. However, only one ship was hit (32 times) and was destroyed. The remaining extra "overkill" missiles exploded, doing no damage to the other two ships:

This is working as intended. The missiles all arrived at the same time and simultaneously attacked the same ship. The missiles can't know ahead of time how many will be needed to destroy the ship, so none are held back for retargeting. If the missiles were in multiples waves, then the missiles that had not yet reached the target when it was destroyed would be retargeted, because they have time to act on the knowledge.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2021, 05:45:26 AM
So you're saying if I hadn't ever had a sensor contact with these Precursor ships before, then I would have gotten a proper sub-pulse interrupt?    But because I've seen them once before, decades earlier, now they don't ever interrupt sub-pulses when they appear again with the same stats?

Yes. It's really weird, and not the behavior most players desire nor expect, but it is WAD although the volume of complaints suggests the D could use some adjustments (which, again, is a suggestions thread topic of some frequency).


This bothers me so much that I'm going to write a db script that will auto-purge old contacts, just to force the game to throw an interrupt at the next sighting.

The problem seems to be that re-establishing contact is not treated as a 'contact update'. I've fixed that for v1.14. When contact is re-established, a contact update event will be generated. A hostile re-established contact will trigger an interrupt.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2021, 06:01:37 AM
"Create Colony" from the Naval Organization window used to work previously, but now that I have two species to choose from, it no longer creates a colony on the chosen body. I had to go to System Body View to create a colony (which defaulted to Human, and didn't ask me to choose a species).

I've fixed the button on Naval Organization window. On the System View window, the colony is created using the species that is selected in the top right species dropdown.
Title: Re: v1.13.0 Bugs Thread
Post by: SpaceMarine on May 05, 2021, 08:15:58 AM
Hey steve or someone knowledgeable of error codes need help really quick with this one, I have been making my custom premade scenario and I am starting to get this every construction cycle, so if someone could let me know what it means I can see if I can track down the culprit and delete/fix it.

(https://i.imgur.com/Gd4tmwC.png)

it seems harmless as time still advances but its of course quite annoying.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2021, 11:36:36 AM
Hey steve or someone knowledgeable of error codes need help really quick with this one, I have been making my custom premade scenario and I am starting to get this every construction cycle, so if someone could let me know what it means I can see if I can track down the culprit and delete/fix it.

(https://i.imgur.com/Gd4tmwC.png)

it seems harmless as time still advances but its of course quite annoying.

The error is somewhere in AI Diplomacy, but that isn't a small function so hard to know the cause without more context.
Title: Re: v1.13.0 Bugs Thread
Post by: SpaceMarine on May 05, 2021, 11:46:11 AM
Hey steve or someone knowledgeable of error codes need help really quick with this one, I have been making my custom premade scenario and I am starting to get this every construction cycle, so if someone could let me know what it means I can see if I can track down the culprit and delete/fix it.

(https://i.imgur.com/Gd4tmwC.png)

it seems harmless as time still advances but its of course quite annoying.

The error is somewhere in AI Diplomacy, but that isn't a small function so hard to know the cause without more context.

The only "diplomacy" I have done is related to SM establishing communications with another NPR in system, along with changing their name and image etc. I can provide the DB, I would really like to get this solved as this DB is planned to be the one with the premade scenario for other players and I dont think an error every construction cycle will make it too appealing.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2021, 01:07:57 PM
Hey steve or someone knowledgeable of error codes need help really quick with this one, I have been making my custom premade scenario and I am starting to get this every construction cycle, so if someone could let me know what it means I can see if I can track down the culprit and delete/fix it.

(https://i.imgur.com/Gd4tmwC.png)

it seems harmless as time still advances but its of course quite annoying.

The error is somewhere in AI Diplomacy, but that isn't a small function so hard to know the cause without more context.

The only "diplomacy" I have done is related to SM establishing communications with another NPR in system, along with changing their name and image etc. I can provide the DB, I would really like to get this solved as this DB is planned to be the one with the premade scenario for other players and I dont think an error every construction cycle will make it too appealing.

Unfortunately, the DB won't help as my code base has moved on so I will just generate errors trying to load a v1.13 database.

Somewhere in that function, something is missing that the code expects to find. It could be a system, a race, a ship, etc. but there is no way to know what. One thing you could try (after backing up the DB) is deleting all the records from the various FCT_Alien<xxx> tables. The game will generate them all again as a result of contacts and it might solve the issue.
Title: Re: v1.13.0 Bugs Thread
Post by: SpaceMarine on May 05, 2021, 01:10:41 PM
Hey steve or someone knowledgeable of error codes need help really quick with this one, I have been making my custom premade scenario and I am starting to get this every construction cycle, so if someone could let me know what it means I can see if I can track down the culprit and delete/fix it.

(https://i.imgur.com/Gd4tmwC.png)

it seems harmless as time still advances but its of course quite annoying.

The error is somewhere in AI Diplomacy, but that isn't a small function so hard to know the cause without more context.

The only "diplomacy" I have done is related to SM establishing communications with another NPR in system, along with changing their name and image etc. I can provide the DB, I would really like to get this solved as this DB is planned to be the one with the premade scenario for other players and I dont think an error every construction cycle will make it too appealing.

Unfortunately, the DB won't help as my code base has moved on so I will just generate errors trying to load a v1.13 database.

Somewhere in that function, something is missing that the code expects to find. It could be a system, a race, a ship, etc. but there is no way to know what. One thing you could try (after backing up the DB) is deleting all the records from the various FCT_Alien<xxx> tables. The game will generate them all again as a result of contacts and it might solve the issue.

It only appeared later on and i have been taking many save files so my plan is to go back reload databases and see when it occurred, also i may have to go into the DB yes unfortunately I have never touched the DB before so that will be fun, also on the code base thing couldnt you for example just download your own 1.13 release and then load my game and check the database? and code or would that not work?
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 05, 2021, 01:11:09 PM
Civilian Shipping Contracts are overfilling.

After a civilian ship loads an installation at the supply location, the "Assigned" amount of the demand contract reduces by 1.
If a new supply contract for this installation is created before this ship finishes unloading at the destination, the civvies will use that supply to fulfill the original demand contract again.
This can happen over and over for a single demand contract.
A civ ship will eventually deliver the installation, causing that demand contract to be deleted. But all the others en route will finish their delivery.

Steps to reproduce:

0) Ensure that a shipping company exists and that no supply or demand contracts currently exist.
1) Create a supply contract for 1 installation at Colony A (make sure Colony A has at least 1 such installation).
2) Create a demand contract for 1 of the same installation at Colony B (must be in same system as Colony A, or a jumpgate route must exist from A to B).
3) Advance time until a civilian freighter has been assigned to deliver the installation. Note that the "Assigned" amount has changed to 1 for both the supply and the demand contract.
4) Advance time until the civilian freighter has finished loading the installation at Colony A and begun moving to B. Note that the supply contract has disappeared, and the "Assigned" amount has changed back to 0 for the demand contract.
5) Create a new supply contract for 1 of the same installation at Colony A. Do not create any matching demand contract.
6) Advance time. If/when a civilian freighter becomes available before the original freighter has unloaded the installation at B, the newly available freighter will be assigned to deliver the installation from A to B. The supply and demand contract "Assigned" amounts will change to 1 and the ship will move to A, load the installation (which reduces the "Assigned" amount on the demand contract back to 0), and begin moving to B.
7) If you like, go back to step 5 and do it again. See how many civvies you can get loaded up before the original freighter finally delivers the installation.

Fixed for v1.14: http://aurora2.pentarch.org/index.php?topic=12523.msg151550#msg151550
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 05, 2021, 05:26:49 PM
The "Fill Class" button doesn't seem to work fully. It only adds munitions to the current ship (like the "Fill Ship" button does) rather than all members of the class.

(https://i.imgur.com/sDdObun.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2021, 05:26:59 PM
on the code base thing couldnt you for example just download your own 1.13 release and then load my game and check the database? and code or would that not work?

The released executable is a binary file so I can't see the code. When I run my own code I can step through it line by line in debug mode and check the values of all variables. I could theoretically convert the executable back into source code but it is obfuscated :)

If I was doing this commercially, I would have version control so I could go back to any previous version and run that code. As it is a hobby project and I have limited time at the moment, I don't really want the hassle of version control.
Title: Re: v1.13.0 Bugs Thread
Post by: GodEmperor on May 07, 2021, 10:04:58 AM
Small one but incredibly frakking annoying - Ship hull type letters ( FFG, DDG, BB etc ) dont appear in most class table, especially in shipyards.
Not a biggie at the start but real pain in the ass when you start hitting 10plus ship types.

Oh and i seem to have a bug when "unload all instalations" from the ship unloads only some - i tested on Auto mines/Mass driver combo and mass drivers arent getting unloaded first time and you need to repeat the order.
Title: Re: v1.13.0 Bugs Thread
Post by: nebbish on May 07, 2021, 01:42:35 PM
The function number:

The function number 1412
The complete error text Function #1412: Value was either too large or too small for a Decimal.
The window affected Main Screen
What you were doing at the time passing time 5 days with green light
Conventional or TN start - Conventional
Random or Real Stars - Random
Is your decimal separator a comma? a dot ". "
Is the bug is easy to reproduce, intermittent or a one-off? One off so far
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - year 73 with 5% research rate so this game has been running short time as only explored Sol

Error box kept coming up had to spam enter tons of times to get out of it eventually the error ceased after spamming enter.

Weird result of this bug is that the mass drivers have mass produced resources on earth my stockpiles for my resources have jumped up from tens of thousands to tens of millions of each resource.

Just quick question is it possible to amend the minerals through SM somewhere or will it have to be a DB edit?



(http://https://i. ibb. co/qjvg7fG/Image1. png)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 07, 2021, 02:38:56 PM
The function number:

The function number 1412
The complete error text Function #1412: Value was either too large or too small for a Decimal.
The window affected Main Screen
What you were doing at the time passing time 5 days with green light
Conventional or TN start - Conventional
Random or Real Stars - Random
Is your decimal separator a comma? a dot ". "
Is the bug is easy to reproduce, intermittent or a one-off? One off so far
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - year 73 with 5% research rate so this game has been running short time as only explored Sol

Error box kept coming up had to spam enter tons of times to get out of it eventually the error ceased after spamming enter.

Weird result of this bug is that the mass drivers have mass produced resources on earth my stockpiles for my resources have jumped up from tens of thousands to tens of millions of each resource.

Just quick question is it possible to amend the minerals through SM somewhere or will it have to be a DB edit?

(https://i. ibb. co/qjvg7fG/Image1. png)

The error is in the function that handles movement of mass driver packets. The distances use doubles, so the only decimals are for size and speed. Are either of those unusually large?

To edit the resources at the colony, go to Mining Tab in SM Mode, unclick the 'Double-click Sets Reserve Level' checkbox and double click on the mineral for which you wish to edit the stockpile.
Title: Re: v1.13.0 Bugs Thread
Post by: RagnarVaren on May 07, 2021, 03:37:20 PM
EDIT: Auto Assign FC makes the railguns reappear.

For some reason my railguns are not appearing in the ship combat tab for a destroyer that was refit from a previous version.

Notes:
-This is a destroyer that was refit from a previous version. Railguns are same type but twin gauss cannon are different.
-When I "instant build" a destroyer the railguns appear for that destroyer in the ship combat tab.
-Another possible cause is that I've prebuilt some railguns (but not twin gauss cannon) at the shipyard colony and it somehow bugs out the refit.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 07, 2021, 04:05:45 PM
Civilian Shipping Contracts are overfilling.

After a civilian ship loads an installation at the supply location, the "Assigned" amount of the demand contract reduces by 1.
If a new supply contract for this installation is created before this ship finishes unloading at the destination, the civvies will use that supply to fulfill the original demand contract again.
This can happen over and over for a single demand contract.
A civ ship will eventually deliver the installation, causing that demand contract to be deleted. But all the others en route will finish their delivery.

Steps to reproduce:

0) Ensure that a shipping company exists and that no supply or demand contracts currently exist.
1) Create a supply contract for 1 installation at Colony A (make sure Colony A has at least 1 such installation).
2) Create a demand contract for 1 of the same installation at Colony B (must be in same system as Colony A, or a jumpgate route must exist from A to B).
3) Advance time until a civilian freighter has been assigned to deliver the installation. Note that the "Assigned" amount has changed to 1 for both the supply and the demand contract.
4) Advance time until the civilian freighter has finished loading the installation at Colony A and begun moving to B. Note that the supply contract has disappeared, and the "Assigned" amount has changed back to 0 for the demand contract.
5) Create a new supply contract for 1 of the same installation at Colony A. Do not create any matching demand contract.
6) Advance time. If/when a civilian freighter becomes available before the original freighter has unloaded the installation at B, the newly available freighter will be assigned to deliver the installation from A to B. The supply and demand contract "Assigned" amounts will change to 1 and the ship will move to A, load the installation (which reduces the "Assigned" amount on the demand contract back to 0), and begin moving to B.
7) If you like, go back to step 5 and do it again. See how many civvies you can get loaded up before the original freighter finally delivers the installation.

Any luck with this one? It greatly hampers the use of civilian shipping contracts. I'm happy to test specific scenarios if that helps track it down.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on May 07, 2021, 08:12:58 PM
After a bit of testing, I can conclude that "Generate non-TN races only" setting straight up does not work in 1,13.
I checked NPRs that are generated at the start of the game and later tested NPRs that are generated with exploration. In both cases, NPRs have TN tech, build ships, research tech, create colonies, explore and so on. They do not even start with Conventional Industries - everything is already converted.
At first I thought that NPRs might wrongly receive and use instant research and build points. After further testing I can say NPRs are generated with TN tech because logs do not have a TN research message (as opposed to any other research being logged, both normal and instant). Because they are not generated as conventional, they receive their normal instant research and build points and immediately spend them and operate as normal post-TN NPR.
Some people told me that conventional NPRs are lobotomized because they have no conventional logic implemented (and lack of logic is the same reason for TN NPRs having hardcoded instant research points), but then why have the "Generate non-TN races only" option at all if it won't function as many players expect it to function? IMO it should either be removed completely, or it is time to make it work.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on May 08, 2021, 03:21:03 AM
1.13
Reassign a new governor or any official to the same position will generate infinite logs of the same content

I am sure I have already reported this in the past as well as this is an old one, which before automatic assignments it was still possible to avoid, however, every time you multiple-click on reassign, or you run a new assignment and the governor does not change you will end up facing it.


(https://i.imgur.com/u6EAJmC.png)
Clicking on Reassign on auto or manual multiple times


(https://i.imgur.com/5vw3pUU.png)
Clicking on reassign auto after a few years

SJW: Added code to prevent a commander being assigned to their existing role
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 08, 2021, 06:55:34 AM
1.13
Reassign a new governor or any official to the same position will generate infinite logs of the same content

Just to clarify, you mean the bug happens when assigning a commander to the role they already occupy?
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on May 08, 2021, 12:11:53 PM
While dragging weapons to Directors it is possible to create a serious error. I believe I did this when I accidentally dragged a fire director onto another Beam fire director which somehow froze Aurora it created the following error series on loading again
Now when I go to the ship combat window for any ship not just the ship I was on or its class I get the following error
Function #2147 The Given Key was not present in the directory
then on clicking ok
Function #463 The Given Key was not present in the directory
clicking ok ends the errors but gives a blank ship combat window.
Following this clicking on a different ship gives
#357 The Given Key was not present in the directory
and still a blank Ship Combat screen

Edit The bug seems to persist in previous saved DB's

SJW: Unable to reproduce.
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 08, 2021, 02:01:44 PM
Game: TN Start
Stars: Random
Decimal Seperator: Period
Reproducibility: Everytime I save.
Campaign Length: 6.5 years
Mods or DB changes: None

I started a new game on 1.13.0, after replacing the .exe and .db file from my 1.12.0 install. Felt bold and started the game with 3 NPRs at game start. Been playing for a few years, mostly just teching up, when I started getting a lot of 5 second increments due to NPR actions. I opened the database using Valentina Studio 11 to read the event log since designer mode isn't available in C#, and saw it looked like an NPR race was slowly getting their homeworld glassed by beam weapons, so I returned to the game without modifying the DB. I set sub-pulse length to Auto and then did automated turns for awhile until the NPR finished their combat and I could successfully get 5 day turn lengths as I resumed teching up and expanding mining operations in my home system.

Since then, every time I save, saving game has taken a few minutes. During saving, on around 3 separate occasions I'll get about 5 repeating pop ups stating "1.13.0 Function #3239: Object reference not set to an instance of an object." Saving appears to eventually complete successfully, but I have to keep checking back in to get through the error boxes so the saving process can continue. I attached a screenshot of the error and my AuroraDB. Game name is "1.13."

SJW: Fixed the #3239 error for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Demetrious on May 08, 2021, 02:05:40 PM
Being fired upon by STO units only doesn't seem to flag a race as hostile. This isn't a problem for the player, as they can do it manually, but it does make NPR's unable to fight back.

The cheeky boys colonized the moon of my colony in Alpha Centauri. Set the "Cronulla Star Empire" hostile and watch the fireworks fly; the STOs are already set to shoot. Oddly enough when I sent that fleeing lifeboat back to drop my scuttled diplo station's survivors off, the planet's STOs lit THAT up, but were not flagged as hostile and are not responding to my own bombardment.

Save file: https://www.mediafire.com/file/e3cr7jlttospgnv/AuroraDB_-_aliens_won%2527t_fire.db/file
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 08, 2021, 02:55:44 PM
Are normal NPRs supposed to know the secrets of "Swarm Extraction Module"? I got this upon capturing an NPR's homeworld. This is the NPR that originally spawned at game start.

I mean, it's kinda neat from an RP perspective. Maybe their backstory is they were performing experiments on the Swarm.... or maybe they are, in fact, the progenitors of the Swarm as a genetic project gone wrong?

(https://i.imgur.com/XgtHlHh.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on May 08, 2021, 03:19:40 PM
1.13
Reassign a new governor or any official to the same position will generate infinite logs of the same content

Just to clarify, you mean the bug happens when assigning a commander to the role they already occupy?

Correct
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 08, 2021, 05:29:35 PM
Game: TN Start
Stars: Random
Decimal Seperator: Period
Reproducibility: Everytime I save.
Campaign Length: 6.5 years
Mods or DB changes: None

I started a new game on 1.13.0, after replacing the .exe and .db file from my 1.12.0 install. Felt bold and started the game with 3 NPRs at game start. Been playing for a few years, mostly just teching up, when I started getting a lot of 5 second increments due to NPR actions. I opened the database using Valentina Studio 11 to read the event log since designer mode isn't available in C#, and saw it looked like an NPR race was slowly getting their homeworld glassed by beam weapons, so I returned to the game without modifying the DB. I set sub-pulse length to Auto and then did automated turns for awhile until the NPR finished their combat and I could successfully get 5 day turn lengths as I resumed teching up and expanding mining operations in my home system.

Since then, every time I save, saving game has taken a few minutes. During saving, on around 3 separate occasions I'll get about 5 repeating pop ups stating "1.13.0 Function #3239: Object reference not set to an instance of an object." Saving appears to eventually complete successfully, but I have to keep checking back in to get through the error boxes so the saving process can continue. I attached a screenshot of the error and my AuroraDB. Game name is "1.13."


Ended up having to abandon this game, game saving continued to take longer and longer with more of the Function #3239 errors; last attempt took ~15 minutes. Game is also stuck in permanent 2 hour time pulses, as best I can tell in the game log this is due to NPR fleets unable to complete their standing orders and/or NPR civilian shipping unable to load structures for requested shipments. Final DB attached.
Title: Re: v1.13.0 Bugs Thread
Post by: mike2R on May 09, 2021, 04:13:47 AM
On the Select Alien Class Hull window, that comes up when you press the Set Class Hull button, on the Intelligence and Foreign Relations window, these is an extra checkbox with the text: "Set all Formations with Same Template at Same Population".

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: mike2R on May 09, 2021, 04:21:54 AM
This has been around for a while, but I'm not sure if I've ever seen it reported:

If I use the Civilian Economy tab of the Economies window to set my capital to supply a quantity of an installation, and then set multiple demands at different colonies that add up to the same quantity, I always end up with some colonies getting more than they ask for, and others getting less or none.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on May 09, 2021, 06:11:37 AM
Quote from: Remilian link=topic=12522. msg151290#msg151290 date=1620436378
After a bit of testing, I can conclude that "Generate non-TN races only" setting straight up does not work in 1,13. 
I checked NPRs that are generated at the start of the game and later tested NPRs that are generated with exploration.  In both cases, NPRs have TN tech, build ships, research tech, create colonies, explore and so on.  They do not even start with Conventional Industries - everything is already converted. 
At first I thought that NPRs might wrongly receive and use instant research and build points.  After further testing I can say NPRs are generated with TN tech because logs do not have a TN research message (as opposed to any other research being logged, both normal and instant).  Because they are not generated as conventional, they receive their normal instant research and build points and immediately spend them and operate as normal post-TN NPR. 
Some people told me that conventional NPRs are lobotomized because they have no conventional logic implemented (and lack of logic is the same reason for TN NPRs having hardcoded instant research points), but then why have the "Generate non-TN races only" option at all if it won't function as many players expect it to function? IMO it should either be removed completely, or it is time to make it work.
Forgot to say what the issue amounts to: if you want to start as conventional then there is no way to make NPR conventional, so you are forced to generate 0 at start and rely only on exploration generation, because if you don't - then you get absolutely steamrolled by the starting NPR due to progress difference. At low research speed games you likely won't even end your conventional era by the time NPR finds and exterminates you.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 09, 2021, 06:59:46 AM
Game: TN Start
Stars: Random
Decimal Seperator: Period
Reproducibility: Everytime I save.
Campaign Length: 6.5 years
Mods or DB changes: None

I started a new game on 1.13.0, after replacing the .exe and .db file from my 1.12.0 install. Felt bold and started the game with 3 NPRs at game start. Been playing for a few years, mostly just teching up, when I started getting a lot of 5 second increments due to NPR actions. I opened the database using Valentina Studio 11 to read the event log since designer mode isn't available in C#, and saw it looked like an NPR race was slowly getting their homeworld glassed by beam weapons, so I returned to the game without modifying the DB. I set sub-pulse length to Auto and then did automated turns for awhile until the NPR finished their combat and I could successfully get 5 day turn lengths as I resumed teching up and expanding mining operations in my home system.

Since then, every time I save, saving game has taken a few minutes. During saving, on around 3 separate occasions I'll get about 5 repeating pop ups stating "1.13.0 Function #3239: Object reference not set to an instance of an object." Saving appears to eventually complete successfully, but I have to keep checking back in to get through the error boxes so the saving process can continue. I attached a screenshot of the error and my AuroraDB. Game name is "1.13."


Ended up having to abandon this game, game saving continued to take longer and longer with more of the Function #3239 errors; last attempt took ~15 minutes. Game is also stuck in permanent 2 hour time pulses, as best I can tell in the game log this is due to NPR fleets unable to complete their standing orders and/or NPR civilian shipping unable to load structures for requested shipments. Final DB attached.

#3239 is saving installations in cargo. The object reference error might be caused by trying to save cargo that originated in a population that no longer exists. I'll add some code to handle that. In the meantime, the workaround would be to delete records from the FCT_ShipCargo table that have a cargo type of 2.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 09, 2021, 07:19:34 AM
After a bit of testing, I can conclude that "Generate non-TN races only" setting straight up does not work in 1,13.
I checked NPRs that are generated at the start of the game and later tested NPRs that are generated with exploration. In both cases, NPRs have TN tech, build ships, research tech, create colonies, explore and so on. They do not even start with Conventional Industries - everything is already converted.
At first I thought that NPRs might wrongly receive and use instant research and build points. After further testing I can say NPRs are generated with TN tech because logs do not have a TN research message (as opposed to any other research being logged, both normal and instant). Because they are not generated as conventional, they receive their normal instant research and build points and immediately spend them and operate as normal post-TN NPR.
Some people told me that conventional NPRs are lobotomized because they have no conventional logic implemented (and lack of logic is the same reason for TN NPRs having hardcoded instant research points), but then why have the "Generate non-TN races only" option at all if it won't function as many players expect it to function? IMO it should either be removed completely, or it is time to make it work.

Non-TN doesn't mean conventional. It means pre-industrial (as per the tooltip) and only for non-starting races. You are correct though that it isn't working, so I have fixed that for v1.14.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 09, 2021, 07:20:39 AM
This has been around for a while, but I'm not sure if I've ever seen it reported:

If I use the Civilian Economy tab of the Economies window to set my capital to supply a quantity of an installation, and then set multiple demands at different colonies that add up to the same quantity, I always end up with some colonies getting more than they ask for, and others getting less or none.

In fact I reported a slightly different version (http://aurora2.pentarch.org/index.php?topic=12522.msg151178#msg151178) just a few days ago.

The cause is that the "Assigned" amount on the demand side decreases by one every time a freighter finishes loading for that contract at the supply site.

I'm glad I'm not the only one running into this. I was starting to wonder if I was going crazy.

It makes civilian contracts far less useful than they could be.
You can still use them, but if any installation type has more than one open demand contract at a time, you get unpredictable results.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 09, 2021, 07:22:11 AM
Forgot to say what the issue amounts to: if you want to start as conventional then there is no way to make NPR conventional, so you are forced to generate 0 at start and rely only on exploration generation, because if you don't - then you get absolutely steamrolled by the starting NPR due to progress difference. At low research speed games you likely won't even end your conventional era by the time NPR finds and exterminates you.

That is working as intended. A Conventional Start is intended as 'hard mode'.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 09, 2021, 07:23:09 AM
Civilian Shipping Contracts are overfilling.

After a civilian ship loads an installation at the supply location, the "Assigned" amount of the demand contract reduces by 1.
If a new supply contract for this installation is created before this ship finishes unloading at the destination, the civvies will use that supply to fulfill the original demand contract again.
This can happen over and over for a single demand contract.
A civ ship will eventually deliver the installation, causing that demand contract to be deleted. But all the others en route will finish their delivery.

Steps to reproduce:

0) Ensure that a shipping company exists and that no supply or demand contracts currently exist.
1) Create a supply contract for 1 installation at Colony A (make sure Colony A has at least 1 such installation).
2) Create a demand contract for 1 of the same installation at Colony B (must be in same system as Colony A, or a jumpgate route must exist from A to B).
3) Advance time until a civilian freighter has been assigned to deliver the installation. Note that the "Assigned" amount has changed to 1 for both the supply and the demand contract.
4) Advance time until the civilian freighter has finished loading the installation at Colony A and begun moving to B. Note that the supply contract has disappeared, and the "Assigned" amount has changed back to 0 for the demand contract.
5) Create a new supply contract for 1 of the same installation at Colony A. Do not create any matching demand contract.
6) Advance time. If/when a civilian freighter becomes available before the original freighter has unloaded the installation at B, the newly available freighter will be assigned to deliver the installation from A to B. The supply and demand contract "Assigned" amounts will change to 1 and the ship will move to A, load the installation (which reduces the "Assigned" amount on the demand contract back to 0), and begin moving to B.
7) If you like, go back to step 5 and do it again. See how many civvies you can get loaded up before the original freighter finally delivers the installation.

Any luck with this one? It greatly hampers the use of civilian shipping contracts. I'm happy to test specific scenarios if that helps track it down.

Not yet. I suspect a lot of investigation needed, so waiting till I have the time to get into properly.
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 09, 2021, 08:25:59 PM

Ended up having to abandon this game, game saving continued to take longer and longer with more of the Function #3239 errors; last attempt took ~15 minutes. Game is also stuck in permanent 2 hour time pulses, as best I can tell in the game log this is due to NPR fleets unable to complete their standing orders and/or NPR civilian shipping unable to load structures for requested shipments. Final DB attached.

#3239 is saving installations in cargo. The object reference error might be caused by trying to save cargo that originated in a population that no longer exists. I'll add some code to handle that. In the meantime, the workaround would be to delete records from the FCT_ShipCargo table that have a cargo type of 2.

Thanks Steve, I went back to this game and deleted all the FCT_ShipCargo records with cargo type of 2. This solved the #3239 error and saving the game takes the normal amount of time now. However, the game is still stuck in 2 hour sub-pulses even with auto-subpulse set. Automated Turns of 5 days just sit there chugging along in two hour blocks. The game log includes lots of these records for the NPR races:

"DDG Lome II 005 is unable to carry out its primary standing order: Join Operational Group"
"Stabilisation Squadron 006 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point"
"SS Spider 004 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)"
"Salvage Squadron 003 is unable to carry out its primary standing order: Salvage Nearest Wreck"

etc.

Could one of them be causing the interrupts? Logs are also still in the DB I provided previously.
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 11, 2021, 12:12:56 PM
"Update all formations with same replacement template" checkbox has no effect.
Extra checkbox in Change Replacement Template window for ground units.

Game: TN Start
Stars: Random
Decimal Seperator: Period
Reproducibility: Everytime I updated a template for an Infantry Regiment
Campaign Length: 17 years
Mods or DB changes: None

I've been working on designing the next series of ground units. Thanks to some help from nuclearslurpee (http://aurora2.pentarch.org/index.php?topic=11545.msg151418#msg151418) he directed me to Steve's post here http://aurora2.pentarch.org/index.php?topic=11593.msg140370#msg140370 about how to handle Ground Unit replacement templates.

My original units used the formation template "Infantry Regiment," and I designed a new template "2042 Infantry Regiment" using the upgraded units. I then went to my Ground Unit OOB to update the existing "Infantry Regiment"'s to use the new "2042 Infantry Regiment" as their replacement template. I am able to update each unit one by one, but I saw there was a "Update all formations with same replacement template" checkbox in the Change Replacement Template Window, which I assume would mean that in one go I can change anything currently using the "Infantry Regiment" replacement template to use the "2042 Infantry Regiment" replacement template. However, this appears to not be the case, and checking this box does not have any effect on any other infantry regiments. There also appears to be a second floating checkbox in the window (screenshot attached), and I tested checking 1 box alone, the other box alone, both boxes at once, and neither box, and all had the same behavior where no other unit's replacement templates were changed. DB attached, game name is "New 13."

(https://i.imgur.com/MgYHeq4l.png) (https://i.imgur.com/MgYHeq4.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on May 11, 2021, 03:36:17 PM
In DIM_SystemAge table, first entry has a really weird Age2 column value.  No idea where it is used, if at all, but might wanna check that one out.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on May 11, 2021, 03:54:41 PM
Gas "None" can be added to the atmosphere with "SM: Set Atm"

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on May 12, 2021, 01:00:44 AM
 - New bug on v1.13.0, but very minor. Cosmetic, really. On the Ground Forces window, the "Base Unit Type" above "Infantry" is a selectable field. Easy enough to reproduce, just... go to the Ground Forces window and click on the "Base Unit Type" field and viola! Bug du jour.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 12, 2021, 07:58:16 AM
Oxygen not showing "(F)" when frozen?

A planet in my game with surface temp -107.034C (165.966k) shows the following atmospheric gases:

GasAtm
Nitrogen 1.2128
Carbon Dioxide (F)0.1499
Oxygen 0.018

The total displayed for Atmospheric Pressure is 1.213.
The CO2 and Oxygen are being ignored in this total.
I believe the "(F)" on the CO2 line means it is frozen, and therefore not contributing to atmospheric pressure.
I suspect the Oxygen is also frozen, but it does not have the indicator.
Title: Re: v1.13.0 Bugs Thread
Post by: serger on May 12, 2021, 08:15:47 AM
Oxygen not showing "(F)" when frozen?

A planet in my game with surface temp -107.034C (165.966k)

It's not a bug - oxygen's temperature of melting is about -220C.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 12, 2021, 08:42:45 AM
Oxygen not showing "(F)" when frozen?

A planet in my game with surface temp -107.034C (165.966k)

It's not a bug - oxygen's temperature of melting is about -220C.

In that case, the bug is that the oxygen is not being counted in the total atmospheric pressure.
Title: Re: v1.13.0 Bugs Thread
Post by: villaincomer on May 12, 2021, 02:09:38 PM
Running without mods, tinkered with numbers at start to give myself a bit of a head start.   

35 years into the game on start-up I get:
1.   13.   0 Function #1168:  The given key was not present in the dictionary.   

I can ok it and get in.     
Background:
I had recently occupied a precursor and recovered some installations on their planet.     Some installations have gone to the colony which my landed army is sitting.     Some installations recovered to the subjugated colony.     
Im assuming its that.     

Q:  Is there a way I can merge those colonies in SM to see if that fixes it?
Some people have emigrated so population isnt empty

*Edit:  I have tried deleting the subjugated planet entirely.   Saved and the game loads ok without errors.   Assuming this confirms my cause hypothesis.  However it would be nice to be able to fix/tinker so I can play from here if at all possible. 

Also:
Earlier in the game I got another error (~cant div by zero ) but I thought it had been caused by a ruin recovery where I was transporting terraformers off planet via the civilian economy while the ruins where still being explored.     At one point there was a fraction of an installation to >10 decimal places.   
I used SM to round it back to a whole number and didn't experience that error again.   

Happy to zip db copy at this point if its of use.   
p.   s  Love the game :)
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 12, 2021, 02:20:02 PM
Logistics Bonus not working as expected.

I have a freighter class with a load time (per the design screen) of 5:18:53.
The class has a bridge.
I have only standard cargo shuttles--I have not researched TN shuttles.

I have a fleet consisting of one of these freighters, with no commander.
The fleet is under the root admin command. The admin commander has no logistics bonus.
I give the fleet orders to load at a population with no planet governor, no sector governor, no spaceport, and no cargo shuttle station.

In this situation, which has no bonuses applying to loading time, I expect the load order to take 5:18:53.
And it does. Good.

Now I assign a ship commander with a 5% logistics bonus.
It is reasonable to expect that the load would now take 95% as long as the base load time.
Instead, the load takes 92.91% as long (5:09:02).

Swapping this commander out for others with various bonuses, here are the results:

commander bonus                      5%                10%         15%        20%         30%        50%
result (pct of base time)             92.91%          86.57%   80.88%   75.76%   66.89%   46.67%
effective bonus                           7.09%           13.43%   19.12%   24.24%   33.11%   53.33%
load time as pct of expected       97.8%           96.2%     95.2%     94.7%      95.6%      93.3%


Something odd is going on here, but I can't quite identify it.
Neither the error magnitude nor percentage are constant.
The error percentage seems to be marginally decreasing until 20% commander bonus, then increasing, then decreasing again.

I suspect that for very high aggregate bonus levels (from stacking admin commands, governors, and spaceports), the error is negative--that is, that load times in those circumstances are longer than expected.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 12, 2021, 04:00:37 PM
I suspect that the problem

umm... did you forget something?
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 12, 2021, 04:07:05 PM
I suspect that the problem

umm... did you forget something?

Of course I did. I forgot a final proofread.
I've deleted that line...it was supplanted by the prior passage.

Thanks for the heads up.
Title: Re: v1.13.0 Bugs Thread
Post by: GodEmperor on May 13, 2021, 02:58:08 PM
I dont know if anyone reported it but there is a bug where sometimes researched ship parts get finished and then disappear from ship design/tech windows and cannot be added to ship designs.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 13, 2021, 04:00:26 PM
When setting the field position of unit templates using the "set all formations with same template at same population", formations set to replace are also affected despite the fact that their template is "none".

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 14, 2021, 10:36:08 AM
The minimum jump engine size tech doesn't seem to do anything.  I can build size 1 jump engines without researching any of the techs.
Title: Re: v1.13.0 Bugs Thread
Post by: Remilian on May 14, 2021, 11:00:04 AM
The minimum jump engine size tech doesn't seem to do anything.  I can build size 1 jump engines without researching any of the techs.
It think this is intended. Engines smaller than your tech can only self-jump.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 14, 2021, 11:02:53 AM
Quote from: Remilian link=topic=12522. msg151520#msg151520 date=1621008004
Quote from: ISN link=topic=12522. msg151517#msg151517 date=1621006568
The minimum jump engine size tech doesn't seem to do anything.   I can build size 1 jump engines without researching any of the techs.
It think this is intended.  Engines smaller than your tech can only self-jump.

Oh, is that so? I didn't realize it only affected the self-jump constraint.  Never mind, the tech is only confusingly named.  ;D
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 14, 2021, 01:30:15 PM
Quote from: Remilian link=topic=12522. msg151520#msg151520 date=1621008004
Quote from: ISN link=topic=12522. msg151517#msg151517 date=1621006568
The minimum jump engine size tech doesn't seem to do anything.   I can build size 1 jump engines without researching any of the techs.
It think this is intended.  Engines smaller than your tech can only self-jump.

Oh, is that so? I didn't realize it only affected the self-jump constraint.  Never mind, the tech is only confusingly named.  ;D

And the term "self-jump" is also confusing.
It only means that the engine can't be used for squadron jumps.
It does not mean that the engine can only jump the ship it is mounted on.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 14, 2021, 03:09:05 PM
It does not mean that the engine can only jump the ship it is mounted on.

Isn't this exactly what "self-jump" is supposed to mean? That the ship can only jump itself? I am certain that self-jump ships cannot act as jump tenders for other ships even for standard transits.
Title: Re: v1.13.0 Bugs Thread
Post by: SpaceMarine on May 14, 2021, 03:36:19 PM
It does not mean that the engine can only jump the ship it is mounted on.

Isn't this exactly what "self-jump" is supposed to mean? That the ship can only jump itself? I am certain that self-jump ships cannot act as jump tenders for other ships even for standard transits.

they can and do, self jump refers to the fact that they cannot jump anyone but themselves in squadron transit, I have tested this infact during my recent star trek game. It is unintuitive but like many things in aurora wdye
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 14, 2021, 04:42:15 PM
It does not mean that the engine can only jump the ship it is mounted on.

Isn't this exactly what "self-jump" is supposed to mean? That the ship can only jump itself? I am certain that self-jump ships cannot act as jump tenders for other ships even for standard transits.

they can and do, self jump refers to the fact that they cannot jump anyone but themselves in squadron transit, I have tested this infact during my recent star trek game. It is unintuitive but like many things in aurora wdye

So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 14, 2021, 08:38:45 PM
So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 14, 2021, 10:19:13 PM
So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".

I wonder if that's the behavior Steve intended, or if it perhaps is a bug.
Title: Re: v1.13.0 Bugs Thread
Post by: Density on May 15, 2021, 04:49:34 AM
Quote from: skoormit link=topic=12522. msg151538#msg151538 date=1621042725
Just replace the term "self-jump only" in your mind with "standard transit only".

When I use self jump drives, those ships can squadron transit themselves.  They just have a squadron size of 1.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 15, 2021, 09:47:38 AM
Quote from: skoormit link=topic=12522. msg151538#msg151538 date=1621042725
Just replace the term "self-jump only" in your mind with "standard transit only".

When I use self jump drives, those ships can squadron transit themselves.  They just have a squadron size of 1.

That's fair. Perhaps a more accurate statement is:

Just replace the term "self-jump only" in your mind with "max squadron size 1 (unlimited standard transits)".
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 15, 2021, 10:09:25 AM
While dragging weapons to Directors it is possible to create a serious error. I believe I did this when I accidentally dragged a fire director onto another Beam fire director which somehow froze Aurora it created the following error series on loading again
Now when I go to the ship combat window for any ship not just the ship I was on or its class I get the following error
Function #2147 The Given Key was not present in the directory
then on clicking ok
Function #463 The Given Key was not present in the directory
clicking ok ends the errors but gives a blank ship combat window.
Following this clicking on a different ship gives
#357 The Given Key was not present in the directory
and still a blank Ship Combat screen

Edit The bug seems to persist in previous saved DB's

I dragged a beam fire control on top of another but I can't reproduce the bug you specified. #2147 is the display of population contacts on the tactical map and #463 is another tactical map contact display function. The only key referenced in both functions is RaceID so not sure why those functions would be affected by a problem with fire control assignment. #357 is the combat information on the fleet window though. It is possible those first two are incorrect error numbers?

While experimenting, I did cause a problem by dragging a fire control on to the point defence node, so I fixed that :)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 15, 2021, 10:34:35 AM
Being fired upon by STO units only doesn't seem to flag a race as hostile. This isn't a problem for the player, as they can do it manually, but it does make NPR's unable to fight back.

The cheeky boys colonized the moon of my colony in Alpha Centauri. Set the "Cronulla Star Empire" hostile and watch the fireworks fly; the STOs are already set to shoot. Oddly enough when I sent that fleeing lifeboat back to drop my scuttled diplo station's survivors off, the planet's STOs lit THAT up, but were not flagged as hostile and are not responding to my own bombardment.

Save file: https://www.mediafire.com/file/e3cr7jlttospgnv/AuroraDB_-_aliens_won%2527t_fire.db/file

Not sure what is going on here. The diplomatic rating is modified during damage resolution and that code is the same whether the damage by caused by an STO or a ship-based energy weapons. There may be some other factor at work.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 15, 2021, 11:16:25 AM
Are normal NPRs supposed to know the secrets of "Swarm Extraction Module"? I got this upon capturing an NPR's homeworld. This is the NPR that originally spawned at game start.

I mean, it's kinda neat from an RP perspective. Maybe their backstory is they were performing experiments on the Swarm.... or maybe they are, in fact, the progenitors of the Swarm as a genetic project gone wrong?

(https://i.imgur.com/XgtHlHh.png)

No idea where the NPR managed to get it, but it shouldn't have access. Good idea on the lore though :)

Title: Re: v1.13.0 Bugs Thread
Post by: Geeptoon on May 15, 2021, 11:46:08 AM
Might be a bug.  Seem to have the increment length always at a lower level than what I have selected.   Started after an npr must have been haveing a battle with another npr.  If I have 30 days selected it runs 6 hour increments.  If I have 5 days selected it runs 2hour increments.  8hour increments were 2mins I think.   Anyways this went on until I started goofing around with the sub pulses by keeping the increment at 1 day and changing the sub pulse one step lower.  now everything is back to normal.   Before that I had tried turning detection off with no results and saveing  and reloading with no change.  The npr has even had a few battles with out the abnormal behavior.
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on May 15, 2021, 12:32:08 PM
Quote

I dragged a beam fire control on top of another but I can't reproduce the bug you specified. #2147 is the display of population contacts on the tactical map and #463 is another tactical map contact display function. The only key referenced in both functions is RaceID so not sure why those functions would be affected by a problem with fire control assignment. #357 is the combat information on the fleet window though. It is possible those first two are incorrect error numbers?

While experimenting, I did cause a problem by dragging a fire control on to the point defence node, so I fixed that :)
I think I misdiagnosed the problem. I have created it in several games, the problem seems actually to be giving Ground combat units to an NPR and then deleting the Player race who provided them, probably doing something that weird is quite rare. One of the symptoms is not seeing the fire controls and the game crashed on that screen before the error first occurred. A db with the error occurring is attached, not the first time the error occurred but a later game. I accidentally deleted the original error
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 15, 2021, 01:29:38 PM
I think this is a bug, but not sure. It was my understanding that Orbital Habitat population is considered 100% Manufacturing population. However, in this example below (where I'm trying to kickstart some terraformers), they are not contributing 100% to manufacturing.

(https://i.imgur.com/BqyzlEz.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 15, 2021, 01:34:52 PM
- New bug on v1.13.0, but very minor. Cosmetic, really. On the Ground Forces window, the "Base Unit Type" above "Infantry" is a selectable field. Easy enough to reproduce, just... go to the Ground Forces window and click on the "Base Unit Type" field and viola! Bug du jour.

You can click on it but it doesn't do anything. You can do the same thing on many different lists.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 15, 2021, 03:51:24 PM
Logistics Bonus not working as expected.

I have a freighter class with a load time (per the design screen) of 5:18:53.
The class has a bridge.
I have only standard cargo shuttles--I have not researched TN shuttles.

I have a fleet consisting of one of these freighters, with no commander.
The fleet is under the root admin command. The admin commander has no logistics bonus.
I give the fleet orders to load at a population with no planet governor, no sector governor, no spaceport, and no cargo shuttle station.

In this situation, which has no bonuses applying to loading time, I expect the load order to take 5:18:53.
And it does. Good.

Now I assign a ship commander with a 5% logistics bonus.
It is reasonable to expect that the load would now take 95% as long as the base load time.
Instead, the load takes 92.91% as long (5:09:02).

Swapping this commander out for others with various bonuses, here are the results:

commander bonus                      5%                10%         15%        20%         30%        50%
result (pct of base time)             92.91%          86.57%   80.88%   75.76%   66.89%   46.67%
effective bonus                           7.09%           13.43%   19.12%   24.24%   33.11%   53.33%
load time as pct of expected       97.8%           96.2%     95.2%     94.7%      95.6%      93.3%


Something odd is going on here, but I can't quite identify it.
Neither the error magnitude nor percentage are constant.
The error percentage seems to be marginally decreasing until 20% commander bonus, then increasing, then decreasing again.

I suspect that for very high aggregate bonus levels (from stacking admin commands, governors, and spaceports), the error is negative--that is, that load times in those circumstances are longer than expected.

The problem was two-fold. Firstly, only half the commander logistics bonus was being applied because I mistakenly called the function that returned a ship bonus (used for situations where a second officer provides the primary bonus), rather than the commander bonus. Secondly, the full commander logistic bonus was being used a modifier to the number of cargo shuttle bays on the ship. Both are fixed for v1.14. I also checked the whole program to ensure I wasn't using the ship bonus incorrectly anywhere else (I wasn't).

The full calculation is:

Cargo Handling Modifier = Number of Cargo Shuttle Bays * Admin Command Bonus * Commander Logistics Bonus * Race Cargo Shuttle Load Modifier
(If there are one or more spaceports or cargo handing stations on the planet, that adds a single extra cargo shuttle bay)

The normal loading time is then divided by the Cargo Handling Modifier.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 15, 2021, 05:58:45 PM
So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".

I wonder if that's the behavior Steve intended, or if it perhaps is a bug.

It was intended as self-jump only. However, I think the unintended behaviour is actually a better option.

I've changed the 'Self-Jump' text to 'No Squadron Jump' and I have changed the 'Minimum Jump Engine Size' tech line to 'Minimum Squadron Jump Engine Size'.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 15, 2021, 06:10:14 PM
So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".

I wonder if that's the behavior Steve intended, or if it perhaps is a bug.

It was intended as self-jump only. However, I think the unintended behaviour is actually a better option.

I've changed the 'Self-Jump' text to 'No Squadron Jump' and I have changed the 'Minimum Jump Engine Size' tech line to 'Minimum Squadron Jump Engine Size'.

Often times the best way to fix a bug is to just call it a feature
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 15, 2021, 06:52:27 PM
So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".

I wonder if that's the behavior Steve intended, or if it perhaps is a bug.

It was intended as self-jump only. However, I think the unintended behaviour is actually a better option.

I've changed the 'Self-Jump' text to 'No Squadron Jump' and I have changed the 'Minimum Jump Engine Size' tech line to 'Minimum Squadron Jump Engine Size'.

Hooray!

I love making my early fighter-sized jump tenders to service my fighter surveyors. Glad I get to keep doing that.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 15, 2021, 08:42:27 PM
I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

(https://i.imgur.com/IWS7QuV.png)

(https://i.imgur.com/Y3q7HAy.png)
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 15, 2021, 11:14:25 PM
Total Atmospheric Pressure Incorrect with Frozen Gases

Planet has the following gases:

Nitrogen 0.3581
Oxygen 0.0952
Sulphur Dioxide (F) 0.0133

The total Atmospheric Pressure shown is 0.440.

One way to arrive at that total is to add just the Nitrogen and the Oxygen, and then subtract the Sulphur Dioxide.

The incorrect ATM total leads to an incorrect GH factor and an incorrect temperature.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 16, 2021, 06:21:12 AM
I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

I am sure you won't be shocked to learn that error #2184 is in Display Mining. I think you are on the right lines with the manufacturing but hard to pin down. It might be caused by extremely small but non-zero production resulting in a depletion time that is longer than a decimal can hold. Could you post a screenshot of the mining window on a turn when you don't have the error?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 16, 2021, 06:35:48 AM
Total Atmospheric Pressure Incorrect with Frozen Gases

Planet has the following gases:

Nitrogen 0.3581
Oxygen 0.0952
Sulphur Dioxide (F) 0.0133

The total Atmospheric Pressure shown is 0.440.

One way to arrive at that total is to add just the Nitrogen and the Oxygen, and then subtract the Sulphur Dioxide.

The incorrect ATM total leads to an incorrect GH factor and an incorrect temperature.

The atmospheric pressure calculation is incorrect (well spotted). The GH factor and temperature calculation are both working fine as they independently check non-frozen gases only and don't reference the atmospheric pressure calculation.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 16, 2021, 08:03:02 AM
I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

I am sure you won't be shocked to learn that error #2184 is in Display Mining. I think you are on the right lines with the manufacturing but hard to pin down. It might be caused by extremely small but non-zero production resulting in a depletion time that is longer than a decimal can hold. Could you post a screenshot of the mining window on a turn when you don't have the error?

I peeked inside the "Population" database table, and all the minerals on that body have a quantity of 8.2e-26 (super small). It's the only population in my 100-year game database that has a mineral quantity readout like that. Also, I have a strong suspicion this same bug might have been interacting with mass driver shipments off this planet (before I stopped them) and causing another function error from mass drivers because of it.

Here's the screenshot you asked for. I had to load an older save backup. When I loaded the game, the error happened right away, then I progressed forward 5 days, and then the error didn't happen. Here's the screenshot of the mining window from when the error did not occur:

Thanks for all your hard work tracking down our bugs!

(https://i.imgur.com/PM7acGo.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 16, 2021, 08:13:05 AM
I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

I am sure you won't be shocked to learn that error #2184 is in Display Mining. I think you are on the right lines with the manufacturing but hard to pin down. It might be caused by extremely small but non-zero production resulting in a depletion time that is longer than a decimal can hold. Could you post a screenshot of the mining window on a turn when you don't have the error?

I peeked inside the "Population" database table, and all the minerals on that body have a quantity of 8.2e-26 (super small). It's the only population in my 100-year game database that has a mineral quantity readout like that. Also, I have a strong suspicion this same bug might have been interacting with mass driver shipments off this planet (before I stopped them) and causing another function error from mass drivers because of it.

Here's the screenshot you asked for. I had to load an older save backup. When I loaded the game, the error happened right away, then I progressed forward 5 days, and then the error didn't happen. Here's the screenshot of the mining window from when the error did not occur:

Thanks for all your hard work tracking down our bugs!

Thanks. Given the huge mineral quantities at low accessibility and the tiny amount of produced minerals you mentioned above, I think my original guess was correct. It looks like there is a minuscule amount of production on some but not all turns. When Aurora tries to calculate the depletion time based on that production, it is exceeding the capacity of the decimal data type. I've added code so that depletion is not calculated if production is below 0.0001.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 16, 2021, 08:48:07 AM
Total Atmospheric Pressure Incorrect with Frozen Gases

Planet has the following gases:

Nitrogen 0.3581
Oxygen 0.0952
Sulphur Dioxide (F) 0.0133

The total Atmospheric Pressure shown is 0.440.

One way to arrive at that total is to add just the Nitrogen and the Oxygen, and then subtract the Sulphur Dioxide.

The incorrect ATM total leads to an incorrect GH factor and an incorrect temperature.

The atmospheric pressure calculation is incorrect (well spotted). The GH factor and temperature calculation are both working fine as they independently check non-frozen gases only and don't reference the atmospheric pressure calculation.

I don't think the GH/temp calculations are using the correct ATM value.

The Environment tab shows the Greenhouse Factor as 1.044.
This matches the incorrectly calculated atmospheric pressure of 0.440.

The stats for the body are:
Base Temp:  216.357
Albedo:  1.010

Using the incorrect GH value of 1.044 gives us a surface temp of
216.357 * 1.010 * 1.044 = 228.13
which is exactly the temperature displayed.

The correct GH value (1.04533) would give a temp of 228.43.
Obviously it's a tiny error in this case because the amount of frozen gas is so small.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 16, 2021, 09:18:01 AM
I don't think the GH/temp calculations are using the correct ATM value.

The Environment tab shows the Greenhouse Factor as 1.044.
This matches the incorrectly calculated atmospheric pressure of 0.440.

The stats for the body are:
Base Temp:  216.357
Albedo:  1.010

Using the incorrect GH value of 1.044 gives us a surface temp of
216.357 * 1.010 * 1.044 = 228.13
which is exactly the temperature displayed.

The correct GH value (1.04533) would give a temp of 228.43.
Obviously it's a tiny error in this case because the amount of frozen gas is so small.

You are correct. The calculation is greenhouse gas pressure plus 10% of total pressure. The greenhouse gas part is excluding any frozen gases, but the 10% part is affected by the original error.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 16, 2021, 12:48:22 PM
The accuracy estimates during ship design don't update when you change the "Range Bands" or the "Target Speed". They only update to reflect the values you type in when you toggle "Show Bands" on/off (which is a workaround, since Show Bands is for a different functionality). Ideally, the accuracy estimates would update instantly as you key in each digit.

(https://i.imgur.com/WPRYRx5.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 16, 2021, 01:58:26 PM
A large tanker ship with a "Refueling Hub" cannot "Transfer Fuel to Colony". The order does not appear (see below). If you use SM to add a "Refueling System 80,000 LPH" to the class design, suddenly the "Transfer Fuel to Colony" option appears. I would expect a ship with a 100kton Refueling Hub to be able to offload fuel to a colony just like it can to multiple ships.

(https://i.imgur.com/xQbDuEf.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Demetrious on May 16, 2021, 02:15:46 PM
Being fired upon by STO units only doesn't seem to flag a race as hostile. This isn't a problem for the player, as they can do it manually, but it does make NPR's unable to fight back.

The cheeky boys colonized the moon of my colony in Alpha Centauri. Set the "Cronulla Star Empire" hostile and watch the fireworks fly; the STOs are already set to shoot. Oddly enough when I sent that fleeing lifeboat back to drop my scuttled diplo station's survivors off, the planet's STOs lit THAT up, but were not flagged as hostile and are not responding to my own bombardment.

Save file: https://www.mediafire.com/file/e3cr7jlttospgnv/AuroraDB_-_aliens_won%2527t_fire.db/file

Not sure what is going on here. The diplomatic rating is modified during damage resolution and that code is the same whether the damage by caused by an STO or a ship-based energy weapons. There may be some other factor at work.

I did notice that the diplomatic rating was not changing immediately after I opened fire (I checked the alien intelligence screen immediately after on a couple of trial runs.) I'll knock together a test save when the next version drops; it sounds like more of an edge case and that'll be hard to track down without being able to load a save and poke at it.

EDIT: Also, I had NO IDEA that "self-jump only" engines could also act as jump tenders for standard transits. That would have saved me SO MUCH trouble in the past; fighter-sized jump tenders for other fighters as someone else mentioned. I'm happy you're renaming the tech line, that'll resolve a lot of confusion for others.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 16, 2021, 03:46:00 PM
I did notice that the diplomatic rating was not changing immediately after I opened fire (I checked the alien intelligence screen immediately after on a couple of trial runs.) I'll knock together a test save when the next version drops; it sounds like more of an edge case and that'll be hard to track down without being able to load a save and poke at it.

I've previously reported in the Suggestions thread, I think, that NPRs in at least some cases fail to register that you've shot at them and should now be considered hostile until the 5-day (construction) increment ticks over. In my case this led to multiple combat fleets sailing into my own fleets and failing to fire a shot.
Title: Re: v1.13.0 Bugs Thread
Post by: Demetrious on May 17, 2021, 04:01:04 AM
I did notice that the diplomatic rating was not changing immediately after I opened fire (I checked the alien intelligence screen immediately after on a couple of trial runs.) I'll knock together a test save when the next version drops; it sounds like more of an edge case and that'll be hard to track down without being able to load a save and poke at it.

I've previously reported in the Suggestions thread, I think, that NPRs in at least some cases fail to register that you've shot at them and should now be considered hostile until the 5-day (construction) increment ticks over. In my case this led to multiple combat fleets sailing into my own fleets and failing to fire a shot.

This fits. I set my construction increment to one day instead of five days and their diplomatic rating changed after a one-day long turn.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 17, 2021, 04:59:07 AM
Being fired upon by STO units only doesn't seem to flag a race as hostile. This isn't a problem for the player, as they can do it manually, but it does make NPR's unable to fight back.

The cheeky boys colonized the moon of my colony in Alpha Centauri. Set the "Cronulla Star Empire" hostile and watch the fireworks fly; the STOs are already set to shoot. Oddly enough when I sent that fleeing lifeboat back to drop my scuttled diplo station's survivors off, the planet's STOs lit THAT up, but were not flagged as hostile and are not responding to my own bombardment.

Save file: https://www.mediafire.com/file/e3cr7jlttospgnv/AuroraDB_-_aliens_won%2527t_fire.db/file

Not sure what is going on here. The diplomatic rating is modified during damage resolution and that code is the same whether the damage by caused by an STO or a ship-based energy weapons. There may be some other factor at work.

I did notice that the diplomatic rating was not changing immediately after I opened fire (I checked the alien intelligence screen immediately after on a couple of trial runs.)

The diplomatic rating you can see on the intelligence window is your view of them. You can't see their view of you.
Title: Re: v1.13.0 Bugs Thread
Post by: Jeltz on May 17, 2021, 04:01:25 PM
From "Disappearing Ground Units" thread, as suggested:

Quote
Hmmm... I don't know if it's a related issue or a desired game mechanic: a small troop transport with troops in refit (I forgot to unload them...); when the refit is complete the troops are gone...

v.1.13, no mods.


J.

Title: Re: v1.13.0 Bugs Thread
Post by: Cobaia on May 17, 2021, 04:38:19 PM
Is it reported that we cannot move Sector Commands via Civilian Contract if you don't have it reserched. One of my ruins returned a sector command and I couldn't select it in the demand combobox  until I researched the tech.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 17, 2021, 05:12:53 PM
There seem to be some issues with the Use Maximum Speed option.   Sometimes if a fleet does not have Use Maximum Speed checked and a ship in that fleet is destroyed the fleet's speed will be set to 1 km/s.   Other times when a ship is destroyed it's set to the actual maximum speed of the fleet, even if it had been manually set lower.   (EDIT: It turns out this can happen both with and without the Use Maximum Speed box checked, so this might be a more general issue with ship detachment or destruction, rather than with the Use Maximum Speed option as I thought at first. )

A possibly related issue is that I've occasionally had ships that lose their engines fail to automatically detach from their fleets -- although other times they've detached properly, and I've had this happen regardless of the maximum speed setting, so I'm not sure what's going on here. 

Title: Re: v1.13.0 Bugs Thread
Post by: Demetrious on May 17, 2021, 05:23:31 PM
Being fired upon by STO units only doesn't seem to flag a race as hostile. This isn't a problem for the player, as they can do it manually, but it does make NPR's unable to fight back.

The cheeky boys colonized the moon of my colony in Alpha Centauri. Set the "Cronulla Star Empire" hostile and watch the fireworks fly; the STOs are already set to shoot. Oddly enough when I sent that fleeing lifeboat back to drop my scuttled diplo station's survivors off, the planet's STOs lit THAT up, but were not flagged as hostile and are not responding to my own bombardment.

Save file: https://www.mediafire.com/file/e3cr7jlttospgnv/AuroraDB_-_aliens_won%2527t_fire.db/file

Not sure what is going on here. The diplomatic rating is modified during damage resolution and that code is the same whether the damage by caused by an STO or a ship-based energy weapons. There may be some other factor at work.

I did notice that the diplomatic rating was not changing immediately after I opened fire (I checked the alien intelligence screen immediately after on a couple of trial runs.)

The diplomatic rating you can see on the intelligence window is your view of them. You can't see their view of you.

I didn't even know those were two different things. Interesting. I should go read those mechanics posts again.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 17, 2021, 06:09:25 PM
"Acanthopholis" class does not appear in this NPR's ship list, despite there being dozens of them still remaining. (There are none at the bottom of the list scrolled down either, I checked.) I boarded a few of their Acanthopholis class, so perhaps this made it disappear when the captured ships were transferred to me?

Ideally, the ship class should not disappear from the NPR intel ship list if I capture one. However, the presumed ship type/hull and full details should be revealed to me upon capture (so it doesn't show as XX). At the bare minimum, if it remained on the ship list then I could set the ship hull manually myself.

Edit: It turns out this ship design actually is on the alien intel list, but it is now listed under its NPR-assigned class name "XX Southampton". I do not have "Use Real Ship / Class Names" selected, so this behavior was unexpected and caused the disconnect that we see in the game--already discovered ships of this class (seen on the System Map) keep their "Acanthopholis" name, while on the Alien Intel screen they have been renamed to the Real Ship / Class Name. The class should ideally not have been renamed in my intel screen.

(https://i.imgur.com/oOdVP9p.png)
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 17, 2021, 06:28:45 PM
"Acanthopholis" class does not appear in this NPR's ship list, despite there being dozens of them still remaining. (There are none at the bottom of the list scrolled down either, I checked.) I boarded a few of their Acanthopholis class, so perhaps this made it disappear when the captured ships were transferred to me?

Ideally, the ship class should not disappear from the NPR intel ship list if I capture one. However, the presumed ship type/hull and full details should be revealed to me upon capture (so it doesn't show as XX). At the bare minimum, if it remained on the ship list then I could set the ship hull manually myself

When you capture an NPR ship, the actual class name replaces the name assigned by your imaginary intel agency. Poke around in the ship class design window and you will probably find them listed by their "real" name and class, which should match an entry in the Intel classes list.

While I frankly would prefer the intel class name be retained, including for the captured class design, this is not a bug and belongs in the suggestions thread.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 17, 2021, 09:17:59 PM
"Acanthopholis" class does not appear in this NPR's ship list, despite there being dozens of them still remaining. (There are none at the bottom of the list scrolled down either, I checked.) I boarded a few of their Acanthopholis class, so perhaps this made it disappear when the captured ships were transferred to me?

Ideally, the ship class should not disappear from the NPR intel ship list if I capture one. However, the presumed ship type/hull and full details should be revealed to me upon capture (so it doesn't show as XX). At the bare minimum, if it remained on the ship list then I could set the ship hull manually myself

When you capture an NPR ship, the actual class name replaces the name assigned by your imaginary intel agency. Poke around in the ship class design window and you will probably find them listed by their "real" name and class, which should match an entry in the Intel classes list.

While I frankly would prefer the intel class name be retained, including for the captured class design, this is not a bug and belongs in the suggestions thread.

I do not have "Use Real Ship / Class Names" checked in the Alien Race Intel screen. I have updated the original bug report to reflect this.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 17, 2021, 09:48:12 PM
I do not have "Use Real Ship / Class Names" checked in the Alien Race Intel screen. I have updated the original bug report to reflect this.

It's still not a bug, although it is a confusing behavior.

The "Use Real Ship / Class Names" checkbox applies to the class names given on the intel screen when you discover new contacts. The option only effects the class name assigned to classes when you first encounter them

When you capture an alien ship or otherwise obtain its class design, you also discover the real class name and the intel screen updates the class entry to reflect this. This is a separate behavior not controlled by the checkbox. Again, one can certainly argue that it ought to be controlled by that checkbox, since the class name changing is disorienting to the player, but that is in the realm of a suggestion rather than a bug and I would recommend posting in the suggestion thread if you'd like to.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 17, 2021, 09:58:36 PM
I'm getting an endless popup of "Function #2079: Object reference not set to an instance of an object."

If you'll let me know what that function is, I don't mind poking around in the database for clues.

I just gave a fleet repeating orders (x99) to haul infrastructure between two planets. I've done those orders before, but not that high of a multiplier. Perhaps that broke some limit?

EDIT: I got the turn to finish generating by just holding down the Enter key for 30 seconds or so to kill the error popups.
On this turn I had two new contacts, of a new alien class (the aliens were already known).
On this turn I also received a message about overallocation of labs (I'm hauling labs from one planet to another).
Save is attached.
Title: Re: v1.13.0 Bugs Thread
Post by: Black on May 18, 2021, 05:12:33 AM
I'm getting an endless popup of "Function #2079: Object reference not set to an instance of an object."

If you'll let me know what that function is, I don't mind poking around in the database for clues.

I just gave a fleet repeating orders (x99) to haul infrastructure between two planets. I've done those orders before, but not that high of a multiplier. Perhaps that broke some limit?

EDIT: I got the turn to finish generating by just holding down the Enter key for 30 seconds or so to kill the error popups.
On this turn I had two new contacts, of a new alien class (the aliens were already known).
On this turn I also received a message about overallocation of labs (I'm hauling labs from one planet to another).
Save is attached.

I got Object reference not set to an instance of an object errors in previous versions several times when I detected new Precursor ships during survey of the systems, but the number was #1943. As you also detected aliens, maybe that was something similar?
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 18, 2021, 10:37:30 AM
While ECM-1 and ECM-2 each require 10 crew, ECM-3 requires only 6 crew for some reason.  This seems like a bug? If anything I'd expect crew requirements to increase for higher ECM levels, but the fact that ECM-1 and ECM-2 (and the ECCM components for that matter) all require the same number of crew makes me think this is unintentional.

SJW: Fixed for v1.14. All ECM should be 6 crew.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 18, 2021, 12:28:42 PM
I'm getting an endless popup of "Function #2079: Object reference not set to an instance of an object."

If you'll let me know what that function is, I don't mind poking around in the database for clues.

I just gave a fleet repeating orders (x99) to haul infrastructure between two planets. I've done those orders before, but not that high of a multiplier. Perhaps that broke some limit?

EDIT: I got the turn to finish generating by just holding down the Enter key for 30 seconds or so to kill the error popups.
On this turn I had two new contacts, of a new alien class (the aliens were already known).
On this turn I also received a message about overallocation of labs (I'm hauling labs from one planet to another).
Save is attached.

This error happened again many months later.
Same as last time, I held down the Enter key for about 30 seconds to close all the popups.
This time I also had a new contact of a new alien class (same aliens as before, in same system).
So that seems to be the prime suspect.

Here's something interesting:

I now have four items under "Known Ship Classes" for this race. In order listed, they are:
2x XX
4x XX
9x XX Class #4
1x XX Class #5

Interesting that the first two don't have a class name, and the 3rd one starts with #4.
I got the Function 2079 errors for the first time on the turn I first encountered that class.

At some point after discovering these aliens I changed their Theme to "Names Beginning with J."
I don't know exactly when I did that, but maybe it was after detecting the 2nd ship class.
Which means that the 3rd class ("Class #4") would have been the first one under the new theme.
Maybe that is causing the problem?

New DB attached.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 18, 2021, 02:20:30 PM
Minor issue with picking up survivors.  I have a fleet with six ships with one emergency cryogenic transport apiece (as well as some other ships without cryogenic transport).  Each one can hold 200 survivors.  However, after picking up several lifepods the survivors were not distributed evenly between the ships; instead, one got 470 survivors, another got 336, and the rest got none.  And now the two ships that took all the survivors are complaining about insufficient accommodations.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 18, 2021, 02:47:51 PM
Bug: The "Fire at Will FC" button erroneously causes every FC on a ship to fire at Will, when it should only cause the selected FC to fire at Will.

And a quick aside, I really love the "Fire at Will" functions. They make fighting huge battles such a breeze. (By the way, I feel very sorry for whoever Will is!)

(https://i.imgur.com/WPZ5DdC.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 18, 2021, 02:59:50 PM
"Fire at Will" erroneously targets Active Sensor contacts which are outside of missile engagement range, whereas the related function "Auto Target MFC" properly respects missile engagement range when choosing targets.

I would expect "Fire At Will" to only target vessels which are within missile engagement range. I haven't noticed this problem with beam weapons and Fire At Will.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 18, 2021, 06:31:26 PM
This is pretty minor, but reporting it since it's likely one element of the late-game lag I experience on turn generation. Over the course of 157 years of gameplay, this NPR has apparently built over two hundred Diplomatic Ships. They had about 2,000 total ships by that point according to the DB, which means a solid 10% of all the military, commercial, and civilian ships their race had constructed were diplomatic ships.

(https://i.imgur.com/0Qp7TGQ.png)

SJW: Fixed for v1.14. I had a function to limit Diplomatic ships, but there was a bug that prevented it being checked.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 19, 2021, 11:29:31 AM
I'm getting an endless popup of "Function #2079: Object reference not set to an instance of an object."

If you'll let me know what that function is, I don't mind poking around in the database for clues.

I just gave a fleet repeating orders (x99) to haul infrastructure between two planets. I've done those orders before, but not that high of a multiplier. Perhaps that broke some limit?

EDIT: I got the turn to finish generating by just holding down the Enter key for 30 seconds or so to kill the error popups.
On this turn I had two new contacts, of a new alien class (the aliens were already known).
On this turn I also received a message about overallocation of labs (I'm hauling labs from one planet to another).
Save is attached.

The error is in a small function called CheckAlienClassesForName, which is used to check existing alien classes for a name that is about to assigned to a new alien class (to avoid duplicates). It also trims those names to avoid white space issues.

A 'normal' error in this function would have been picked up a long time ago. The only way I could see the error is if the ClassName field somehow didn't exist or was set to null rather than a string value. That would cause the above error when the ClassName field tried to use the Trim function.
Title: Re: v1.13.0 Bugs Thread
Post by: Silvarelion on May 19, 2021, 02:42:45 PM
It looks like the exploding carrier bug has survived from V1.11.

Last time it was diagnosed as the game not skipping over unbreakable parts during a maintenance check.  Just did a test on 1.13 and it looks as if that is still happening.  Carrier blew up, with plenty of MSP, no enemies in sight, and lots of maintenance time left on the clock. 
Title: Re: v1.13.0 Bugs Thread
Post by: Stormtrooper on May 19, 2021, 04:50:46 PM
Seems like "create swarm" button in system view when SM is turned on doesn't work. It didn't work in 1.12 either, producing an error message, but in 1.12 I was deleting nprs mid-game to salvage performance and smeg so that might be on me, but in this campaign I've yet to do something with the db, I didn't even purge FCT_GameLog as of yet, let alone try to delete an npr, but the problem persists, the only difference being now there's no error popup whatsoever - but the swarm is not created.

The function number: no error popup at all
Complete error text: no error popup at all
Window affected: I guess... tactical map, since they're not there?...
What were you doing at the time: nothing, just opened the game precisely to test the "create swarm", used sm to add ridiculous amount of every mineral at 1 acc on an empty world to make sure it is rich enough for swarm to spawn, positioned my fleet with active sensors on in orbit to instantly detect swarm ships the moment they appear, clicked on that planet in system view mode and pressed "create swarm"... Even multiple times... Nothing in-game happened.
TN start
Random stars
default aurora decimal separator
is the bug easy to reproduce: should be, just try to create a swarm via SM mode in system view...
campaign length: over 45 years
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 19, 2021, 10:10:33 PM
This is probably a well-known bug, but I have yet to see any colony since even the VB6 era that generates the "Ancient Artifact" trade goods. Even colonies with ruins don't generate them.

(https://i.imgur.com/YfdwnkT.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 19, 2021, 10:24:19 PM
While dropping some troops from orbit on a planet with Rakhas I got an error message popup: "Function #11: Object reference not set to an instance of an object. " The game then created a new race of Civilians with my race picture and a diplomacy rating of 10000.  The Rakha ground forces signature is still there, but now there's also an active sensor signal belonging to the Civilians on the planet.  (S1/R1, same as the actives on the Rakha STOs I'd just destroyed. ) The game is now throwing the same error message every turn.  I can't see anything wrong from poking around in the database, although Civilians don't seem to be a normal race -- they're not listed anywhere, and there are only two populations listed on the planet, mine and the Rakha population.  What does function 11 do?

SJW: Fixed for v1.14. See later post for details
Title: Re: v1.13.0 Bugs Thread
Post by: simast on May 19, 2021, 11:08:08 PM
Really tiny minor issue, but the tooltip for Ground Forces toolbar button says "Open Ground Forces Tab on the Colonies Window" - which is not really what it does (e.g. it is actually opening it's own window).

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 20, 2021, 01:54:25 AM
While dropping some troops from orbit on a planet with Rakhas I got an error message popup: "Function #11: Object reference not set to an instance of an object. " The game then created a new race of Civilians with my race picture and a diplomacy rating of 10000.  The Rakha ground forces signature is still there, but now there's also an active sensor signal belonging to the Civilians on the planet.  (S1/R1, same as the actives on the Rakha STOs I'd just destroyed. ) The game is now throwing the same error message every turn.  I can't see anything wrong from poking around in the database, although Civilians don't seem to be a normal race -- they're not listed anywhere, and there are only two populations listed on the planet, mine and the Rakha population.  What does function 11 do?

This one is odd as any general problem with dropping troops would have caused a lot of bug reports. Function #11 is part of AI fire decisions.

Has anyone else seen a similar problem?

Also, are you running any mods?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 20, 2021, 02:06:11 AM
Seems like "create swarm" button in system view when SM is turned on doesn't work. It didn't work in 1.12 either, producing an error message, but in 1.12 I was deleting nprs mid-game to salvage performance and smeg so that might be on me, but in this campaign I've yet to do something with the db, I didn't even purge FCT_GameLog as of yet, let alone try to delete an npr, but the problem persists, the only difference being now there's no error popup whatsoever - but the swarm is not created.

The function number: no error popup at all
Complete error text: no error popup at all
Window affected: I guess... tactical map, since they're not there?...
What were you doing at the time: nothing, just opened the game precisely to test the "create swarm", used sm to add ridiculous amount of every mineral at 1 acc on an empty world to make sure it is rich enough for swarm to spawn, positioned my fleet with active sensors on in orbit to instantly detect swarm ships the moment they appear, clicked on that planet in system view mode and pressed "create swarm"... Even multiple times... Nothing in-game happened.
TN start
Random stars
default aurora decimal separator
is the bug easy to reproduce: should be, just try to create a swarm via SM mode in system view...
campaign length: over 45 years

I just tried this and the Swarm appeared as normal. Did you advance time so your own forces could detect the swarm?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 20, 2021, 02:09:21 AM
I'm getting an endless popup of "Function #2079: Object reference not set to an instance of an object."

If you'll let me know what that function is, I don't mind poking around in the database for clues.

I just gave a fleet repeating orders (x99) to haul infrastructure between two planets. I've done those orders before, but not that high of a multiplier. Perhaps that broke some limit?

EDIT: I got the turn to finish generating by just holding down the Enter key for 30 seconds or so to kill the error popups.
On this turn I had two new contacts, of a new alien class (the aliens were already known).
On this turn I also received a message about overallocation of labs (I'm hauling labs from one planet to another).
Save is attached.

This error happened again many months later.
Same as last time, I held down the Enter key for about 30 seconds to close all the popups.
This time I also had a new contact of a new alien class (same aliens as before, in same system).
So that seems to be the prime suspect.

Here's something interesting:

I now have four items under "Known Ship Classes" for this race. In order listed, they are:
2x XX
4x XX
9x XX Class #4
1x XX Class #5

Interesting that the first two don't have a class name, and the 3rd one starts with #4.
I got the Function 2079 errors for the first time on the turn I first encountered that class.

At some point after discovering these aliens I changed their Theme to "Names Beginning with J."
I don't know exactly when I did that, but maybe it was after detecting the 2nd ship class.
Which means that the 3rd class ("Class #4") would have been the first one under the new theme.
Maybe that is causing the problem?

New DB attached.

If you rename the classes with the missing names, does that stop the bug?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 20, 2021, 06:17:54 AM
Minor issue with picking up survivors.  I have a fleet with six ships with one emergency cryogenic transport apiece (as well as some other ships without cryogenic transport).  Each one can hold 200 survivors.  However, after picking up several lifepods the survivors were not distributed evenly between the ships; instead, one got 470 survivors, another got 336, and the rest got none.  And now the two ships that took all the survivors are complaining about insufficient accommodations.

I have updated the rescue code so that the ship that picks up a specific life pod is the top ship in list ordered by:
Descending Available Cryogenic Capacity Then Descending (Class Crew - Current Survivors)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 20, 2021, 06:51:52 AM
"Fire at Will" erroneously targets Active Sensor contacts which are outside of missile engagement range, whereas the related function "Auto Target MFC" properly respects missile engagement range when choosing targets.

I would expect "Fire At Will" to only target vessels which are within missile engagement range. I haven't noticed this problem with beam weapons and Fire At Will.

Please can you provide some detail? Range of fire control, range of missile, range of target that was selected, etc.

Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 20, 2021, 07:31:48 AM
I'm getting an endless popup of "Function #2079: Object reference not set to an instance of an object."

...

...

I now have four items under "Known Ship Classes" for this race. In order listed, they are:
2x XX
4x XX
9x XX Class #4
1x XX Class #5

If you rename the classes with the missing names, does that stop the bug?

I will give it a shot.
The problem only occurs when a new ship class is detected. I have renamed those two classes, and I'll let you know the outcome when it occurs.

Also interesting to note:
I have detected new classes since then (the error occurred each time), and this is the current list (after I renamed):

Code: [Select]
2x XX MyClassName1
4x XX MyClassName2
2x XX Class #10
1x XX Class #11
9x XX Class #4
2x XX Class #5
1x XX Class #8
1x XX Class #9


It seems that #6 and #7 were skipped?
I discovered 8,9,and 10 at the same time, and discovered 11 shortly thereafter.
Not sure if this is expected, or gives a clue about this bug.
Title: Re: v1.13.0 Bugs Thread
Post by: Stormtrooper on May 20, 2021, 07:50:34 AM
Quote
I just tried this and the Swarm appeared as normal. Did you advance time so your own forces could detect the swarm?

Yep, I advanced the time... multiple times... Did you suceed at creating it in my db?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 20, 2021, 08:24:19 AM
Quote
I just tried this and the Swarm appeared as normal. Did you advance time so your own forces could detect the swarm?

Yep, I advanced the time... multiple times... Did you suceed at creating it in my db?

I can't use your db as I working with v1.14 code now, but when I try this on my own database it works fine. I know you have made database changes in the past - were there any modification for this game?
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 20, 2021, 08:39:40 AM
This box needs scroll bars to be able to show the entire class design. (The current workaround is to select the text and drag your cursor to the bottom of the box so it auto-scrolls down to display the rest.)

(https://i.imgur.com/BTBWqjp.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Stormtrooper on May 20, 2021, 08:42:03 AM
Quote
I just tried this and the Swarm appeared as normal. Did you advance time so your own forces could detect the swarm?

Yep, I advanced the time... multiple times... Did you suceed at creating it in my db?

I can't use your db as I working with v1.14 code now, but when I try this on my own database it works fine. I know you have made database changes in the past - were there any modification for this game?

Nope, this db is pure, not even a single FCT_GameLog purge yet. All I did was remove the default game in the settings after I created my own, but that shouldn't cause any problems, should it?
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 20, 2021, 09:42:21 AM
While dropping some troops from orbit on a planet with Rakhas I got an error message popup: "Function #11: Object reference not set to an instance of an object. " The game then created a new race of Civilians with my race picture and a diplomacy rating of 10000.  The Rakha ground forces signature is still there, but now there's also an active sensor signal belonging to the Civilians on the planet.  (S1/R1, same as the actives on the Rakha STOs I'd just destroyed. ) The game is now throwing the same error message every turn.  I can't see anything wrong from poking around in the database, although Civilians don't seem to be a normal race -- they're not listed anywhere, and there are only two populations listed on the planet, mine and the Rakha population.  What does function 11 do?

This one is odd as any general problem with dropping troops would have caused a lot of bug reports. Function #11 is part of AI fire decisions.

Has anyone else seen a similar problem?

Also, are you running any mods?

No mods, no database edits. I think I figured it out, though, and you're right -- it is an odd one. The ships I was using to drop the troops were actually alien ships that had surrendered to me. (Incidentally, they should probably be a bit more cautious about sending large, vulnerable troop transports into enemy systems.) I somehow hadn't noticed at the time, but it turns out one of them still contained an alien planetary defence regiment! It seems the game got very confused as to who the regiment belongs to. In the database it's listed under my population, but the original alien's RaceID. Not sure why this would lead to errors in the AI firing code, though -- maybe the regiment is trying to fire at me or at the Rakhas? Either way it seems the problem is with the ship surrendering code.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 20, 2021, 12:42:13 PM
While dropping some troops from orbit on a planet with Rakhas I got an error message popup: "Function #11: Object reference not set to an instance of an object. " The game then created a new race of Civilians with my race picture and a diplomacy rating of 10000.  The Rakha ground forces signature is still there, but now there's also an active sensor signal belonging to the Civilians on the planet.  (S1/R1, same as the actives on the Rakha STOs I'd just destroyed. ) The game is now throwing the same error message every turn.  I can't see anything wrong from poking around in the database, although Civilians don't seem to be a normal race -- they're not listed anywhere, and there are only two populations listed on the planet, mine and the Rakha population.  What does function 11 do?

This one is odd as any general problem with dropping troops would have caused a lot of bug reports. Function #11 is part of AI fire decisions.

Has anyone else seen a similar problem?

Also, are you running any mods?

No mods, no database edits. I think I figured it out, though, and you're right -- it is an odd one. The ships I was using to drop the troops were actually alien ships that had surrendered to me. (Incidentally, they should probably be a bit more cautious about sending large, vulnerable troop transports into enemy systems.) I somehow hadn't noticed at the time, but it turns out one of them still contained an alien planetary defence regiment! It seems the game got very confused as to who the regiment belongs to. In the database it's listed under my population, but the original alien's RaceID. Not sure why this would lead to errors in the AI firing code, though -- maybe the regiment is trying to fire at me or at the Rakhas? Either way it seems the problem is with the ship surrendering code.

Thanks - that is really useful.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 20, 2021, 01:42:38 PM
I got this function error #899 when I entered the command telling this captured ship to "Absorb" another captured fleet at the same location. It may be because this fleet is set to 0 km/sec.

(https://i.imgur.com/cykSchw.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Black on May 20, 2021, 03:06:48 PM
It seems that Auto Assign FC is still bugged and not working correctly (reported this bug in one of the previous versions). Ship in screenshot has four 10cm railguns, six 12cm railguns and four gauss turrets. For some reason, auto assign duplicates 10cm railguns and sets them for two different firecontrols at the same time.

(https://i.ibb.co/SRq3xrg/firecontrol-bug.png) (https://ibb.co/D53RbpF)
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 20, 2021, 04:57:35 PM
Quote
I just tried this and the Swarm appeared as normal. Did you advance time so your own forces could detect the swarm?

Yep, I advanced the time... multiple times... Did you suceed at creating it in my db?

I can't use your db as I working with v1.14 code now, but when I try this on my own database it works fine. I know you have made database changes in the past - were there any modification for this game?

Nope, this db is pure, not even a single FCT_GameLog purge yet. All I did was remove the default game in the settings after I created my own, but that shouldn't cause any problems, should it?

It actually might because I also deleted the initial game with the Terran Federation and for some reason I can't rename my save game because of it. Is there some special initialization that happens for spoilers that exists in that initial game that isn't repeated for subsequently generated games?

I should say that besides the renaming issue I haven't encountered anything else.
Title: Re: v1.13.0 Bugs Thread
Post by: Black on May 21, 2021, 03:28:38 AM
Quote
I just tried this and the Swarm appeared as normal. Did you advance time so your own forces could detect the swarm?

Yep, I advanced the time... multiple times... Did you suceed at creating it in my db?

I can't use your db as I working with v1.14 code now, but when I try this on my own database it works fine. I know you have made database changes in the past - were there any modification for this game?

Nope, this db is pure, not even a single FCT_GameLog purge yet. All I did was remove the default game in the settings after I created my own, but that shouldn't cause any problems, should it?

It actually might because I also deleted the initial game with the Terran Federation and for some reason I can't rename my save game because of it. Is there some special initialization that happens for spoilers that exists in that initial game that isn't repeated for subsequently generated games?

I should say that besides the renaming issue I haven't encountered anything else.

This shouldn't have effect IMO, I tried to generate Swarm in my game and it spawned correctly. And I also deleted the default game after I created my own.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 21, 2021, 06:13:55 AM
In Cadbury system, many years ago, I detected an alien ground force signature.
No population, no ships, just a small ground force signature.
My geo survey ship completed the survey without incident, and found alien ruins and a potential for a geological surface survey.

Unafraid of the ground forces, I sent in xeno troops (non-combat), and after a long time they completed their work and identified the ruins: a small site with just 7 installations.
I then sent in construction troops (non-combat), and over a period of many months (maybe years) they completely excavated the ruins.
A long while later I sent in geo survey troops (also non-combat). They worked without incident for more than 3 years.
So, for many, many years, I had troops on the surface of this planet, and never had an incident with the alien ground forces.
I could still detect the signature, but otherwise there was no sign of them.

Just now, in Mabel system (5 hops away), a geo survey ship of mine was attacked and destroyed by unknown ships.
At the exact same time as this attack, the alien forces on Cadbury attacked my troops there (to disastrous effect for me, since mine were all non-combat).


I see no logical reason for the Cadbury aliens to suddenly become hostile to my non-combat forces because of something that happened five hops away.
So I'm reporting it as a bug. If this is WAI I can accept that, even if it is kind of a head scratcher.
DB is attached.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 21, 2021, 08:22:23 AM
I'm getting an endless popup of "Function #2079: Object reference not set to an instance of an object."
...
...
I now have four items under "Known Ship Classes" for this race. In order listed, they are:
2x XX
4x XX
9x XX Class #4
1x XX Class #5
If you rename the classes with the missing names, does that stop the bug?
I will give it a shot.
The problem only occurs when a new ship class is detected. I have renamed those two classes, and I'll let you know the outcome when it occurs.
Giving names to the unnamed classes seemed to work--the next time I encountered a new class for this race, no errors occurred.

Sidenote: You can use the null-conditional operator (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators--and-) (as of C# 6) to avoid these types of runtime errors. I only learned about this last year. My coworkers pointed it out after they found my obsessive null-checking amusing.  ::)
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 11:46:02 AM
In Cadbury system, many years ago, I detected an alien ground force signature.
No population, no ships, just a small ground force signature.
My geo survey ship completed the survey without incident, and found alien ruins and a potential for a geological surface survey.

Unafraid of the ground forces, I sent in xeno troops (non-combat), and after a long time they completed their work and identified the ruins: a small site with just 7 installations.
I then sent in construction troops (non-combat), and over a period of many months (maybe years) they completely excavated the ruins.
A long while later I sent in geo survey troops (also non-combat). They worked without incident for more than 3 years.
So, for many, many years, I had troops on the surface of this planet, and never had an incident with the alien ground forces.
I could still detect the signature, but otherwise there was no sign of them.

Just now, in Mabel system (5 hops away), a geo survey ship of mine was attacked and destroyed by unknown ships.
At the exact same time as this attack, the alien forces on Cadbury attacked my troops there (to disastrous effect for me, since mine were all non-combat).


I see no logical reason for the Cadbury aliens to suddenly become hostile to my non-combat forces because of something that happened five hops away.
So I'm reporting it as a bug. If this is WAI I can accept that, even if it is kind of a head scratcher.
DB is attached.

I believe I noticed a similar thing with Precursors. My geosurvey troops were doing their thing for a long time on a particular body, but when I brought in xeno troops and landed them, I suddenly got attacked by alien troops on the planet. It was bizarre enough that I thought it was ruin-related Robotic Defenders being activated.

I'm not a ground combat expert, but it may be because neither side was set to "attack" the other side (front line attack vs. defense maybe?) until I landed xeno troops (which I may have forgot to set to non-combat, I don't remember). That's just a guess on my part.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 21, 2021, 11:50:05 AM
I got several error messages reading "Function #840: The given key was not present in the dictionary." I believe this is because some troop transports had been ordered to load some formations which were destroyed between when I gave the order and when the transports got around to it. Doesn't seem to have caused any lasting issues, though.

SJW: Added code to check formation exists before loading
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 01:08:51 PM
No mods, no database edits. I think I figured it out, though, and you're right -- it is an odd one. The ships I was using to drop the troops were actually alien ships that had surrendered to me. (Incidentally, they should probably be a bit more cautious about sending large, vulnerable troop transports into enemy systems.) I somehow hadn't noticed at the time, but it turns out one of them still contained an alien planetary defence regiment! It seems the game got very confused as to who the regiment belongs to. In the database it's listed under my population, but the original alien's RaceID. Not sure why this would lead to errors in the AI firing code, though -- maybe the regiment is trying to fire at me or at the Rakhas? Either way it seems the problem is with the ship surrendering code.

I've added code to remove alien ground forces from ships that are transferred to an alien race.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 01:09:54 PM
I got this function error #899 when I entered the command telling this captured ship to "Absorb" another captured fleet at the same location. It may be because this fleet is set to 0 km/sec.

(https://i.imgur.com/cykSchw.png)

How did you get the speed to zero? Ships with no engines should default to 1 km/s to avoid divide by zero errors. If you set speed manually to zero then it should be corrected to 1.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 21, 2021, 01:33:02 PM
Adding a cargo bay to specialized commercial vessels causes them to be considered a freighter for auto-assignment purposes.

This can be observed by loading up the default game in a fresh 1.13 install and immediately designing ships with the necessary components.

Adding a cargo bay to a commercial ship which mounts any of the below components will change its designation to 'i' which I presume is the obfuscated designation for a freighter type.

This may technically be WAD, however I am submitting this as a bug because this high priority placed on a cargo module interacts poorly with the auto-assignment system, which as documented elsewhere assigns commanders to Construction (Production skill), Terraformer (Terraforming skill), Harvester (Mining skill), Miner (Mining skill), and Salvage (Production skill) before assigning commanders with the Logistics skill to any other types of ships on the (broadly correct) assumption that any non-military ship not of these types will benefit from the Logistics bonus.

The priority placed on the cargo hold component over the other components listed above does not match the documented commander auto-assignment behavior.

This is likely to confuse and frustrate players trying to play with interesting ship designs. For example, salvage ships usually are built with cargo holds to store the salvaged materials, however this behavior will ensure that a Production-skilled commander will not be assigned to such a sensibly-designed salvager because the cargo hold will take priority and label the ship as a "freighter" instead. Similarly, the not-uncommon practice of including a cargo hold on an orbital miner to tote a mass driver between mining sites will cause orbital miners to have assigned a Logistics-skill commander instead of a Mining-skill one.

As a "bug fix" I would like to see the priority of cargo holds in determining the ship type for auto-assignment made consistent with the documented priority behavior of the commander auto-assignment system.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 02:26:40 PM
It seems that Auto Assign FC is still bugged and not working correctly (reported this bug in one of the previous versions). Ship in screenshot has four 10cm railguns, six 12cm railguns and four gauss turrets. For some reason, auto assign duplicates 10cm railguns and sets them for two different firecontrols at the same time.

(https://i.ibb.co/SRq3xrg/firecontrol-bug.png) (https://ibb.co/D53RbpF)

Had the ship been refitted?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 02:28:59 PM
In Cadbury system, many years ago, I detected an alien ground force signature.
No population, no ships, just a small ground force signature.
My geo survey ship completed the survey without incident, and found alien ruins and a potential for a geological surface survey.

Unafraid of the ground forces, I sent in xeno troops (non-combat), and after a long time they completed their work and identified the ruins: a small site with just 7 installations.
I then sent in construction troops (non-combat), and over a period of many months (maybe years) they compleexcavated the ruins.
A long while later I sent in geo survey troops (also non-combat). They worked without incident for more than 3 years.
So, for many, many years, I had troops on the surface of this planet, and never had an incident with the alien ground forces.
I could still detect the signature, but otherwise there was no sign of them.

Just now, in Mabel system (5 hops away), a geo survey ship of mine was attacked and destroyed by unknown ships.
At the exact same time as this attack, the alien forces on Cadbury attacked my troops there (to disastrous effect for me, since mine were all non-combat).


I see no logical reason for the Cadbury aliens to suddenly become hostile to my non-combat forces because of something that happened five hops away.
So I'm reporting it as a bug. If this is WAI I can accept that, even if it is kind of a head scratcher.
DB is attached.

You didn't specifically mention it, but are the aliens in Cadbury a different race than the aliens five transits away?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 02:39:04 PM
Giving names to the unnamed classes seemed to work--the next time I encountered a new class for this race, no errors occurred.

Sidenote: You can use the null-conditional operator (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators--and-) (as of C# 6) to avoid these types of runtime errors. I only learned about this last year. My coworkers pointed it out after they found my obsessive null-checking amusing.  ::)

I have plenty of null checks in the code, but didn't bother with ClassName as it is a string data type. That is the first time I have ever had a bug in C# Aurora caused by a value type (string, int, double, etc.) being null. Something extremely odd must have happened to cause it. Anyway, it now has a null check :)
Title: Re: v1.13.0 Bugs Thread
Post by: Black on May 21, 2021, 03:47:16 PM
It seems that Auto Assign FC is still bugged and not working correctly (reported this bug in one of the previous versions). Ship in screenshot has four 10cm railguns, six 12cm railguns and four gauss turrets. For some reason, auto assign duplicates 10cm railguns and sets them for two different firecontrols at the same time.

(https://i.ibb.co/SRq3xrg/firecontrol-bug.png) (https://ibb.co/D53RbpF)

Had the ship been refitted?

No, the ship is new construction, I was setting the firecontrols for the first time on this ship.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 03:55:08 PM
I got this function error #899 when I entered the command telling this captured ship to "Absorb" another captured fleet at the same location. It may be because this fleet is set to 0 km/sec.


How did you get the speed to zero? Ships with no engines should default to 1 km/s to avoid divide by zero errors. If you set speed manually to zero then it should be corrected to 1.

It was a fuel harvester that the NPRs surrendered after I damaged it. I didn't modify the speed in any way, it was like that when I got it.

SJW: Can't reproduce but added extra checks in case it happens
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 04:00:53 PM
"Fire at Will" erroneously targets Active Sensor contacts which are outside of missile engagement range, whereas the related function "Auto Target MFC" properly respects missile engagement range when choosing targets.

I would expect "Fire At Will" to only target vessels which are within missile engagement range. I haven't noticed this problem with beam weapons and Fire At Will.

Please can you provide some detail? Range of fire control, range of missile, range of target that was selected, etc.

I belive it was approximately:

Active Sensor Range: 175 mil km
MFC Range: 75 mil km
Missile Range: 50 mil km

When I disable the 175 mil km active sensor and instead use an active sensor with just 50 mil km range (same range as my missiles), then "Fire At Will" stops targeting enemies that are outside the range of my missiles. It might have specifically been due to my MFC being longer-ranged than the missiles I had in the tubes, causing out-of-missile-range enemy ships to be targeted upon clicking "Fire At Will" (and therefore refusing to fire their missiles at those targets when I advance time).

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 21, 2021, 04:29:25 PM
I got some error messages reading "Function #1793: Attempted to divide by zero" while in combat with Rakhas. I think it's because one of my formations on front-line defense had zero elements: deleting the formation got rid of the error messages.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 05:27:54 PM
I got this function error #899 when I entered the command telling this captured ship to "Absorb" another captured fleet at the same location. It may be because this fleet is set to 0 km/sec.


How did you get the speed to zero? Ships with no engines should default to 1 km/s to avoid divide by zero errors. If you set speed manually to zero then it should be corrected to 1.

It was a fuel harvester that the NPRs surrendered after I damaged it. I didn't modify the speed in any way, it was like that when I got it.

The zero speed was the problem, but I can't see a way for the code to generate that speed (although it did somehow). I've added some extra checks in case zero speed is set.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 05:29:34 PM
I got some error messages reading "Function #1793: Attempted to divide by zero" while in combat with Rakhas. I think it's because one of my formations on front-line defense had zero elements: deleting the formation got rid of the error messages.

I think its a problem with a breakthrough by a zero-sized unit. I've already fixed it for v1.14.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 05:48:22 PM
Adding a cargo bay to specialized commercial vessels causes them to be considered a freighter for auto-assignment purposes.

This can be observed by loading up the default game in a fresh 1.13 install and immediately designing ships with the necessary components.

Adding a cargo bay to a commercial ship which mounts any of the below components will change its designation to 'i' which I presume is the obfuscated designation for a freighter type.
  • Cryogenic Transport (should be labeled as Colony Ship)
  • Jump Point Stabilisation Module (should be labeled as Stabilisation Ship)
  • Sorium Harvester (should be labeled as Fuel Harvester)
  • Orbital Mining Module (should be labeled as Orbital Miner)
  • Salvage Module (should be labeled as 'p' which I presume to be the obfuscated definition for a salvager type)
  • Terraforming Module (should be labeled as 'n' which I presume to be the obfuscated definition for a Terraformer type)
  • Troop Transport Bay (should be labeled as Troop Transport)

This may technically be WAD, however I am submitting this as a bug because this high priority placed on a cargo module interacts poorly with the auto-assignment system, which as documented elsewhere assigns commanders to Construction (Production skill), Terraformer (Terraforming skill), Harvester (Mining skill), Miner (Mining skill), and Salvage (Production skill) before assigning commanders with the Logistics skill to any other types of ships on the (broadly correct) assumption that any non-military ship not of these types will benefit from the Logistics bonus.

The priority placed on the cargo hold component over the other components listed above does not match the documented commander auto-assignment behavior.

This is likely to confuse and frustrate players trying to play with interesting ship designs. For example, salvage ships usually are built with cargo holds to store the salvaged materials, however this behavior will ensure that a Production-skilled commander will not be assigned to such a sensibly-designed salvager because the cargo hold will take priority and label the ship as a "freighter" instead. Similarly, the not-uncommon practice of including a cargo hold on an orbital miner to tote a mass driver between mining sites will cause orbital miners to have assigned a Logistics-skill commander instead of a Mining-skill one.

As a "bug fix" I would like to see the priority of cargo holds in determining the ship type for auto-assignment made consistent with the documented priority behavior of the commander auto-assignment system.

I've moved the freighter check below all the other types you mentioned.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 21, 2021, 05:51:19 PM
In Cadbury system, many years ago, I detected an alien ground force signature.
No population, no ships, just a small ground force signature.
My geo survey ship completed the survey without incident, and found alien ruins and a potential for a geological surface survey.

Unafraid of the ground forces, I sent in xeno troops (non-combat), and after a long time they completed their work and identified the ruins: a small site with just 7 installations.
I then sent in construction troops (non-combat), and over a period of many months (maybe years) they compleexcavated the ruins.
A long while later I sent in geo survey troops (also non-combat). They worked without incident for more than 3 years.
So, for many, many years, I had troops on the surface of this planet, and never had an incident with the alien ground forces.
I could still detect the signature, but otherwise there was no sign of them.

Just now, in Mabel system (5 hops away), a geo survey ship of mine was attacked and destroyed by unknown ships.
At the exact same time as this attack, the alien forces on Cadbury attacked my troops there (to disastrous effect for me, since mine were all non-combat).


I see no logical reason for the Cadbury aliens to suddenly become hostile to my non-combat forces because of something that happened five hops away.
So I'm reporting it as a bug. If this is WAI I can accept that, even if it is kind of a head scratcher.
DB is attached.

You didn't specifically mention it, but are the aliens in Cadbury a different race than the aliens five transits away?

I don't know, because I never saw the aliens five hops away. My ship was destroyed by unknown, unseen ships and STO weapons.
I neglected to add a thermal sensor to my geo survey ships, and now I pay the price.

However, I started the game with no NPRs, so I don't see how these two races could be the same race. They certainly didn't hop from Cadbury to Mabel without me seeing them. And they couldn't have grown from Mabel to Cadbury: Mabel didn't exist (i.e., I did not discover it) until years and years after Cadbury.

If they are both the same spoiler race, it is odd that one has ships and STO weapons but the other does not.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 21, 2021, 05:53:17 PM
Giving names to the unnamed classes seemed to work--the next time I encountered a new class for this race, no errors occurred.

Sidenote: You can use the null-conditional operator (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators--and-) (as of C# 6) to avoid these types of runtime errors. I only learned about this last year. My coworkers pointed it out after they found my obsessive null-checking amusing.  ::)

I have plenty of null checks in the code, but didn't bother with ClassName as it is a string data type. That is the first time I have ever had a bug in C# Aurora caused by a value type (string, int, double, etc.) being null. Something extremely odd must have happened to cause it. Anyway, it now has a null check :)

The only out of the ordinary thing that happened in this scenario is that I changed the name theme for the race at some point after the first two classes were named.
Doesn't seem like that's likely to cause a problem, but it might be a code path that has not been thoroughly traveled.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 21, 2021, 06:05:55 PM
I don't know, because I never saw the aliens five hops away. My ship was destroyed by unknown, unseen ships and STO weapons.
I neglected to add a thermal sensor to my geo survey ships, and now I pay the price.

However, I started the game with no NPRs, so I don't see how these two races could be the same race. They certainly didn't hop from Cadbury to Mabel without me seeing them. And they couldn't have grown from Mabel to Cadbury: Mabel didn't exist (i.e., I did not discover it) until years and years after Cadbury.

If they are both the same spoiler race, it is odd that one has ships and STO weapons but the other does not.

I am guessing, but I think what happened was as follows
I'll add at least one tracking station to Rakhas to prevent that situation (assuming my guess is correct).
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 06:27:40 PM
This checkbox toggle seems to apply to all fleets, instead of the single fleet. I'm not sure if it's intended or not. "Auto-Include Lagrange Points" also applies to all fleets instead of just the individual fleet selected. I assume these also affect Standing Orders auto-routing (and not just manual auto-routing), in which case this is definitely a bug, since sometimes the player would want different routing logic for different fleets.

To reproduce:
1) Select a fleet.
2) Check or uncheck one of these two checkboxes.
3) Select a different fleet, and see that the option you chose persists (even after 'refreshing'--it's not just visual)

(https://i.imgur.com/ruzEEFP.png)

SJW: Changed Assume Jump-Capable to Fleet-specific
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 06:33:29 PM
When you reopen the Naval Organizations window, whichever fleet was last selected does not show anything when you look at the Standing Orders tab. I notice this fairly often when dealing with salvagers, jump gate constructors, and surveyors since I modify their standing or conditional orders depending on the situation.

To reproduce:
1) Open the Naval Org window, and select a fleet.
2) Select some Standing Orders (or conditional orders)
3) Close the Naval Org window.
4) Reopen Naval Org window.
5) Click the "Standing Orders" tab, and see that it visually does not show its current orders until you click away to another fleet and reselect this one.

Thanks for all your hard work, Steve! :)

(https://i.imgur.com/jAxFRdd.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 08:03:19 PM
Got what seemed like a couple hundred errors during system generation jumping into a new JP. Function #2608, #222, #224, #2339 in that order, and then repeating. Over and over.

According to a quick peek in the database, this is a new NPR (not a spoiler race) and they have been generated with the "pre-industrial" flag.

Edit: So, I don't know if this is intended or not, but when I approached their planet I discovered that they have two separate empires for the same NPR race on the planet. I'm only detecting STO and ground forces for one of them.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 09:29:02 PM
For some reason, the below orders give a "Transit Failure - cannot carry out a squadron transit as there is no available jump drive capable" error in the game log.

For clarity, the orders below are to:
1) Jump back through "JP2 Sabbat" that the ship is already sitting right on.
2) And then travel through "J3: Unex" in the system of Sabbat.

When I push the "30 days" button, a single sub-pulse of 6 hours is executed, and the Transit Failure message appears. I got the message one time and then deleted order #2 above. When I pushed the 30-day button again, the ship successfully transited. (The ship was not damaged at any time. Its jump drive was fully functional.)

I remember having this bug on previous versions of C#. I didn't do much troubleshooting this time, but I seem to recall it having something to do with interval length or subpulse length?


https://i.imgur.com/aRqYX4I.png (https://i.imgur.com/aRqYX4I.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Density on May 21, 2021, 09:48:37 PM
For some reason, the below orders give a "Transit Failure - cannot carry out a squadron transit as there is no available jump drive capable" error in the game log.

For clarity, the orders below are to:
1) Jump back through "JP2 Sabbat" that the ship is already sitting right on.
2) And then travel through "J3: Unex" in the system of Sabbat.

When I push the "30 days" button, a single sub-pulse of 6 hours is executed, and the Transit Failure message appears. I got the message one time and then deleted order #2 above. When I pushed the 30-day button again, the ship successfully transited. (The ship was not damaged at any time. Its jump drive was fully functional.)

I remember having this bug on previous versions of C#. I didn't do much troubleshooting this time, but I seem to recall it having something to do with interval length or subpulse length?


This is WAI. After a jump, some systems need to come back online before they can be used. This includes active sensors, fire controls, and jump engines.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 21, 2021, 09:59:09 PM
For some reason, the below orders give a "Transit Failure - cannot carry out a squadron transit as there is no available jump drive capable" error in the game log.

For clarity, the orders below are to:
1) Jump back through "JP2 Sabbat" that the ship is already sitting right on.
2) And then travel through "J3: Unex" in the system of Sabbat.

When I push the "30 days" button, a single sub-pulse of 6 hours is executed, and the Transit Failure message appears. I got the message one time and then deleted order #2 above. When I pushed the 30-day button again, the ship successfully transited. (The ship was not damaged at any time. Its jump drive was fully functional.)

I remember having this bug on previous versions of C#. I didn't do much troubleshooting this time, but I seem to recall it having something to do with interval length or subpulse length?


This is WAI. After a jump, some systems need to come back online before they can be used. This includes active sensors, fire controls, and jump engines.

Oops. It was almost certainly this! Thank you.
Title: Re: v1.13.0 Bugs Thread
Post by: 01010100 on May 21, 2021, 10:34:52 PM
That is the first time I have ever had a bug in C# Aurora caused by a value type (string, int, double, etc.) being null.

string isn't a value type, value types can not be null, only reference types can be null. String is basically just an alias for char[] but with some special handling, in particular whenever you have two strings that are the same they'll both refer to the same internal char[].
Title: Re: v1.13.0 Bugs Thread
Post by: Norm49 on May 22, 2021, 12:22:56 AM
Maybe this is working as intended, i don't know.

I you cancel a ship yard task before it start when it is still at 0.0% if you use already build component you lose them even if you cancel the task before the fit turn.

SJW: WAI. Once you create a task and use up components, they are lost.
Title: Re: v1.13.0 Bugs Thread
Post by: simast on May 22, 2021, 03:59:25 AM
I've moved the freighter check below all the other types you mentioned.

Would like to add another case that I think was not listed in OP. If you have a diplomatic ship and add some ELINT modules - it becomes an intelligent ship for auto-assign purposes. I would move that check below as well as it is quite common for diplomatic ships to also include ELINT modules I think, but they should not be considered dedicated intel ships in this case.

SJW: Changed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 22, 2021, 04:12:12 AM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; Exploring & Ground Combat
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? Exploring most of the time. Ground Combat constant
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 32 years


Potential bug 1: My survey ships set with standing orders refuel at colony or hub at 50% fuel rarely travel to colony to refuel preferring to run dry (I have no hubs). Same applies to maintenance supplies. Is this WAI?

Potential bug 2: An alien race tried to set up shop on my colony cost 0 colony. I set to hostile and appeared to destroy the interlopers. But I am still getting Ground Intelligence Report  Estimated Hostile Force (Error Range: 7%) Estimated Hostile Force: Unknown Unit Types: 211. but my ground forces will no longer engage the enemy. There is no separate colony that I have conquered so what is going on?

Potential bug 3: I have been unable to transfer maintenance supplies from supply ships to other vessels. Is there a tech to enable this?

Potential bug 4: Even though I emplaced an ordnance transfer Station on a captured precursor colony still unable to load missiles from colony, including on to a captured precursor warship that uses these missiles. There is no cargo shuttle station on colony. Is this the problem?

Things I miss: Standing order to refuel at tanker.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 22, 2021, 05:07:31 AM
This checkbox toggle seems to apply to all fleets, instead of the single fleet. I'm not sure if it's intended or not. "Auto-Include Lagrange Points" also applies to all fleets instead of just the individual fleet selected. I assume these also affect Standing Orders auto-routing (and not just manual auto-routing), in which case this is definitely a bug, since sometimes the player would want different routing logic for different fleets.

To reproduce:
1) Select a fleet.
2) Check or uncheck one of these two checkboxes.
3) Select a different fleet, and see that the option you chose persists (even after 'refreshing'--it's not just visual)

(https://i.imgur.com/ruzEEFP.png)

"Auto-Include Lagrange Points" is intended to apply to all fleets as it is a general setting. "Assume Fleet is Jump-Capable" was intended as a general setting but after considering it, I think it is more appropriate to be fleet-specific so I have changed it on that basis.

This setting doesn't affect standing orders.

SJW: Jump-Capable fixed for v1.14. Auto-Include Lagrange is working as intended.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 22, 2021, 05:36:06 AM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; Exploring & Ground Combat
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? Exploring most of the time. Ground Combat constant
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 32 years


Potential bug 1: My survey ships set with standing orders refuel at colony or hub at 50% fuel rarely travel to colony to refuel preferring to run dry (I have no hubs). Same applies to maintenance supplies. Is this WAI?

Potential bug 2: An alien race tried to set up shop on my colony cost 0 colony. I set to hostile and appeared to destroy the interlopers. But I am still getting Ground Intelligence Report  Estimated Hostile Force (Error Range: 7%) Estimated Hostile Force: Unknown Unit Types: 211. but my ground forces will no longer engage the enemy. There is no separate colony that I have conquered so what is going on?

Potential bug 3: I have been unable to transfer maintenance supplies from supply ships to other vessels. Is there a tech to enable this?

Potential bug 4: Even though I emplaced an ordnance transfer Station on a captured precursor colony still unable to load missiles from colony, including on to a captured precursor warship that uses these missiles. There is no cargo shuttle station on colony. Is this the problem?

Things I miss: Standing order to refuel at tanker.

#1 Something else at play here. If refuel at colony didn't work I would be getting a lot of bug reports to that effect. Are there colonies with refuelling stations or spaceports that the survey ships can reach (using either jump engines or jump gates)?

#2 Do you have any units set to frontline attack?

#3 Do you have cargo handling systems on your supply ships?

#4 Does the ship picking up the missiles have them listed in its class or ship loadout?
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 22, 2021, 07:14:44 AM
The function number; 1.13.0
The complete error text; n/a
The window affected; various
What you were doing at the time; Exploring & Ground Combat
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; intermittent or a one-off? Exploring most of the time. Ground Combat constant
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 32 years


Potential bug 1: My survey ships set with standing orders refuel at colony or hub at 50% fuel rarely travel to colony to refuel preferring to run dry (I have no hubs). Same applies to maintenance supplies. Is this WAI?

Potential bug 2: An alien race tried to set up shop on my colony cost 0 colony. I set to hostile and appeared to destroy the interlopers. But I am still getting Ground Intelligence Report  Estimated Hostile Force (Error Range: 7%) Estimated Hostile Force: Unknown Unit Types: 211. but my ground forces will no longer engage the enemy. There is no separate colony that I have conquered so what is going on?

Potential bug 3: I have been unable to transfer maintenance supplies from supply ships to other vessels. Is there a tech to enable this?

Potential bug 4: Even though I emplaced an ordnance transfer Station on a captured precursor colony still unable to load missiles from colony, including on to a captured precursor warship that uses these missiles. There is no cargo shuttle station on colony. Is this the problem?

Things I miss: Standing order to refuel at tanker.

#1 Something else at play here. If refuel at colony didn't work I would be getting a lot of bug reports to that effect. Are there colonies with refuelling stations or spaceports that the survey ships can reach (using either jump engines or jump gates)?

#2 Do you have any units set to frontline attack?

#3 Do you have cargo handling systems on your supply ships?

#4 Does the ship picking up the missiles have them listed in its class or ship loadout?

#1: Yes, the home colony has refueling facilities, and 50% fuel should be sufficient to get home and all have jump engines and usually only a couple of jumps from home. Occasionally I will see a survey ship go to refuel but very infrequent.

#2: Yes, set 52 Tank battalions set to front line attack, via drop down menu.

#3: Oops! No! Managed to miss that out. Sorry!

#4: That's why I used a former precursor escort cruiser which that missile was specified for. but no cargo shuttle station on colony or ship, but there is an ordnance transfer station. Because they are alien missiles they do not show up in stockpile or in the ordnance tab so cannot allocate them as load out..
Title: Re: v1.13.0 Bugs Thread
Post by: Zap0 on May 22, 2021, 07:44:29 AM
#4: That's why I used a former precursor escort cruiser which that missile was specified for. but no cargo shuttle station on colony or ship, but there is an ordnance transfer station. Because they are alien missiles they do not show up in stockpile or in the ordnance tab so cannot allocate them as load out..

That's the problem, ships will only load things that are in their loadout, either the stuff set in their ship loadout, or if that doesn't exist, that of their class loadout. Mechanically the ship can fire precursor AMMs equally well as any other size 1 missile.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 22, 2021, 08:33:43 AM
Got what seemed like a couple hundred errors during system generation jumping into a new JP. Function #2608, #222, #224, #2339 in that order, and then repeating. Over and over.

According to a quick peek in the database, this is a new NPR (not a spoiler race) and they have been generated with the "pre-industrial" flag.

Edit: So, I don't know if this is intended or not, but when I approached their planet I discovered that they have two separate empires for the same NPR race on the planet. I'm only detecting STO and ground forces for one of them.

Update on the strike-through text: This system actually spawned with both a 1) Pre-industrial NPR, and 2) Rakhas on the same body. That seems like a bug, although it's an interesting situation with roleplay implications. Also, apparently they're not hostile to each other even after time progresses. I don't think they can detect each other. Maybe this bug created an interesting enough situation not to fix it. (Except for all the error messages I originally got above on system gen)
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 22, 2021, 08:56:57 AM
Ship Design Display tab throws divide by zero errors for ships of size 38t or less.

Steps to reproduce:
The breakpoints bracket 0.75 HS, which is interesting.
Could be that something is rounding ship size to the nearest 0.1HS, then squaring it, then rounding that to nearest integer, then using that as a divisor.
Maintenance failure chance perhaps?

Fixed for v1.14. The problem was caused by Armour Width = 0
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 22, 2021, 09:08:19 AM
Due to how the Max Number of Systems interacts with jump point linking, the chance of generating a jump point link to an existing system increases dramatically as you explore more and more systems, quickly turning what was an orderly and linear galactic map for decades or centuries into a very sudden spaghetti bowl. This seems like a very complicated problem, and I am not a math person so I don't know how to fix this. Ideally one would want a relatively constant chance of a JP linking to an existing system regardless of total systems surveyed, instead of a very, very low chance throughout most of the game until you reach some threshold and then suddenly linking to existing systems becomes a common occurrence.

I'm using default Local Gen Spread and Chance (15 spread, 50% chance) and Max Systems of 250 instead of the default 1000.

SJW: This is working as intended and is not a bug. A random connection in a fixed universe is more likely to connect to an existing system if you have generated a higher proportion of the potential systems.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 22, 2021, 09:09:28 AM
Due to how the Max Number of Systems interacts with jump point linking, the chance of generating a jump point link to an existing system increases dramatically as you explore more and more systems, quickly turning what was an orderly and linear galactic map for decades or centuries into a very sudden spaghetti bowl. This seems like a very complicated problem, and I am not a math person so I don't know how to fix this. Ideally one would want a relatively constant chance of a JP linking to an existing system regardless of total systems surveyed, instead of a very, very low chance throughout most of the game until you reach some threshold and then suddenly linking to existing systems becomes a common occurrence.

I'm using default Local Gen Spread and Chance (15 spread, 50% chance) and Max Systems of 250 instead of the default 1000.

I don't think this belongs in the bugs thread. Suggestions thread perhaps?
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 22, 2021, 09:18:14 AM
Due to how the Max Number of Systems interacts with jump point linking, the chance of generating a jump point link to an existing system increases dramatically as you explore more and more systems, quickly turning what was an orderly and linear galactic map for decades or centuries into a very sudden spaghetti bowl. This seems like a very complicated problem, and I am not a math person so I don't know how to fix this. Ideally one would want a relatively constant chance of a JP linking to an existing system regardless of total systems surveyed, instead of a very, very low chance throughout most of the game until you reach some threshold and then suddenly linking to existing systems becomes a common occurrence.

I'm using default Local Gen Spread and Chance (15 spread, 50% chance) and Max Systems of 250 instead of the default 1000.

I don't think this belongs in the bugs thread. Suggestions thread perhaps?

It's a side effect of how a current system in the game works. If it doesn't rise to the level of a bug then just ignore it.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 22, 2021, 09:27:01 AM
Due to how the Max Number of Systems interacts with jump point linking, the chance of generating a jump point link to an existing system increases dramatically as you explore more and more systems, quickly turning what was an orderly and linear galactic map for decades or centuries into a very sudden spaghetti bowl. This seems like a very complicated problem, and I am not a math person so I don't know how to fix this. Ideally one would want a relatively constant chance of a JP linking to an existing system regardless of total systems surveyed, instead of a very, very low chance throughout most of the game until you reach some threshold and then suddenly linking to existing systems becomes a common occurrence.

I'm using default Local Gen Spread and Chance (15 spread, 50% chance) and Max Systems of 250 instead of the default 1000.

I don't think this belongs in the bugs thread. Suggestions thread perhaps?

It's a side effect of how a current system in the game works. If it doesn't rise to the level of a bug then just ignore it.

I really like your suggestion, and I think a fruitful discussion about it could lead to an improvement in the game.
But this is not the appropriate thread for that discussion.

To ignore your post, one must first read it.
Steve has very limited time. The volunteers who help vet bugs on this thread also have very limited time.
You are asking them to spend some of that time reading about something that is very clearly not a bug.


Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 22, 2021, 10:20:48 AM
Due to how the Max Number of Systems interacts with jump point linking, the chance of generating a jump point link to an existing system increases dramatically as you explore more and more systems, quickly turning what was an orderly and linear galactic map for decades or centuries into a very sudden spaghetti bowl. This seems like a very complicated problem, and I am not a math person so I don't know how to fix this. Ideally one would want a relatively constant chance of a JP linking to an existing system regardless of total systems surveyed, instead of a very, very low chance throughout most of the game until you reach some threshold and then suddenly linking to existing systems becomes a common occurrence.

I'm using default Local Gen Spread and Chance (15 spread, 50% chance) and Max Systems of 250 instead of the default 1000.

I don't think this belongs in the bugs thread. Suggestions thread perhaps?

It's a side effect of how a current system in the game works. If it doesn't rise to the level of a bug then just ignore it.

I really like your suggestion, and I think a fruitful discussion about it could lead to an improvement in the game.
But this is not the appropriate thread for that discussion.

To ignore your post, one must first read it.
Steve has very limited time. The volunteers who help vet bugs on this thread also have very limited time.
You are asking them to spend some of that time reading about something that is very clearly not a bug.

I would like to echo this. It is good to post suggestions in the appropriate thread, because this helps to stimulate discussion. Often if a good idea is proposed in the suggestion thread, other players will comment on it, refining the suggestion or discussing whether they agree with the idea. Getting a lot of players who share the opinion makes the suggestion more visible and more likely to be implemented.

This cannot happen in the bugs thread because it is for bug reporting/fixing/workarounds, not ideas discussion.

So if you report something you think is a bug, and are told that it is not by other knowledgeable forumers, but you still think the behavior is not good or should be changed, the suggestions thread is the place to discuss this and see if other players agree, which if so makes it more likely that such an idea will be noticed and implemented by Steve (although of course it is not for certain).
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 22, 2021, 11:13:34 AM
Due to how the Max Number of Systems interacts with jump point linking, the chance of generating a jump point link to an existing system increases dramatically as you explore more and more systems, quickly turning what was an orderly and linear galactic map for decades or centuries into a very sudden spaghetti bowl. This seems like a very complicated problem, and I am not a math person so I don't know how to fix this. Ideally one would want a relatively constant chance of a JP linking to an existing system regardless of total systems surveyed, instead of a very, very low chance throughout most of the game until you reach some threshold and then suddenly linking to existing systems becomes a common occurrence.

I'm using default Local Gen Spread and Chance (15 spread, 50% chance) and Max Systems of 250 instead of the default 1000.

I made this bug report here in good faith because these may (or may not) turn out to be unintended side effects in how the JP link system is implemented.

My working assumption in reporting this on the bug thread is that the jump point link system is intended, by default, to have a low but relatively constant chance of linking to an existing system. That does not seem to be what actually happens in game.

In practice, I have found during the early game when most of the "system numbers" are ungenerated, there is a much lower than normal chance of systems linking to each other. As more and more systems are discovered, the "system number space" gets crowded and the chance of systems linking to each other grows far, far larger than in the early game. The net effect is that in the early game, JPs linking to existing systems are quite rare, while in the late game you start getting an avalanche of JPs linking to existing systems.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 22, 2021, 04:46:46 PM
I looked at the "Alien Race" table in the DB to watch diplomacy progress with a new NPR that shot at me, and I have not noticed diplomatic relations trending back to non-war while our races are not in mutual detection range of each other.

This prevents the scenario referenced in the C# Diplomacy Changes, where a race shoots at another's survey ship, but as long as you avoid contact, relations trend back to non-war. Instead, they are remaining static according to the DB, across many construction periods.

Once I put a fleet back in mutual detection range, relations started trending back to normal. This is obviously going to be a problem if they keep trying to shoot at every ship I try to bring in diplomatic sensor range. Perhaps relations should continue trending towards baseline, regardless of whether you are in mutual detection?
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 22, 2021, 05:23:41 PM
I got this function error #899 when I entered the command telling this captured ship to "Absorb" another captured fleet at the same location. It may be because this fleet is set to 0 km/sec.


How did you get the speed to zero? Ships with no engines should default to 1 km/s to avoid divide by zero errors. If you set speed manually to zero then it should be corrected to 1.

It was a fuel harvester that the NPRs surrendered after I damaged it. I didn't modify the speed in any way, it was like that when I got it.

The zero speed was the problem, but I can't see a way for the code to generate that speed (although it did somehow). I've added some extra checks in case zero speed is set.

I've noticed this interesting occurrence twice now: after some enemy ships get hit with my missiles, they show as traveling at 0 km/sec. On the next interval, they correctly update to their new speeds. This might be related.

(https://i.imgur.com/aplQXQ7.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Erik L on May 22, 2021, 11:36:46 PM
I got this function error #899 when I entered the command telling this captured ship to "Absorb" another captured fleet at the same location. It may be because this fleet is set to 0 km/sec.


How did you get the speed to zero? Ships with no engines should default to 1 km/s to avoid divide by zero errors. If you set speed manually to zero then it should be corrected to 1.
Damage control?

It was a fuel harvester that the NPRs surrendered after I damaged it. I didn't modify the speed in any way, it was like that when I got it.

The zero speed was the problem, but I can't see a way for the code to generate that speed (although it did somehow). I've added some extra checks in case zero speed is set.

I've noticed this interesting occurrence twice now: after some enemy ships get hit with my missiles, they show as traveling at 0 km/sec. On the next interval, they correctly update to their new speeds. This might be related.

(https://i.imgur.com/aplQXQ7.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on May 23, 2021, 03:45:43 AM
When viewing contacts as targets for movement orders on the ship movement tab there are a large number of Con:SalvoID XXXX  Contacts showing up. When I look at the system display there are none visible , these odd salvo contacts have persisted for many 5 second turns and I have seen no explosions in the Solar system so I have to assume they are a lingering remenent of the missile salvo's I shot down.
The game has been in 5 second turns for several hours since those missiles were destroyed but with NPR's outside the system I do not know if they are causing that.
Title: Re: v1.13.0 Bugs Thread
Post by: simast on May 23, 2021, 04:52:11 AM
In game settings dialog "Detection" dropdown value does not seem to save when you change it and click "Save Settings".

Steps to reproduce:

1. Open game information dialog.
2. Change Detection from "Normal in all systems" to "Automatic without player presence".
3. Click "Save Settings".
4. Close game information dialog.
5. Open game information dialog again - dropdown is still in "Normal in all systems" state.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Stryker on May 23, 2021, 05:24:15 AM
The move to gas giant with sorium standing order appears to be broken.  When I give the order to a sorium harvester, it tells me that there is no suitable destination.  However, Jupiter has over 6000000 sorium.  If I manually order the harvester to a gas giant, it works fine.
Edit: this worked fine in v1.12.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 07:25:48 AM
I looked at the "Alien Race" table in the DB to watch diplomacy progress with a new NPR that shot at me, and I have not noticed diplomatic relations trending back to non-war while our races are not in mutual detection range of each other.

This prevents the scenario referenced in the C# Diplomacy Changes, where a race shoots at another's survey ship, but as long as you avoid contact, relations trend back to non-war. Instead, they are remaining static according to the DB, across many construction periods.

Once I put a fleet back in mutual detection range, relations started trending back to normal. This is obviously going to be a problem if they keep trying to shoot at every ship I try to bring in diplomatic sensor range. Perhaps relations should continue trending towards baseline, regardless of whether you are in mutual detection?

The situation you describe should happen when there is contact (including populations) but no diplomacy module present or a diplomacy ship without an appropriate ccommander or when communications have not been established. Are you sure none of those is applicable in this context?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 07:46:26 AM
I've noticed this interesting occurrence twice now: after some enemy ships get hit with my missiles, they show as traveling at 0 km/sec. On the next interval, they correctly update to their new speeds. This might be related.

(https://i.imgur.com/aplQXQ7.png)

A good suggestion. I looked into but that is contact speed rather than ship speed.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 08:20:05 AM
In game settings dialog "Detection" dropdown value does not seem to save when you change it and click "Save Settings".

Steps to reproduce:

1. Open game information dialog.
2. Change Detection from "Normal in all systems" to "Automatic without player presence".
3. Click "Save Settings".
4. Close game information dialog.
5. Open game information dialog again - dropdown is still in "Normal in all systems" state.

This was a problem for all game settings. All changes were made to the active game but not reflected in the game details window until you saved the game on the tactical map. It was the performance changes to saving that caused the problem. The correct information will now be reflected in the game details window.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 23, 2021, 08:29:47 AM
I looked at the "Alien Race" table in the DB to watch diplomacy progress with a new NPR that shot at me, and I have not noticed diplomatic relations trending back to non-war while our races are not in mutual detection range of each other.

This prevents the scenario referenced in the C# Diplomacy Changes, where a race shoots at another's survey ship, but as long as you avoid contact, relations trend back to non-war. Instead, they are remaining static according to the DB, across many construction periods.

Once I put a fleet back in mutual detection range, relations started trending back to normal. This is obviously going to be a problem if they keep trying to shoot at every ship I try to bring in diplomatic sensor range. Perhaps relations should continue trending towards baseline, regardless of whether you are in mutual detection?

The situation you describe should happen when there is contact (including populations) but no diplomacy module present or a diplomacy ship without an appropriate ccommander or when communications have not been established. Are you sure none of those is applicable in this context?

In this case, communications indeed have not yet been established. There have been a handful of commo rolls, but they are hard to come by as they keep shooting my ships, even in a neutral system that hasn't received an unintelligible message.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 23, 2021, 08:32:32 AM
There does not seem to be an in-game way to view Race Intelligence Points (rather than per pop intelligence points) that I can find. This may be intentionally obfuscated, although per pop intel points are shown on the Intel Screen.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 23, 2021, 09:22:06 AM
Naval mines do not seem to be working. I am using a mine which consists of a 1st stage buoy with "No Engine" and active sensors (range 6mil km), containing a second stage of two anti-ship missiles with active sensors (range 6mil km). Separation distance is configured to be 5mil km.

If you use the "Launch Ready Ordnance" command, the mines erroneously disappear immediately (you don't even see them appear on the map even after a 5-second interval) unless a target is already within range, making them unusable as a long-term static defense.

Alternatively, if you target a distant waypoint (such as "Point of Interest #1") with the MFC to which the mine missile launchers are attached and "Open Fire", the mines appear on the map and persist forever. However, as you can see below, they remain targeted at the Point of Interest forever and do not retarget enemies that are in range. Even if you delete the POI, the missiles remained locked onto the non-existent POI and do nothing. Moving your ship so the mines are out of MFC range likewise does nothing, they remain locked onto the POI forever.

It is possible I am doing something wrong, but I can't find anyone else who has direct experience with working C# mines, and I am out of ideas.

(https://i.imgur.com/hax78r4.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 23, 2021, 09:26:24 AM
Another bug with multi-stage missiles: Although the game appears to be correctly saving and using the designs of multi-stage missiles, you cannot load them up again in the Missile Designer.

The second-stage settings for your missiles do not load properly when selected, unlike single-stage missiles which load properly.

(https://i.imgur.com/ZLijdcY.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 23, 2021, 09:28:55 AM
When loading the design of a previously saved missile, the typeable name box doesn't update with the name of the loaded missile, which becomes annoying when you go back to design a new Mark version.

(https://i.imgur.com/PoCGVrL.png)

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 09:48:10 AM
If you use the "Launch Ready Ordnance" command, the mines erroneously disappear immediately (you don't even see them appear on the map even after a 5-second interval) unless a target is already within range, making them unusable as a long-term static defense.

Do you get any event associated with the disappearance of the missiles? Also, have the missiles been deducted from the magazine?
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 23, 2021, 09:53:33 AM
If you use the "Launch Ready Ordnance" command, the mines erroneously disappear immediately (you don't even see them appear on the map even after a 5-second interval) unless a target is already within range, making them unusable as a long-term static defense.

Do you get any event associated with the disappearance of the missiles? Also, have the missiles been deducted from the magazine?

When using "Launch Ready Ordnance", the missiles are indeed deducted from the magazine. There is an entry in the fleet history that indicates the order took place. The only event log message is the one indicating the fleet "completed orders".

If there is an enemy already within range, the second stages will immediately appear (you never see the first stage) and they will target the enemy.

(https://i.imgur.com/W4oJW63.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 23, 2021, 10:19:08 AM
If you use the "Launch Ready Ordnance" command, the mines erroneously disappear immediately (you don't even see them appear on the map even after a 5-second interval) unless a target is already within range, making them unusable as a long-term static defense.

Do you get any event associated with the disappearance of the missiles? Also, have the missiles been deducted from the magazine?

When using "Launch Ready Ordnance", the missiles are indeed deducted from the magazine. There is an entry in the fleet history that indicates the order took place. The only event log message is the one indicating the fleet "completed orders".

If there is an enemy already within range, the second stages will immediately appear (you never see the first stage) and they will target the enemy.


I did some testing on a save backup, and deleted the "TargetID" and "TargetType" entries from the database on all existing mine salvos which had manually fired by targeting a distant waypoint (i.e. they had been stuck as buoys perpetually targeting the distant waypoint). Upon pushing time forward 5 seconds, the mines that had no enemies within range instantly disappeared, while the mines with enemies in range activated their second stages at the enemies.

It could simply be that right now all missiles without targets, even buoys, auto-self destruct if there is no target in range.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 10:21:51 AM
If you use the "Launch Ready Ordnance" command, the mines erroneously disappear immediately (you don't even see them appear on the map even after a 5-second interval) unless a target is already within range, making them unusable as a long-term static defense.

Do you get any event associated with the disappearance of the missiles? Also, have the missiles been deducted from the magazine?

When using "Launch Ready Ordnance", the missiles are indeed deducted from the magazine. There is an entry in the fleet history that indicates the order took place. The only event log message is the one indicating the fleet "completed orders".

If there is an enemy already within range, the second stages will immediately appear (you never see the first stage) and they will target the enemy.

(https://i.imgur.com/W4oJW63.png)

I have found a bug that would fit the behaviour described. I'm surprised this hasn't come up before, but fixed now.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 10:22:52 AM
It could simply be that right now all missiles without targets, even buoys, auto-self destruct if there is no target in range.

Yes, that is what it seems is happening. Fixed for v1.14.
Title: Re: v1.13.0 Bugs Thread
Post by: Cobaia on May 23, 2021, 11:58:32 AM
Hello everyone,

Is it just me or do you guys can build Stations with prototype components?
Title: Re: v1.13.0 Bugs Thread
Post by: Azuraal on May 23, 2021, 12:35:23 PM
Game option "Generate non-TN races only" doesn't seem to work. The game generates standard NPRs with ships and everything, that proceeds to explore and expand as normal.

Happened twice to me, once on a conventional start, the second time on standard. I'm sure in both cases that I set the starting NPR number to 0.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 06:05:17 PM
Hello everyone,

Is it just me or do you guys can build Stations with prototype components?

Yes, already fixed for v1.14. See the changes list.
http://aurora2.pentarch.org/index.php?topic=12523.0
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 23, 2021, 06:10:36 PM
Game option "Generate non-TN races only" doesn't seem to work. The game generates standard NPRs with ships and everything, that proceeds to explore and expand as normal.

Happened twice to me, once on a conventional start, the second time on standard. I'm sure in both cases that I set the starting NPR number to 0.

The 'Generate non-TN races only' option only applies to races generated after start. As far as I can tell, the option is working as intended.
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 23, 2021, 07:48:57 PM
Free Research Centers Received?

I had been researching Missile Launcher Reload Rate 3 using a scientist with a Research Admin rating of 20, but only using 4 Research Centers. Other than that, all research centers on Earth were in use. At the time I was both building research centers, transporting some in from a xenoarchaeology dig, and also gathering intel on an alien race I had detected using ELINT modules.

Not sure what the specific trigger was, but in one turn I got notification that I had stolen information on Visible Light Lasers from the alien race, I had either built or transferred an RC to Earth such that 1 inactive research center on Earth was available, and that my team on Earth completed research into Missile Launcher Reload Rate 3. However, when I went to queue my next research project, I found 21 Research Centers available instead of my expected 5 (4 previously use + 1 new RC). Potentially what happened is when the project finished I was given the scientist's fill Research Admin rating of labs in addition to the new one (20 Admin rating + 1 new one). When I queued the next research project using the same 4 labs, that left with with 17 to assign out. DB attached.
Title: Re: v1.13.0 Bugs Thread
Post by: kyonkundenwa on May 23, 2021, 08:05:38 PM
Free Research Centers Received?

I had been researching Missile Launcher Reload Rate 3 using a scientist with a Research Admin rating of 20, but only using 4 Research Centers. Other than that, all research centers on Earth were in use. At the time I was both building research centers, transporting some in from a xenoarchaeology dig, and also gathering intel on an alien race I had detected using ELINT modules.

Not sure what the specific trigger was, but in one turn I got notification that I had stolen information on Visible Light Lasers from the alien race, I had either built or transferred an RC to Earth such that 1 inactive research center on Earth was available, and that my team on Earth completed research into Missile Launcher Reload Rate 3. However, when I went to queue my next research project, I found 21 Research Centers available instead of my expected 5 (4 previously use + 1 new RC). Potentially what happened is when the project finished I was given the scientist's fill Research Admin rating of labs in addition to the new one (20 Admin rating + 1 new one). When I queued the next research project using the same 4 labs, that left with with 17 to assign out. DB attached.

I didn't look at your DB but I give it a 99% chance that you have an idle energy weapons scientist who was previously researching Visible Light Lasers with ~17 labs.
I looked at your DB this time, I think you just forgot who had the labs. Your MK guy Yasir Yousif took over two months (16 May to 28 July) to finish a 2K RP tech (reload 2), which indicates he was producing about 10K RP per year and thus had 4 labs as expected. He then finished a 4K tech (reload 3) in one month which indicates that he was producing around 50K RP per year and thus was maxed out at 20 labs the whole time, you just didn't notice.
Your low-lab CP guy started working on Wealth Production 160 the same cycle that Yasir Yousif started working on Reload 2, and finished on the same cycle as him as well. That's a 10K tech in a little over two months, indicating ~20 labs of production. I'm guessing you had 20 labs dedicated to him (intentionally or not) and you accidentally transferred them to Yasir Yousif when they both finished working on the same cycle.

Labs can also get assigned unexpectedly when you're using the Assign (N)ew feature and somebody finishes their work on the same cycle that a new lab becomes available but I'm not sure if that happened here because you don't seem to be using the assign new feature.

You can always load up your backup DBs (assuming they're not from decades before) and check to see if 172 labs total is sensible based on how many you had before.
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 23, 2021, 08:09:38 PM
Free Research Centers Received?

I had been researching Missile Launcher Reload Rate 3 using a scientist with a Research Admin rating of 20, but only using 4 Research Centers. Other than that, all research centers on Earth were in use. At the time I was both building research centers, transporting some in from a xenoarchaeology dig, and also gathering intel on an alien race I had detected using ELINT modules.

Not sure what the specific trigger was, but in one turn I got notification that I had stolen information on Visible Light Lasers from the alien race, I had either built or transferred an RC to Earth such that 1 inactive research center on Earth was available, and that my team on Earth completed research into Missile Launcher Reload Rate 3. However, when I went to queue my next research project, I found 21 Research Centers available instead of my expected 5 (4 previously use + 1 new RC). Potentially what happened is when the project finished I was given the scientist's fill Research Admin rating of labs in addition to the new one (20 Admin rating + 1 new one). When I queued the next research project using the same 4 labs, that left with with 17 to assign out. DB attached.

I didn't look at your DB but I give it a 99% chance that you have an idle energy weapons scientist who was previously researching Visible Light Lasers with ~17 labs.

Surprisingly not! This run has been 100% Particle Beams/Lances, other than Gauss Cannons for point defense.

EDIT: kyonkundenwa thanks for taking the time to look through the DB. I think you may be right and I may have just missed the Wealth Production 160 finishing. I didn't think I had maxed him on labs but now I'm not sure and based on your math it sounds like I likely had. Thanks for taking the time to do the analysis!
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on May 24, 2021, 12:21:23 PM
Dissapearing NPR ground forces
I have been having problems with NPR's seemingly having no ground forces. So on this start I created the NPR's including one on Venus then saved the game. As a test I then SM'd a colony on the world and several regiments of ground troops, ground combat started and troops were killed on both sides.
So I returned to the saved game and then proceded to fight a war, now I have invaded Venus and have had no ground fighting but have been informed that enemy ground forces have been defeated and I need more troops to occupy the colony.
It seems that all 4 NPR's in the system have lost their ground troops in 2 months of game time without anything being done to them. I don't think this is intended behaviour.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 24, 2021, 07:15:44 PM
220x missiles fired, 220x missiles detonated against the enemy NPR STOs and STO-PDs. No point defense beam fire was observed. This NPR outtechs me and has pretty good ship-based PD tech.

Is NPR STO PD working as intended? Seems like it didn't fire at all.

(https://i.imgur.com/NxTnzih.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 24, 2021, 07:42:24 PM
Also, while bombarding the NPR homeworld I got function error #755 one time.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 24, 2021, 08:29:34 PM
Mineral packets arriving at a planet which has no mass drivers do not cause any explosive side-effects. They just disappear when they reach the target body.

SJW: Working as Intended. I changed this to avoid the regular new player problem of destroying their own colonies by accident :)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 25, 2021, 05:07:36 AM
Dissapearing NPR ground forces
I have been having problems with NPR's seemingly having no ground forces. So on this start I created the NPR's including one on Venus then saved the game. As a test I then SM'd a colony on the world and several regiments of ground troops, ground combat started and troops were killed on both sides.
So I returned to the saved game and then proceded to fight a war, now I have invaded Venus and have had no ground fighting but have been informed that enemy ground forces have been defeated and I need more troops to occupy the colony.
It seems that all 4 NPR's in the system have lost their ground troops in 2 months of game time without anything being done to them. I don't think this is intended behaviour.

Has anyone else seen this bug? I checked the NPRs in my recent campaign and they still have all their ground forces.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 25, 2021, 05:16:39 AM
220x missiles fired, 220x missiles detonated against the enemy NPR STOs and STO-PDs. No point defense beam fire was observed. This NPR outtechs me and has pretty good ship-based PD tech.

Is NPR STO PD working as intended? Seems like it didn't fire at all.

(https://i.imgur.com/NxTnzih.png)

What was the time increment used? I assume the four minute increment length was an interrupted longer increment. STO weapons only have a short detection range, so the missiles probably passed through that detection range in a single sub-pulse and the NPR was therefore unable to detect them before impact.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 25, 2021, 10:55:57 AM
This is kind of silly, but if you use the manual damage tool in the Miscellaneous tab of the Ship Overview page to attack a ship multiple times, the ship may be destroyed multiple times, leaving multiple lifepods and wrecks. Luckily, it seems that the commanders are not duplicated if they escape, ending up only in a single lifepod. And this is a pretty niche situation, so probably not the highest priority to fix.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 25, 2021, 11:11:00 AM
If a fleet is following an enemy ship that leaves active sensor range, the fleet will stop with a "destination not found" message even if the ship it was following is still visible e.g. by a tracking station. You can then continue following the ship, you just have to give the fleet a new order.

SJW: Fleet Orders will now change to another current contact for the same ship if one exists.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 25, 2021, 12:36:42 PM
If a fleet is following an enemy ship that leaves active sensor range, the fleet will stop with a "destination not found" message even if the ship it was following is still visible e.g. by a tracking station. You can then continue following the ship, you just have to give the fleet a new order.

This happens to me a lot and it is very annoying.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 25, 2021, 02:01:50 PM
220x missiles fired, 220x missiles detonated against the enemy NPR STOs and STO-PDs. No point defense beam fire was observed. This NPR outtechs me and has pretty good ship-based PD tech.

Is NPR STO PD working as intended? Seems like it didn't fire at all.


What was the time increment used? I assume the four minute increment length was an interrupted longer increment. STO weapons only have a short detection range, so the missiles probably passed through that detection range in a single sub-pulse and the NPR was therefore unable to detect them before impact.

I was likely using 5-minute turns in that screenshot. So I tested it again with 5-second turns:

Same NPR population, reloaded my save. 330x missiles fired, using 5-second increments. Right before impact, the missiles were just 38,000 km away from the planet. All 330x missiles all impacted, with no observed PD fire. The NPRs out-tech me by a fair bit, so I'd expect them to intercept at least some of my missiles. My missiles only travel 43,000 km/sec.

I was under the impression that final fire PD was always supposed to have a chance to fire in C#.

(https://i.imgur.com/h4lz8cy.png)
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 27, 2021, 04:42:42 AM
Planetary Invasions definitely broken!

The function number; 1.13.0
The complete error text; n/a
The window affected; Events
What you were doing at the time;Ground Combat
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; Ground Combat constant
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 37 years

Reported earlier
Potential bug 1: An alien race tried to set up shop on my colony cost 0 colony. I set to hostile and appeared to destroy the interlopers. But I am still getting Ground Intelligence Report  Estimated Hostile Force (Error Range: 7%) Estimated Hostile Force: Unknown Unit Types: 211. but my ground forces will no longer engage the enemy. There is no separate colony that I have conquered so what is going on?

New problem
Potential bug 2: Invaded Tau Ceti - A I. After three years of combat I get the following report "Estimated Hostile Force (Error Range: 1%) Estimated Hostile Force: Infantry 1" All ground combat has stopped and I am unable to conquer the enemy colony, even though I have 40 battalions of ultra heavy vehicles and 10 battalions of heavy tanks all set to Forward Attack. Very frustrating!

I have seen the following error during the invasion but not towards the end of the ground combat.
"1:13:0 Function #2714. Object reference not set to the instance of an object"

Further to planetary invasions the current logistics rules do not work without horrendous micro management. Need to set it up that combat units can draw from a supply dump in the rear area. I also think logistics requirements need to be considerably reduced.
The second point is on the initial landing it appears that defending units are attacking while still having the benefits of Forward Defence. This means that the initial landing forces are devastated without the same ability to counter attack the defending forces. The defending forces should loose the benefit of being dug-in while attacking. (Yes I am assuming that is what is happening. I was higher tech and loosing 200-300 vehicles every eight hours while the defenders only lost 100-150. All my units set to Forward Defence but with only 8 hours it was insufficient to dig-in.) Perhaps I misunderstand what is meant by Forward Attack and Forward Defence?
Finally eight hour combat rounds are far too frequent and a hit rate of 1.5% is far too low. I also think ground force production is still too low. In the current invasion I only had 1 million tons of forces (almost my total production in game so far) to invade with but the defenders had a visible 450,000 tons of defenders.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 27, 2021, 06:00:32 AM
Planetary Invasions definitely broken!

The function number; 1.13.0
The complete error text; n/a
The window affected; Events
What you were doing at the time;Ground Combat
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?  decimal separator
Is the bug is easy to reproduce; Ground Combat constant
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well; 37 years

Reported earlier
Potential bug 1: An alien race tried to set up shop on my colony cost 0 colony. I set to hostile and appeared to destroy the interlopers. But I am still getting Ground Intelligence Report  Estimated Hostile Force (Error Range: 7%) Estimated Hostile Force: Unknown Unit Types: 211. but my ground forces will no longer engage the enemy. There is no separate colony that I have conquered so what is going on?

New problem
Potential bug 2: Invaded Tau Ceti - A I. After three years of combat I get the following report "Estimated Hostile Force (Error Range: 1%) Estimated Hostile Force: Infantry 1" All ground combat has stopped and I am unable to conquer the enemy colony, even though I have 40 battalions of ultra heavy vehicles and 10 battalions of heavy tanks all set to Forward Attack. Very frustrating!

I have seen the following error during the invasion but not towards the end of the ground combat.
"1:13:0 Function #2714. Object reference not set to the instance of an object"

Further to planetary invasions the current logistics rules do not work without horrendous micro management. Need to set it up that combat units can draw from a supply dump in the rear area. I also think logistics requirements need to be considerably reduced.
The second point is on the initial landing it appears that defending units are attacking while still having the benefits of Forward Defence. This means that the initial landing forces are devastated without the same ability to counter attack the defending forces. The defending forces should loose the benefit of being dug-in while attacking. (Yes I am assuming that is what is happening. I was higher tech and loosing 200-300 vehicles every eight hours while the defenders only lost 100-150. All my units set to Forward Defence but with only 8 hours it was insufficient to dig-in.) Perhaps I misunderstand what is meant by Forward Attack and Forward Defence?
Finally eight hour combat rounds are far too frequent and a hit rate of 1.5% is far too low. I also think ground force production is still too low. In the current invasion I only had 1 million tons of forces (almost my total production in game so far) to invade with but the defenders had a visible 450,000 tons of defenders.

Try setting some of your ground units to "Front Attack" in the Ground Unit Window for each of those planets, and report back. That will probably solve your issues.
Title: Re: v1.13.0 Bugs Thread
Post by: serger on May 27, 2021, 06:18:13 AM
Forvard Attack units are using evasion stats, while Forvard Defence are using entrenchment (if any).
There is no difference in fire density between Attack and Defence units in current version.
Title: Re: v1.13.0 Bugs Thread
Post by: Density on May 27, 2021, 06:33:46 AM
New problem
Potential bug 2: Invaded Tau Ceti - A I. After three years of combat I get the following report "Estimated Hostile Force (Error Range: 1%) Estimated Hostile Force: Infantry 1" All ground combat has stopped and I am unable to conquer the enemy colony, even though I have 40 battalions of ultra heavy vehicles and 10 battalions of heavy tanks all set to Forward Attack. Very frustrating!

Try setting some of your ground units to "Front Attack" in the Ground Unit Window for each of those planets, and report back. That will probably solve your issues.

This is already a followup from IanD. He knows about front line attack and is using it in the cases he's reporting a potential bug 1 and 2.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 27, 2021, 10:22:16 AM
Update

Attacked a mining colony Tau Ceti-A III with two brigades of ultra heavy armour,, about 100,000 tons.

First unusual happening - Colony had STOs but did not open fire on troop transports.

Second unusual happening - This time I annihilated the garrison  - no Ground Combat Intelligence, but no conquest either.

Ian
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 27, 2021, 10:26:05 AM
Further to planetary invasions the current logistics rules do not work without horrendous micro management. Need to set it up that combat units can draw from a supply dump in the rear area.

This is already 100% possible. The trick is you must use LVH+LOG units for this to happen (representing supply trucks). INF+LOG will only resupply its own formation, the LVH type is capable of resupplying formations which are subordinate in the hierarchy. Of course, also note that the formation hierarchy must be followed as LVH+LOG can only supply subordinate formations to their own formation.

Quote
I also think logistics requirements need to be considerably reduced.

Disagree. If anything, logistics requirements in Aurora are rather low compared to those for a real army at least in terms of raw tonnage of materiel transported.

Quote
The second point is on the initial landing it appears that defending units are attacking while still having the benefits of Forward Defence. This means that the initial landing forces are devastated without the same ability to counter attack the defending forces. The defending forces should loose the benefit of being dug-in while attacking. (Yes I am assuming that is what is happening. I was higher tech and loosing 200-300 vehicles every eight hours while the defenders only lost 100-150. All my units set to Forward Defence but with only 8 hours it was insufficient to dig-in.) Perhaps I misunderstand what is meant by Forward Attack and Forward Defence?

As other commenters have alluded, both front line attack and defense positions are able to fire at the enemy without hindrance. The main difference is the use of evasion and fortification, respectively, to reduce the enemy %chance to hit. The attack position also gains the ability to conduct breakthroughs and capture the enemy colony once the ground force has been defeated.

Quote
Finally eight hour combat rounds are far too frequent and a hit rate of 1.5% is far too low. I also think ground force production is still too low. In the current invasion I only had 1 million tons of forces (almost my total production in game so far) to invade with but the defenders had a visible 450,000 tons of defenders.

Not agreed on hit rates as the pace of ground combat seems reasonable to me, however GU production is problematic as planetary invasions are quite prohibitive against alien homeworlds. This may be a case where realism and fun gameplay are divergent and should be looked at. As it stands any homeworld invasion all but forces a long bombardment period which destroys the actual colony in the process, so that conquest becomes largely pointless.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 27, 2021, 11:26:38 AM
The GU production stuff I agree on (just make it work like construction industry) but this should probably be a discussion for the suggestion thread not the bug thread.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 27, 2021, 11:59:50 AM
Further to planetary invasions the current logistics rules do not work without horrendous micro management. Need to set it up that combat units can draw from a supply dump in the rear area.

This is already 100% possible. The trick is you must use LVH+LOG units for this to happen (representing supply trucks). INF+LOG will only resupply its own formation, the LVH type is capable of resupplying formations which are subordinate in the hierarchy. Of course, also note that the formation hierarchy must be followed as LVH+LOG can only supply subordinate formations to their own formation.

Quote
I also think logistics requirements need to be considerably reduced.

Disagree. If anything, logistics requirements in Aurora are rather low compared to those for a real army at least in terms of raw tonnage of materiel transported.

I had logistics vehicles with all formations but they do not last long usually well under a year. I produced a little over a million tons of combat units in the 37 years of the game, trying to produce several thousand logistics vehicles would have been impossible. So what you are suggesting is that you require an army command unit with every thing subordinate to it? That would work. Finally 8 hour increments for 3-4 game years is boring. Have you actually tried it?
I have also had breakthroughs while the unit is in Front Line Defence.

It is a game not an accurate simulation, if you cannot conquer an alien homeworld it becomes a little pointless to bother with ground units at all. in addition the enemies ability to concentrate all its ground units in one place within 8 hours of the landing is highly improbable. Further the fight to the death is also improbable, usually they would surrender before total annihilation. Though this could be a double edged sword.

So at the moment it looks like nuking every thing from orbit is the only solution. I will give that a go as I have another war on another front!
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 27, 2021, 12:18:36 PM
I had logistics vehicles with all formations but they do not last long usually well under a year. I produced a little over a million tons of combat units in the 37 years of the game, trying to produce several thousand logistics vehicles would have been impossible. So what you are suggesting is that you require an army command unit with every thing subordinate to it?

Correct, or several army commands as having a single command for several million tons of ground troops is not practical. With this organization it also becomes much easier to resupply an invasion force over a very long time as you only need to periodically ship in a new replacement formation full of logistics vehicles to replenish the army commands.

The rest of the discussion I think needs to be branched into a suggestion thread.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 27, 2021, 01:04:20 PM
I had logistics vehicles with all formations but they do not last long usually well under a year. I produced a little over a million tons of combat units in the 37 years of the game, trying to produce several thousand logistics vehicles would have been impossible. So what you are suggesting is that you require an army command unit with every thing subordinate to it?

Correct, or several army commands as having a single command for several million tons of ground troops is not practical. With this organization it also becomes much easier to resupply an invasion force over a very long time as you only need to periodically ship in a new replacement formation full of logistics vehicles to replenish the army commands.

The rest of the discussion I think needs to be branched into a suggestion thread.

You will need a little more than a few shipments periodically. I had to supply 100 logistics vehicles every two weeks for every brigade, and I had 40 in action. That's 4000 logistics vehicles every fortnight. If I didn't it would have taken another 3-4 years at least to finish the war, not that I could in the current state of play.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 27, 2021, 04:12:21 PM
I might be using it wrong, but the contacts list in the Contacts tab on the main screen doesn't seem to be working correctly. With the "Current System Only" box checked it correctly lists several ships, but when the box is unchecked it doesn't list anything. I've tried refreshing the window with no effect. Strangely, it does seem to work if you check one of the "Lost Contacts" options, listing contacts appropriately both when "Current System Only" is checked and when it isn't.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 27, 2021, 06:54:48 PM
Jump Gates can be used instantly, over and over, with no jump delay. This has the annoying (but not game-breaking) side effect of causing a game of cat-and-mouse with an enemy fleet where you jump into an enemy gatecamp with overwhelming forces, and they decide to run by jumping through the gate, and you chase them back on the next 5-second interval but they jump back instantly to the original system, over and over (until you decide to split your forces). I've seen other players report this as well. I assume the lack of delay on jump gate usage was originally intended, but maybe not the instant back-and-forth, cat-and-mouse behavior that NPR fleets can exhibit.

You can also make multiple jumps forward and back, over and over, in the same 5-second interval. I just made 131,072 transits in a single 5-second interval, although this is probably not as important.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 27, 2021, 07:29:48 PM
Jump Gates can be used instantly, over and over, with no jump delay. This has the annoying (but not game-breaking) side effect of causing a game of cat-and-mouse with an enemy fleet where you jump into an enemy gatecamp with overwhelming forces, and they decide to run by jumping through the gate, and you chase them back on the next 5-second interval but they jump back instantly to the original system, over and over (until you decide to split your forces). I've seen other players report this as well. I assume the lack of delay on jump gate usage was originally intended, but maybe not the instant back-and-forth, cat-and-mouse behavior that NPR fleets can exhibit.

Believe it or not, this isn't a bug, but rather is a mechanical concession to the NPRs to make up for their poor AI. it is, however, extremely irritating and frequently the cause of increment slowdowns and interrupts.

Quote
You can also make multiple jumps forward and back, over and over, in the same 5-second interval. I just made 131,072 transits in a single 5-second interval, although this is probably not as important.

This one...might be a bug? I'm not sure. I thought jump gates were subject to the same jump shock effects as any other jump point, except for the NPR exception.
Title: Re: v1.13.0 Bugs Thread
Post by: Density on May 28, 2021, 01:44:15 AM
You can also make multiple jumps forward and back, over and over, in the same 5-second interval. I just made 131,072 transits in a single 5-second interval, although this is probably not as important.

This one...might be a bug? I'm not sure. I thought jump gates were subject to the same jump shock effects as any other jump point, except for the NPR exception.

Still not a bug. Jumping through a stabilized jump point causes jump shock. But shock doesn't prevent jumping, it briefly prevents sensors and jump engines from working. But the jump point is still there, and still stabilized, and it itself didn't jump. The same situation also wouldn't be a bug if a ship were jumped back and forth by another ship that wasn't itself jumping (i.e. a jump tender).
It would be a bug if say, a ship with a jump engine made a standard transit through a stabilized/tended jump point and immediately made a squadron transit back through the same jump point. But that isn't the case here.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on May 28, 2021, 05:38:59 AM
Planetary Invasion Update 2

A nuclear strike destroyed the last remaining solder, after that the normal surrender mechanics ensued.

Is this a similar problem to that seen in VB versions when units in bases could only loose half of their strength ad infinitum? But instead of leaving a fraction the value could not go below 1? Probably rubbish,

Also noticed that Shipyards were 2/-12. This is probably because once you have destroyed the actual shipyards you are able to continue firing on them without any shipyards present. SM function can resolve this.
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on May 28, 2021, 11:32:18 AM
Planetary Invasion Update 2

A nuclear strike destroyed the last remaining solder, after that the normal surrender mechanics ensued.

Is this a similar problem to that seen in VB versions when units in bases could only loose half of their strength ad infinitum? But instead of leaving a fraction the value could not go below 1? Probably rubbish,

Also noticed that Shipyards were 2/-12. This is probably because once you have destroyed the actual shipyards you are able to continue firing on them without any shipyards present. SM function can resolve this.
Yeah both are known issues, reported before. I think Steve fixed the shipyard one already but I'm not 100% sure.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 29, 2021, 09:16:51 AM

"Earth" and "Luna" reappear after they have been destroyed due to the disaster.

(https://i.imgur.com/cSp6DMs.png)

Steps to reproduce:

1) Let Earth be destroyed by the disaster (download attached save file, and skip time forward 30 days)
2) Save game
3) Close game
4) Reopen game, and zoom in on the sun to see Sol-A III and its moon suddenly in close orbit around the sun.
5) Sol III will be destroyed in a couple months again if you leave the disaster enabled. If you disable the disaster, Sol III will survive forever close to the sun.


I just wanted to touch base on this bug again, since I didn't see it fixed on the changelog or in the thread. Earth and Luna reappear after destruction when you save, close, and then reopen the game.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 29, 2021, 10:49:35 AM
I just wanted to touch base on this bug again, since I didn't see it fixed on the changelog or in the thread. Earth and Luna reappear after destruction when you save, close, and then reopen the game.

It is fixed and it is in the change log from a while ago.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on May 29, 2021, 12:40:03 PM
I just wanted to touch base on this bug again, since I didn't see it fixed on the changelog or in the thread. Earth and Luna reappear after destruction when you save, close, and then reopen the game.

It is fixed and it is in the change log from a while ago.

I don't think it's on the changelog. The only related entry I can find is for a different bug:   "Fixed #1552 Object Not Found error by ending Death Spiral scenario once Earth crashes into the Sun. Workaround is to manually turn this off."

I just wanted to make sure that one hadn't slipped through the cracks.
Title: Re: v1.13.0 Bugs Thread
Post by: Black on May 29, 2021, 02:55:12 PM
Select Alien Class Hull window (Intelligence and Foreign Relations - Set Class Hull) has checkbox with following text: Set all Formations with Same Template at Same Population.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on May 29, 2021, 06:37:48 PM
Related question: How do you set the distance at which missile second stages will separate? I set the separation range to 1700k km but they seem to be separating at about twice that, roughly 3400k km.

What is the range of the 1st stage? Does it happen to be roughly 3400k km?

As an aside, I do wish that there would be a way to set the separation range based on distance to target since contacts might be moving towards (separates too late) or away (separates too early) from the missile.

No, the first stage is long-range, around 150m km. The second stage has a range of around 2m km. I tested setting the separation range down to 1m km, and now they're separating at around 2m km. (I'm testing this in SM mode.) I can't tell if this is a bug or if I'm just doing this wrong -- I haven't used missiles in C# yet, and I barely used them in the old VB version.

EDIT: To clarify, they're separating at 2m km from the target.

Try keeping the sep range 1m km, but now make the second stage have a range of 4M km. I want to see if for some reason there's a bug where the separation range is being multiplied by the second stage range.

It seems that when targeted at waypoints the separation distance works correctly, which makes me suspect there's a bug here -- although I haven't seen any bug reports to that effect. Have other people seen something like this? I'd previously been using the friendly neighborhood spoiler race as target practice, but their habit of shooting down my missiles and my ships is making testing difficult. I'm going to make a more cooperative race to test this on.

I think I've figured out what's going on. It turns out that what's happening is that the missile, when deciding when to release the second stage, is taking into account the motion of the ship being targeted; so if the target is moving away the second stage will appear to be released late, while if the target is moving towards the missile the second stage will appear to be released early. So far so good. However, if the target is following something stationary, then it may be moving back and forth even if it appears stationary, which can cause the second stage to be released early or late. Not sure whether this should be classed as a bug or not. The second issue, though, is definitely a bug: as far as I can tell, the first stage uses its own speed, rather than the speed of the second stage, when calculating when to release the second stage. Thus the relatively small correction needed for the fast second stage to catch up to an enemy ship becomes a much larger correction for the slow first stage to catch up.

Since at least one of these issues seems to be a genuine bug, I'm going to post this in the bugs thread.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 30, 2021, 07:24:02 PM
An NPR generated when I was playing on 260% difficulty 80 years in.

I get that the size of NPR populations is dependent on the above factors in order to give some sort of challenge.
But what just happened is that the game spawned 30bn aliens on a world that can only accommodate 8bn population (they have 100% population density).

I think what should happen is either:
- Game respects the carrying capacity of the body
- Game creates designs of colossal orbital habitats in such a way that the carrying capacity + orbital capacity is sufficient to house the population.


EDIT: I should also mention this world had dangerous levels of CO2 as well which I had to SM replace with aesthesium.
EDIT: For the problem I pointed out in the edit, the game should, once it's decided that the planet in question will have an NPR, modify the body to actually have 0 cost for whatever alien it's decided to put there.

SJW: Max pop for NPR will now be the capacity of the planet. Also fixed dangerous gas problem.
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 30, 2021, 09:43:40 PM
After a long drawn-out battle with lots of ship captures that left an alien planet cleared of space-defenses but left with STO and ground units, I seem to be stuck in 5-second increments because "increment adjusted due to combat or open fire controls with no targets." I see no warnings about any of my ships having fire controls open, and I opened the database and checked FCT_GameLog but I see no logs for other races in combat, just repeating lines of "increment adjusted" logs since I turned on auto turns and let the game go through a long set of 1 day increments auto-adjusted down to 5 seconds. Typically I would have expected to see the NPR still trying to fire or other NPRs still in combat in these logs as the source of the issue.

Some of the captured ships are still very slow due to damaged engines and a skeleton crew of marines, maybe the STO units on the planet detect the ships and are out of range but still trying to fire, and this isn't generating game logs but causing the five second increments? Not sure what to check.

EDIT: Ok it was apparently one of my fleets, I went through all the fleets for ships I captured as well as the main battle fleet and hit "Cease Fire Fleet," and I can now increment time normally.

EDIT #2: Also have a large number of Missile Salvos listed as Contacts in Fleet Orders, but trying to move the fleet to any of them says "Destination cannot be found."
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 31, 2021, 08:54:55 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on May 31, 2021, 10:27:40 AM
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.

As a workaround, try SM repairing the ship and turning off the now repaired FC. Should hopefully get the game going again.
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on May 31, 2021, 11:57:53 AM
That bug happened before and was fixed once already. Very curious why it has made a comeback!
Title: Re: v1.13.0 Bugs Thread
Post by: ChubbyPitbull on May 31, 2021, 12:53:27 PM
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.

As a workaround, try SM repairing the ship and turning off the now repaired FC. Should hopefully get the game going again.

Yessir, that fixed it! SM Repaiting it brought up the final Fire Control which appeared in Orange "Open Fire" state. Once I ordered it to cease fire, game resumed advancing time normally.
Title: Re: v1.13.0 Bugs Thread
Post by: Black on May 31, 2021, 01:49:31 PM
It seems that unloading installations from ships is still somewhat bugged. This is cargo that is loaded on 10 cargo ships with total capacity of 500000 (each ship has 50000 capacity):

(https://i.ibb.co/FhkmxGz/cargo01.png) (https://imgbb.com/)

After I gave command to unload all installations and after I received confirmation that order is finished, this is what remains in cargo holds:

(https://i.ibb.co/Gtyg7w6/cargo02.png) (https://imgbb.com/)

So for some reason, not all installations were unloaded.

SJW: Fixed for v1.14. It is only affecting fleets where ships can carry more than one installation each.
Title: Re: v1.13.0 Bugs Thread
Post by: davidr on June 01, 2021, 01:56:17 PM
Error 1168

Attached is my current Save game where I have the Pop-up error "Function #1168 : the given key was not present in the dictionary."


Running Medals mod and the BlueGeGone Mod ( black background ) due to fuzzy text using the standard blue background ( my failing eyesight).

DavidR
Title: Re: v1.13.0 Bugs Thread
Post by: Drakale on June 01, 2021, 03:22:00 PM
It seems that unloading installations from ships is still somewhat bugged.

I have the same issue popping upsometimes, seem like it happen mostly with multiple types of cargo being unloaded. I took the habit of queuing multiple unload command in the meantime, it seem to fix the issue.
Title: Re: v1.13.0 Bugs Thread
Post by: davidr on June 02, 2021, 05:03:35 AM
I don't know if this is a follow on from my Function #1168 error but i have requested the Civilian Economy to load Construction Factories from Earth and transport them to one of my colonies . However I am getting messages that various Civilian line ships are unable to load Construction Factories on Earth.
On looking at some of the Cargo ships mentioned it seems that the ships are already carrying cargo yet are attempting to load the Construction Factory and failing.

What can I do about this ?

My save game DB is attached.

DavidR   
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on June 02, 2021, 05:52:18 AM
Unmodified 1.13.0

Seeing the following error messages while invading enemy colonies.

1.13.0 Function #1793. Attempt to divide by zero.

Edit
Second error message

1.13.0 Function #840 The given key was not present in the dictionary

SJW: This is the error caused by a breakthrough by a formation with no units. Already fixed for v1.14.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 02, 2021, 09:09:44 AM
The MSP provided by engineering spaces seems to depend unpredictably on the other components in the ship. With nothing but a fighter engineering space my ship has 8 MSP. After adding an engine, fuel, and small thermal and EM sensors it goes down to 7 MSP; adding an active sensor brings it up to 10 MSP. But this varies considerably depending on which components I add. This doesn't seem to depend on the Max Repair value, which is 16 with all components added -- and this couldn't explain the MSP going down with added components. It also doesn't seem to depend on deployment time. This seems like a bug, unless there's some mechanic here that I'm unfamiliar with?
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on June 02, 2021, 10:06:00 AM
The MSP provided by engineering spaces seems to depend unpredictably on the other components in the ship. With nothing but a fighter engineering space my ship has 8 MSP. After adding an engine, fuel, and small thermal and EM sensors it goes down to 7 MSP; adding an active sensor brings it up to 10 MSP. But this varies considerably depending on which components I add. This doesn't seem to depend on the Max Repair value, which is 16 with all components added -- and this couldn't explain the MSP going down with added components. It also doesn't seem to depend on deployment time. This seems like a bug, unless there's some mechanic here that I'm unfamiliar with?

The MSP from engineering spaces is not simple to determine as described by Steve here (http://aurora2.pentarch.org/index.php?topic=11056.msg127449#msg127449).
Title: Re: v1.13.0 Bugs Thread
Post by: Black on June 02, 2021, 01:17:56 PM
Minor issue only. I have replacement formation that has only my engineering vehicles and no HQ element. Formation is set as Use For Replacement. Autoassignment assigned commander to this formation, I believe that should not happen for formations that are set as replacement.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on June 02, 2021, 01:38:18 PM
Minor issue only. I have replacement formation that has only my engineering vehicles and no HQ element. Formation is set as Use For Replacement. Autoassignment assigned commander to this formation, I believe that should not happen for formations that are set as replacement.

Not a bug, but a good suggestion nonetheless.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 02, 2021, 01:38:55 PM
The MSP provided by engineering spaces seems to depend unpredictably on the other components in the ship. With nothing but a fighter engineering space my ship has 8 MSP. After adding an engine, fuel, and small thermal and EM sensors it goes down to 7 MSP; adding an active sensor brings it up to 10 MSP. But this varies considerably depending on which components I add. This doesn't seem to depend on the Max Repair value, which is 16 with all components added -- and this couldn't explain the MSP going down with added components. It also doesn't seem to depend on deployment time. This seems like a bug, unless there's some mechanic here that I'm unfamiliar with?

The MSP from engineering spaces is not simple to determine as described by Steve here (http://aurora2.pentarch.org/index.php?topic=11056.msg127449#msg127449).

"Give the number of 'bug' reports concerning the interaction of engineering and maintenance storage..." -- well now I feel silly! Thanks for pointing this out.
Title: Re: v1.13.0 Bugs Thread
Post by: Black on June 02, 2021, 02:20:03 PM
I encountered small issue while spawning super jovian with trojan asteroids. It spawned with two asteroids and both have same name - Asteroid #0. I checked other systems and none of the other asteroids have this name. I play with real stars.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 06, 2021, 08:32:18 PM
I'm not sure if these have been reported previously but there seem to be quite a few issues with the ship contact system. For instance, in my game an enemy fleet that was last seen in Sol just showed up in a different system where I have tracking stations; the events I got listed hostile ship contacts in Sol, not the actual system they were spotted in. Needless to say, this is very confusing. I've also noticed that if an enemy fleet you had previously encountered transits to a new system, the lost contacts are placed in a seemingly random location in the new system regardless of whether or not you have any sensor coverage there. This is kind of nice because it lets you track when an enemy fleet leaves or enters a system without having sensor contact, but this is clearly unintentional.
Title: Re: v1.13.0 Bugs Thread
Post by: themousemaster on June 07, 2021, 02:29:58 AM
The function number: 1951, 1943, 478
The complete error text An item with the same key has already been added Object reference not set to an instance of an object
The window affected main screen
What you were doing at the time Finishing a battle at the NPR homeworld (though there was some NPR-NPR fighting somewhere else in the galaxy just before the error)
Conventional or TN start TN
Random or Real Stars Real
Is your decimal separator a comma? No. US Layout
Is the bug is easy to reproduce, intermittent or a one-off? Second time it happened, but since I suspect it's NPR related, I don't think I can reproduce on command.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well 65 years into a game.

The only other "unusual" thing happening is I have some ships massively overloaded with survivors I picked up from destroying the NPRs commercial shipping.

I am facing the same situation now. 

I was not involved in a fight, nor am carrying survivors.  Also, the only NPR in the game was shot back to the stone age a century ago, and has only just been able to build ships again a couple years back.

I was just advancing time hoping my next Sensor tech would finish before another round of Spoilers spawned.

After watching it for dozens of 1-day increments, these 3 errors popped up.  Now, any attempt at advancing time causes me to have to click through these 3 errors ~50 times apiece.

(I'm about 250years into the game)
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on June 07, 2021, 10:44:49 AM
...I've also noticed that if an enemy fleet you had previously encountered transits to a new system, the lost contacts are placed in a seemingly random location in the new system regardless of whether or not you have any sensor coverage there. ...

I've noticed this before, and I think that the displayed location of the contact in the new system has the same bearing and distance (relative to the system center) as the contact location in the previous system of contact.
Title: Re: v1.13.0 Bugs Thread
Post by: TMaekler on June 08, 2021, 05:16:49 AM
Mineral packets arriving at a planet which has no mass drivers do not cause any explosive side-effects. They just disappear when they reach the target body.

SJW: Working as Intended. I changed this to avoid the regular new player problem of destroying their own colonies by accident :)
Could Steve add a game option where you can choose between both behaviours? I want to be able to "Expanse the Earth" ;-)
Title: Re: v1.13.0 Bugs Thread
Post by: Stryker on June 09, 2021, 06:07:23 PM
When loading a saved game, sub-fleets attached to sub-fleets are detached from the parent sub-fleet , and reattached to the parent fleet.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 10, 2021, 01:24:52 PM
There seem to be some issues with the Use Maximum Speed option.   Sometimes if a fleet does not have Use Maximum Speed checked and a ship in that fleet is destroyed the fleet's speed will be set to 1 km/s.   Other times when a ship is destroyed it's set to the actual maximum speed of the fleet, even if it had been manually set lower.   (EDIT: It turns out this can happen both with and without the Use Maximum Speed box checked, so this might be a more general issue with ship detachment or destruction, rather than with the Use Maximum Speed option as I thought at first. )

A possibly related issue is that I've occasionally had ships that lose their engines fail to automatically detach from their fleets -- although other times they've detached properly, and I've had this happen regardless of the maximum speed setting, so I'm not sure what's going on here.

Since this doesn't seem to have been addressed, I just want to confirm that there's definitely some issue with the automatic detachment code for damages ships, as I've observed this happen to NPRs as well: fleets of NPR ships sometimes slow to 1 km/s and stay at that speed after some ships in the fleet sustain damage. On the other hand, sometimes ships do seem to detach properly, so I'm not sure what's going on.
Title: Re: v1.13.0 Bugs Thread
Post by: Black on June 10, 2021, 01:38:46 PM

Since this doesn't seem to have been addressed, I just want to confirm that there's definitely some issue with the automatic detachment code for damages ships, as I've observed this happen to NPRs as well: fleets of NPR ships sometimes slow to 1 km/s and stay at that speed after some ships in the fleet sustain damage. On the other hand, sometimes ships do seem to detach properly, so I'm not sure what's going on.

That explains my last encounter with Space Swarm. I killed/crippled few of them and rest of the fleet stopped moving until there were no cripples left.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 10, 2021, 02:08:23 PM
If a target is in range but the chance of hitting it is zero, your ships will hold fire. However, they still seem to experience maintenance failures as if they were firing.
Title: Re: v1.13.0 Bugs Thread
Post by: kyonkundenwa on June 10, 2021, 03:02:45 PM
Bug Report: fractional capacitor recharge rates are not respected in High Power Microwave designs.
To reproduce: Start a new game, research capacitor recharge rate 2, and design a High Power Microwave with a fractional recharge rate. Recharge rate, cost, and rate of fire will be shown as though you selected recharge rate 1 for all recharge rate values between 1 and 2.

I didn't see any other reports on this, probably because nobody uses HPMs. Fractional capacitor recharge rates work as expected for all other weapons.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on June 10, 2021, 03:28:37 PM
Bug Report: fractional capacitor recharge rates are not respected in High Power Microwave designs.
To reproduce: Start a new game, research capacitor recharge rate 2, and design a High Power Microwave with a fractional recharge rate. Recharge rate, cost, and rate of fire will be shown as though you selected recharge rate 1 for all recharge rate values between 1 and 2.

I didn't see any other reports on this, probably because nobody uses HPMs. Fractional capacitor recharge rates work as expected for all other weapons.

I can confirm this. It is not a display bug on the component design screen, as the power requirement in the class design window also does not reflect the fractional recharge rate.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on June 11, 2021, 05:17:05 AM
(https://cdn.discordapp.com/attachments/837880336536698893/852848847411871784/Aurora_v1.13_PrototypeDisplayBug.jpg)

 --- A interesting one to be sure. At first I thought it to be a bug in the display... however, upon closer inspection it turns out that isn't the case. These components are completely wrong. You might be thinking, "What the heck am I supposed to be looking at, here?" and that's a fabulous question. This image was taken at the moment of the bug, and it turns out that in the "Class Design" Window you can open multiple instances of the "Create Research Project" Window, unlike when opened from the Main System Map. When opened from the main screen, only one instance of the "Create Research Project" Window can be opened at a time. Re-clicking the button simply brings up the instance. So, with three instances open simultaneously, it turns out that my Missile Launcher was Prototyped as a Missile FCS, while my Magazine was turned into a Missile Launcher. I was going to report having three "Create Research Project" Windows open at the same time as a bug because I'm like 99.9% sure that this was fixed in a prior version... 1.10~ or something like that. P.S. Sorry for the gigantic picture, I'm not 100% how to resize them. :(

The function number - Not Applicable
The complete error text - Not Applicable
The window affected - Class Design & Create Research Project Windows
What you were doing at the time - Designing a Fighter-Sized Survey Ship, with three instances of the "Create Research Project" Window open at the same time.
Conventional or TN start - Trans-Newtonian (TN)
Random or Real Stars - Random
Is your decimal separator a comma? - Oops. My HDD got wiped because Dell is ass... my decimal separator is back to the standard comma.
Is the bug is easy to reproduce, intermittent or a one-off? - Unknown.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on June 11, 2021, 08:13:36 AM

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.

Can you confirm you are using version 1.13 as the fix is already in the code?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on June 11, 2021, 08:18:45 AM
Error 1168

Attached is my current Save game where I have the Pop-up error "Function #1168 : the given key was not present in the dictionary."


Running Medals mod and the BlueGeGone Mod ( black background ) due to fuzzy text using the standard blue background ( my failing eyesight).

DavidR

The error is in load movement orders. Do you have any fleets that have a destination that no longer exists, such as a population, jump point or system?

Pops should already be covered as deleting a population will remove any associated movement orders. Have you modified or deleted any systems?
Title: Re: v1.13.0 Bugs Thread
Post by: davidr on June 12, 2021, 03:33:29 AM
Steve - re your query re my 1168 error message.

As far as I know there are no destinations that no longer exist /removed etc

The only changes I make are to renaming the systems in alphabetical order on discovery by a Survey vessel and before any colonies exist. I requested the AI Civilian transports to collect 20 construction Factories from Earth to be transported to Cathcart-A IV where I have a colony of 15.98m.

It appears that the AI freighters are carrying trade goods yet are wanting to collect my Factories. I have not deleted or amended any of the destinations to where the trade items could be going.

No jump points have been deleted - jump points have been stabilised to every system where I have a colony population.

I don't know why I have the 1168 error.

DavidR


 Steve - Please note my Post 394 in this Bugs thread for a more updated post re my 1168 error together with the related save game position.
Title: Re: v1.13.0 Bugs Thread
Post by: Jeltz on June 12, 2021, 02:35:18 PM
As suggested, linked here (http://aurora2.pentarch.org/index.php?topic=12610.msg152675#msg152675), maybe not only a cosmetic issue
Title: Re: v1.13.0 Bugs Thread
Post by: ty55101 on June 14, 2021, 01:29:34 AM
In the fleet view the "Ship Design Display" doesn't update for at least the crew after crew casualties (such as after a failed boarding attempt).

If it isn't fixed, it would be nice for the text box with the ship information to be taken out and only the "Class Design Display" to remain with that info to reduce confusion.
Title: Re: v1.13.0 Bugs Thread
Post by: Ancalagon on June 15, 2021, 02:00:53 PM
I looked at the "Alien Race" table in the DB to watch diplomacy progress with a new NPR that shot at me, and I have not noticed diplomatic relations trending back to non-war while our races are not in mutual detection range of each other.

This prevents the scenario referenced in the C# Diplomacy Changes, where a race shoots at another's survey ship, but as long as you avoid contact, relations trend back to non-war. Instead, they are remaining static according to the DB, across many construction periods.

Once I put a fleet back in mutual detection range, relations started trending back to normal. This is obviously going to be a problem if they keep trying to shoot at every ship I try to bring in diplomatic sensor range. Perhaps relations should continue trending towards baseline, regardless of whether you are in mutual detection?

The situation you describe should happen when there is contact (including populations) but no diplomacy module present or a diplomacy ship without an appropriate ccommander or when communications have not been established. Are you sure none of those is applicable in this context?

I just want to touch base on this once more. According to the C# Diplomacy Changes, do I understand correctly that relations should trend back to neutral even if both 1) communications are not established, and 2) neither race has sensor contacts with each other? Because that did not happen in my report above. Instead, relations stayed frozen at hostile while we were in mutual non-contact with each other, instead of trending back to neutral.

Here's the C# Diplomacy Changelog excerpt I'm referencing for this behavior being a bug:

Quote
If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point. However a period of mutual non-interaction following a small clash will probably return the diplomatic status to neutral. For example, if communications are established you may ask a survey ship to leave your system (mechanics in a future post). If that didn't work or you did not have communication, you can slightly damage that ship. An unarmed ship would retreat from hostile aliens and the immediate impact would be the alien race treating you as hostile. However, with no further combat in the short term, the status would soon return to a wary neutrality. Future communication and diplomacy would still be an option.
Title: Re: v1.13.0 Bugs Thread
Post by: Jaz010 on June 15, 2021, 03:57:29 PM
Seems there is a bug in downloading tech,
I fought some precursors, after salvaging their ships I gained 7,000 point of tech in Laminate composite armor.  ( which is currently being researched on earth with 2,000 points or so remaining) . 
on the way to sol, the fleet passes by a system that is controlled by me and contains research lab ( the system is specialized in sensor fire control research) . 
once it transits i get the message tech downloaded in the said system. 

I cancel the research in earth to start it again in the said system and I see that the research cost has increased by 10,000.

I have a copy of the db if needed. 


Title: Re: v1.13.0 Bugs Thread
Post by: Density on June 15, 2021, 07:18:44 PM
I fought some precursors, after salvaging their ships I gained 7,000 point of tech in Laminate composite armor.  ( which is currently being researched on earth with 2,000 points or so remaining) . 
on the way to sol, the fleet passes by a system that is controlled by me and contains research lab ( the system is specialized in sensor fire control research) . 
once it transits i get the message tech downloaded in the said system. 

Did the ship have "Retain Tech Data" checked? This box can be found in the naval org screen, on the misc tab when the ship (not the fleet) is selected. If it was, this is a bug. If not, not.

I cancel the research in earth to start it again in the said system and I see that the research cost has increased by 10,000.

To the best of my knowledge, Aurora doesn't handle concurrent tech progress from multiple locations. (If it did, the checkbox I mentioned above wouldn't be needed.) If you restart the project on earth, is the research cost 2k or 13k?
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on June 16, 2021, 11:29:51 AM
I play Aurora with three monitors.
Two are side by side (one of which is my primary monitor), the third is above the other two.
All three are 1920x1080.
(I also have a fourth monitor off to the side, but I never put Aurora windows on it.)

When I open a game window (Fleet, Econ, etc.), the window opens on whichever monitor I last closed that type of window, in the same position it was in when I closed it.

At least, it tries to.
For the side-by-side monitors, it works fine.
But when the game tries to open a window on the third monitor (the one above the other two), the window appears at the very top of the monitor below.
Perhaps this happens because the y-coordinate for the window is negative (being above the top of my primary monitor), and the game just changes it to zero?

This is a minor annoyance over time, since I have to reposition such a window every time it happens.
Probably not worth a major time investment, but if it's an easy thing to fix in the code, that fix sure would be welcome.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 16, 2021, 09:42:33 PM
I'm getting occasional "Function 2824: Attempted to divide by zero" errors after boarding and capturing Swarm ships. I think it triggers each construction cycle. So far it hasn't seemed to cause any problems, though.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 17, 2021, 10:19:54 PM
Ran into another bug with boarding. This is a very niche situation, but in my game I boarded an enemy ship right before it transited into an unexplored system. This seems to have greatly confused the game. When they captured the ship in the still-unexplored system, I got a bunch of errors (including some that triggered each time I tried to scroll to zoom in or out), which persisted when I used SM mode to explore the system. Saving, closing, and reopening the game has stopped the errors, but the ships I captured appear to have vanished.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on June 17, 2021, 10:45:29 PM
I'm getting occasional "Function 2824: Attempted to divide by zero" errors after boarding and capturing Swarm ships. I think it triggers each construction cycle. So far it hasn't seemed to cause any problems, though.

Have you lost any men?

Usually this happens in ground combat when a formation is left empty and before it gets cancelled you get the attempted to divide by zero issue.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 17, 2021, 11:17:40 PM
I'm getting occasional "Function 2824: Attempted to divide by zero" errors after boarding and capturing Swarm ships. I think it triggers each construction cycle. So far it hasn't seemed to cause any problems, though.

Have you lost any men?

Usually this happens in ground combat when a formation is left empty and before it gets cancelled you get the attempted to divide by zero issue.

No, but it likely has a similar cause, since the ships had no crew to defend them. Maybe the game is making an empty crew formation and getting confused?
Title: Re: v1.13.0 Bugs Thread
Post by: FjordBjorn on June 18, 2021, 11:06:19 AM
I am getting Function error #2423 for each production cycle I run
TN start and 38 years into game
Title: Re: v1.13.0 Bugs Thread
Post by: davidr on June 18, 2021, 11:12:28 AM
Just got the following sequence of 1.13.0 Function errors  2608 , 222 , 224 , 2339 , all stating "object reference not set to an instance of an object".

I had to make quite a number of mouse clicks before the errors disappeared and the game seemed to begin processing orders once more.

Any thoughts on the reason for these errors ?

Are they terminal ?


DavidR
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 20, 2021, 10:29:16 AM
When events are hidden on the tactical window it is still possible to click on them, which may move the tactical window to the associated system.

SJW: Fixed for v1.14
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 22, 2021, 12:07:11 PM
Here's a really strange one. In the class design window, if you first rename a component, open the Select Name window, then close the window using the X button at the top of the window (the Cancel button seems to work normally), it will rename the ship class to the last component you named.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on June 22, 2021, 12:51:20 PM
Here's a really strange one. In the class design window, if you first rename a component, open the Select Name window, then close the window using the X button at the top of the window (the Cancel button seems to work normally), it will rename the ship class to the last component you named.

Can confirm this seems to happen with a few different kinds of Rename X windows.
Title: Re: v1.13.0 Bugs Thread
Post by: blh42 on June 23, 2021, 06:22:08 AM
1. 13. 0 Function #755 Object reference not set to an instance of an object.
Happened as time progressed.  Attaching a save game from just a few days prior.  No player interractions should have occurred after the save game.

Title: Re: v1.13.0 Bugs Thread
Post by: ZimRathbone on June 23, 2021, 09:00:46 PM
Issue with auto-resupply for supply ships. (1.13)

As an experiment in my fleet standard I am now putting a fleet train as a subfleet to my main fleets, usually consisting of a tanker, collier, supply ship and hospital ship.  The purpose is to cut down on the micro involved with particularly the training squadron so that all regular units are kept to full capacity in fuel and MSP, and I can use conditionals to make sure that the tanker and supply ship replenish themselves when they get below 20%. It should mean that I only need to worry about brigning individual ships in when either they exceed deployment or complete training, and as long as I design the classes with sufficient on board maintenance I don't need to worry about individual component failures Its a bit more involved when the fleet is out on maneuvers rather than orbiting a base planet but still helpful.

I set the support units up to auto refuel/load ammo/resupply their own fleet as appropriate.

The tankers appear to work correctly, refueling the rest of the fleet as it goes, but the supply ships don't retain the auto resupply status, reverting to "no auto resupply" on a regular basis, This is whether the supply ship is in the subfleet or the main fleet.  If you enable auto supply again and there are some units that are not at maximum MSP then they will be replenished, but it will revert again shortly after.  I have not seen anything with the colliers but have had no ammunition expenditures by fleets with support available (all major combat has been beam only so far).

update: just had a small encounter which used missiles and the attached ammunition colliers also worked as expected so the issue is only with supply ships.
Title: Re: v1.13.0 Bugs Thread
Post by: Blogaugis on June 25, 2021, 02:33:23 PM
Is this intentional, that you can assign ground force officers to formations with no HQ unit?
Title: Re: v1.13.0 Bugs Thread
Post by: Demetrious on June 25, 2021, 05:46:57 PM
Issue with auto-resupply for supply ships. (1.13)

I have also experienced this. The auto-refuel drop-down box setting, however, works properly.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 25, 2021, 07:33:08 PM
The Transported Items tab in the Ship Overview screen of the fleets window is somewhat buggy. For some reason all the ordnance quantities are doubled. (They're displayed correctly in the Ordnance Template tab.) Also, if you select a parasite craft the display claims that it is carrying two of itself as parasites.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on June 27, 2021, 01:27:25 PM
I'm getting a number of different error messages at various points. I'm not sure if they're related or if they're separate issues. The only unusual thing that I can remember happening before these started is that five NPR (non-spoiler) ships surrendered to me at once, and then one of my ships destroyed one of the ships that had surrendered as it had been set to fire before they surrendered. But I don't know if that actually has anything to do with the errors.

The errors are as follows (all "Object reference..." errors):

I'm not sure what I did that led to all these errors. So far nothing has been game-breaking, but I'm not very optimistic about this campaign lasting very long if these errors continue.  :(
Title: Re: v1.13.0 Bugs Thread
Post by: Fray on June 27, 2021, 01:35:31 PM
The function number: None
The complete error text: No error
The window affected: n/a
What you were doing at the time: Boarding a ship
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent or a one-off? Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: Short campaign

Let's say that a ship has had all of its fuel storage damaged, but its engines are ok. Without fuel a ship still technically has normal speed, it just can't execute any move orders it has.

Now let's say you try to board such a ship. Even though it's stationary, the boarding roll still uses the fake "speed" of the target ship, and the boarders get clobbered. The workaround is to access the target ship (requiring a DB edit if the target ship belongs to an NPR) and manually set its fleet speed to zero.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on June 28, 2021, 04:00:38 AM
 - So, uh... Fighter-Sized Colony Ships still can't unload colonists without a cargo shuttle station / starport. Longstanding bug, still present in v1.13; I saw it reported somewhere prior for v1.13, but figured I'd confirm it on my game as well. Would really like this one fixed.
Title: Re: v1.13.0 Bugs Thread
Post by: db48x on June 28, 2021, 05:44:48 AM
If you use the "Launch Ready Ordnance" command, the mines erroneously disappear immediately (you don't even see them appear on the map even after a 5-second interval) unless a target is already within range, making them unusable as a long-term static defense.

I have found a bug that would fit the behaviour described. I'm surprised this hasn't come up before, but fixed now.

Thank you Steve for fixing this bug!

I do feel compelled to point out that it’s been reported several times, and the workaround has been known for a while as well. I even know of a Youtube series where the author was using mines, and specifically stated that the targeting was broken in the Aurora version he was using, so he would be employing the manual workaround.

And thank you Ancalagon for producing a clear and simple explanation of the bug.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on June 28, 2021, 02:48:26 PM
The Transported Items tab in the Ship Overview screen of the fleets window is somewhat buggy. For some reason all the ordnance quantities are doubled. (They're displayed correctly in the Ordnance Template tab.) Also, if you select a parasite craft the display claims that it is carrying two of itself as parasites.

 --- With regards to the fighter bug, the fighters in question showed 400 Colonists in their transport holds, despite having only 200 space. The order to "Load Colonists" was given without specifying a maximum.
Title: Re: v1.13.0 Bugs Thread
Post by: Norm49 on June 28, 2021, 11:50:41 PM
When a tanker ship transfer fuel to a station with a refuelling hub the tanker can end up with is fuel tank in the negative. I not sure I can reproduce this incident. I took a picture.

(https://zupimages.net/up/21/26/6esx.png) (https://zupimages.net/viewer.php?id=21/26/6esx.png)
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on June 29, 2021, 05:04:19 AM
If you refit a ship and replace Beam Fire Directors while weapons are still assigned to the old fire controls all the weapons dissapear from the ship combat display. Fortunatly if you auto assign BFC then the weapons are found
Title: Re: v1.13.0 Bugs Thread
Post by: Bremen on July 02, 2021, 02:47:10 PM
Just got the following sequence of 1.13.0 Function errors  2608 , 222 , 224 , 2339 , all stating "object reference not set to an instance of an object".

I had to make quite a number of mouse clicks before the errors disappeared and the game seemed to begin processing orders once more.

Any thoughts on the reason for these errors ?

Are they terminal ?


DavidR

Conventional start, real stars, decimal separator = period, Another New system Discovered

I received these errors on advancing time:
Function #2608: object reference not set
Function #222: object reference not set
Function #224: object reference not set
Function #2339: object reference not set

These 4 errors repeated around 16 to 20 times but I was eventually able to click through them. 

Database attached.   Noticed that exactly the same sequence has been reported in bugs thread 1.  9.  3. 

P. S.  on Saturday 15 january 2084 the game starts to callculate something and well, wont stop :(

It looks like an error in ground force creation, but I suspect not happening every time or there would be a lot more errors reported. I plan to start a new test campaign soon, so I will try to reproduce then. Thanks for DB attachment but my code has moved on now, so I am at the point where I can't load v1.13 games.

As a followup on these, I have gotten a similar error several times, across multiple versions, and been able to narrow down the circumstances:

It begins with a survey ship surveying an unknown jump point, and there always ends up being an NPR in the system, so I am fairly confident it relates to NPR generation.

It starts with "1.13.0 Function #2608: Object reference not set to an instance of an object". Then I get the same for #222, #224, #2339, #2608 cycling in that order many, many times, so much I gave up on counting after about 30 cycles and just clicked through. It finally ended with a Function #1654.

Exploring the system showed it had an NPR homeworld with an EM signature of 89,491. At first I thought it had no Thermal signature, but looking closer I found a thermal signature of 8,949 and a ground force signature of 200 tons. No ships were detected at all. I have no idea how this compares to normal generation(other than the apparent lack of ships) but it seems curiously small, perhaps indicating many resources an NPR would normally have didn't spawn.

I can't confirm that this happens 100% of the time on NPR creation, and at the very least pre-start NPR generation seems to work fine, but what's notable is I get this error often. The fact that it happens frequently to me but doesn't appear frequently in bug reports makes me wonder if it only happens on certain computers, perhaps due to a missing library or similar. OTOH, it's not impossible some people get a large succession of these errors and don't report them because it doesn't create any obvious and immediate problems.
Title: Re: v1.13.0 Bugs Thread
Post by: Carthar on July 02, 2021, 03:49:47 PM
Double Colony Entries
This is likely a known bug, but I can't find it when I search for it.

1.  Make a colony via system view window on a body that is occupied (enemy pop or troops work)
2.  Land troops via an orbital drop.
3.  If you then conquer the world you end up with a double entry for that body in the colony summary tab.   

The troops are on one body and the captured pop and installations on the other.
I am able to consistently do this.   No Mods and using a comma separator.   TN start.   Done on both random and real stars.

(http://https://i. postimg. cc/KYLxkn5n/double. jpg)
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on July 02, 2021, 03:59:01 PM
Double Colony Entries
This is likely a known bug, but I can't find it when I search for it.

1.  Make a colony via system view window on a body that is occupied (enemy pop or troops work)
2.  Land troops via an orbital drop.
3.  If you then conquer the world you end up with a double entry for that body in the colony summary tab.   

The troops are on one body and the captured pop and installations on the other.
I am able to consistently do this.   No Mods and using a comma separator.   TN start.   Done on both random and real stars.

(https://i. postimg. cc/KYLxkn5n/double. jpg)

Not a bug, this is how conquering an alien colony works. You can move all of the troops from the "old" colony to the "new" colony in the ground forces window and then delete the now-empty old colony.
Title: Re: v1.13.0 Bugs Thread
Post by: Norm49 on July 05, 2021, 10:56:50 PM
If ship live or join fleet. In my case dock and udnock form a carrier. It reset the speed form the fleet. It happen to men when i was pursuing a invader fleet just out of there weapon range.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on July 05, 2021, 11:39:07 PM
If ship live or join fleet. In my case dock and udnock form a carrier. It reset the speed form the fleet. It happen to men when i was pursuing a invader fleet just out of there weapon range.

I think this is a case of WAD, but maybe not WAI. The fleet speed is probably reset when new ships join to avoid problems where the fleet speed is greater than the speed of the new ships which could be exploited. However, I think it would be good to add a conditional so this code only triggers if the fleet speed is faster than the speed of the new ships.
Title: Re: v1.13.0 Bugs Thread
Post by: kks on July 07, 2021, 11:13:07 AM
I'm not sure if this really warrants a bug report, but I did find an asteroid which generated inside of its parent star. It also is hotter than the surface temperature of its star would be. I attached the screenshots. It was on version 13.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on July 08, 2021, 10:42:42 PM
Minor Bug: Renaming a body does not update your Intelligence and Foreign relations screen. So if you discover Alpha Centauri A-I and you find aliens there and decide to rename the planet Alien Planet A-I, all your information in the Intelligence and Foreign relations screen is still under Alpha Centauri for all populations under that race. The system renaming, however, it's working as intended and update throughout the screen across all data.

The function number: n/a
The complete error text: n/a
The window affected: Intelligence and Foreign Relations screen under Known Systems and Populations.
What you were doing at the time: Rename Earth Moon-1 as Luna after creating a new race on Earth.
Conventional or TN start: Conventional
Random or Real Stars: Real Stars
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent, or a one-off? I would say easy. I thought was due to Name Sol Bodies not working properly, but I could reproduce on other games in  different systems.
Title: Re: v1.13.0 Bugs Thread
Post by: nonum on July 10, 2021, 09:07:06 AM
Bug: When fleet has anchor set and has standing order such as "Survey Nearest body" or "Survey Nearest Location" then after arriving at body/location to conduct survey it begins to travel back to anchor during that survey.  It actually surveys that location while traveling from it.

Expected behavior is to stay at location of survey and only travel to anchor after survey is complete and standing orders are no longer possible.

Steps to reproduce:

1.  Create parent fleet with 2+ ships, detach survey ship(s) from parent fleet and then set anchor of detached fleet(s) to parent fleet that still has 1 ship.
2.  Travel to system with unsurveyed locations/bodies
3.  Click button Detach Escorts for parent fleet, set Standing orders of detached fleets(ships) to "Survey Nearest body" or "Survey Nearest Location"

The function number: n/a
The complete error text: n/a
The window affected: (related to anchor functionality and standing orders)
What you were doing at the time: Just incrementing time
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy to reproduce, always happens.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on July 10, 2021, 04:44:54 PM
Minor error
Alien ships receiving same ship designations for different classes.

Example:
Enemy alien ship assigned Cadmus designation. This was a DDG. I destroy all know examples. Then come across new fleet of same alien with 10 Ships designated Cadmus. Get torn into them, find afterwards They were fuel harvesters. Tried changing Theme but same thing happens.

I have also had five ships of one class of orbital miners designated "Resurrection Ship" another six of same class designated "Allosaurus", previously the name of a beam cruiser. Those ships were in the same alien fleet I captured.
Title: Re: v1.13.0 Bugs Thread
Post by: AlStar on July 12, 2021, 11:03:16 AM
Bug: Commanders are getting reassigned to new ships instead of dying in the depths of space (or possibly in an alien gulag).

After a botched raid against an NPR's home system, my fleet had to run with their tails between their legs - full speed, shooting at volleys of incoming missiles every 15 or so seconds, with a depressing number managing to make it past the railguns to strike the fleet. Anyway, long story short, two ships exploded, leaving lifepods with commanders. We couldn't turn around to pick them up, so left them as the fleet jumped out system.

Shortly thereafter, some new ships were built and I was surprised to see one of the left-behind commanders assigned to it (CAPT Frodo Baggins - memorable enough that I noticed). It is indeed the same captain - his history shows him getting his ship blown up around him (twice, as it so happens, but I picked up his lifepod the first time.)

This is on v1.13.0, with no database hacking or anything else funny going on.
Title: Re: v1.13.0 Bugs Thread
Post by: AlStar on July 12, 2021, 11:26:02 AM
Bug: Ship with a destroyed geo scanner will sit above a planet and try (and fail) to scan it without any error message.

I had an exploration ship that lost its scanner due to a random malfunction. It didn't have enough supplies on board to fix the scanner, and either that message didn't pause time, or it happened simultaneously with other events and I didn't notice it. Regardless, the ship already had auto-generated orders input to scan several planetary bodies. It arrived at the planet, and just sat there - for years, before I noticed one of my ships was way, way, overdue for a refit.

Given that I can't ignore ships who fail when they want to transit through a jump point for more than a 30 second increment without them spamming me to death, I feel that this seems like an oversight.
Title: Re: v1.13.0 Bugs Thread
Post by: Tuck Davis on July 13, 2021, 09:10:39 AM
Found a minor text bug.  .  . 
(http://https://s20.  directupload.  net/images/210713/nlycneeb.  png)

When a fleet can't grab minerals cause the planets reserve settings prohibit it, the news log will show "None" as pickup good instead of "Minerals". 

Greets
Tuck
Title: Re: v1.13.0 Bugs Thread
Post by: TMaekler on July 13, 2021, 02:22:37 PM
V1.13: Naval Organisation Window - Ship Design Display
There are two fields "Target Speed" and "Range Bands". If you want to change the numbers and try to exit these fields by pressing the Enter button it creates a "Carriage Return" in that field and makes it an invalid number.
Title: Re: v1.13.0 Bugs Thread
Post by: Kiero on July 15, 2021, 08:12:12 AM
Is this a Bug?

The enemy alien race started to throw ships at me. I've already killed like 50 of them, but they are still coming.
And they still have 141 of them (13 642 t each), those are not diplo ships.

Screens below.

Title: Re: v1.13.0 Bugs Thread
Post by: TMaekler on July 21, 2021, 11:10:53 AM
V1.13: Medal Management:

After selecting an already existing medal, changing all attributes, and saving it as a new medal, the conditions in the new medal are empty and the original medal contains the changed conditions. The original conditions are lost.
Title: Re: v1.13.0 Bugs Thread
Post by: Zhatelier on July 21, 2021, 11:29:39 AM
Bug: When using premade components on multiple tasks in a row, you get extra resources back.

Only tested this on a single shipyard with 5 slipways. If you place a single order and then close the menu and open it again, everything works just fine. But after having set the first one and I clicked the Create Task -button 4 times in a row, which resulted in the mineral usage of corundium (which was the main number I was paying attention to as no other ships were using it) for SY Tasks was listed as -1440. And it wasn't just ghost numbers, I did actually get that much back. Considering each ship uses 240 corundium for two orbital mining modules each, that means I got an extra 240 corundium back from that ordeal. Then on the next try, I ordered all 5 ships back to back, which resulted in a corundium use of -4800 for SY Tasks, so 4 times as much corundium as I used in making the modules in the first place.
Title: Re: v1.13.0 Bugs Thread
Post by: ZimRathbone on July 22, 2021, 09:36:41 AM
Ancient Constructs bugs

I haven't yet trained any Xeno teams (still two years off) but noticed a couple of issues...

(1) On the Ancient Constructs tab of the Economic screen it shows the type and bonus of the dormant constructs on every planet even though they have not had Xeno teams visit yet.

(2) The bonus for Ancient Constructs is applied to research projects of the appropriate type on the planet, again without any Xeno involvement (as long as the min 1m pop is present which is a given if there is at least one operating research lab)

v1.13, no mods, UK decimals, 10 years in.
Title: Re: v1.13.0 Bugs Thread
Post by: TMaekler on July 25, 2021, 08:52:34 AM
V1.13: Getting the error message: Function #2801: Tried to divide by zero
Clicked on a Ground Support Fighter in the Naval Organisation Window. The tab "Ship Design Display" only shows "error" as text. The fighter looks like this:

Code: [Select]
Hawk Mk.6 class Ground Support Fighter      15 tons       1 Crew       8.1 BP       TCS 0    TH 0    EM 0
5409 km/s      Armour 1-0       Shields 0-0       HTK 1      Sensors 0/0/0/0      DCR 0      PPV 0.1
Maint Life 0 Years     MSP 0    AFR 2%    IFR 0.0%    1YR 0    5YR 1    Max Repair 15 MSP
Magazine 2   
Lieutenant Commander    Control Rating 1   
Intended Deployment Time: 3 months    Morale Check Required   

Magnan Marine M7-1.60 5t 6.40LH MP Engine TH25% (1)    Power 1.6    Fuel Use 400%    Signature 0.384    Explosion 10%
Fuel Capacity 1,000 Litres    Range 3 billion km (6 days at full power)

S2.0 Fighter Pod Bay (1)     Pod Size: 2    Hangar Reload 70 minutes    MF Reload 11 hours

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


I thought it strange that I didn't need to put engineering onto the fighter. But there was no warning or error message. I added one but it didn't remove the error message above.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on July 25, 2021, 10:03:29 PM
I've observed the following NPR design:

Off-Topic: Shincliffe class Jump Cruiser • show
CJ Fenrir 001  (Shincliffe class Jump Cruiser)      15,656 tons       251 Crew       1,730.2 BP       TCS 313    TH 992    EM 0
3168 km/s      Armour 11-55       Shields 0-0       HTK 59      Sensors 18/18/0/0      DCR 8      PPV 0
Maint Life 1.83 Years     MSP 552    AFR 245%    IFR 3.4%    1YR 208    5YR 3,113    Max Repair 124 MSP
Commandant General    Control Rating 3   BRG   ENG   CIC   
Intended Deployment Time: 12 months    Morale Check Required   

Nuclear Pulse Engine  EP248 (4)    Power 992    Fuel Use 56.80%    Signature 248    Explosion 10%
Fuel Capacity 850,000 Litres    Range 17.2 billion km (62 days at full power)

CIWS-120 (3x4)    Range 1000 km     TS: 12,000 km/s     ROF 5       
Active Search Sensor AS56-R111 (1)     GPS 7992     Range 56.4m km    Resolution 111
Thermal Sensor TH3-18 (1)     Sensitivity 18     Detect Sig Strength 1000:  33.5m km
EM Sensor EM3-18 (1)     Sensitivity 18     Detect Sig Strength 1000:  33.5m km

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


While I must admit that the tactical value of a large hunk of armor is non-negligible, particularly when the opponent is not aware of the ship type and fires a bunch of missiles at it, I am not sure that a "Jump Cruiser" with no jump engine is something the NPRs should be sending out to battle.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on July 26, 2021, 04:23:16 AM
I have noticed that Reduced Size Laser 0.75/4x Recharge does not reduce the size of the laser. With a Capacitor 3, 10cm Infrared you have 150 tons size and if you apply the reduction while all the other values go down the laser weight is still 150 tons. The following tech (0.5) does reduce the amount of tonnage to 100 though.
Title: Re: v1.13.0 Bugs Thread
Post by: Elminster on July 26, 2021, 04:40:51 AM
1. 13. 0

I marked a system as "Block Fleet Movement Auto Route".
This does not prevent my survey ships to auto seek this system for the standing order of "Move to System Requiring . . . survey".  It should though.
Title: Re: v1.13.0 Bugs Thread
Post by: TMaekler on July 26, 2021, 08:36:12 AM
V1.13: Deselecting the option to auto-use Lagrange points when setting a fleet route does work - except when you let it automatically search for the route to the final system - in that case, it keeps considering Lagrange points and add them to the route.
Title: Re: v1.13.0 Bugs Thread
Post by: Elminster on July 26, 2021, 09:05:24 PM
1. 13. 0


I get a research bonus even though the ancient construct is not yet explored.  I think that is not intended.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on July 26, 2021, 09:22:34 PM
I have noticed that Reduced Size Laser 0.75/4x Recharge does not reduce the size of the laser. With a Capacitor 3, 10cm Infrared you have 150 tons size and if you apply the reduction while all the other values go down the laser weight is still 150 tons. The following tech (0.5) does reduce the amount of tonnage to 100 though.

It's worth noting that this is a bug with lasers in general, basically laser sizes are rounded (up? or nearest?) to the nearest HS instead of operating on tonnage like everything else...probably a holdover from an old VB6 version. The fix should be as simple as removing the rounding behavior from the relevant code snippet(s).
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on July 28, 2021, 04:39:43 AM
When playing with Generate New Races as NPRs "OFF" you cannot access the created race Tactical Map unless you restart the game.

Not sure if the following is afflicting also normal NPR generation, but the ship design of the NPRs is larger than the maximum displacement available at the Race Shipyards.

In my case: designs for 18,000 tons max Naval Yard Displacement 10,000 tons.

Eventually, while new ship designs are generated, there are no Ground troops templates available and have to be designed from scratch.

The function number: n/a
The complete error text: n/a
The window affected: Tactical Map
What you were doing at the time: Entered a new system and a New Race was generated. Being Generate New Races as NPRs "OFF" I was supposed to have had access to the new race map, but it was available on all screens but the tactical.
Conventional or TN start: TN
Random or Real Stars: Real Stars
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent, or a one-off? I would say easy. Create a new game with Generate New Races as NPRs "OFF", explore the universe until a race is generated.
Title: Re: v1.13.0 Bugs Thread
Post by: MasonMac on July 31, 2021, 03:25:51 PM
You can instant research a technology to completion even if you have less than the required amount. I am using the solaris theme mod with period decimal punctuation.
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on July 31, 2021, 06:46:50 PM
You can instant research a technology to completion even if you have less than the required amount. I am using the solaris theme mod with period decimal punctuation.

Was SM mode on by any chance?
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on July 31, 2021, 11:28:18 PM
You can instant research a technology to completion even if you have less than the required amount. I am using the solaris theme mod with period decimal punctuation.

This is as far as I know WAI. If you have any amount of free RP (or BP) left you can research (or build) anything even without SM mode. It is a tad exploitable, but I think much preferable to the situation of having some amount of free RP left which can't actually be used in a helpful way.
Title: Re: v1.13.0 Bugs Thread
Post by: MasonMac on August 01, 2021, 12:45:03 PM
I think the correct behaviour would be to invest those RP into the technology, not unlike how you can cancel a research project and the RP is retained. For example, if you had 1000 RP for a 5000 RP project, it would fill to be 1000/5000 RP
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on August 01, 2021, 02:54:27 PM
Personally, I like it as it is. However this is properly a suggestion for the Suggestions thread now.
Title: Re: v1.13.0 Bugs Thread
Post by: Demonius on August 05, 2021, 08:55:54 AM
I encountered a possible bug in a rather special circumstance.

V1.13 - no mods - ~33 years of game time in

I had a group of 2 tugs tractoring 2 captured vessels formerly of an NPR toward Sol. When they passed a jump node from the system where I captured them to the next, there was an NPR fleet blockading this node on the other side. The fleet attacked and immediately destroyed one of the 2 tugs. I ordered the fleet to immediately jump back. Surprisingly, the surviving tug and both of the captured ships made the jump back. The NPR fleet followed and eliminated the second tug, then sped away and started to fire AMMs at the 2 stranded, former NPR ships. The missiles were engaged by one of the ships lone gauss cannon, then struck the 2 ships and did 0 damage. This continues for about 20 salvos, until the NPR fleet had moved out of range for the AMMs. Of all the missiles launched, none ever actually does any damage to the 2 stranded, formerly NPR and formerly tugged ships.

A bit later on, the NPR fleet engages my stationed warships and deals normal damage to them with the same AMM spam attack. So something made those "formerly being tugged" ships to evade all incoming damage.

DB attached.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on August 05, 2021, 05:23:26 PM
Getting a weird message on my campaign when I start Aurora and I click on the Research Icon

(https://i.imgur.com/nyjXoPN.png)

It's a conventional start with 7 powers all player-controlled, roughly 80 years in.

EDIT: A bit more info, the problem seems to have started after 2 powers have agreed to share Research Data. In fact, I get this message only when I open the research screen of either power but not the others. Furthermore, the message appears only when I freshly open Aurora and click on the Research Icon for the first time. After that, even if I advance in the game or click again on the Research, I do not get it anymore.

I am not saving as I still don't know if it's a game-breaking message or not and keeping the campaign on hold.
Title: Re: v1.13.0 Bugs Thread
Post by: Elminster on August 06, 2021, 07:57:13 AM
So someone mentioned it in a separate thread (http://aurora2.pentarch.org/index.php?topic=12680.0 (http://aurora2.pentarch.org/index.php?topic=12680.0)).

After refit weapons are missing until you hit "Auto Assign FC".

Attached DB is before Auto Assign.
Title: Re: v1.13.0 Bugs Thread
Post by: Voltbot on August 10, 2021, 08:02:39 AM
When I was assigning weapons to fire control (Naval Organization window), I accidentally clicked fire control section.  After that game changed cursor to assigning one (this with rectangle below) and after 2-3 seconds stopped responding.  This is repetitive bug.  Sorry if someone found it before.  I'm just too lazy, to check 32 posts pages.
Title: Re: v1.13.0 Bugs Thread
Post by: The0didactus on August 12, 2021, 06:50:20 AM
Don't know if this is a known issue or not, also don't know if somehow this is something i did. . .
Title: Re: v1.13.0 Bugs Thread
Post by: Black on August 12, 2021, 07:37:54 AM
Don't know if this is a known issue or not, also don't know if somehow this is something i did. . .

Do you have asteroid motion turned off?
Title: Re: v1.13.0 Bugs Thread
Post by: idefelipe on August 13, 2021, 03:08:29 AM
I found a bug in the medal system.

When you set a medal with "Allow Multiple Awards" it will give it to the officer but will not be displayed in the medal rack. So it will only show one medal regardless the amount of them you award it to the officer.

In the file attached I awarded two times the same medal to the officer and it is only shown once.

Title: Re: v1.13.0 Bugs Thread
Post by: Droll on August 13, 2021, 08:18:44 AM
I found a bug in the medal system.

When you set a medal with "Allow Multiple Awards" it will give it to the officer but will not be displayed in the medal rack. So it will only show one medal regardless the amount of them you award it to the officer.

In the file attached I awarded two times the same medal to the officer and it is only shown once.

I'm fairly certain this is WAI, as otherwise such medals could easily clutter and overwhelm the UI space.
Title: Re: v1.13.0 Bugs Thread
Post by: idefelipe on August 13, 2021, 11:55:12 AM
What is WAI?

And there is a loooot of space to repeat as many times as you need any medal in the medal rack :)
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on August 13, 2021, 11:56:55 AM
What is WAI?

And there is a loooot of space to repeat as many times as you need any medal in the medal rack :)

Working as intended. Usually comes up when a behavior is not what a player wants, but is (probably) working the way Steve wants it to.

Usually if something is not a bug, but WAI, the correct follow-up is to re-post in the suggestions thread. For some reason people don't like doing this though.
Title: Re: v1.13.0 Bugs Thread
Post by: idefelipe on August 13, 2021, 11:59:52 AM
Ok. Well, if Steve confirms this is a WAI then I will post it in the suggestions thread. Meanwhile I think it is a bug (if you look at military general medals rack you will see sometimes that medals are repeated because the same could be awarded several times to the same officer)
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on August 13, 2021, 06:44:26 PM
A science vessel of mine was just destroyed, and I got two sets of events telling me about the death of my commander: one listing him as the C.O. and a second listing him as the science officer. I know I had a science officer assigned to the ship because I also got a separate event telling me about the death of a different officer. After further testing on my other guinea pigs science vessels, I think the issue shows up specifically when the bridge is destroyed prior to the whole ship being lost. This might just be a purely cosmetic issue, so probably not a high priority.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on August 15, 2021, 07:32:18 PM
If some ships in a fleet are damaged and detached, it seems that orders to join that fleet will be removed from other fleet's order lists.
Title: Re: v1.13.0 Bugs Thread
Post by: Kamilo on August 16, 2021, 12:37:50 PM
I have an ECCM installed on my ship but I can't select it in the ship combat.
Title: Re: v1.13.0 Bugs Thread
Post by: bankshot on August 16, 2021, 12:44:08 PM
Join fleet orders don't respect jump points.

Setup: produce one slow ship, say a terraformer in Sol system.  Send it off to its destination in another system, say "Tarn Vedra" a journey that will take months.  Now produce another one in Sol, and while the first ship is still in the production system have it join the first fleet. 

Expected result: the ships have identical speed, so #2 won't catch up to #1 until #1 arrives at its destination.

Expected failure: When fleet #1 jumps Fleet #2 orders error out due to invalid target.

Actual result: fleet #2 chases the real-space position of fleet #1, irrespective of the solar system where Fleet #1 resides.  When Fleet #1 jumps to Tarn Vedra Fleet #2 changes its course to intercept fleet #1 as if fleet #1 had teleported to the exit coordinates of the jump point of the sol jump point (in Tarn Vedra) but within sol system.  Once Fleet #2 reaches the corresponding x,y coordinate in Sol system currently occupied by fleet #1 in Tarn Vedra system the join fleet command is satisfied and fleet #2 joins fleet #1


no error code
13 year old game
player race and naval organization windows
terraforming a planet one system over from Sol
v1.13.0, TN start, decimal separator
easy to reproduce

See attached database - fleets TR Sierra 1 002 (fleet #2) and Terraformer 2b (fleet #1)
Title: Re: v1.13.0 Bugs Thread
Post by: Elminster on August 17, 2021, 01:15:28 AM
I have an ECCM installed on my ship but I can't select it in the ship combat.
If it is a refit, as a workaround try clicking "Auto-Assign FC".
When this helps, that's a reported bug. :)
Title: Re: v1.13.0 Bugs Thread
Post by: Demonius on August 25, 2021, 05:19:08 PM
If you use SM mode to edit the minerals on a planet, it reads coru-m-dium instead of corundium

But only in active edit mode, after save it is displayed correctly
Title: Re: v1.13.0 Bugs Thread
Post by: Mat93412 on August 26, 2021, 02:42:25 AM
I have got a bug, I recently captured an alien planet with its shipyards intact, it also came with a large population of aliens, however for some reason there were no installations to find or uncover so i used space master to spawn them in.  the issue is with the shipyards, every game tick it gives me a message saying #function 2186 attempting to divide by zero.  none of the shipyards show up in the shipyard screen for the planet despite 100 million people being employed in the role

(http://https://cdn. discordapp. com/attachments/655776232733933578/880355015817068554/unknown. png) (http://https://cdn. discordapp. com/attachments/655776232733933578/880355165025230848/unknown. png)
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on August 26, 2021, 03:29:16 AM
I have got a bug, I recently captured an alien planet with its shipyards intact, it also came with a large population of aliens, however for some reason there were no installations to find or uncover so i used space master to spawn them in.  the issue is with the shipyards, every game tick it gives me a message saying #function 2186 attempting to divide by zero.  none of the shipyards show up in the shipyard screen for the planet despite 100 million people being employed in the role

(https://cdn.discordapp.com/attachments/655776232733933578/880355015817068554/unknown.png)
(https://cdn.discordapp.com/attachments/655776232733933578/880355165025230848/unknown.png)
Hello and welcome to the forum. Please register your account so you can post normally in the future and we don't have to manually approve of each post. Also, once you've posted ten times, your links will start working.

This sounds like a esoteric bug that I don't believe we've encountered before. Could you upload your database somewhere and link it so Steve could have a closer look, please.
Title: Re: v1.13.0 Bugs Thread
Post by: Mat93412 on August 26, 2021, 05:43:27 AM
Thanks for just applied for the permissions to the forum, any way here is the link https://drive. google. com/file/d/1_NPhSLZ8E_IPUG5gTJ2sDyk1nh-J-hkT/view?usp=sharing.  that should contain my database.  do note, that this is my first run-through of the game (enjoying it a lot) but because of that, I have made a lot of screw-ups so I used space master a bit to recover.   so the bug may be caused by that.     

ill give you the actions concerning the planet just in case that helps narrow it down.  at the start of the game, I gave myself a lot of research points and build points to get familiar with the game.  when I found the alien world we started a war, which I won due to higher-tech, however, the planet had something like 300,000 ground troops, so after a failed invasion, I tried to nuke the planet from orbit but they had ALOT of STO so it took over an hour to kill even 10% of the ground troops, I used SM to create a massive bombardment ship, and nuked the planet a lot, (2000 or so nukes at once) I then did some reading and found that with a certain build it was possible to win so used SM again to make a ground force and invaded.  after that, I decided to use SM to retiform the world to habitable, as if I had known it was possible to attack I would have not nuked the world.  after capturing the world it gave me the pop but no installations or buried installations so I used a random number generator to generate installations.  I also found that the spaceports that the planet had used almost 600 million people so I used SM to delete a few.  i think i might have also told the remaining spaceports to expand.  sometime after that, I started to get the bugs. 
hopefully, something in that helps you figure out what the hell happened.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on August 26, 2021, 11:19:55 AM
"Show next tech" does not seem to properly take into account minimum jump engine size for squadron jumps.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on August 26, 2021, 12:13:02 PM
I recently assaulted the enemy homeworld and am getting some weird, related issues.    First, I destroyed their shipyards using beam ships, and while the shipyard signature disappeared, the ships kept firing and I kept getting events saying slipways were being destroyed.    Finally I just stopped and moved on with the invasion.    After I captured the planet, it is showing about -90 million works in the shipbuilding industry on the Summary tab.    On the Shipyards tab, it lists two shipyards, both Naval type, with -14 and -28 Slipways.    The Available Slipways shows the same negative numbers.    The Mod rate is still positive, though.    There are no assigned classes, and no current activity, and the Capacity is positive for both (11,200 and 8000, respectively).   

This may potentially be related to the one the new member above just posted, too.   

***

Update 8/28/21: I tried retooling, and it let me, so I tried ordering construction and it just made the number of slots available go further negative. . .  forever.  I now have infinite slipways! As cool/handy as that it, that's a bridge too far for me (not to mention the -90M pop I get for free), so I deleted the two bugged shipyards and everything appears to be back to normal now.  Still may be a bug worth hunting down and fixing if it's easy, but it's not a game-breaker and you can fix it yourself, so low priority.
Title: Re: v1.13.0 Bugs Thread
Post by: somebody1212 on August 30, 2021, 03:21:16 PM
Bug? - Crew rescued from lifepods do not add to the crew formation size during boarding combat.

This came up during one of the duels being run on the Aurora4x discord - one of the players was running short on crew during a boarding action and decided to bolster their numbers by picking up the lifepods from some of their ships which had previously been destroyed but this did not add any additional crew to the combat.

Unclear whether this is WAI or not (cannot find anything on this on the forums) so posting here to confirm.

What you were doing at the time - collecting lifepods with a ship which has been boarded.
Conventional or TN start - Tested on both.
Random or Real Stars - Tested on both.
Is your decimal separator a comma? - Decimal separator is a full-stop, thousands separator is a space.
Is the bug is easy to reproduce, intermittent or a one-off? - Easy to reproduce.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on September 04, 2021, 08:13:16 PM
You can order a fleet to unload survivors on a planet with no colony, but this does not actually unload any survivors. I imagine you shouldn't be able to give this order if there's no colony on the planet.
Title: Re: v1.13.0 Bugs Thread
Post by: idefelipe on September 06, 2021, 12:02:57 AM
Good morning!

I have this chain of errors messages (see three images attached). And it happens all the time and massively, I mean that I click on ok and they are shown again and again and again... (I guess I have lost the game)


Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on September 10, 2021, 01:12:01 PM
Here's a fun one: Beam Fire Controls with tracking speed less than 1000 km/s have no build cost nor development cost.

I don't know why this exception should exist, since BFC cost is dependent only on size and this behavior does not seem to happen for very short ranges. Since a tracking speed <1000 km/s could be relevant in some SMed conventional settings I would recommend removing that exception if possible.
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on September 11, 2021, 10:50:07 PM
Might be related to the issue where a weapon with less than 10,000 km range never fires, ie in that there's something funky about beam weapons and BFCs at very short ranges and velocities.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on September 14, 2021, 02:56:38 AM
 --- Can we get Fighters fixed? They still don't load / unload colonists. :(
Title: Re: v1.13.0 Bugs Thread
Post by: Vandermeer on September 18, 2021, 11:41:14 AM
Hello, quickly jumping in because it might be important. I think I got a critical clue or perhaps even solution on the #478, #1943, #1951 error loop that has been reported here at least 5 times like here (http://aurora2.pentarch.org/index.php?topic=11298.msg133287#msg133287) and here (http://aurora2.pentarch.org/index.php?topic=11565.msg141225#msg141225).
Bughunter moved to report it to Steve here (http://aurora2.pentarch.org/index.php?topic=11298.msg133603#msg133603) more than a year ago, but since I stumbled across the issue in my modern game, it seems there was yet no solution found.

I thought by myself that it was about civilian cargo, because I had been very busy managing some armaggeddon level evactuation that raised suspicion to be error prone. Luckily the critical clues in the forum set me towards that this was about an emerging spoiler, which I had missed was just discovered at some frontier routine search.
I stepped into the db to take a look and found this:
(https://abload.de/img/screenshot2021-09-181a1juq.jpg)
...A double instance of some Rakhas race. I expected to run into many problems trying to take them out, like having to one by one remove their ships, populations etcetc., but apparently I could just delete the second instance there, and then all the errors vanished.

So, precise analysis goes to Steve for this, but I can wager that it is either caused by having this spoiler race be generated at discovery (while others seem to exist at game start), or maybe just something with them spawning without having any apparent assets (again, ships or population). Either way, I would think the reason people seem to get these errors ~2 out of 5 times when encountering spoilers is that they encounter Rakhas, which seem to be broken in some way or the other. (Maybe someone can confirm if they have ever seen them for real and working)

Anyway, so whether this is caused by double race spawn or something else entirely, if you have the error and it comes from just Rakhas, you can save your original DB and then like me try to erase one or possibly more of them to see the errors go away.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on September 18, 2021, 11:52:44 AM
There can be multiple Rakhas races in a single game with different levels of tech. The same is true for Star Swarm.
Title: Re: v1.13.0 Bugs Thread
Post by: Vandermeer on September 18, 2021, 12:34:22 PM
I figured. These two spawned in the same system at the same time but on different (closeby) system bodies though. If you need access to the erroneous db to find the exact issue with species 238 here, I still have it on file.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on September 19, 2021, 07:26:06 PM
If you order a fleet containing both dropships and regular troop transports to perform an orbital drop, it will drop all ground units, even the ones in transports that aren't drop-capable.
Title: Re: v1.13.0 Bugs Thread
Post by: bankshot on September 23, 2021, 08:45:28 AM
Mass driver packet sizes are reduced by setting reserve levels on minerals.

Setup: Mars has three mass drivers, totaling 15kt/yr capacity.  There are 72x five day production cycles/year so maximum packet size should be just over 200t.  Its mass drivers are set to send minerals to Luna.  Because I'd like to keep some minerals on hand in case of future needs I have 5K reserve levels set for all minerals.  Five minerals have stockpiles in excess of the reserve, with about 4K total minerals available to be sent to Luna.  But packet sizes are around 18t.  Packets are sent at high velocity indicating there is reserve capacity available.  Zeroing the reserve for some minerals increases packet size.  Zeroing it for all minerals gives 205t packets.

So the code appears to be building a 205t packet out of all materials in the stockpile then removing minerals that are ineligible for launch instead of determining what minerals are available and then building a packet. 

To duplicate:  Have a few thousand tons of minerals stockpiled on a colony.  Set reserve levels above zero but below stockpile levels.  Target the mass driver at another colony, observe packet size and speed. 

See attached database - you can manipulate reserve levels on Mars then advance time to see the effect on packet size/speed
Title: Re: v1.13.0 Bugs Thread
Post by: Marski on September 25, 2021, 01:29:49 PM
"1.13.0 Function #5: Object reference not set to an instance of an object."
Absolute fresh start.
50-year ceasefire.
This error appears at every increment, be it 5-second or 30-day.
TN start, real stars.
5 NPR's on earth besides player, 3 alien NPR's elsewhere in the galaxy.
Multi-NPR on earth start, all earth-based NPR's were initially player controlled to ensure that no ships were spawned for them. Ship and ground unit designs I allowed to be auto-generated. Earth-based NPR's weren't given shipyards to give an even start.
Earth NPR's had their ground unit vehicles renamed to match real-life equipment. However this seemingly doesn't cause problems since the A.I builds formations that use said vehicles. The A.I also commences industry projects normally as well.

Switching the earth-based NPR's to player control and making turns with them however doesn't cause errors.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on September 25, 2021, 04:10:38 PM
There's a major bug with missile fire controls, and I'm really not sure how this hasn't been caught before (so if it has and I just haven't seen any mention of it I apologize in advance). When an MFC is destroyed, any salvo in flight fired by that MFC will disappear. This includes salvos fired by other ships in the same class: if an MFC on one ship is destroyed, all salvos fired by the equivalent MFC on any other ship of that class will disappear as well. If a ship is entirely destroyed it seems that the salvos sometimes don't disappear -- presumably in some cases the MFCs are destroyed before the ship is, while if the ship is destroyed without the MFCs being destroyed then the salvos don't disappear.

Version 1.13.0, period decimal separator. I tested this on a totally fresh DB and was able to reproduce it repeatedly. I really don't understand how this hasn't been spotted, as it makes many missile fights basically unplayable.
Title: Re: v1.13.0 Bugs Thread
Post by: ArcWolf on September 25, 2021, 09:48:10 PM
"1.13.0 Function #5: Object reference not set to an instance of an object."
Absolute fresh start.
50-year ceasefire.
This error appears at every increment, be it 5-second or 30-day.
TN start, real stars.
5 NPR's on earth besides player, 3 alien NPR's elsewhere in the galaxy.
Multi-NPR on earth start, all earth-based NPR's were initially player controlled to ensure that no ships were spawned for them. Ship and ground unit designs I allowed to be auto-generated. Earth-based NPR's weren't given shipyards to give an even start.
Earth NPR's had their ground unit vehicles renamed to match real-life equipment. However this seemingly doesn't cause problems since the A.I builds formations that use said vehicles. The A.I also commences industry projects normally as well.

Switching the earth-based NPR's to player control and making turns with them however doesn't cause errors.

I've had the same thing happen to me, Not sure if it is truly a bug or the fact that a Player faction was made an NPR and is missing vital techs/AI logic.
Title: Re: v1.13.0 Bugs Thread
Post by: Marski on September 25, 2021, 10:18:43 PM
"1.13.0 Function #5: Object reference not set to an instance of an object."
Absolute fresh start.
50-year ceasefire.
This error appears at every increment, be it 5-second or 30-day.
TN start, real stars.
5 NPR's on earth besides player, 3 alien NPR's elsewhere in the galaxy.
Multi-NPR on earth start, all earth-based NPR's were initially player controlled to ensure that no ships were spawned for them. Ship and ground unit designs I allowed to be auto-generated. Earth-based NPR's weren't given shipyards to give an even start.
Earth NPR's had their ground unit vehicles renamed to match real-life equipment. However this seemingly doesn't cause problems since the A.I builds formations that use said vehicles. The A.I also commences industry projects normally as well.

Switching the earth-based NPR's to player control and making turns with them however doesn't cause errors.

I've had the same thing happen to me, Not sure if it is truly a bug or the fact that a Player faction was made an NPR and is missing vital techs/AI logic.
Been trying to troubleshoot it, I've pinpointed it down to creating a player race and then turning it into NPR.
I haven't been able to find in the DB's how to "reverse" the tech advantages a generated NPR gets when auto-design is enabled.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on September 26, 2021, 09:12:17 AM
Setting a former player faction as a NPR is expressly not supported, per Steve. As I understand it, there is a lot of AI logic that gets lost when a NPR is "created" from a player race which will almost certainly break the game.

Even turning a NPR into a player race is not supported but it is less likely to break the game at least in theory.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on September 26, 2021, 05:03:50 PM
When transferring ground elements between formations, you can put in ANY number and it will add that many to the "To" formation and subtract that number from the "From" formation. This means you can create an infinite amount of troops, but that's player self-policed (no different than using SM mode to cheat). The potentially bigger problem is I don't know what happens when -4 units of rifleman attempt to participate in combat.

Easy to reproduce, just try transferring more troops than you have.
Title: Re: v1.13.0 Bugs Thread
Post by: Lord Solar on September 26, 2021, 05:13:41 PM
Bug: When a cloaking device is destroyed the size of the ship on active contacts remains the same as if it still had a cloaking device
(edited: Removed sensitive info from ongoing duel at request)
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on September 27, 2021, 08:07:22 PM
Bug: Upon system generation, received a series of four distinct error codes which repeated in cycle around a dozen times.

Unfortunately, I did not have the presence of mind to write them down as they happened, but I think two of them were #222 and #224. The other two were four-digit numbers beginning with '2'.

Checking the DB immediately after this indicates that a NPR and a Rakhas race both generated on the same body of the same system, which may be the cause of the error or be related.

Database is attached, I do not recall modding this database except for changing the engine tech names to match the planned 1.14/2.0 techs.
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on October 01, 2021, 10:34:33 PM
I am not sure if already said or if it is something that just happened to me, but I started multiple games and still seeing the issue, so I am reporting.

When awarding a Medal, I cannot see the Ribbon next to the list anymore. I use to award the medal right away, now I need to read through the list.

That is how I noticed.

Unless my mind starts to imagine features...
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on October 07, 2021, 08:38:09 PM
I have no idea how this happened, but I somehow lost a jump point. I'm currently in the middle of grav-surveying one system and at the same time I have a ship surveying the next system in the chain. On the tactical map and the system display I can see the jump point from the second system into the first, but not from the first system into the second. This must have occurred recently, because otherwise I don't know how I could've gotten my survey ship into the second system. Jumping back from the second system into the first drops my ship at the right point in space without revealing the jump point. Using SM mode to completely survey the first system fixes the problem and reveals the jump point.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on October 09, 2021, 07:44:21 PM
 --- A simple error to reproduce; this one affects 25-Ton craft. Namely, in the Fleet Organization window if you select a 25 Ton craft (0.5HS) it throws an error. The error in question reads: "1.13.0 Function #2801: Attempted to divide by zero."
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on October 13, 2021, 07:31:31 AM
Moving research facilities typically auto-adjusts the number of labs assigned downward, but somehow in the process of moving all of my labs off Earth, I now have a project with 1 lab assigned but my research labs available line says -1 at the bottom of the screenshot attached. It's possible this happened because I had more than one fleet with an order to pick up labs from Earth, or it may just be a bug in how removal of labs and impact on your research queue works when you get to zero labs left.

Edit: It also looks like you can continue to add negative labs and fill up your queue with as many labs as your scientist can hold (obviously not WAI).
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on October 14, 2021, 10:10:14 AM
I've poked around with the options to auto-research techs and auto-design ships and ground units on startup, which to my knowledge uses the same logic that the NPRs use on creation to assign techs and designs to a player race. I've noticed some interesting quirks which could be considered bugs, certainly if a player uses this option they will get some unexpected results:
None of these appears to be a game-breaking bug, as the NPR tech progression does not depend on these being corrected in any meaningful way, however for a player using the automatic options these are confusing and unhelpful errors to deal with in many cases. I also suspect that the Heavy Armour and Fuel Efficiency could be fixed to slightly improve NPR performance.

Additionally, I have previously mentioned a ship design error where "jump" ships will be designed without a jump drive if the NPR generates with too low of a tech level to have jump drive techs. I did not observe that error in this little experiment but I feel it is worth re-mentioning as it fits this topic.
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on October 15, 2021, 04:31:10 AM
Immortal defender
After extensive fighting the defenders of a homeworld have been reduced to 1 infantry , who after about 45 days can neither be attacked nor does he attack, but while he exists the planet cannot be conquered.
Could not manage to attach the database file
edit
went back to a save game prior to the invasion and was able to conquer the planet
Title: Re: v1.13.0 Bugs Thread
Post by: kilo on October 15, 2021, 08:43:39 AM
Maybe it is not a bug; might be an unintended feature.

Beam weapons do not have the same number of caliber techs. Lasers have more than particle beams, which have more than rail guns. The consequence of that is, that the maximum racial ground attack capabilities you can achieve differ widely depending on your choice of beam weapon. For rail guns this damage value is 30, while it is 36 for particle beams and 45 for lasers.
Title: Re: v1.13.0 Bugs Thread
Post by: Fistandantillus7 on October 18, 2021, 09:33:48 AM
The function number:
The complete error text:

#1170 Object cannot be cast from DBNull to other types.
#3056 Object reference not set to an instance of an object.
#3060 Object reference not set to an instance of an object.

The window affected:
What you were doing at the time:

Start the game. #1170 appears. Click it away and main screen loads but with white instead of the blue Sol System map; #3056 appears. Hold down enter key to dismiss many repeated #3056. Blue Sol System map appears and error changes to #3060. Hold down enter key and keep it down. At some point error changes back to #3056. Eventually the event messages appear in the top left. Keep that enter key down! When the Economics window appears, lift finger. Trying to do anything will bring back the endless errors.
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma? Period
Is the bug is easy to reproduce, intermittent or a one-off? Easy. Happens every time.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 50 or 55 years

This happened to me (#?) days ago as well, but I rolled back and kept playing.

15minutegamer on April 24, 2020 — v1.8.0 Bugs Thread (http://aurora2.pentarch.org/index.php?topic=10990.msg127640#msg127640)
Hastermain on May 02, 2020 — v1.9.3 Bugs Thread (http://aurora2.pentarch.org/index.php?topic=11173.msg130028#msg130028)
theplahunter on May 04, 2020 — v1.9.4 Potential Bugs Thread (http://aurora2.pentarch.org/index.php?topic=11231.msg130688#msg130688)
brevduva on January 05, 2021 — Re: v1.12.0 Bugs Thread (http://aurora2.pentarch.org/index.php?topic=11945.msg145900#msg145900)
Title: Re: v1.13.0 Bugs Thread
Post by: Fistandantillus7 on October 18, 2021, 09:34:43 AM
The function number:
The complete error text:

Function #41: Object reference not set to an instance of an object.
The window affected:
What you were doing at the time:

Started when or soon after game spawned the Härjedalen Kingdom NPC/NPR/NPE on entering a new system. Click to start time progressing and error pops up. Click OK and the game progresses. Sometimes error will pop up on a sub-pulse. If there is a diplomacy event message when time stops, half the event messages will display then the error will pop up; dismissing the error will display the diplomacy event message followed by other messages. No diplomacy event message, no error. Click to start time progressing and error pops up... and repeat as before.
Diplomacy with all/any of the aliens seems unaffected and when the error first occurred it had been several hours since I had last saved so I decided to live with it.
I no longer have an error free backup.
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma? Period
Is the bug is easy to reproduce, intermittent or a one-off? Easy. Happens every time.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 50 or 55 years
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on October 19, 2021, 04:13:22 PM
Microwave weapons sometimes seem to hit multiple fire controls at once. Twice now I've gotten events reading "Total Hits 1, Penetrating Hits 1, Components Hit 6" which doesn't seem right.
Title: Re: v1.13.0 Bugs Thread
Post by: Iceranger on October 19, 2021, 04:28:37 PM
Microwave weapons sometimes seem to hit multiple fire controls at once. Twice now I've gotten events reading "Total Hits 1, Penetrating Hits 1, Components Hit 6" which doesn't seem right.
What is the HTK of the fire controls being hit? One 1 damage hit can destroy an infinite amount of HTK 0 components.
Title: Re: v1.13.0 Bugs Thread
Post by: ISN on October 19, 2021, 06:17:57 PM
Microwave weapons sometimes seem to hit multiple fire controls at once. Twice now I've gotten events reading "Total Hits 1, Penetrating Hits 1, Components Hit 6" which doesn't seem right.
What is the HTK of the fire controls being hit? One 1 damage hit can destroy an infinite amount of HTK 0 components.

Huh -- you're right, they have HTK 0. I did not realize that was possible, or that that meant the damage would continue to other components. Thanks for the clarification!
Title: Re: v1.13.0 Bugs Thread
Post by: kuhaica on October 29, 2021, 12:23:31 PM
The function number: 1.13.0 Function #1170 Object cannot be cast from DBNull to other types (This occurs on Startup, once I press "Okay" it goes away.

The complete error text:
 1.13.0 Function #1170 Object cannot be cast from DBNull to other types
1.13.0 Function #3060 Object reference not set an instance of object

The window affected: All Windows except the System View on systems other than Sol.
What you were doing at the time. Loading the game up, I did not have any issues prior to starting up when I last had Aurora loaded up the previous day. I had considered that attempting to spawn asteroids may have caused this. However, the system which had the asteroids spawned was not getting the error message nor did the other systems other than Sol have this message. Deleting the system also did not change anything.

Conventional or TN start: TN start
Random or Real Stars: Random start
Is your decimal separator a comma? It's a period

Is the bug is easy to reproduce, intermittent or a one-off? I constantly get this every time I try to load Aurora

If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well. Started 2400, it's now 2420, only recently become a problem.
Title: Re: v1.13.0 Bugs Thread
Post by: L0ckAndL0ad on October 31, 2021, 03:39:13 PM
Game version: 1.13, TN start, default start date. Current year: 2104

Problem: I have a mobile resupply base with Ordnance Transfer Hub, Cargo Shuttle Bay, Commercial Magazines and missiles on board. When ships armed with spent (empty after firing) box launchers come to rearm, their launcher reload timers go back to normal, but no missiles are transferred. The base is set to "Load Fleet Ordnance". Fleet that needs to rearm is given order to "Load from Ordnance Transfer Hub".

Base Design
Off-Topic: show
Ananke class Resupply Base      200 000 tons       768 Crew       6 595.6 BP       TCS 4 000    TH 7 200    EM 0
1800 km/s    JR 2-25(C)      Armour 1-304       Shields 0-0       HTK 162      Sensors 0/0/0/0      DCR 11      PPV 0
MSP 15 020    Max Repair 2400 MSP
Magazine 5 000    Cryogenic Berths 1 000    Cargo Shuttle Multiplier 2   
Commander    Control Rating 2   BRG   AUX   
Intended Deployment Time: 3 months   
Ordnance Transfer Hub - Capable of transferring ordnance to multiple ships simultaneously

JC200K E10 Commercial Jump Drive     Max Ship Size 200500 tons    Distance 25k km     Squadron Size 2

Commercial Internal Fusion Drive  EP600.0 (12)    Power 7200    Fuel Use 2.89%    Signature 600    Explosion 5%
Fuel Capacity 5 200 000 Litres    Range 162.1 billion km (1042 days at full power)
Refuelling Capability: 125 000 litres per hour     Complete Refuel 41 hours

CIWS-250 (4x10)    Range 1000 km     TS: 25 000 km/s     ROF 5       
ASM-62 Spike Anti-Ship Missile (300)    Speed: 40 467 km/s    End: 20.6m     Range: 50.1m km    WH: 12    Size: 6    TH: 202/121/60

Missile to hit chances are vs targets moving at 3000 km/s, 5000 km/s and 10,000 km/s

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as a Colony Ship for auto-assignment purposes


Save file (https://drive.google.com/file/d/15NwtBzYy8R6cePMHffpr_uy6jQPuQhZv/view?usp=sharing)

Fleet that needs to be reloaded: TF 5 Main Body
Fleet with Resupply Base: TG 5.8.2 Mobile Resupply Base

Bonus report: If you give order to "Replace at Ordnance Transfer Hub" and try progressing time, the game will hang up and will stop answering.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on October 31, 2021, 03:51:57 PM
You need to have a hangar (either military or commercial) in order to reload box launchers from a ship or station. It looks like the error here is that the box launcher reload timers should not be affected, however it is correct behavior that no ordnance is transferred.
Title: Re: v1.13.0 Bugs Thread
Post by: L0ckAndL0ad on October 31, 2021, 11:11:08 PM
You need to have a hangar (either military or commercial) in order to reload box launchers from a ship or station. It looks like the error here is that the box launcher reload timers should not be affected, however it is correct behavior that no ordnance is transferred.
My expectations were based on these change notes (http://aurora2.pentarch.org/index.php?topic=8495.msg109127#msg109127):

Quote
Box Launcher Reloading

In VB6 Aurora, box launchers can be reloaded in a hangar or at maintenance facilities. For C# Aurora, box launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in VB6 Aurora).

Because of the changes to maintenance facilities in C# Aurora, it will be a lot easier to forward deploy facilities for full-size warships, both on planets and in space, which would increase the potential of box launchers if they could still use those facilities to reload, especially given they are immediately available in C#. The introduction of ordnance-specific facilities for C# provides a good alternative.
Title: Re: v1.13.0 Bugs Thread
Post by: Blogaugis on November 01, 2021, 07:16:40 AM
Problem: I have a mobile resupply base with Ordnance Transfer Hub, Cargo Shuttle Bay, Commercial Magazines and missiles on board. When ships armed with spent (empty after firing) box launchers come to rearm, their launcher reload timers go back to normal, but no missiles are transferred. The base is set to "Load Fleet Ordnance". Fleet that needs to rearm is given order to "Load from Ordnance Transfer Hub".
But no maintenance facility, or as nuclearslurpee said - hangars...
You probably need at least 1 of those..?
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on November 04, 2021, 03:58:17 PM
The function number: 1.13.0 Function #1170 Object cannot be cast from DBNull to other types (This occurs on Startup, once I press "Okay" it goes away.

The complete error text:
 1.13.0 Function #1170 Object cannot be cast from DBNull to other types
1.13.0 Function #3060 Object reference not set an instance of object

The window affected: All Windows except the System View on systems other than Sol.
What you were doing at the time. Loading the game up, I did not have any issues prior to starting up when I last had Aurora loaded up the previous day. I had considered that attempting to spawn asteroids may have caused this. However, the system which had the asteroids spawned was not getting the error message nor did the other systems other than Sol have this message. Deleting the system also did not change anything.

Conventional or TN start: TN start
Random or Real Stars: Random start
Is your decimal separator a comma? It's a period

Is the bug is easy to reproduce, intermittent or a one-off? I constantly get this every time I try to load Aurora

If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well. Started 2400, it's now 2420, only recently become a problem.

I am now seeing this error on opening Aurora, a Function #1170 followed by 24 x Function #3060 as defined above. When I change the display to Sol I get between 7-10 repeats of the Function #3060. On a 5 sec time increment I get 42 X Function #3060 followed by 4 X Function #917 Value was too large or too small for an int32.

Empire is 95 years old
Conventional or TN start: TN start
Random or Real Stars: Real stars
Is your decimal separator a comma? It's a period.

Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on November 04, 2021, 04:00:20 PM
Problem: I have a mobile resupply base with Ordnance Transfer Hub, Cargo Shuttle Bay, Commercial Magazines and missiles on board. When ships armed with spent (empty after firing) box launchers come to rearm, their launcher reload timers go back to normal, but no missiles are transferred. The base is set to "Load Fleet Ordnance". Fleet that needs to rearm is given order to "Load from Ordnance Transfer Hub".
But no maintenance facility, or as nuclearslurpee said - hangars...
You probably need at least 1 of those..?

 --- No, this is a bug as you are supposed to be able to do either or. Ordinance Transfer Points have replaced the Maintenance Facilities of VB6 for the purposes of Box Launcher reloads, with Hangars retaining the same functionality.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 06, 2021, 06:33:02 PM
Bug: When fleet has anchor set and has standing order such as "Survey Nearest body" or "Survey Nearest Location" then after arriving at body/location to conduct survey it begins to travel back to anchor during that survey.  It actually surveys that location while traveling from it.

Expected behavior is to stay at location of survey and only travel to anchor after survey is complete and standing orders are no longer possible.

Steps to reproduce:

1.  Create parent fleet with 2+ ships, detach survey ship(s) from parent fleet and then set anchor of detached fleet(s) to parent fleet that still has 1 ship.
2.  Travel to system with unsurveyed locations/bodies
3.  Click button Detach Escorts for parent fleet, set Standing orders of detached fleets(ships) to "Survey Nearest body" or "Survey Nearest Location"

The function number: n/a
The complete error text: n/a
The window affected: (related to anchor functionality and standing orders)
What you were doing at the time: Just incrementing time
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy to reproduce, always happens.

I'd like to confirm this bug as I've observed the same thing, 6 years into a typical 1.13 campaign.
Title: Re: v1.13.0 Bugs Thread
Post by: Velociranga on November 08, 2021, 11:23:14 PM
Sorry if this has been bought up before or is WAI.

But I don't think the order to resupply a target fleet with the selected fleets supply ships is working. 

To test this I took the example game and create two ship types a commercial supply ship with maintenance supply bays and a cargo shuttle bay and a military ship.  I advanced time to drain the ships MSP.  Then I selected the Supply ship fleet in the naval organisation window, chose the military ships fleet as a target and chose resupply with own supply ships.

The supply fleet moved to the military ship and noted that it had completed its orders.  However no supply moved between the ships.  I have attached some screenshots and can add the DB if it helps.

Sorry if I am missing something but as someone who has been trying to figure out how to resupply some jump defence stations this has been driving me insane. 

Screenshots are numbered in a chronological order (1 is the first 4 is the last).
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 09, 2021, 12:44:09 PM
Make sure that this ship is checked as a Supply Ship in the class design window.
Title: Re: v1.13.0 Bugs Thread
Post by: Oafsalot on November 10, 2021, 03:45:57 AM
Concerning Block Fleet Movement Auto Route; Sometimes if I set it to true (boxed ticked) then unset it, it continues to block fleet movement even when unticked.

https://www. dropbox. com/s/b4ey6780m339tff/AuroraDB. 7z?dl=0 The system in question is 61 Cygni.


Title: Re: v1.13.0 Bugs Thread
Post by: Velociranga on November 10, 2021, 10:31:14 PM
Quote from: nuclearslurpee link=topic=12522. msg156670#msg156670 date=1636483449
Make sure that this ship is checked as a Supply Ship in the class design window.

It is, I have had this issue pop in multiple games.  At first I thought I was screwing things up but now I think its not working correctly.

I have attached the DB and a screen shot of both ships designs.  Its the example game in the DB.
Title: Re: v1.13.0 Bugs Thread
Post by: somebody1212 on November 13, 2021, 01:19:08 PM
Not sure if this is a bug, precisely, but it's certainly an inconsistency.

When designing a turret, it does not state the total rate of fire of the guns in the turret like it does when designing railguns/gauss. It only states the recharge time of the weapon, as it does when designing laser weapons (or anything else that only fires single shots). This makes it harder for new players to keep track of the effectiveness of their turret designs.

(originally reported by Whackem on the discord, who does not have a forum account)
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 13, 2021, 01:37:30 PM
Not sure if this is a bug, precisely, but it's certainly an inconsistency.

When designing a turret, it does not state the total rate of fire of the guns in the turret like it does when designing railguns/gauss. It only states the recharge time of the weapon, as it does when designing laser weapons (or anything else that only fires single shots). This makes it harder for new players to keep track of the effectiveness of their turret designs.

(originally reported by Whackem on the discord, who does not have a forum account)

Yeah, not a bug, and not inconsistent either. "ROF" in Aurora has pretty much always been a misnomer for recharge time, and you'll see the same when you design a railgun or Gauss cannon: you'll always see ROF 5, and the number of shots is indicated elsewhere.

It would be nice for turrets to display the total number of shots on the design screen but this is properly a post for the Suggestions thread.
Title: Re: v1.13.0 Bugs Thread
Post by: Bluebreaker on November 13, 2021, 04:01:49 PM
Then I selected the Supply ship fleet in the naval organisation window, chose the military ships fleet as a target and chose resupply with own supply ships.
This is the part where you made the mistake. What you did here is tell the supply ship to resupply it's own fleet, which consist of just itself.

To resupply from ships you have two options:
1- The supply ship has to be inside the fleet that you want resupplied, with instructions to resupply own fleet. Join & Resupply Target Fleet order would work here.
or
2- The fleet that wants to ressuply targets the supply vessel (fleet) and give the order to Resupply from Stationary Supply Ship
Title: Re: v1.13.0 Bugs Thread
Post by: somebody1212 on November 13, 2021, 04:40:43 PM
Not sure if this is a bug, precisely, but it's certainly an inconsistency.

When designing a turret, it does not state the total rate of fire of the guns in the turret like it does when designing railguns/gauss. It only states the recharge time of the weapon, as it does when designing laser weapons (or anything else that only fires single shots). This makes it harder for new players to keep track of the effectiveness of their turret designs.

(originally reported by Whackem on the discord, who does not have a forum account)

Yeah, not a bug, and not inconsistent either. "ROF" in Aurora has pretty much always been a misnomer for recharge time, and you'll see the same when you design a railgun or Gauss cannon: you'll always see ROF 5, and the number of shots is indicated elsewhere.

It would be nice for turrets to display the total number of shots on the design screen but this is properly a post for the Suggestions thread.

I'm aware of what Rate of Fire means in Aurora, but there's most definitely an inconsistency in how weapons that fire multiple shots are displayed.

Gauss indicates the number of shots they fire next to the RoF:
Damage Output 1      Rate of Fire 6 / 5s     Range Modifier 60 000
Max Range 60 000 km     Size 1 HS  (50 tons)    HTK 1


Railguns indicate the number of shots they fire next to the damage:
Damage Per Shot (4) 16     Rate of Fire 25 seconds     Range Modifier 80 000
Max Range 1 280 000 km     Railgun Size 13.0 HS  (650 tons)    Railgun HTK 6
Power Requirement 48    Recharge Rate 10


Turrets do neither, and since the rate of fire isn't stated in the default Gauss naming scheme this has been catching a lot of newer players out:
Damage Output 1    Rate of Fire 5 seconds     Range Modifier 60 000
Max Range 60 000 km     Turret Size 4.26 HS  (213 tons)     HTK 4


I'll make a post in the suggestions thread.
Title: Re: v1.13.0 Bugs Thread
Post by: Velociranga on November 15, 2021, 06:47:44 PM
Quote from: Bluebreaker link=topic=12522. msg156767#msg156767 date=1636840909
Quote from: Velociranga link=topic=12522. msg156666#msg156666 date=1636435394
Then I selected the Supply ship fleet in the naval organisation window, chose the military ships fleet as a target and chose resupply with own supply ships.
This is the part where you made the mistake.  What you did here is tell the supply ship to resupply it's own fleet, which consist of just itself.

To resupply from ships you have two options:
1- The supply ship has to be inside the fleet that you want resupplied, with instructions to resupply own fleet.  Join & Resupply Target Fleet order would work here.
or
2- The fleet that wants to ressuply targets the supply vessel (fleet) and give the order to Resupply from Stationary Supply Ship

Well if that is the case I will have to move this to suggestions however I am still not sure.  With the two different ways of resupplying a fleet you've listed its not possible to initiate resupply from the supply ship side without it joining the fleet.  The supply ship either needs to be part of the fleet or needs to sit around and have the fleet needing resupply come to it.  This makes it quite difficult to automate the resupply of stations and any fleet you don't want to move.  If this is working correctly then I would suggest changing the name of the "Resupply with own supply ships" order when you have another fleet selected.  At the moment it is unclear that the order is to resupply the ships own fleet and not the target fleet. 
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on November 15, 2021, 10:21:47 PM
Quote from: Bluebreaker link=topic=12522. msg156767#msg156767 date=1636840909
Quote from: Velociranga link=topic=12522. msg156666#msg156666 date=1636435394
Then I selected the Supply ship fleet in the naval organisation window, chose the military ships fleet as a target and chose resupply with own supply ships.
This is the part where you made the mistake.  What you did here is tell the supply ship to resupply it's own fleet, which consist of just itself.

To resupply from ships you have two options:
1- The supply ship has to be inside the fleet that you want resupplied, with instructions to resupply own fleet.  Join & Resupply Target Fleet order would work here.
or
2- The fleet that wants to ressuply targets the supply vessel (fleet) and give the order to Resupply from Stationary Supply Ship

Well if that is the case I will have to move this to suggestions however I am still not sure.  With the two different ways of resupplying a fleet you've listed its not possible to initiate resupply from the supply ship side without it joining the fleet.  The supply ship either needs to be part of the fleet or needs to sit around and have the fleet needing resupply come to it.  This makes it quite difficult to automate the resupply of stations and any fleet you don't want to move.  If this is working correctly then I would suggest changing the name of the "Resupply with own supply ships" order when you have another fleet selected.  At the moment it is unclear that the order is to resupply the ships own fleet and not the target fleet.

The join as subfleet function might help make this a little less painful, especially when you have multiple supply ships in play.
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on November 16, 2021, 01:01:23 AM
Uhh, I seem to had my shipyards "kidnapped", they are all producing in Economics, but I cant find them on the map, they show up as an enemy shipyard in my Naval organization, but cant be targeted by tractor beams, weapons or marine attacks...  ???

Noticed it when I was in the process of sending repair yards to the front, the second repair area is also vacant but can bee accessed via Economics...

Title: Re: v1.13.0 Bugs Thread
Post by: Velociranga on November 16, 2021, 01:10:06 AM
Quote from: Droll link=topic=12522. msg156805#msg156805 date=1637036507
Quote from: Velociranga link=topic=12522. msg156803#msg156803 date=1637023664
Quote from: Bluebreaker link=topic=12522.  msg156767#msg156767 date=1636840909
Quote from: Velociranga link=topic=12522.  msg156666#msg156666 date=1636435394
Then I selected the Supply ship fleet in the naval organisation window, chose the military ships fleet as a target and chose resupply with own supply ships. 
This is the part where you made the mistake.   What you did here is tell the supply ship to resupply it's own fleet, which consist of just itself. 

To resupply from ships you have two options:
1- The supply ship has to be inside the fleet that you want resupplied, with instructions to resupply own fleet.   Join & Resupply Target Fleet order would work here. 
or
2- The fleet that wants to ressuply targets the supply vessel (fleet) and give the order to Resupply from Stationary Supply Ship

Well if that is the case I will have to move this to suggestions however I am still not sure.   With the two different ways of resupplying a fleet you've listed its not possible to initiate resupply from the supply ship side without it joining the fleet.   The supply ship either needs to be part of the fleet or needs to sit around and have the fleet needing resupply come to it.   This makes it quite difficult to automate the resupply of stations and any fleet you don't want to move.   If this is working correctly then I would suggest changing the name of the "Resupply with own supply ships" order when you have another fleet selected.   At the moment it is unclear that the order is to resupply the ships own fleet and not the target fleet. 

The join as subfleet function might help make this a little less painful, especially when you have multiple supply ships in play.

It does make it a bit less painful but is still geared towards having a division of supply ships within a bigger fleet.  I'm trying to stay within the bug specification here because I am not sure if this is WAI and therefore everything I'm saying would be a suggestion.

But so far the supply ships work perfectly in the instances of planet to planet logistics, as a division inside a bigger fleet and joining a fleet to resupply it.  They struggle with orbital habitats/space stations and resupplying fleets without joining them. 
Title: Re: v1.13.0 Bugs Thread
Post by: Scout1 on November 16, 2021, 06:46:24 PM
The events log produces no combat text for fighters engaged in "search&destroy" and "planetary flak suppression" missions.  A "Combat summary" event is generated, but the event is blank.  I toggled the colors and background colors a few times *just in case* that was causing text to blend in, but nope. . .  just blank.

It also appears that fighters might not actually be engaging ground forces during these missions, although due to the complete lack of information I'm unsure.  (See edit)   I have fighters reporting catastrophic explosions but I do not know the source - I presume it is due to AA fire.

https://i.imgur.com/gUU6dxa.png

The fighters are equipped with pod bays(size 18), have multiple ground weapon pods(size 6 autocannon) in those bays, have a missile fire control, and the opposing ground forces are in active sensor range of a nearby fleet, being registered as an active contact.  The opposing forces appear to be losing ~100tons per 8-hour ground combat cycle, but that could simply be appears to be the consumption of logistics units.

I tried using SM mode to generate allied ground forces on the planet to see if their presence would cause the fighters' combat summary to appear.  It did not.  I did not test if including FFD in the SM-spawned allied ground forces would affect anything (but the fighters are on a search&destroy mission so it *shouldn't*. . . )

I also tried checking the "Show All Events" button, which produced no change.  Reloading from before the fighters were carrier-launched, and issuing new orders produced no change. 

A previous ground invasion was carried out in this save without any noted game issues.

Per the reporting guidelines: Decimal separator is a comma, date format was changed to shorten, this is a long campaign in the year 2109 (default start date).  No error text or other messages seen that would indicate source of any problems.  No mods, no database edits, only thing I've done is closed the game a few times without saving when I oopsie an order and get everyone killed.

edit: Apparently you have to set the FCs on fighters, which. . .  kind of makes sense? But I really feel like the game should tell you "Hey, buddy.  You're telling them to bomb, but they don't have permission to bomb anything.  You should fix that. " with a 5-second interrupt like an active fire control w/o a target.    The auto-assign is also not able to successfully select MFCs for fighter pod bays, but that's not a huge issue.    Although I now have the fighters correctly shooting at the ground forces, I still am unable to see any reports of AA fire.    Just fighters randomly exploding without apparent cause.  https://i.   imgur.   com/XTpyKgk.   png
Title: Re: v1.13.0 Bugs Thread
Post by: Scout1 on November 16, 2021, 07:34:12 PM
(All above conditions, but different bug)

Fighters on ground attack assignments (search&destroy/planetary flak suppression) do not generate intelligence reports of ground units, although such could be pretty easily calculated by the player's hand with a large enough sample since pod weapons have directly comparable stats to ground units.

Orbital bombardment does not generate intelligence reports (although it *can* display unit names/etc).  The lack of intelligence information from orbital bombardment would seem intentional and reasonable.  The lack of intelligence information from fighters directly attacking units does not.  (WAD?)
Title: Re: v1.13.0 Bugs Thread
Post by: Scout1 on November 16, 2021, 07:41:39 PM
(All above conditions, but different bug)

Something very strange with ground attack fighters (search&destroy tasked).  These are equipped with 3 autocannons in one pod bay (one MFC).  They should have 3 autocannons x 3 shots = 9 shots per combat round.  Instead, they are delivering only 6 shots.  I have included an image showing the events log showing 6 shots per combat round *for every involved fighter* despite them being uniformly equipped for 9 shots per combat round.  Their attacks seem to be spread across multiple unit types, so it's not a matter of 1 MFC = 1 target either.  The cause for this is unclear to me.

https://i.imgur.com/XsQkWj2.png

Note that the organization window displays 'FB Warrior Knight 113', which is the highlighted line(+ one above it) in the events log. 
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on November 17, 2021, 02:59:47 AM
I fixed your Imgur links for convenience. It's an anti-spam function that will vanish once you have posted 10 times.
Title: Re: v1.13.0 Bugs Thread
Post by: Scout1 on November 18, 2021, 01:24:04 PM
I'm not sure where the "bug" begins here and what's intended and isn't.  There's some sort of undocumented mechanic in regards to ground force combat and being outnumbered.  Hits seem to be amalgamated and penetration fudged so that even swarms of conventional infantry can achieve 100% penetrations on maximum teched ultra-heavies if the outnumbering is bad enough.

Reproducible test setup: 10 SM-researched maximum-armor ultraheavy tanks vs TL3-TL4 NPR homeworld garrison of ~1. 1m tons (maximum penetration: 72 from the 'Bee Tank' medium vehicle with a heavy anti-vehicle weapon). 

Chance to penetrate per-hit for even the largest attack should be: (72/540)^2 = ~1. 777%.  Observed penetration rate: 30-70%, or more than 10x the expected rate. 

Below is that test setup showing 2 combat rounds, with penetrations of 7/10 and 3/10 respectively. 

https://i. imgur. com/Wx6xoQm. png

Note that in both cases, the formation suffered 10 hits - exactly as many as units existed in the formation.  Although there are over 100,000 estimated enemy infantry and hundreds if not thousands of incoming shots(estimated).  The hits have been amalgamated in some way that is not documented, causing penetration to be artificially high.

Several additional examples have been seen showing similar results, including a super-heavy(racial AR: 108) drop of 250,000 tons in a live game which resulted in 100% penetration rates to the super-heavies across 1,600 attacks(1 combat round) despite maximum enemy penetration being 72.  (Penetration rate is not 100% in this example, but sufficiently high as to be way above what is possible by RNG).  Please see below image for an example (the super-heavies are called "Invasion Fortress 2110", the HQs and anti-air are medium vehicles with medium armor if such information is helpful).

https://i. imgur. com/y8dyUKg. png

The variable responsible for this seems to be the numbering of allied troops vs enemy troops.  Test setups with arbitrarily large numbers of ultra-heavies (sufficient to match enemy tonnage, or greater) produces closer to the expected penetration results, getting closer and closer the greater the ultra-heavy tonnage advantage is.  I've reviewed all the C# aurora postings and there is no mention of outnumbered attacks causing hit amalgamation or penetration changes.  As far as I am aware, the only penetration formula that exists is: (attacker penetration/defender armor)^2 = %chance to penetrate

Per the reporting guidelines: Decimal separator is a comma, date format was changed to shorten, this is a long campaign in the year 2117 (default start date).   No error text or other messages seen that would indicate source of any problems.   No mods, no database edits.  SM was used to add all relevant armor techs to player race during a game where noted.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 18, 2021, 01:27:34 PM
Per the reporting guidelines: Decimal separator is a comma,

I would bet money that this is your problem. Your decimal separator needs to be a period in order for Aurora to work correctly.
Title: Re: v1.13.0 Bugs Thread
Post by: Scout1 on November 18, 2021, 01:44:58 PM
Quote from: nuclearslurpee link=topic=12522. msg156836#msg156836 date=1637263654
Quote from: Scout1 link=topic=12522. msg156835#msg156835 date=1637263444
Per the reporting guidelines: Decimal separator is a comma,

I would bet money that this is your problem.  Your decimal separator needs to be a period in order for Aurora to work correctly.

Sorry, seems to be some confusion over the terminology here. 

There's two distinct settings: Decimal symbol and list separator.  Decimal symbol is set to period, list separator is set to comma.  As is common in American parlance(I am in the US).  Has been set this way for years, checked it back in the vb6 days.  https://i. imgur. com/3WKhUr7. png

As far as I know these are the valid and correct settings for Aurora to work properly, and all saves and examples given have been with these settings.

This applies to all four previous posts.  I would edit them, but it'll just cause a mess of extra (extra!) spaces added everywhere.  If a mod doesn't edit them in the next day or so, I will.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 18, 2021, 02:48:40 PM
Okay.

I have looked over the screenshots for the last bug report. It looks to me like everything is probably working correctly "under the hood", as the number of penetrations seems to be reasonable given the intel reporting. The issue seems to be that the number of hits reported is a misnomer, and should more accurately be labeled "Number of units hit" and this number is capped to the number of units in the formation/element. Basically, there are no hidden mechanics or gameplay bugs, the error is in the UI which displays this information to the player.
Title: Re: v1.13.0 Bugs Thread
Post by: Silvarelion on November 22, 2021, 04:38:59 PM
Carrier Module blew up.  Tested it on two fresh installs.  Test ship was 100 Hangar bays, plus 100 Large Maintenance bays.  Test 1 had 2 out of 5 ships blowing up with 249 900+ MSP still in the tank after 20 days with a 3 year deployment, 4 year maintenance.  Second test, same ship set up, had a ship blow up in the first 5 day increment.

What you were doing at the time:  Training new carriers with parasites.
Conventional or TN start: Both
Random or Real Stars: Both
Is your decimal separator a comma?  No.
Is the bug is easy to reproduce, intermittent or a one-off? Easily reproduced.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well.  Initial campaign was 70+ years, the two test campaigns were brand new.
Title: Re: v1.13.0 Bugs Thread
Post by: Entaro on November 26, 2021, 03:33:16 PM
Not sure if this is a bug, but this is definitely not the correct logic of the AI ​​behavior:
During the war with NPR, the enemy fleet flew up to my planet and did absolutely nothing, allowing my fleet to approach and shoot it with missiles. Shoot a lot of time and destroy everything.

The class of ships - the same one that fired energy weapons at my colony - but they did not try to use them for point defense against my missiles.
They did not try to get close to me, although my huge ships cannot be overlooked, did not try to escape. They were just in orbit around my colony while I destroyed them.

Details here:
http://aurora2.pentarch.org/index.php?topic=12838.15
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 26, 2021, 04:50:19 PM
I have had something similar happen which was documented in my 1.12 AAR.

My best guess as to the cause is that relations with the NPR somehow dropped enough that they felt obligated to shoot at you (blow up a colony, destroy a few picket ships, whatever), and then in the intervening time relations returned to a neutral enough value that they no longer considered the player hostile. However, when the player then fires at the NPR the NPR seems unable to register that the player is hostile to them, and respond appropriately, until another construction increment passes and they can reassess the relationship status.

It really is a big hole in the NPR logic and very easily exploited to score an early battle victory, and there is not much a player can do to avoid this exploit since the NPR-player relationship is opaque when unfriendly.
Title: Re: v1.13.0 Bugs Thread
Post by: Entaro on November 26, 2021, 05:50:27 PM
I have had something similar happen which was documented in my 1.12 AAR.

My best guess as to the cause is that relations with the NPR somehow dropped enough that they felt obligated to shoot at you (blow up a colony, destroy a few picket ships, whatever), and then in the intervening time relations returned to a neutral enough value that they no longer considered the player hostile. However, when the player then fires at the NPR the NPR seems unable to register that the player is hostile to them, and respond appropriately, until another construction increment passes and they can reassess the relationship status.

It really is a big hole in the NPR logic and very easily exploited to score an early battle victory, and there is not much a player can do to avoid this exploit since the NPR-player relationship is opaque when unfriendly.
Yes, there was a report that the relationship had become neutral some time before they arrived.
It turns out that I myself, without knowing it, used the exploit ... sad (But, I hope this helps to draw attention to this bug :)

But in this case, it is not clear why they are not "at war" with me, they have become in the orbit of my colony for a long time. Perhaps they sent this fleet there even before they "declared neutrality" and that caused the bug? Maybe they wanted to destroy my colony, but did not have time to make this decision?)
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 26, 2021, 07:00:11 PM
But in this case, it is not clear why they are not "at war" with me, they have become in the orbit of my colony for a long time. Perhaps they sent this fleet there even before they "declared neutrality" and that caused the bug? Maybe they wanted to destroy my colony, but did not have time to make this decision?)

Yes. Basically they became annoyed enough at your presence in "their" territory that they decided to shoot at you, then once you were no longer in their territory they calmed down and decided the humans were not so bad. Then they got shot at, but persisted in believing that humans are not so bad for the mandatory 5 day waiting period.

Aurora is weird.  :P
Title: Re: v1.13.0 Bugs Thread
Post by: Entaro on November 26, 2021, 10:20:34 PM
Not sure if this is a bug, given the mechanics of the game, but ...
Found that NPR was flying near my fleet with his small fleet. With an interval of an hour or 3 hours, it flies into the range of my missiles for several million km, and then immediately flies away. I don't know if this is an attempt to simulate tactics so that I spend missiles, or he simply does not see me at a distance of more than 70 million km, and cannot remember where I was just when he retreats, but ...
In general, I chose an interval of 8 hours. And after 8 hours the enemy fleet was right next to mine, which allowed me to easily destroy it. It looks like the AI ​​is processing fleet movement decisions no more often than my time frame ...? Sadly, I will have to take this feature into account and try not to use it, but the enemy fleet flying on the edge of the range of my missiles is enraging.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on November 27, 2021, 07:02:39 AM
Okay.

I have looked over the screenshots for the last bug report. It looks to me like everything is probably working correctly "under the hood", as the number of penetrations seems to be reasonable given the intel reporting. The issue seems to be that the number of hits reported is a misnomer, and should more accurately be labeled "Number of units hit" and this number is capped to the number of units in the formation/element. Basically, there are no hidden mechanics or gameplay bugs, the error is in the UI which displays this information to the player.

The number of hits is reported, rather than the number of units destroyed. You don't have exact knowledge of the number of enemy units, at least until the battle has been going on for quite a while, so this reflects the claims of your own forces, not the 'true' situation. It is similar to what happens in reality where multiple sources may claim the same 'kill'.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on November 27, 2021, 07:05:33 AM
I have had something similar happen which was documented in my 1.12 AAR.

My best guess as to the cause is that relations with the NPR somehow dropped enough that they felt obligated to shoot at you (blow up a colony, destroy a few picket ships, whatever), and then in the intervening time relations returned to a neutral enough value that they no longer considered the player hostile. However, when the player then fires at the NPR the NPR seems unable to register that the player is hostile to them, and respond appropriately, until another construction increment passes and they can reassess the relationship status.

It really is a big hole in the NPR logic and very easily exploited to score an early battle victory, and there is not much a player can do to avoid this exploit since the NPR-player relationship is opaque when unfriendly.

I can't find this bug. If you fire on an NPR, they will declare you hostile immediately. There may be a situation, as I suspect happened in the original report, where an NPR turns hostile but won't fire on a population without STOs. Some NPRs will avoid planetary bombardment in favour of ground attack.
Title: Re: v1.13.0 Bugs Thread
Post by: Entaro on November 27, 2021, 12:01:06 PM
I can't find this bug. If you fire on an NPR, they will declare you hostile immediately. There may be a situation, as I suspect happened in the original report, where an NPR turns hostile but won't fire on a population without STOs. Some NPRs will avoid planetary bombardment in favour of ground attack.
If you have time, attach it to your post above - your save in the middle of the battle.

The enemy fleet was over my planet and did nothing. I shot him with rockets, and there was no reaction to this. Generally. No attempt to fly away, no attempt to get close to attack.

I can list a number of other things that may not be bugs, but this is definitely what is a flaw in the AI ​​logic:
1. It seemed to me that the template of the main ships of the enemy for 30 years has not changed. These are all the same ships, with the same tonnage, speed, and weak railgun armament. But the enemy built several dozen more of just such ships.
2. Being armed with railguns, this type of ships did not try to use it against missiles.
In principle, this can be explained logically - if they do not have sensors that can see my missiles ... But this is rather stupid.
If there are no such sensors on this ship, what prevents the AI ​​from adding to the fleet consisting of such ships - several ships capable of detecting incoming missiles?
3. The civilization with which I am at war does not have any missiles at all. Neither anti-ship nor anti-missile. This allows me to destroy their ships from a distance just by shooting at targets. The only "difficulty" I face is to calculate the number of missiles so as not to waste extra ones.
If only they used their railguns for defensive fire against my missiles ... but that doesn't happen either.
4. Well, with the logic of the division of the AI ​​fleets, something needs to be done ... Perhaps I could not have destroyed their entire fleet together (I would have run out of missiles and my slow rocket platforms would not have escaped), but I could easily deal with several parts of their fleet.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 27, 2021, 12:01:44 PM
I can't find this bug. If you fire on an NPR, they will declare you hostile immediately. There may be a situation, as I suspect happened in the original report, where an NPR turns hostile but won't fire on a population without STOs. Some NPRs will avoid planetary bombardment in favour of ground attack.

What happened to me in my 1.12 game was:
If you can tolerate reading my admittedly long-winded writing, the original account of these "battles" can be found in my AAR thread here (http://aurora2.pentarch.org/index.php?topic=12445.msg149776#msg149776). Again, it is a 1.12 game so not the current version but Entaro reports something quite similar so I suspect the bug still exists in 1.13. Seems like a tricky one to track down but hopefully having more information helps. I do want to note that in this campaign I have not build any STOs, nor has the NPR even come near any of my populations since they initially opened fire on my ships.
Title: Re: v1.13.0 Bugs Thread
Post by: Entaro on November 27, 2021, 12:04:25 PM
If you can tolerate reading my admittedly long-winded writing, the original account of the battle can be found in my AAR thread here (http://aurora2.pentarch.org/index.php?topic=12445.msg149776#msg149776). Again, it is a 1.12 game so not the current version but Entaro reports something quite similar so I suspect the bug still exists in 1.13. Seems like a tricky one to track down but hopefully having more information helps. I do want to note that in this campaign I have not build any STOs, nor has the NPR even come near any of my populations since they initially opened fire on my ships.
It seems to me that this error is very easy to track down, just take the save in the middle of the battle from the person who encountered this error and load it :)
The only thing - I'm not sure if the building time counter doesn't reset after loading the game.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on November 27, 2021, 01:30:17 PM
I can't find this bug. If you fire on an NPR, they will declare you hostile immediately. There may be a situation, as I suspect happened in the original report, where an NPR turns hostile but won't fire on a population without STOs. Some NPRs will avoid planetary bombardment in favour of ground attack.
If you have time, attach it to your post above - your save in the middle of the battle.

The enemy fleet was over my planet and did nothing. I shot him with rockets, and there was no reaction to this. Generally. No attempt to fly away, no attempt to get close to attack.

I can list a number of other things that may not be bugs, but this is definitely what is a flaw in the AI ​​logic:
1. It seemed to me that the template of the main ships of the enemy for 30 years has not changed. These are all the same ships, with the same tonnage, speed, and weak railgun armament. But the enemy built several dozen more of just such ships.
2. Being armed with railguns, this type of ships did not try to use it against missiles.
In principle, this can be explained logically - if they do not have sensors that can see my missiles ... But this is rather stupid.
If there are no such sensors on this ship, what prevents the AI ​​from adding to the fleet consisting of such ships - several ships capable of detecting incoming missiles?
3. The civilization with which I am at war does not have any missiles at all. Neither anti-ship nor anti-missile. This allows me to destroy their ships from a distance just by shooting at targets. The only "difficulty" I face is to calculate the number of missiles so as not to waste extra ones.
If only they used their railguns for defensive fire against my missiles ... but that doesn't happen either.
4. Well, with the logic of the division of the AI ​​fleets, something needs to be done ... Perhaps I could not have destroyed their entire fleet together (I would have run out of missiles and my slow rocket platforms would not have escaped), but I could easily deal with several parts of their fleet.

The problem is that if was a common issue, it would have been raised and fixed by now. I have no idea why the AI in your game is not using its railguns to fire against inbound missiles, when it works fine in my games and apparently other games. Are you using long time jumps perhaps so the missiles pass through the AI sensor range in a single increment?

A beam-only strategy is fine. As you play more games, you will learn about the strategic weaknesses of missiles, despite their short-term tactical advantages.
Title: Re: v1.13.0 Bugs Thread
Post by: Entaro on November 27, 2021, 01:41:27 PM

The problem is that if was a common issue, it would have been raised and fixed by now. I have no idea why the AI in your game is not using its railguns to fire against inbound missiles, when it works fine in my games and apparently other games. Are you using long time jumps perhaps so the missiles pass through the AI sensor range in a single increment?

A beam-only strategy is fine. As you play more games, you will learn about the strategic weaknesses of missiles, despite their short-term tactical advantages.
I understood. Perhaps the problem is in my game, precisely with my enemy, who, due to the fact that I found him too early, or for some other reason, did not include in his base warships or active scanners against missiles, or the point function itself protection ... it's weird. I will try to fight other AIs and write if everything goes well.
By the way, this AI has a ship type capable of shooting down missiles and using point defense. The problem is with only one class of ships.

No, I use 5 second time intervals during combat and my missiles approaching.

As for the beam ships - I understand. In fact, if they used their 17 * 4 railguns on each of their beam ships, including for point defense, it would be very difficult for me. I suspect in that case, I would simply run out of missiles ... in which case it would be a winning strategy from the point of view of AI.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on November 27, 2021, 01:42:26 PM
I can't find this bug. If you fire on an NPR, they will declare you hostile immediately. There may be a situation, as I suspect happened in the original report, where an NPR turns hostile but won't fire on a population without STOs. Some NPRs will avoid planetary bombardment in favour of ground attack.

What happened to me in my 1.12 game was:
  • NPR gets mad for some reason and blows up a few of my JP monitor ships.
  • After a bit, I get a notification that the NPR now considers me neutral again.
  • Some short time later, as my fleets arrive on the scene I engage the NPRs in a series of battles. Despite having multiple of their fleets fired upon and destroyed by my railgun-armed ships, the NPR does not fire back - and they assuredly had sufficient opportunity to do so.
  • Once the construction increment ticked over, the next NPR fleet I engaged fired back as expected.
If you can tolerate reading my admittedly long-winded writing, the original account of these "battles" can be found in my AAR thread here (http://aurora2.pentarch.org/index.php?topic=12445.msg149776#msg149776). Again, it is a 1.12 game so not the current version but Entaro reports something quite similar so I suspect the bug still exists in 1.13. Seems like a tricky one to track down but hopefully having more information helps. I do want to note that in this campaign I have not build any STOs, nor has the NPR even come near any of my populations since they initially opened fire on my ships.

I'm almost 100% certain you will have checked this, but I need to ask anyway :)  I assume the attacked NPR units were warships and had weapons with sufficient range to engage you?

The mechanics for this are based on diplomatic points. When you inflict damage on a ship it lowers the diplomacy points. If the current level is still above -101 post-damage, it reduces to that point and declares war (changes the status of your race to hostile). The only exception in the code is a situation where the NPR has no alien race record, but that is more of a bug-check than anticipating a real situation.

Its odd that a construction cycle fixes things because there is nothing related to combat or damage in political terms during that phase. That only changes during combat phases. It is also a rare bug, because otherwise this would get reported a LOT. Some very weird combination of circumstances must be in play. Can you think of anything else unusual about the situation?

Also, if it happens again, please can you save the DB.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on November 27, 2021, 02:03:58 PM
I'm almost 100% certain you will have checked this, but I need to ask anyway :)  I assume the attacked NPR units were warships and had weapons with sufficient range to engage you?

Yes. Missiles and 10cm + 15cm lasers against my 10cm + 15cm railguns, so range would not be a problem for the NPR fleets. Most of the ships were armed aside from a jump cruiser class (Kiev) and one stabilisation ship (Svobodny).

Quote
The mechanics for this are based on diplomatic points. When you inflict damage on a ship it lowers the diplomacy points. If the current level is still above -101 post-damage, it reduces to that point and declares war (changes the status of your race to hostile). The only exception in the code is a situation where the NPR has no alien race record, but that is more of a bug-check than anticipating a real situation.

Its odd that a construction cycle fixes things because there is nothing related to combat or damage in political terms during that phase. That only changes during combat phases. It is also a rare bug, because otherwise this would get reported a LOT. Some very weird combination of circumstances must be in play. Can you think of anything else unusual about the situation?

The closest thing to "unusual" I can think of, besides what I already described, is that the first fleet I engaged came through a jump point - I initially thought they were suffering from some extremely long jump shock. However the next two battles before the construction tick were in open space and exhibited the same behavior.

Quote
Also, if it happens again, please can you save the DB.

I'll do my best. Looking over my post history I realize I never filed a bug report since this was in a 1.12 game after 1.13 had been released, but I will try to save the DB next time even if this happens in my 1.12 campaign in case it is still useful.
Title: Re: v1.13.0 Bugs Thread
Post by: Entaro on November 27, 2021, 02:11:50 PM
I'm almost 100% certain you will have checked this, but I need to ask anyway :)  I assume the attacked NPR units were warships and had weapons with sufficient range to engage you?

Also, if it happens again, please can you save the DB.
In my case, these were warships, had weapons, but did not have sufficient range to attack my ships (but could attack the planet, or try to get closer, or try to retreat).

In my case, the database is saved, in addition:
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on November 28, 2021, 07:31:31 AM
I'm almost 100% certain you will have checked this, but I need to ask anyway :)  I assume the attacked NPR units were warships and had weapons with sufficient range to engage you?

Also, if it happens again, please can you save the DB.
In my case, these were warships, had weapons, but did not have sufficient range to attack my ships (but could attack the planet, or try to get closer, or try to retreat).

In my case, the database is saved, in addition:

Is this database after the point you opened fire, but before the next construction phase?
Title: Re: v1.13.0 Bugs Thread
Post by: smoelf on November 29, 2021, 11:04:09 AM
When acquiring knowledge of another system through espionage, it seems that the system is not renamed according to the player's naming scheme, but uses the naming scheme of the target of the espionage. It might not be a bug per se, but it ends up looking rather weird to have a systems named 'System #85' and 'System #938' alongside your other system names.

This is for 1.13.
Title: Re: v1.13.0 Bugs Thread
Post by: LuuBluum on November 29, 2021, 03:06:02 PM
According to this post (http://aurora2.pentarch.org/index.php?topic=8495.msg101818#msg101818), and specifically this quote:

Quote
For auto-assignment purposes, each ship class now has a specific rank requirement for its commander, based on its command and control modules. The rank requirement for the XO, CAG and Science Officer is one lower than for the ship commander. The rank requirement for the Chief Engineer and Tactical Office is two lower than the ship commander. The rank requirement for a fleet commander is one higher than for the ship commander. You can manually assign higher-ranked ship commanders and fleet commanders if desired but other officers can only be assigned at the specified rank. The commander priority setting for each class of ship remains as before and is still set manually.

(emphasis mine)

It is not possible to assign fleet commanders of higher rank; their rank is fixed like every other. The "Senior C.O." button merely raises all of these ranks by 1, but does not alleviate the issue.

Version 1.13
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on November 30, 2021, 06:12:13 PM
When you create a Prototype component, the message in the log says "A prototype of XYZ has been created".
When you create a Future Prototype component, the message in the log says "Research into ABC completed".

(As an aside, because the event type for prototypes is 'research completed' you can't hide prototype events in the log without hiding real completed research)
Title: Re: v1.13.0 Bugs Thread
Post by: Andrew on December 01, 2021, 06:27:16 PM
On exploring a Jump point I got a long series of errors. Examination of the system reveals that on the Habitable world an NPR and a Rakasha race were generated at the same time. It looks like the NPR got not ships as a result . I don't think this is meant to happen.I have a saved game just after I detected teh 2 races
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on December 02, 2021, 04:32:23 AM
On exploring a Jump point I got a long series of errors. Examination of the system reveals that on the Habitable world an NPR and a Rakasha race were generated at the same time. It looks like the NPR got not ships as a result . I don't think this is meant to happen.I have a saved game just after I detected teh 2 races
I'm pretty sure this is a known issue and should be fixed for the next version already.
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on December 04, 2021, 02:31:43 PM
I think this is probably not WAI.
In the Economy window, Industry tab, when selecting the destination fleet for Fighters and Space Stations, you can select civilian fleets.
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on December 04, 2021, 03:52:39 PM
Sorry for the double post but this is a different issue.
When a commander is assigned to an Academy it doesn't generate a Command Assignment event in the event log. (The commander history does show them being assigned)
I suspect, but I'm not certain, that when officers die or retire when commanding an Academy, it doesn't generate the relevant Commander Health or Retirement events.
Title: Re: v1.13.0 Bugs Thread
Post by: dsedrez on December 04, 2021, 11:30:18 PM
I've found a number of laser mounts with capacitor 4, and tried to disassemble them to get the tech. The events reported a number of research points gained, but the number of points didn't change in the research tab. I'm currently with Capacitor Tech 3.

Apparently there was a number of bugs regarding the disassembly of components in previous versions, but I didn't find this one, so I'm reporting it here.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on December 04, 2021, 11:38:05 PM
I've found a number of laser mounts with capacitor 4, and tried to disassemble them to get the tech. The events reported a number of research points gained, but the number of points didn't change in the research tab. I'm currently with Capacitor Tech 3.

Apparently there was a number of bugs regarding the disassembly of components in previous versions, but I didn't find this one, so I'm reporting it here.

I wonder if the research points are being diverted to the Cap 3.25 tech (and similar at other tech levels)?
Title: Re: v1.13.0 Bugs Thread
Post by: dsedrez on December 04, 2021, 11:56:27 PM
I've found a number of laser mounts with capacitor 4, and tried to disassemble them to get the tech. The events reported a number of research points gained, but the number of points didn't change in the research tab. I'm currently with Capacitor Tech 3.

Apparently there was a number of bugs regarding the disassembly of components in previous versions, but I didn't find this one, so I'm reporting it here.

I wonder if the research points are being diverted to the Cap 3.25 tech (and similar at other tech levels)?

Now that you mention, I think it's quite possible...


Another one, I'm not sure if it's a bug or WAI, but a terraforming station under tow doesn't terraform the planet below. It was working, but the task was almost complete so I sent the tug to prepare to move it to the next body. And then the terraforming rate fell to 0, when it was 0.0001 before (it was a big planet). Ordering the release of the station corrects the issue.
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on December 05, 2021, 02:56:54 AM
Another one, I'm not sure if it's a bug or WAI, but a terraforming station under tow doesn't terraform the planet below. It was working, but the task was almost complete so I sent the tug to prepare to move it to the next body. And then the terraforming rate fell to 0, when it was 0.0001 before (it was a big planet). Ordering the release of the station corrects the issue.
This is WAI. When anything gets tractored, it stops being useful and becomes inert lump of mass.
Title: Re: v1.13.0 Bugs Thread
Post by: somebody1212 on December 05, 2021, 04:51:02 PM
ECM modules currently stack for combat purposes. The design screen does not show the increased ECM rating but it does show in the combat reports in the event log.

Steps to reproduce:
Design a ship and add multiple ECM modules.
Spawn in the ship and spawn in another ship to shoot at it.
Fire at the ship with multiple ECM modules. Note that your chance to hit has been reduced by each of the ECM modules, not just by one.

This means that, for example, a ship with 20 ECM 2 modules reduces incoming fire by 400%, making it effectively immune to everything.

Example logs from firing at ships with 1, 2 and 3 ECM 3 modules:
Sensor data reveals that the alien class AMT Target ECM 3 x1 has an ECM rating of 30
Sensor data reveals that the alien class AMT Target ECM 3 x2 has an ECM rating of 60
Sensor data reveals that the alien class AMT Target ECM 3 x3 has an ECM rating of 90
AMT Tribal 001 attacked AMT Target ECM 3 x1 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 100%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x1 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1
AMT Tribal 001 attacked AMT Target ECM 3 x2 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 70%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x2 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1
AMT Tribal 001 attacked AMT Target ECM 3 x3 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 40%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x3 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1



Iceranger's been doing some further testing on this bug on the Discord but isn't able to make a post on the forum at the moment so I'm posting this here so it doesn't get missed - he should be along later with more details of his testing.
Title: Re: v1.13.0 Bugs Thread
Post by: Density on December 05, 2021, 05:00:12 PM
Sorry for the double post but this is a different issue.
When a commander is assigned to an Academy it doesn't generate a Command Assignment event in the event log. (The commander history does show them being assigned)
I suspect, but I'm not certain, that when officers die or retire when commanding an Academy, it doesn't generate the relevant Commander Health or Retirement events.
I just had a ground officer retire from an academy; it generated the retirement event and current assignment was listed as part of that event. And I know I've seen health events for academy commanders (idk specifically about death, but I'd be surprised if it were different).
The problem is promotions, where the assigment the officer is getting promoted out of is a seperate event from the promotion event itself. As with assigning, unassigning from an academy doesn't generate an event.
Title: Re: v1.13.0 Bugs Thread
Post by: Density on December 05, 2021, 05:13:51 PM
Another one, I'm not sure if it's a bug or WAI, but a terraforming station under tow doesn't terraform the planet below. It was working, but the task was almost complete so I sent the tug to prepare to move it to the next body. And then the terraforming rate fell to 0, when it was 0.0001 before (it was a big planet). Ordering the release of the station corrects the issue.
This is WAI. When anything gets tractored, it stops being useful and becomes inert lump of mass.
That's inaccurate. If it were true, tractor-trailer shipping wouldn't work (and it does). Further, I've done the above expecting the terraforming rate to drop and was surprised at the time that it didn't until I moved the towed station away from the body.
Title: Re: v1.13.0 Bugs Thread
Post by: Iceranger on December 05, 2021, 08:01:30 PM
ECM modules currently stack for combat purposes. The design screen does not show the increased ECM rating but it does show in the combat reports in the event log.

Steps to reproduce:
Design a ship and add multiple ECM modules.
Spawn in the ship and spawn in another ship to shoot at it.
Fire at the ship with multiple ECM modules. Note that your chance to hit has been reduced by each of the ECM modules, not just by one.

This means that, for example, a ship with 20 ECM 2 modules reduces incoming fire by 400%, making it effectively immune to everything.

Example logs from firing at ships with 1, 2 and 3 ECM 3 modules:
Sensor data reveals that the alien class AMT Target ECM 3 x1 has an ECM rating of 30
Sensor data reveals that the alien class AMT Target ECM 3 x2 has an ECM rating of 60
Sensor data reveals that the alien class AMT Target ECM 3 x3 has an ECM rating of 90
AMT Tribal 001 attacked AMT Target ECM 3 x1 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 100%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x1 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1
AMT Tribal 001 attacked AMT Target ECM 3 x2 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 70%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x2 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1
AMT Tribal 001 attacked AMT Target ECM 3 x3 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 40%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x3 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1



Iceranger's been doing some further testing on this bug on the Discord but isn't able to make a post on the forum at the moment so I'm posting this here so it doesn't get missed - he should be along later with more details of his testing.


More details on my test for this bug:

Target ships used are as below. They only show ECM30, but the actual ECM modules mounted on the ship are recorded in their names.

Code: [Select]
Target ECM 3 x1 class Ammunition Transport      4,043 tons       16 Crew       969.2 BP       TCS 81    TH 0    EM 0
1 km/s      Armour 40-22       Shields 0-0       HTK 3      Sensors 0/0/0/0      DCR 1      PPV 0
Maint Life 3.12 Years     MSP 149    AFR 131%    IFR 1.8%    1YR 23    5YR 345    Max Repair 30 MSP
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

ECM 30

Code: [Select]
Target ECM 3 x2 class Ammunition Transport      4,455 tons       22 Crew       1,061.6 BP       TCS 89    TH 0    EM 0
1 km/s      Armour 40-24       Shields 0-0       HTK 4      Sensors 0/0/0/0      DCR 1      PPV 0
Maint Life 2.46 Years     MSP 148    AFR 159%    IFR 2.2%    1YR 34    5YR 507    Max Repair 30 MSP
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

ECM 30

Code: [Select]
Target ECM 3 x3 class Ammunition Transport      4,848 tons       28 Crew       1,149.6 BP       TCS 97    TH 0    EM 0
1 km/s      Armour 40-25       Shields 0-0       HTK 5      Sensors 0/0/0/0      DCR 1      PPV 0
Maint Life 2.13 Years     MSP 148    AFR 188%    IFR 2.6%    1YR 44    5YR 657    Max Repair 30 MSP
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

ECM 30

Code: [Select]
Target ECM 3 x2 ECM 2 x1 class Ammunition Transport      4,860 tons       32 Crew       1,142.3 BP       TCS 97    TH 0    EM 0
1 km/s      Armour 40-25       Shields 0-0       HTK 5      Sensors 0/0/0/0      DCR 1      PPV 0
Maint Life 2.23 Years     MSP 146    AFR 189%    IFR 2.6%    1YR 40    5YR 595    Max Repair 30 MSP
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

ECM 30

Code: [Select]
Target ECM 3 x2 ECM 2 x2 class Ammunition Transport      5,250 tons       42 Crew       1,219.2 BP       TCS 105    TH 0    EM 0
1 km/s      Armour 40-26       Shields 0-0       HTK 7      Sensors 0/0/0/0      DCR 1      PPV 0
Maint Life 2.09 Years     MSP 145    AFR 220%    IFR 3.1%    1YR 44    5YR 667    Max Repair 30 MSP
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

ECM 30

Code: [Select]
Target ECM 3 x2 ECM 2 x3 class Ammunition Transport      5,616 tons       52 Crew       1,290.7 BP       TCS 112    TH 0    EM 0
1 km/s      Armour 40-28       Shields 0-0       HTK 8      Sensors 0/0/0/0      DCR 1      PPV 0
Maint Life 1.91 Years     MSP 143    AFR 252%    IFR 3.5%    1YR 51    5YR 762    Max Repair 30 MSP
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

ECM 30

The attacker, nothing special but it definitely should have 100% hit chance against the target at point blank range.
Code: [Select]
Tribal class Ammunition Transport      4,097 tons       213 Crew       1,510.8 BP       TCS 82    TH 0    EM 0
1 km/s      Armour 1-22       Shields 0-0       HTK 29      Sensors 0/0/0/0      DCR 1      PPV 31.68
Maint Life 1.10 Years     MSP 230    AFR 134%    IFR 1.9%    1YR 191    5YR 2,870    Max Repair 320 MSP
Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

Fuel Capacity 50,000 Litres    Range N/A

Single 25.0cm C4 Far Ultraviolet Laser Turret (3x1)    Range 320,000km     TS: 20000 km/s     Power 16-4     RM 50,000 km    ROF 20       
Beam Fire Control R320-TS20000 (3)     Max Range: 320,000 km   TS: 20,000 km/s     97 94 91 88 84 81 78 75 72 69
Tokamak Fusion Reactor R13 (1)     Total Power Output 12.6    Exp 5%

Active Search Sensor AS11-R1 (1)     GPS 28     Range 11.2m km    MCR 1m km    Resolution 1

ECCM-3 (3)         This design is classed as a Military Vessel for maintenance purposes
This design is classed as a c for auto-assignment purposes

Actual relevant logs:
Code: [Select]
Sensor data reveals that the alien class AMT Target ECM 3 x1 has an ECM rating of 30
Sensor data reveals that the alien class AMT Target ECM 3 x2 has an ECM rating of 60
Sensor data reveals that the alien class AMT Target ECM 3 x3 has an ECM rating of 90
AMT Tribal 001 attacked AMT Target ECM 3 x1 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 100%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x1 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1
AMT Tribal 001 attacked AMT Target ECM 3 x2 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 70%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x2 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1
AMT Tribal 001 attacked AMT Target ECM 3 x3 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 40%    Shots 1    Damage per Hit 16    Armour Hits 1    New Target Speed 1 km/s
AMT Target ECM 3 x3 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    Armour Hits 1

Sensor data reveals that the alien class AMT Target ECM 3 x2 ECM 2 x1 has an ECM rating of 80
Sensor data reveals that the alien class AMT Target ECM 3 x2 ECM 2 x2 has an ECM rating of 100
Sensor data reveals that the alien class AMT Target ECM 3 x2 ECM 2 x3 has an ECM rating of 120
AMT Tribal 001 attacked AMT Target ECM 3 x2 ECM 2 x1 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 50%    Shots 1    Damage per Hit 16    No hits    New Target Speed 1 km/s
AMT Target ECM 3 x2 ECM 2 x1 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    No hits
AMT Tribal 001 attacked AMT Target ECM 3 x2 ECM 2 x2 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 30%    Shots 1    Damage per Hit 16    No hits    New Target Speed 1 km/s
AMT Target ECM 3 x2 ECM 2 x2 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    No hits
AMT Tribal 001 attacked AMT Target ECM 3 x2 ECM 2 x3 001 with Single 25.0cm C4 Far Ultraviolet Laser Turret.    Range 0 km    Chance to Hit 10%    Shots 1    Damage per Hit 16    No hits    New Target Speed 1 km/s
AMT Target ECM 3 x2 ECM 2 x3 001 attacked by AMT Tribal 001 using energy weapons.    Range 0 km    Shots 1    Damage per Hit 16    No hits

So ALL installed ECM modules stack in combat calculation (also in the alien ship intel screen), only in the ship design screen it displays the correct ECM rating.

Test DB file attached.

SJW: Fixed for v2.0. Thanks for testing it.
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on December 05, 2021, 09:28:09 PM
Sorry for the double post but this is a different issue.
When a commander is assigned to an Academy it doesn't generate a Command Assignment event in the event log. (The commander history does show them being assigned)
I suspect, but I'm not certain, that when officers die or retire when commanding an Academy, it doesn't generate the relevant Commander Health or Retirement events.
I just had a ground officer retire from an academy; it generated the retirement event and current assignment was listed as part of that event. And I know I've seen health events for academy commanders (idk specifically about death, but I'd be surprised if it were different).
The problem is promotions, where the assigment the officer is getting promoted out of is a seperate event from the promotion event itself. As with assigning, unassigning from an academy doesn't generate an event.
Good to know.
The reason I reported assignment but not unassignment as a bug was because I was going by what happens when you assign a commander to a ship, which is admittedly an assumption. Ship commanders who are manually replaced don't get an unassignment message, as the same thing occurred for academy commanders I assumed it was WAI.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on December 20, 2021, 04:38:25 AM
The ship designs of all the civilian lines I deleted have returned from the netherworld to haunt me in the design window. Looks like this old report:
http://aurora2.pentarch.org/index.php?topic=11565.msg139813#msg139813

In the DB , ClassShippingLineID is 0.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on December 20, 2021, 05:38:47 PM
My fleet spent its ordnance in battle and should replenish its missiles from a tender. But no missiles are transferred. I tried with a different tender type and different warship type and different missile type, same result. The tender can remove missiles, but not load the size 10 type. However, it does work as advertised with my size 1 AMMs.

My ships all have *both* box and normal launchers in size 10. Is that the problem, that magazines do not get reloaded in space if box launchers are present on the same ship?

http://aurora2.pentarch.org/index.php?topic=12522.msg156478#msg156478
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on December 24, 2021, 10:02:18 AM
I have finally captured two Precursor cruisers, both armed with missiles. All is fine; their mags were empty after I captured them. Nobody tried to load/unload anything from them.

Now, months later, I was trying to rearm two carrier groups in the Precursor system, where the fight is still going on (due to lack of ammo on my part). Rearming in space can be painful with the new ordnance system and I was experimenting with various ways of load/unload/replace missiles (I needed to get old missiles out and new ones in, with no spare room in the tender's magazine). After some time I noticed Alien missile types on the tender, and plenty of them. I fly to a nearby staging area where I had placed an ordnance transfer point and unloaded the stuff. Well.

Days later they were still unloading, with their magazines still full. The missile horn of plenty. Mineral cornucopia.

(Disclaimer: I tinkered with the DB several times earlier in this game by changing the X-coordinate of misbehaving NPR fleets. Nothing else.)

Savegame here:
https://ufile.io/q08jni82
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on December 24, 2021, 10:44:18 AM
After some time I noticed Alien missile types on the tender, and plenty of them. I fly to a nearby staging area where I had placed an ordnance transfer point and unloaded the stuff.

Are you sure you didn't have the tenders pick these up from the planet some time ago and forgot about them? Precursor planets usually contain large stockpiles of missiles, so it seems probable that you may have gotten them from the planet after capturing it.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on December 25, 2021, 05:18:27 AM
I never captured anything in this game. The only time I tried I was taught a lesson about cosmophibious invasions, if that's the term.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on December 27, 2021, 05:38:25 PM
My boarding team (30 guys, 4 machineguns, 1 boss) is counted twice.
Title: Re: v1.13.0 Bugs Thread
Post by: SikeSky on January 02, 2022, 02:20:47 PM
1. 13. 0 - Function #2047: Object Reference not set to an instance of an object

Using the missile design window and selecting any of the ground support weapon boxes - bombardment, autocannon, or air-to-air.  Pressing "Instant research" does not do anything other than give the error message.  Pressing "Create project" displays the error message but also creates the research project.  I was able to research the project and add the weapon to ship designs.
I vaguely remember running into this same bug when I first started the campaign.  I'd been hesitating to use ground support fighters and only now do I remember why.

TN Start
Real Stars, I think
Decimal Separator
108 year long campaign
Title: Re: v1.13.0 Bugs Thread
Post by: Grimm Spector on January 04, 2022, 06:13:13 PM
Error: 1.    13.    0 Function #2184: Value was either too large or too small for a Decimal.   
Error: 1.    13.    0 Function #2092: Value was either too large or too small for a Decimal.   

When I click on Venus I get this error message, I also get it randomly sometimes when passing time.     I can never see how many minerals are left on Venus, which is the other large body in Sol that had minerals for me.     Conversely you can see Mars in the third image which has none, just to allay anyone who doesn't recall what the screen looks like when there's no minerals.     I assume the turn proc error is when it tries to fire the Mass Driver.     Fourth image is the proc.     And as seen in the fifth image, the mineral packet is empty.    .    .    so I've been getting no minerals from Venus this whole time, without realizing it, explaining why I've run out on Earth soooo quickly.     So I guess this entire save is borked.     :( What a waste of time.     If anyone knows a good way to salvage this I'd love to know!



This means I can never see how many minerals are left on Venus, to make any judgement about adding or removing more mines or population.     Or as far as I can tell, retrieve any minerals whatsoever.   



Images imgur link! https://imgur.    com/a/OC6v24U

Couldn't post the fifth or sixth image due to forum limitations.     Sixth image shows a Cargo attempt and all minerals show 0 despite the mining having been going on there for more than a decade now.   

TN Start
Real Stars
Comma Separator I think? Like a million is 1,000,000
Don't know the campaign length, if it's a setting? Game started in 2025 it's now 2053. 
Don't know how I'd even go about reproducing this bug. 

Nothing really modified in the start or racial parameters, just a normal game.     Haven't mucked around with anything.     When I originally surveyed Venus it was fine, it had a ground survey option, and everything went well at first and then suddenly it looks like it must've lost or corrupted some data or something.   

Edit: Added a seventh image to the imgur link that shows the survey screen, showing what Venus is SUPPOSED to have, what it generated with on it's own.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on January 04, 2022, 11:07:30 PM
I think I have seen this one before. When there is a planet with a very large amount of low-accessibility resources, it is possible for the time-to-depletion value to exceed the size of what can be stored in a C# Decimal type if you have either very few mines there or (as is common with Venus) a very small actual production due to low manufacturing efficiency. Probably a similar error is causing the random turn pop-ups, possibly due to the mass driver having too small of a packet.

This has been fixed in the v2.0 which will release Soon™. In the meantime my suggestion is to not place manual mines on Venus, automatic mines should probably be fine if you really want to mine Venus. However, it is very rarely worth doing anyways and I would just not colonize Venus at least until you have much better terraforming tech, as it is a surprisingly tricky endeavor fraught with peril (OrbHabs, for example, rarely work as well as you hope).
Title: Re: v1.13.0 Bugs Thread
Post by: silverpenny7 on January 06, 2022, 08:09:29 AM
Bug? Size 100 Missile Launchers is missing from the research project options. 
Title: Re: v1.13.0 Bugs Thread
Post by: Silvarelion on January 06, 2022, 12:14:02 PM
Missiles don't hit tugged ships.

Seems to happen every time my tugged survey ships encounter precursors, the tug dies, while the tugged ship has a 0% hit rate against it.  Once the tug dies, the tugged ship starts moving at 1/3rd the speed of light.
Title: Re: v1.13.0 Bugs Thread
Post by: Silvarelion on January 06, 2022, 12:15:19 PM
When applying multiple SM internal damage to a ship, multiple wrecks can be formed.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on January 06, 2022, 12:20:41 PM
When applying multiple SM internal damage to a ship, multiple wrecks can be formed.

I never knew about this, but now that I do I think this could be kept as a feature to create scenarios with multiple wrecks around a planet very easily.
Title: Re: v1.13.0 Bugs Thread
Post by: GodEmperor on January 06, 2022, 04:09:11 PM
It seems like sometimes researching a player created component doesnt stick.
You design it, get it to research guys, they complete it ( the message about finishing research project shows ) and the part is nowhere to be seen on either tech screen, production screen, ship design, loadout ( if missile ) etc.

EDIT : it seems to happen mostly to missiles.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on January 06, 2022, 04:22:04 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on January 09, 2022, 03:25:36 AM
The numbers under Total Organization don't add up. I haven't done the math yet, but I'd say that some units belonging to this HQ, which are probably stuck on a transport out of fuel in godknowswhere, are included in the total. Is that by design?
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on January 09, 2022, 09:35:57 AM
I think I remember seeing an earlier post that there is a bug where units in certain formations get counted twice. Can you correlate the numbers in the Complete Organization section with formations to see which one(s) might be doubled?
Title: Re: v1.13.0 Bugs Thread
Post by: Froggiest1982 on January 09, 2022, 09:05:56 PM
I think I have already highlighted this and I don't remember if I have already received an answer.

Gauss Turrets appears for research under Energy Weapons and require an Energy Weapons scientist to be researched with a bonus.

I believe Gauss Turrets should be researched under kinetics weapons by a Missile and Kinetic Weapons Scientist.

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on January 09, 2022, 09:14:40 PM
I think I have already highlighted this and I don't remember if I have already received an answer.

Gauss Turrets appears for research under Energy Weapons and require an Energy Weapons scientist to be researched with a bonus.

I believe Gauss Turrets should be researched under kinetics weapons by a Missile and Kinetic Weapons Scientist.

Should probably be in the suggestions thread, not the bugs thread. Currently it is this way because the turret gearing tech is an EW tech, probably when turrets were originally being added the expectation was to create laser turrets and this has stuck. However it would make more sense for the weapon type to determine research category.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on January 09, 2022, 11:00:53 PM
I think I remember seeing an earlier post that there is a bug where units in certain formations get counted twice. Can you correlate the numbers in the Complete Organization section with formations to see which one(s) might be doubled?
If you look at the numbers, you'll see that there is a lot of stuff *missing*, so it's not about that.
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on January 10, 2022, 03:51:47 AM
Uhu... My Corps supply units its on the move, only supply trucks in it, now its making a Kelly´s Heroes move, following their mechanoids in the breakthrough, I presume this is not the right move... Oh well thats okay if they doing a forward supply base.  ;D
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on January 11, 2022, 03:58:31 AM
The numbers under Total Organization don't add up. I haven't done the math yet, but I'd say that some units belonging to this HQ, which are probably stuck on a transport out of fuel in godknowswhere, are included in the total. Is that by design?
Yes, it's intended since the total here includes all the formations belonging to the HQ formation you have highlighted. While a formation cannot be split into multiple transports, a high-level HQ might control dozen formations that get put into dozen transports. So, while the information here might be slightly misleading in that it shows formations not currently present, it's also needed to show what formations are meant to be part of this higher HQ formation.

To make things easier for yourself, use transports big enough to move your standard formation in one go, and make bigger formations only when needed by planetary invasions once you're on the target body - that way you won't ever be confused/misled by this.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on January 13, 2022, 11:53:39 AM
I've checked the intercept bug mentioned in the QuestionsNWTOT, and it's indeed the moving-while-out-of-fuel status that causes problems.

1: Fleet sent to join & refuel the fleet going to Sol JP. Plotted course if quite off.

2: When move orders of the stationary fleet are removed, problem disappears.

3: Just to check, I've sent the fleet in the other direction. Intercepting fleet's course is off again, now in the opposite direction.
Title: Re: v1.13.0 Bugs Thread
Post by: GodEmperor on January 16, 2022, 07:25:33 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on January 20, 2022, 09:13:24 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on January 21, 2022, 03:36:30 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on January 21, 2022, 03:40:23 AM
I have captured a ship with damaged active sensors. But apparently they are still active (circle on map, plus "A" status) and I can't switch them off.
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on January 21, 2022, 09:13:50 AM
I have captured a ship with damaged active sensors. But apparently they are still active (circle on map, plus "A" status) and I can't switch them off.
Known issue and fixed for 2.0
Title: Re: v1.13.0 Bugs Thread
Post by: Ragnarsson on February 06, 2022, 06:01:12 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on February 07, 2022, 07:02:02 AM
Known issue and fixed for 2.0
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on February 07, 2022, 09:10:38 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: somebody1212 on February 08, 2022, 09:33:09 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: LiAlH4 on February 12, 2022, 07:52:19 PM
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.       



Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on February 12, 2022, 11:59:55 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Ragnarsson on February 13, 2022, 11:24:11 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on February 14, 2022, 01:22:04 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on February 14, 2022, 02:24:10 PM
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)
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on February 14, 2022, 02:56:02 PM
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   
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on February 14, 2022, 04:45:55 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: boolybooly on February 17, 2022, 12:30:08 PM
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.

Title: Re: v1.13.0 Bugs Thread
Post by: Ragnarsson on February 17, 2022, 05:17:00 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on February 17, 2022, 05:42:35 PM
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!  :D
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on February 17, 2022, 07:07:48 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: IanD on February 18, 2022, 04:54:53 AM
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?
Title: Re: v1.13.0 Bugs Thread
Post by: M_Gargantua on February 20, 2022, 08:14:40 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Ragnarsson on February 22, 2022, 04:50:28 AM
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. 
Title: Re: v1.13.0 Bugs Thread
Post by: Rince Wind on February 23, 2022, 06:58:23 AM
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

Title: Re: v1.13.0 Bugs Thread
Post by: Ragnarsson on February 26, 2022, 02:29:13 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on February 26, 2022, 09:21:38 PM
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.)  :P

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
Title: Re: v1.13.0 Bugs Thread
Post by: Zook on March 07, 2022, 12:11:29 AM
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
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on March 07, 2022, 12:28:58 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: bankshot on March 07, 2022, 09:07:03 AM
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. 
Title: Re: v1.13.0 Bugs Thread
Post by: Migi on March 07, 2022, 01:06:50 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on March 07, 2022, 01:14:33 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Marski on March 13, 2022, 09:52:55 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: alamoes on March 16, 2022, 03:09:25 AM
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.   
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on March 19, 2022, 08:07:23 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on March 19, 2022, 08:28:55 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on March 19, 2022, 08:37:50 AM
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.

OrbitalPopulation is stored as a decimal, so it won't cause an overflow for an Int32 value. Without the the error message code and text I can't track down what is causing the issue, but a divide by zero error is not the same as an overflow error.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on March 19, 2022, 08:58:31 AM
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.

Finally confirming this undocumented-but-observed piece of the CMC behavior, thanks Steve!
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on March 19, 2022, 10:46:36 AM
CMC not spawning on highest scoring body.

...

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.

Ah, that's an interesting wrinkle.
It might be worthwhile to add that detail to the post about C# CMC changes (http://aurora2.pentarch.org/index.php?topic=8495.msg110347#msg110347).
Title: Re: v1.13.0 Bugs Thread
Post by: alex_brunius on March 19, 2022, 11:36:02 AM
I noticed an odd thing with SM Add/Edit Installations in the Civilian Economy tab - Economics window. Not sure if it's to be considered a bug or not.

There is a built in check (error input string is not in correct format) forcing you to input a non decimal number when changing numbers of installations. However using normal game mechanics you can easily end up with non decimal numbers here when moving installations in smaller cargo holds that can't move the full installation at once. So what is the purpose of this limitation if the game already supports decimal numbers of installations?

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: Vandermeer on March 22, 2022, 10:44:55 AM
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.

Finally confirming this undocumented-but-observed piece of the CMC behavior, thanks Steve!
I really like that, because such randomness keeps every game fresh. I would like to see this more in the NPR spawn statistics, instead of current gametime based calculation. Or maybe some hybrid between some actual progression metric (because gametime can in some RP scenarios be deceiving), and then a broad gauss curve around that center of random potentialities, so extremely high or low tech encounters are never quite off the table. Just unlikely.
Title: Re: v1.13.0 Bugs Thread
Post by: Vivalas on March 31, 2022, 02:51:18 AM
Very strange one that stumped me for a while. Having a neutral race can bug out the intel screen and prevent the hostile/neutral ratio boxes from showing up to be checked, if the neutral race is the highest race alphabetically. The reason seems to be that the neutral race displays first on the intel screen when you open it, and the game really doesn't like that...

SJW: I've excluded Neutral races from this window.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on April 02, 2022, 01:01:51 AM
If you receive Research Points toward a tech from disassembling "found" components higher than your tech level, but you are currently researching the predecessor tech (e.g. got points towards Cap Recharge 5, but currently researching Cap Recharge 4), you don't get the points.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 02, 2022, 05:40:06 AM
If you receive Research Points toward a tech from disassembling "found" components higher than your tech level, but you are currently researching the predecessor tech (e.g. got points towards Cap Recharge 5, but currently researching Cap Recharge 4), you don't get the points.

You get the points towards Cap Recharge 4 instead.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on April 02, 2022, 04:30:22 PM
If you receive Research Points toward a tech from disassembling "found" components higher than your tech level, but you are currently researching the predecessor tech (e.g. got points towards Cap Recharge 5, but currently researching Cap Recharge 4), you don't get the points.

You get the points towards Cap Recharge 4 instead.

I just got another few components and tried it again, paying attention to the points currently going toward Fuel Consumption: 0.5 liters, and while I got events stating I received a bunch of points (450, 600, etc), the Research screen did not reflect any change due to that, even after I tried closing and reopening the Economics screen, advancing time several 5 day periods, etc.

However, if I cancel the research project, THEN disassemble the components, the points are applied correctly. Hence it appears that if a Research project is in queue, the points from disassembly do not get applied.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on April 02, 2022, 05:06:42 PM
If you receive Research Points toward a tech from disassembling "found" components higher than your tech level, but you are currently researching the predecessor tech (e.g. got points towards Cap Recharge 5, but currently researching Cap Recharge 4), you don't get the points.

You get the points towards Cap Recharge 4 instead.

I just got another few components and tried it again, paying attention to the points currently going toward Fuel Consumption: 0.5 liters, and while I got events stating I received a bunch of points (450, 600, etc), the Research screen did not reflect any change due to that, even after I tried closing and reopening the Economics screen, advancing time several 5 day periods, etc.

However, if I cancel the research project, THEN disassemble the components, the points are applied correctly. Hence it appears that if a Research project is in queue, the points from disassembly do not get applied.

I thought I fixed the research queue bug a while ago. Its working fine in my current game. Are you definitely on v1.13?
Title: Re: v1.13.0 Bugs Thread
Post by: Ragnarsson on April 02, 2022, 06:26:03 PM
If you receive Research Points toward a tech from disassembling "found" components higher than your tech level, but you are currently researching the predecessor tech (e.g. got points towards Cap Recharge 5, but currently researching Cap Recharge 4), you don't get the points.

You get the points towards Cap Recharge 4 instead.

I just got another few components and tried it again, paying attention to the points currently going toward Fuel Consumption: 0.5 liters, and while I got events stating I received a bunch of points (450, 600, etc), the Research screen did not reflect any change due to that, even after I tried closing and reopening the Economics screen, advancing time several 5 day periods, etc.

However, if I cancel the research project, THEN disassemble the components, the points are applied correctly. Hence it appears that if a Research project is in queue, the points from disassembly do not get applied.
I've observed this as well, though in my case I disassembled a Salvage Module 500 while researching that same tech, and the points were not applied. However, in other identical circumstances I've seen it work properly. I'd speculate it requires the tech to be being actively researched but that there's some other factor also required - I'm not sure what that might be.

My similar bug reported here: http://aurora2.pentarch.org/index.php?topic=12522.msg158952#msg158952

Absolutely occurred in version 1.13
Title: Re: v1.13.0 Bugs Thread
Post by: dsedrez on April 02, 2022, 09:04:34 PM
Wealth bug

I've been running a (relatively) longer campaign and found a ruin and began exploiting it. However I noticed that the wealth didn't seem to reflect the gains from the ruins. It also made me remember that the wealth recovered from scrapped ships and components were strange as well, and that my reported annual wealth gains didn't seem to be fully reflected on my wealth balance. I don't remember ever reading a bug report about it (though I might have missed it). So I started a new game in an unmodded DB to check for it. Mostly default settings (no NPR), added a ruin to Earth, SM-built a Xeno brigade and a number of Construction brigades.

I waited for the ruins to be IDed and then began tracking the total wealth and added wealth per turn, and got this:

2026-01-26   26659 (+828)
2026-01-31   26797 (+137)
2026-03-02   27624 (+828)
2026-04-01   28453 (+828)
2026-05-01   29284 (+832)
2026-05-31   30098 (+814)
2026-06-30   30915 (+817)
2026-07-30   31735 (+820)
2026-08-29   37960 (+6224)   5400 from ruins
2026-09-28   43365 (+5405)    6600 from ruins
2026-10-28   37013 (-6352)

I can make no sense from these numbers after the weird second wealth from ruins event. It's interesting though. I haven't tested scrapping ships/components but I believe there's something similar happening with them (the wealth added in one increment disappears soon after). I have no idea whether this bug affects anything else, but something is off with the annual wealth calculations and the effective wealth evolution (it seems much less than it should).

I've annexed the DB file after the wealth disappeared, and some screenshots.

The function number - N/A
The complete error text - N/A
The window affected - N/A
What you were doing at the time - exploring ruins
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? - Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - No
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on April 02, 2022, 10:29:18 PM
Quote
I thought I fixed the research queue bug a while ago. Its working fine in my current game. Are you definitely on v1.13?

Yep, definitely v1.13
Title: Re: v1.13.0 Bugs Thread
Post by: JacenHan on April 02, 2022, 11:33:27 PM
Wealth bug

[cut for conciseness]

In C# there was a change for the wealth balance to be limited to double annual wealth (http://aurora2.pentarch.org/index.php?topic=8495.msg111163#msg111163). It looks like the ruin is allowing you to go over the limit (which is 37836, according to your annual wealth of 18918), but then being corrected on the next tick.
Title: Re: v1.13.0 Bugs Thread
Post by: dsedrez on April 02, 2022, 11:36:25 PM

In C# there was a change for the wealth balance to be limited to double annual wealth (http://aurora2.pentarch.org/index.php?topic=8495.msg111163#msg111163). It looks like the ruin is allowing you to go over the limit (which is 37836, according to your annual wealth of 18918), but then being corrected on the next tick.

Ah that explains it! Thanks JacenHan! Don't know how I missed that earlier.
Title: Re: v1.13.0 Bugs Thread
Post by: db48x on April 03, 2022, 12:51:20 AM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Marski on April 03, 2022, 04:38:01 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: jamac41 on April 06, 2022, 05:11:54 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: M_Gargantua on April 06, 2022, 10:32:51 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 06, 2022, 11:09:22 PM
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 (http://aurora2.pentarch.org/index.php?topic=12258.0), 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.

Quote
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.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on April 10, 2022, 04:59:42 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: boolybooly on April 11, 2022, 10:37:04 AM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Vandermeer on April 11, 2022, 10:51:30 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on April 15, 2022, 07:30:07 AM
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
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on April 15, 2022, 10:33:45 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Marv on April 24, 2022, 12:44:14 PM
Quote from: Zook link=topic=12522. msg158179#msg158179 date=1642757790
Quote from: nakorkren link=topic=12522. msg158177#msg158177 date=1642734804
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
Title: Re: v1.13.0 Bugs Thread
Post by: boolybooly on April 24, 2022, 04:20:35 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: dlathro1 on April 27, 2022, 09:53:58 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Droll on April 27, 2022, 10:20:43 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Vandermeer on April 28, 2022, 05:59:39 AM
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.
(https://abload.de/img/screenshot2022-04-2815cksw.jpg)

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.
(https://abload.de/img/screenshot2022-04-281c6kko.jpg)

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
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 02, 2022, 08:27:36 AM
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
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on May 05, 2022, 04:47:50 AM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: dlathro1 on May 06, 2022, 08:12:37 PM
The 1.25x size, 1.25x range option on the beam fire control acts like a 0.25x size, 0.25x range option.
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on May 06, 2022, 08:39:54 PM
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...
Title: Re: v1.13.0 Bugs Thread
Post by: xenoscepter on May 06, 2022, 09:00:18 PM
--- This is from a 1.13 game; a fighter sized Colony Ship:
(https://cdn.discordapp.com/attachments/837880336536698893/972314452055703572/unknown.png)

--- The ship prior to a simple load at Terra, Unload at Luna Order:
(https://cdn.discordapp.com/attachments/837880336536698893/972314865123352626/unknown.png)

--- After unloading at Luna.
(https://cdn.discordapp.com/attachments/837880336536698893/972315741648990228/unknown.png)
(https://cdn.discordapp.com/attachments/837880336536698893/972313397188263946/unknown.png)
(https://cdn.discordapp.com/attachments/837880336536698893/972313453605838858/unknown.png)
(https://cdn.discordapp.com/attachments/837880336536698893/972313517887721502/unknown.png)

--- After 10 more Load / Unload orders:
(https://cdn.discordapp.com/attachments/837880336536698893/972316306672082996/unknown.png)
(https://cdn.discordapp.com/attachments/837880336536698893/972316462326890577/unknown.png)

 --- It seems Fighter Colonist Load / Unload orders are still quite bugged. I'd appreciate them being fxed. :)
Title: Re: v1.13.0 Bugs Thread
Post by: dlathro1 on May 06, 2022, 09:27:09 PM
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. :P
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 13, 2022, 09:14:27 AM
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 (http://aurora2.pentarch.org/index.php?topic=11565.msg140468#msg140468)?
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
Title: Re: v1.13.0 Bugs Thread
Post by: somebody1212 on May 13, 2022, 01:45:46 PM
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 (http://aurora2.pentarch.org/index.php?topic=11565.msg140468#msg140468)?
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
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 15, 2022, 07:05:27 AM
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
Title: Re: v1.13.0 Bugs Thread
Post by: somebody1212 on May 17, 2022, 04:04:56 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 18, 2022, 06:33:26 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on May 21, 2022, 12:39:26 PM
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
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 21, 2022, 02:22:46 PM
...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.
Title: Re: v1.13.0 Bugs Thread
Post by: Youngbloodclaw on May 24, 2022, 03:33:06 PM
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.
Title: Re: v1.13.0 Bugs Thread
Post by: Youngbloodclaw on May 24, 2022, 03:36:03 PM
Quote from: Youngbloodclaw link=topic=12522. msg160161#msg160161 date=1653424386
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. 
Title: Re: v1.13.0 Bugs Thread
Post by: rtsummer on May 24, 2022, 04:47:38 PM
The Minerals screen stopped working in my current game.  It won't perform searches correctly.  It seems to ignore the first number when searching for a specific mineral.  For instance, if I enter . 5 in the first box and then 1. 0 in the second box and press the search button it will return only deposits with a value of 1. 0.  This happens whether I choose a specific system or all systems when performing the search

I don't know if this may have something to do with the number of systems that have been surveyed or explored.  In this game, I have 45 known systems and 33 surveyed in year 42.  To check this I loaded a previous much smaller game with 4 known systems and the mineral search worked correctly.

SJW: WAI - see next post.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on May 24, 2022, 08:24:00 PM
The Minerals screen stopped working in my current game.  It won't perform searches correctly.  It seems to ignore the first number when searching for a specific mineral.  For instance, if I enter . 5 in the first box and then 1. 0 in the second box and press the search button it will return only deposits with a value of 1. 0.  This happens whether I choose a specific system or all systems when performing the search

Not a bug. The two search parameters for minerals are not a range; the first number is a minimum quantity, the second is a minimum accessibility. Neither value represents a maximum.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on May 29, 2022, 09:51:29 PM
I am seeing a STO hitting fighters AFTER those fighters go back and land on their mothership, despite being successfully docked. Upon being hit and taking damage, they are being detached from the fleet. For context, the carrier is inside the STO's range, so it should be a fair target, but fighters docked inside should not. This is happening repeatedly as I try to get the fighters to dock and then move the fighter away.

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on May 30, 2022, 11:14:02 AM
Duplicate alien components excavated from ruins do not stack.

Some time ago, I excavated four Theta S40 / R300 Shields from a ruins site.
Recently from the same site I excavated another identical shield component.
The stockpiles list now has two entries for these shields--one for the first four, one for the recent one.

According to the class designer, the two components are entirely identical.

SJW: Fixed for v2.0. Only affects shield generators where max size tech is greater than 10
Title: Re: v1.13.0 Bugs Thread
Post by: TheDrgnRbrn on June 02, 2022, 09:39:37 PM
Infinite Range PD Bug

1.   13, no mods, no database edits.   

New-ish player, encountered while trying to setup area-defense FCs in combat.   

The Bug:
If you set a FC to area-defense mode for PD, then give it a target, it will fire at incoming enemy salvos but will actually hit the target you have designated.   

Setup

Fleet is about 2.   1m Km away from the enemy, told to stop moving.    Incoming missiles.    Note that my best range possible outside of missiles is 320k at this tech level

I tell all my ships to area defense with weapons that will be able to get at least one shot off inside the fire envelope before the missiles connect.    This bug works with all the longer range beam weapons as far as I can tell, in this example I only could make it happen with lasers because they were the only things that could hit the enemy missiles.    It might happen with railguns/other beam options, but I didn't have high enough tech to make it happen.   

Note: I originally had this bug because I was trying to figure out how to make area defense work.    Tried to give them a target because I was trying to close range with the enemy and wanted them to be ready to shoot the moment they crossed the fire line.    Woops.   

What happens is the ships fire area defense as normal, but instead of killing missiles it impacts on the ships/stations I have targeted instead, 2.   1m km away from the fleet.    It doesn't destroy the missiles either I think.   

You can see the energy impact on the salvo, but the event log shows the shots hitting the ships.   

This is the event log entries, just to confirm.   

Hope this is helpful, I can provide any other information as needed.   

EDIT: I am an idiot at using BBC and can't get images to link at the right places, I attached them instead, sorry. 

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on June 04, 2022, 04:53:11 PM
Let's call this one a bug. Relates to spoiler races, so spoilered below:

Rakhas ground formations lack logistics elements, so after 10 rounds of combat they will become only 25% as effective and thus pretty easy to defeat even with a force that shouldn't have any business doing so. This seems wrong, as Precursor formations have logistics elements and I see no flavor reason why Rakhas should not.

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on June 05, 2022, 09:34:59 AM
Lost contact displays current distance, not distance when contact was lost.

I have a small sensor station parked on a jump point.
The station has only a Res1 active sensor with range 1.26mkm.
A hostile fleet arrived within range. A "New Hostile Contact" event was registered, as expected.
I advanced time in small increments as the fleet retreated from the jump point.
When the fleet passed out of sensor range, the displayed contact information had "[LOST]" appended.

With the map still centered on the jump point, I continued to advance time slowly.
The displayed contact distance continued to increase over time, apparently showing the distance from the jump point to the current location of the hostile fleet.
I would have expected the displayed distance to remain at 1.26mkm (the distance at which contact was lost).

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on June 12, 2022, 12:44:45 PM
Losing the listing of hierarchy of troops: When I first landed the five units (a HQ, three infantry and one supply unit) and put them into the hierarchy, they displayed correctly. Now after a few rounds of combat, they are still fighting and still listed by qty of units if you click on the planet, but there's no list of divisions, so I can't set field positions.

Update: it appears that the HQ unit was killed (both HQ units died) and now all divisions under them "disappeared" from the hierarchy list, but are still fighting. Still a bug, but that might help trace it down. When I SM back in an HQ, that shows up in the hierarchy but the other units are still missing.

Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on June 13, 2022, 12:15:30 PM
If you disassemble a component that gives research points in a technology that you currently have an active research project for, the research points will not be deducted from the points remaining to complete the project.
If you then cancel the project, the displayed research cost of the technology will equal the original cost of the technology minus the research points received from disassembling the component.

Edit: Note that if you cancel the project and then disassemble the component, the points are correctly deducted from the points remaining for the technology.

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on June 16, 2022, 11:16:20 AM
Not clear to me if this is a bug or working-as-intended:

When I jumped a fleet in-system and used the "Fleet Fire at Will" command, every single ship focused on shooting the enemy's large commercial ships sitting at the gate, ignoring the 400k tons of enemy cruisers and destroyers also sitting on the gate that were shooting at my fleet. It seems like Fleet Fire at Will should prioritize military ships, not commercial ships, in the list of targets.
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on June 17, 2022, 11:12:01 AM
My salvage ships were merrily salvaging along when all of the sudden I got the message that "Orders Completed: Salvage Beta cannot salvage the target wreck as no ships within the fleet have salvage capability".

Obviously that's not true, since that fleet just salvaged several fighter wrecks right before that. I'm thinking it's an issue with the target wreck. Before being being killed, it was a 49 ton sensor fighter. The wreck is now a 0 ton wreck, which is probably what's causing the problem. I'm betting that because it was below 50 tons when it got destroyed it was rounded down to a 0 ton wreck and the salvage code doesn't know what to do with a 0 ton wreck.

SJW: Good Guess. Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on June 17, 2022, 12:39:26 PM
On a related note, salvage time seems to depend only on the salvage rate of a single ship, regardless of how many ships are in the fleet. Not sure if this is working as intended, but it seems like salvage should depend on the fleet's total salvage rate.

SJW: WAI - only one ship can work on a wreck.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on June 22, 2022, 12:56:07 PM
Use Components can give free minerals.

If you use components when building multiple ships at a time, you can get free minerals.

Steps:
1) Make a new ship class, add a single engine, and then build a few of those engines with factories.
2) Create a new shipyard, tool it for the new class, and add a second slipway.
3) Delete all other shipbuilding tasks at this colony (not required, but makes it easier to see the effect of the bug).
4) Back on The Shipyards tab, select the new yard, tick the Use Components checkbox (make sure you have the correct engine in the stockpile at this colony), and click the Create Task button twice.
5) On the Mining tab, middle pane, observe the negative value for Gallicite in the SY Tasks column. (It is probably equal to twice the gallicite cost of the new ship class.)
6) Advance time, and observe that your Gallicite stockpile is in fact benefiting from this "income" (i.e., it is not merely a display glitch).

Note that if you do more ships at once, the negative gallicite gained per ship increases. It seems to be equal to N * (N-1) * cost per ship.

Also note: you can prevent the bug by selecting a different shipyard after you click the Create Task button. If you then re-select the original yard and click the Create Task button again, the bug does not occur.

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: Voltbot on June 22, 2022, 04:20:34 PM
I'm not sure, whather it's a bug or a feature, but I'll bring it anyways.
As much as I was experimenting it looks like jump shock doesn't affect parasites.

SW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on July 03, 2022, 06:02:45 AM
When motionless at a recreational location, deployment time seems to reduce at 9x the passage of time rather than 10x.

I parked a survey ship in orbit of my HW after a long tour of duty.
It had a deployment time of 112.24 months.
I gave the ship a Send Message order, targeting the HW, with an order delay of 29030400 seconds (= 336 days = 11.2 months).

When the ship executed the order it had a deployment time of 11.49 months remaining.
So the clock reduced by 100.75 months in 11.2 months, which gives a ratio of ~8.9955.

Perhaps the fact that the ship had an order in its list caused the deployment clock to increment at normal time rate simultaneously with decrementing at 10x rate.

EDIT:
I then left the ship in orbit, and gave a different fleet a send message order delayed by 1.14 months.
This should have been almost enough time for the survey fleet deployment clock to reduce from 11.49 to zero.

Instead, when that message executed, the survey fleet had a remaining deployment clock of 1.32 months.
So it seems that the issue of reducing by 9x rather than 10x time has nothing to do with an order being in the list.

Possibly related: this survey fleet has two ships.
One is a commercial tug with a maintenance module.
The other is a 1kt engineless survey vessel. It is this vessel that has the deployment clock. (The maintenance clock never rises above 0, because it is always accompanied by the maintenance module.)
Perhaps the issue is that the survey ship is "being tugged" (even though motionless), and that is causing deployment time to increment as time passes, even as it simultaneously reduces by 10x.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on July 03, 2022, 09:51:36 AM
When motionless at a recreational location, deployment time seems to reduce at 9x the passage of time rather than 10x.

I actually thought it was supposed to be 3x, and the observed faster rate was an undocumented change in my favor.
Title: Re: v1.13.0 Bugs Thread
Post by: Erik L on July 07, 2022, 01:46:00 PM
Aurora does not like medal images to be in subfolders. Works fine until you close and restart.
Title: Re: v1.13.0 Bugs Thread
Post by: Erik L on July 08, 2022, 06:07:26 PM
When exporting the medal conditions, commas in the description throw the csv file out of alignment.
Title: Re: v1.13.0 Bugs Thread
Post by: Lightning on July 08, 2022, 11:07:11 PM
On a related note, salvage time seems to depend only on the salvage rate of a single ship, regardless of how many ships are in the fleet. Not sure if this is working as intended, but it seems like salvage should depend on the fleet's total salvage rate.

I believe this is working as intended. I remember having this same question and being told only the modules on one ship can salvage a wreck at a time , though it might have been back in vb. I don't recall seeing anything indicating a change to that functionality in any of the change logs since I asked that question.
Title: Re: v1.13.0 Bugs Thread
Post by: Vandermeer on July 19, 2022, 01:23:30 PM
Not sure if this has been reported before because I have vague, near Deja Vu memories of it, but when you salvage advanced enemy energy weapons, the capacitor recharge tech received will not actually go towards a full tech grade, but only advance towards the next increment faction. See screenshot:
(https://abload.de/img/screenshot2022-07-19121k85.jpg)

Instead of getting the full upgrade to capacitor recharge 4, you only advance towards 3.25, even though it presumably costs just as much research. (I managed to advance focal and frequency tech by 1 full level with the same batch of salvage after all)
This is further proven by the fact that I continued to get tech points to capacitor here, but it is not reflected on the tech screen on the right, since it most likely went to a hidden (also likel 8k RP costing) 3.5 capacitor technology.

This behavior possibly has further implications for other hidden fractional techs. Maybe in the future in might be possible to learn max engine size or power factors from salvage or espionage in some way, which will likely fall to the same code trap and instead research every fractional increment (size 124, size 125, size...) before the actual technology.

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: ZimRathbone on July 21, 2022, 07:42:22 AM
Make a training command, put fighters inside a carrier, move carrier under the training command with a tanker set to refuel own fleet.

also add a Supply ship set to Resupply own fleet (handles the maint failures assuming that all ships have at least enough MSP to repair the largest component on each ship).  I usually set this up for all my major fleets, and have these as a separate sub-fleet (along with an ammo collier) that can be detached before advancing into combat.  You do have to reset the Supply ship status periodically (at least after every save) as for some reason the status keeps reverting to No Resupply.

I think I have found the source of the resupply bug...

in FCT_Ship  there are fields for [RefuelStatus] and [OrdinanceTransferStatus] but none for [ResupplyStatus]  (there is one for [ResupplyPriority] tho).  It looks to me that when the database saves the value that's set in the dynamic memory of the program, it gets lost as the internal data structure doesn't quite match the database one. 

SJW: Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on July 29, 2022, 03:19:24 PM
Getting a error, from xx - xxx times per turn, tried with days or hours, still popping up, don't destroy game but annoying...

27 years into game,


1.13.0 Function #1414: The value was either too large or too small for Decimal.

Saved the game last night, now when I try to start it I get the following error

1.13.0 Function #3248: Cannot convert object from DBnull to other types.

Clicking ok and the game starts...

The first I notice is a lost some ships, some 120 destroyers and some 60 light cruisers...  :-X
Title: Re: v1.13.0 Bugs Thread
Post by: nakorkren on July 29, 2022, 04:21:11 PM
Very minor thing, but when you create a Future Prototype, the event message states that the research for the item has been completed. Presumably it should say something like what happens with prototypes, i.e. "A (Future) Prototype for item xyz has been created"
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on July 31, 2022, 12:33:58 AM
I have a strange thing on one of my planets, my troop transports found out that there is xx genestealer units waiting for pickup? But only when I try to load, might be why there is a string of #1415 errors?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 06:55:17 AM
Getting a error, from xx - xxx times per turn, tried with days or hours, still popping up, don't destroy game but annoying...

27 years into game,


1.13.0 Function #1414: The value was either too large or too small for Decimal.

Saved the game last night, now when I try to start it I get the following error

1.13.0 Function #3248: Cannot convert object from DBnull to other types.

Clicking ok and the game starts...

The first I notice is a lost some ships, some 120 destroyers and some 60 light cruisers...  :-X

#1414 is Execute Orders - one of the largest functions in the game - I really need to start adding more granular error checking in large functions.

Its a guess, but was it possible a fleet had an order that would take a really, really, large amount of time to execute?
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 06:57:54 AM
When exporting the medal conditions, commas in the description throw the csv file out of alignment.

Yes, I encountered this myself. Its a CSV file so I would either have to change the file format, or exclude commas from the description field.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 07:03:34 AM
Make a training command, put fighters inside a carrier, move carrier under the training command with a tanker set to refuel own fleet.

also add a Supply ship set to Resupply own fleet (handles the maint failures assuming that all ships have at least enough MSP to repair the largest component on each ship).  I usually set this up for all my major fleets, and have these as a separate sub-fleet (along with an ammo collier) that can be detached before advancing into combat.  You do have to reset the Supply ship status periodically (at least after every save) as for some reason the status keeps reverting to No Resupply.

I think I have found the source of the resupply bug...

in FCT_Ship  there are fields for [RefuelStatus] and [OrdinanceTransferStatus] but none for [ResupplyStatus]  (there is one for [ResupplyPriority] tho).  It looks to me that when the database saves the value that's set in the dynamic memory of the program, it gets lost as the internal data structure doesn't quite match the database one.

Good detective work. Fixed now.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 07:05:10 AM
When motionless at a recreational location, deployment time seems to reduce at 9x the passage of time rather than 10x.

I actually thought it was supposed to be 3x, and the observed faster rate was an undocumented change in my favor.

I think it is going back x10 but time is also moving forward so it is a net x9.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 07:14:35 AM
Instead of getting the full upgrade to capacitor recharge 4, you only advance towards 3.25, even though it presumably costs just as much research. (I managed to advance focal and frequency tech by 1 full level with the same batch of salvage after all)
This is further proven by the fact that I continued to get tech points to capacitor here, but it is not reflected on the tech screen on the right, since it most likely went to a hidden (also likel 8k RP costing) 3.5 capacitor technology.

This one is already fixed but I forgot to mention it in the bugs list. This is true for both downloading tech and disassembling components
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 07:30:32 AM
I am seeing a STO hitting fighters AFTER those fighters go back and land on their mothership, despite being successfully docked. Upon being hit and taking damage, they are being detached from the fleet. For context, the carrier is inside the STO's range, so it should be a fair target, but fighters docked inside should not. This is happening repeatedly as I try to get the fighters to dock and then move the fighter away.

The STO firing decision was not checking that the last update time for active contacts was equal to the current game time. Therefore it was effectively firing at the fighter in the past, rather than the present :)

However, the only realistic scenario in which that was a problem was when something disappeared from sensors inside the STO weapon range, which was happening when the fighters landed on the mothership.

Fixed for v2.0
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 07:46:21 AM
Duplicate alien components excavated from ruins do not stack.

Some time ago, I excavated four Theta S40 / R300 Shields from a ruins site.
Recently from the same site I excavated another identical shield component.
The stockpiles list now has two entries for these shields--one for the first four, one for the recent one.

According to the class designer, the two components are entirely identical.

This only seems to be a problem for shields and even then only if larger than 10 HS. Normally, the component recovery code does a temporary component design and then checks to see if anything from the same race already exists. If so, it uses the existing design; if not it creates a new permanent design.

This works fine for most components. However, for shields the permanent design was using 10 HS, rather than the max possible HS of the temporary design. Therefore, the temp design for the second set of generators didn't match the previous permanent design, so it created a new 10 HS permanent generator that was identical to the previous permanent one.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 08:10:06 AM
Infinite Range PD Bug

1.   13, no mods, no database edits.   

New-ish player, encountered while trying to setup area-defense FCs in combat.   

The Bug:
If you set a FC to area-defense mode for PD, then give it a target, it will fire at incoming enemy salvos but will actually hit the target you have designated.   

Setup

Fleet is about 2.   1m Km away from the enemy, told to stop moving.    Incoming missiles.    Note that my best range possible outside of missiles is 320k at this tech level

I tell all my ships to area defense with weapons that will be able to get at least one shot off inside the fire envelope before the missiles connect.    This bug works with all the longer range beam weapons as far as I can tell, in this example I only could make it happen with lasers because they were the only things that could hit the enemy missiles.    It might happen with railguns/other beam options, but I didn't have high enough tech to make it happen.   

Note: I originally had this bug because I was trying to figure out how to make area defense work.    Tried to give them a target because I was trying to close range with the enemy and wanted them to be ready to shoot the moment they crossed the fire line.    Woops.   

What happens is the ships fire area defense as normal, but instead of killing missiles it impacts on the ships/stations I have targeted instead, 2.   1m km away from the fleet.    It doesn't destroy the missiles either I think.   

You can see the energy impact on the salvo, but the event log shows the shots hitting the ships.   

This is the event log entries, just to confirm.   

Hope this is helpful, I can provide any other information as needed.   

EDIT: I am an idiot at using BBC and can't get images to link at the right places, I attached them instead, sorry.

Thanks for the detailed report. I'm surprised this hasn't been picked up sooner, but its probably because area mode isn't used very often and you need to have a ship target as well as area mode for the bug to happen.

Aurora handles missile destruction immediately, but ship damage is resolved once all firing is complete. In both cases, a 'damage report' record is created, for reporting purposes only in the case of missile targets and for both damage resolution and reporting in the case of ship targets. In this situation, the missiles were being destroyed but then the 'damage report' included the current ship target of the fire control, so the damage in that record was also applied to the ship after being applied to the missiles. It was working fine for point-blank point defence, so the bug only happened for area mode.

I've adjusted the damage report to ignore the current ship target when the fire control is operating in area mode.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on July 31, 2022, 09:34:03 AM
When exporting the medal conditions, commas in the description throw the csv file out of alignment.

Yes, I encountered this myself. Its a CSV file so I would either have to change the file format, or exclude commas from the description field.

A cheap hack solution would be to replace any commas in the descriptions with another comma-like character when saving. I've used the character '‚' which is U+201A but looks identical to a comma.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 10:38:20 AM
Use Components can give free minerals.

If you use components when building multiple ships at a time, you can get free minerals.

Steps:
1) Make a new ship class, add a single engine, and then build a few of those engines with factories.
2) Create a new shipyard, tool it for the new class, and add a second slipway.
3) Delete all other shipbuilding tasks at this colony (not required, but makes it easier to see the effect of the bug).
4) Back on The Shipyards tab, select the new yard, tick the Use Components checkbox (make sure you have the correct engine in the stockpile at this colony), and click the Create Task button twice.
5) On the Mining tab, middle pane, observe the negative value for Gallicite in the SY Tasks column. (It is probably equal to twice the gallicite cost of the new ship class.)
6) Advance time, and observe that your Gallicite stockpile is in fact benefiting from this "income" (i.e., it is not merely a display glitch).

Note that if you do more ships at once, the negative gallicite gained per ship increases. It seems to be equal to N * (N-1) * cost per ship.

Also note: you can prevent the bug by selecting a different shipyard after you click the Create Task button. If you then re-select the original yard and click the Create Task button again, the bug does not occur.

Well spotted!

Aurora uses a class called Materials to hold amounts of all eleven minerals, along with a variety of functions to manipulate them. When you are setting up a shipyard task, an instance of this class called CurrentMaterials is used to hold the mineral requirements for the current selection, which allows display of those amounts, etc.. When a shipyard task is created, the information from CurrentMaterials is passed to the TaskMaterials object associated with the shipyard task.

However, I was passing CurrentMaterials by reference and not by value (the Materials class has a specific CopyMaterials function that passes by value but I forgot on this occasion). This issue doesn't matter if you build several ships in the same shipyard without using components because they are all the same materials anyway. However, if you use components then the same Materials instance is being reduced once for every new TaskMaterials object that references the original CurrentMaterials object.

Once you change task type or shipyard, the CopyMaterials is set to null or a new instance and then repopulated, so the problem goes away. In C#, as you probably know, when you pass an object by reference to a second object, you are not passing the address of the first object, but actually passing a reference to the address of the data used by the first object. If that data changes, it changes for both objects using that data reference. However, if you reset the first object (either using new or null), it now references a new data location. The second object retains knowledge of the first objects original data, even though the first object is now using new data. That is why changing shipyards in-between tasks avoids the bug.

An intriguing demonstration of C# referencing rules :)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 10:49:16 AM
When motionless at a recreational location, deployment time seems to reduce at 9x the passage of time rather than 10x.

I parked a survey ship in orbit of my HW after a long tour of duty.
It had a deployment time of 112.24 months.
I gave the ship a Send Message order, targeting the HW, with an order delay of 29030400 seconds (= 336 days = 11.2 months).

When the ship executed the order it had a deployment time of 11.49 months remaining.
So the clock reduced by 100.75 months in 11.2 months, which gives a ratio of ~8.9955.

Perhaps the fact that the ship had an order in its list caused the deployment clock to increment at normal time rate simultaneously with decrementing at 10x rate.

EDIT:
I then left the ship in orbit, and gave a different fleet a send message order delayed by 1.14 months.
This should have been almost enough time for the survey fleet deployment clock to reduce from 11.49 to zero.

Instead, when that message executed, the survey fleet had a remaining deployment clock of 1.32 months.
So it seems that the issue of reducing by 9x rather than 10x time has nothing to do with an order being in the list.

Possibly related: this survey fleet has two ships.
One is a commercial tug with a maintenance module.
The other is a 1kt engineless survey vessel. It is this vessel that has the deployment clock. (The maintenance clock never rises above 0, because it is always accompanied by the maintenance module.)
Perhaps the issue is that the survey ship is "being tugged" (even though motionless), and that is causing deployment time to increment as time passes, even as it simultaneously reduces by 10x.

This is working as intended. A recreational location increases the last shore leave date by 10x time passed. However because time is passing during that period, the net gain is only 9x.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 11:06:05 AM
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 (http://aurora2.pentarch.org/index.php?topic=11565.msg140468#msg140468)?
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.

I thought I had fixed this in this past, but I just checked the code and found a logic error.

For v2.0, when components are being selected on the damage allocation chart during maintenance failure, any 'No Maint Failure' components will be re-rolled, without adding to the cumulative '20 times and you are out' rule that leads to catastrophic hull failure.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on July 31, 2022, 11:16:22 AM
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.

Shield regeneration currently occurs after movement but before combat. However, missile impacts occur during movement so the shield regen will happen after missile damage.

For v2.0, I have changed shield regeneration to happen before movement, which will avoid the above problem. It also has a impact on detection as well.
Title: Re: v1.13.0 Bugs Thread
Post by: Kiero on July 31, 2022, 12:44:57 PM
Stabilization ship bug, step by step:

I had a fuel fleet with one tanker.
To which I joined a Stabilization fleet (with one stabilization ship) as a sub-fleet.
Then I gave that fleet an order to stabilize a LP in orbit of a gas giant.
After "stabilization" started I detached the stabilization sub-fleet and fly away with it.
Stabilization was still going, but with only Tanker present at the location.
Title: Re: v1.13.0 Bugs Thread
Post by: db48x on July 31, 2022, 01:35:16 PM
When exporting the medal conditions, commas in the description throw the csv file out of alignment.

Yes, I encountered this myself. Its a CSV file so I would either have to change the file format, or exclude commas from the description field.

Or allow quoted fields, as all good CSV parsers should.

Proper RFC4180 style:
Code: [Select]
foo,bar,baz,"quoted field, with commas and ""escaped"" quotes",zed
Using C–style escape sequences as well:
Code: [Select]
foo,bar,baz,"quoted field, with commas, \"escaped\" quotes, and \\backslashes",zed
The former is harder to read when the field includes newline characters, while in the latter the newline can be replaced with
Code: [Select]
\n. Same goes for tabs, vertical tabs, other control characters, thin spaces, wide spaces, non–breaking spaces, etc, etc. Exactly which escape sequences you support depends on how much you care about readability of the CSV file, since none of those will distract a proper parser.[/code]
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on July 31, 2022, 02:49:46 PM
Getting a error, from xx - xxx times per turn, tried with days or hours, still popping up, don't destroy game but annoying...

27 years into game,


1.13.0 Function #1414: The value was either too large or too small for Decimal.

Saved the game last night, now when I try to start it I get the following error

1.13.0 Function #3248: Cannot convert object from DBnull to other types.

Clicking ok and the game starts...

The first I notice is a lost some ships, some 120 destroyers and some 60 light cruisers...  :-X

#1414 is Execute Orders - one of the largest functions in the game - I really need to start adding more granular error checking in large functions.

Its a guess, but was it possible a fleet had an order that would take a really, really, large amount of time to execute?

Yea I found 2 small fleets that were in for the looong haul, around 10000 days, 1414 went away and I got a few 1415, shall check again
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 01, 2022, 05:50:26 AM
Getting a error, from xx - xxx times per turn, tried with days or hours, still popping up, don't destroy game but annoying...

27 years into game,


1.13.0 Function #1414: The value was either too large or too small for Decimal.

Saved the game last night, now when I try to start it I get the following error

1.13.0 Function #3248: Cannot convert object from DBnull to other types.

Clicking ok and the game starts...

The first I notice is a lost some ships, some 120 destroyers and some 60 light cruisers...  :-X

#1414 is Execute Orders - one of the largest functions in the game - I really need to start adding more granular error checking in large functions.

Its a guess, but was it possible a fleet had an order that would take a really, really, large amount of time to execute?

Yea I found 2 small fleets that were in for the looong haul, around 10000 days, 1414 went away and I got a few 1415, shall check again

#1415 is a very small function that updates the contact location for a fleet. If Execute Orders failed it probably would cause an error in this function as it wouldn't have the position information.
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on August 01, 2022, 06:41:26 AM
Getting a error, from xx - xxx times per turn, tried with days or hours, still popping up, don't destroy game but annoying...

27 years into game,


1.13.0 Function #1414: The value was either too large or too small for Decimal.

Saved the game last night, now when I try to start it I get the following error

1.13.0 Function #3248: Cannot convert object from DBnull to other types.

Clicking ok and the game starts...

The first I notice is a lost some ships, some 120 destroyers and some 60 light cruisers...  :-X

#1414 is Execute Orders - one of the largest functions in the game - I really need to start adding more granular error checking in large functions.

Its a guess, but was it possible a fleet had an order that would take a really, really, large amount of time to execute?

Yea I found 2 small fleets that were in for the looong haul, around 10000 days, 1414 went away and I got a few 1415, shall check again

#1415 is a very small function that updates the contact location for a fleet. If Execute Orders failed it probably would cause an error in this function as it wouldn't have the position information.

Get this from a few to 50-60 per turn, I presume that has to do with how long the time advances with, a day fewer and a lot more with a month...

Comes and goes, so this might not be from one of my fleets?

Shall try and move everything to Earth and se what happens.

Been checking my shipping lines and there is some realy old types there, going in the 5-600 km/s speed, spending up to a 1000 days to finish that run, fuel is for perhaps 200 days...
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 01, 2022, 08:18:52 AM
Get this from a few to 50-60 per turn, I presume that has to do with how long the time advances with, a day fewer and a lot more with a month...

Comes and goes, so this might not be from one of my fleets?

Shall try and move everything to Earth and se what happens.

Been checking my shipping lines and there is some realy old types there, going in the 5-600 km/s speed, spending up to a 1000 days to finish that run, fuel is for perhaps 200 days...

After checking the max value of a decimal, I don't think it is journey times. It can handle trillions of years. Something else is going on - I'll some more error checking.
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on August 01, 2022, 10:16:44 AM
When motionless at a recreational location, deployment time seems to reduce at 9x the passage of time rather than 10x.

I actually thought it was supposed to be 3x, and the observed faster rate was an undocumented change in my favor.

I think it is going back x10 but time is also moving forward so it is a net x9.

But why would time be going forward for deployment purposes while a ship is in orbit of a recreational location?
Title: Re: v1.13.0 Bugs Thread
Post by: skoormit on August 01, 2022, 10:22:23 AM
...I was passing CurrentMaterials by reference and not by value

Holy moley, a pass by reference vs value error in the wild.
I thought these only existed as interview questions.

Quote
An intriguing demonstration of C# referencing rules :)
Haha, nerd.  :)
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 01, 2022, 10:57:59 AM
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.

Replaced with a new Wealth History section
http://aurora2.pentarch.org/index.php?topic=12523.msg160864#msg160864
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 01, 2022, 11:03:17 AM
I think it is going back x10 but time is also moving forward so it is a net x9.

But why would time be going forward for deployment purposes while a ship is in orbit of a recreational location?

There is the game clock, which is moving forward at the normal rate, and a 'Last Shore Leave' clock for each ship. The difference between the two is the deployment time for the ship. The ship clock does not advance while on deployments, advances at 10x normal when at a recreational location and advances at different rates when in a hangar bay, depending on the mothership's own deployment time.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 01, 2022, 12:03:05 PM
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.

Towed ships were being assigned a speed of 300,000 km. I think this was originally done to avoid the speed of the parent fleet being affected by the tractored ship. However, the same piece of code was subsequently used for other purposes, including combat, and that led to the 'light-speed tractored ship' bug

Anyway, I have removed the assignment of 300,000, so the speed of towed ships will be calculated normally. I've excluded tractored ships from fleet speed calculation (instead of the 300k hack). I've also added a check for fuel status when speed is being used for combat purposes as 'out of fuel' ships were still using their current speed. In effect, engine damage was considered for max speed, but not damage to fuel storage.
Title: Re: v1.13.0 Bugs Thread
Post by: db48x on August 01, 2022, 06:08:08 PM
I thought I had fixed this in this past, but I just checked the code and found a logic error.

For v2.0, when components are being selected on the damage allocation chart during maintenance failure, any 'No Maint Failure' components will be re-rolled, without adding to the cumulative '20 times and you are out' rule that leads to catastrophic hull failure.

I have occasionally wondered if it wouldn’t simply be easier to have a second DAC just for maintenance failures. It would omit any parts that cannot suffer maintenance failures. You could then pick parts out of this DAC in the usual way but without ever needing to reroll. On the other hand, maybe now you’ve finally gotten the rerolls implemented perfectly in all cases, and we won’t ever this this bug again…
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 01, 2022, 06:30:25 PM
I thought I had fixed this in this past, but I just checked the code and found a logic error.

For v2.0, when components are being selected on the damage allocation chart during maintenance failure, any 'No Maint Failure' components will be re-rolled, without adding to the cumulative '20 times and you are out' rule that leads to catastrophic hull failure.

I have occasionally wondered if it wouldn’t simply be easier to have a second DAC just for maintenance failures. It would omit any parts that cannot suffer maintenance failures. You could then pick parts out of this DAC in the usual way but without ever needing to reroll. On the other hand, maybe now you’ve finally gotten the rerolls implemented perfectly in all cases, and we won’t ever this this bug again…

There are already two DACs - one normal and one electronic only. I did consider adding a third, but decided to go with the simpler option.
Title: Re: v1.13.0 Bugs Thread
Post by: Joshua Wood on August 01, 2022, 07:56:42 PM
In the economy screen of a population the "Maintenance Facilities Capacity" Section isn't correctly updated when orbital maintenance facilities are present and the "Economic Production Modifier" is less than 100%. 

This is a screenshot where 190 Maintenance modules are in orbit providing 1000t each and 1 maintenance facility in present on the population.  https://i.imgur.com/1kUkpFo.png

The readout says 190,354 tons capacity and 170998 tons of ships, the ships are still suffering from maintenance failures (even with supplies etc. ) suggesting this number isn't correct and in the background the number is still correct. 

SJW: Display Bug. Fixed for v2.0.
Title: Re: v1.13.0 Bugs Thread
Post by: Garfunkel on August 01, 2022, 09:12:14 PM
Please register your account so you can post normally and we don't have to manually approve of each post you make, Joshua. I also fixed your Imgur link.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 02, 2022, 06:54:45 AM
I think I have already highlighted this and I don't remember if I have already received an answer.

Gauss Turrets appears for research under Energy Weapons and require an Energy Weapons scientist to be researched with a bonus.

I believe Gauss Turrets should be researched under kinetics weapons by a Missile and Kinetic Weapons Scientist.

Research field is determined by the tech type of a component. Turrets have their own tech type, which sits under energy. I've split this into two tech types (Energy Turrets and Kinetic Turrets) and assigned the tech type to new turrets based on the chosen weapon. TLDR: Gauss turrets are now kinetic research.
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on August 02, 2022, 07:48:11 AM
About error #1415: Can it have with commanders, had a lot of retirements and 4 times as many changes in rank and so on, but had to hold down enter for 40 seconds with repeated 1415s, in the hundreds, not as many events on the commander side, but a thaught.
Title: Re: v1.13.0 Bugs Thread
Post by: nuclearslurpee on August 02, 2022, 08:17:29 AM
TLDR: Gauss turrets are now kinetic research.

Best change in patch.
Title: Re: v1.13.0 Bugs Thread
Post by: Steve Walmsley on August 02, 2022, 08:59:10 AM
About error #1415: Can it have with commanders, had a lot of retirements and 4 times as many changes in rank and so on, but had to hold down enter for 40 seconds with repeated 1415s, in the hundreds, not as many events on the commander side, but a thaught.

Its a very short function that only involves contacts and fleets.

This is the entire code in function #1415 for v1.13

        public void UpdateContactStartPoint(Fleet f)
        {
            try
            {
                List<Contact> Contacts = ContactList.Values.Where(x => x.ContactType == AuroraContactType.Ship).Where(x => x.ContactShip.ShipFleet == f).ToList();

                foreach (Contact c in Contacts)
                {
                    c.IncrementStartX = f.Xcor;
                    c.IncrementStartY = f.Ycor;
                }
            }
            catch (Exception error) { GlobalValues.ErrorHandler(error, 1415); return; }
        }

The only place I can see this being an issue is if you somehow have a ship contact for a ship that doesn't exist. If you have access to the database, trying running the following SQL. The result should be 0. If not, that is the problem

Select Count(*) from FCT_Contacts Where ContactType = 1 AND ContactID NOT IN (Select ShipID from FCT_Ship)

I've changed the main line of code in v2.0 to check that ContactShip is not null in case this is the issue.

List<Contact> Contacts = ContactList.Values.Where(x => x.ContactType == AuroraContactType.Ship && x.ContactShip != null).Where(x => x.ContactShip.ShipFleet == f).ToList();
Title: Re: v1.13.0 Bugs Thread
Post by: Kiero on August 03, 2022, 03:05:00 AM
Can anyone confirm this stabilization ship bug?

http://aurora2.pentarch.org/index.php?topic=12522.msg160850#msg160850
Title: Re: v1.13.0 Bugs Thread
Post by: ExChairman on August 05, 2022, 12:16:33 AM
About error #1415: Can it have with commanders, had a lot of retirements and 4 times as many changes in rank and so on, but had to hold down enter for 40 seconds with repeated 1415s, in the hundreds, not as many events on the commander side, but a thought.

Its a very short function that only involves contacts and fleets.

This is the entire code in function #1415 for v1.13

        public void UpdateContactStartPoint(Fleet f)
        {
            try
            {
                List<Contact> Contacts = ContactList.Values.Where(x => x.ContactType == AuroraContactType.Ship).Where(x => x.ContactShip.ShipFleet == f).ToList();

                foreach (Contact c in Contacts)
                {
                    c.IncrementStartX = f.Xcor;
                    c.IncrementStartY = f.Ycor;
                }
            }
            catch (Exception error) { GlobalValues.ErrorHandler(error, 1415); return; }
        }

The only place I can see this being an issue is if you somehow have a ship contact for a ship that doesn't exist. If you have access to the database, trying running the following SQL. The result should be 0. If not, that is the problem

Select Count(*) from FCT_Contacts Where ContactType = 1 AND ContactID NOT IN (Select ShipID from FCT_Ship)

I've changed the main line of code in v2.0 to check that ContactShip is not null in case this is the issue.

List<Contact> Contacts = ContactList.Values.Where(x => x.ContactType == AuroraContactType.Ship && x.ContactShip != null).Where(x => x.ContactShip.ShipFleet == f).ToList();


Don`t have access to the program, but I have noticed a strange happening, I am losing ships, not to any specific reason, they just vanish...
First it was some 200 destroyers/light cruisers, SM them back but now my carrier fleet is going away, also after checking, entire "fleets/groups" of specific ships in class design is gone, the design is there but no ships/bases are left...