v1.9.4 Potential Bugs Thread 1.9.4

[Tyrannus Rex]

Version 1.9.4 from 1.9.3
The function number - None
The complete error text - None
The window affected - Ground Forces -> Tactical map
What you were doing at the time - One day turns to process game.
Conventional or TN start - Conventional
Random or Real Stars - Random
Is your decimal separator a comma? - Yes
Is the bug is easy to reproduce, intermittent or a one-off? - Intermittent
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - 20 years both race and system is custom.

Steps to reproduce - Current Geo/Grav and ODB are set to overhaul when supply less than 20%
All vessels have msp greater than highest failure rate; and with AFR approx 15-17%.
When going for overhaul no vessel is being resupplied, planet has excess in maintenance facilities needed to overhaul with MSP available to resupply all vessels.
Currently each vessel is overhauling at various times, completing and going back into overhaul without restocking MSP. Removed condition with one geo survey and surveying with no MSP onboard.
It also appears that MSP is being taken but not appearing to be loaded onto said vessels.

[SpaceMarine]

Version 1.9.4 from 1.9.3
The function number - None
The complete error text - None
The window affected - Ground Forces -> Tactical map
What you were doing at the time - One day turns to process game.
Conventional or TN start - Conventional
Random or Real Stars - Random
Is your decimal separator a comma? - Yes
Is the bug is easy to reproduce, intermittent or a one-off? - Intermittent
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - 20 years both race and system is custom.

Steps to reproduce - Current Geo/Grav and ODB are set to overhaul when supply less than 20%
All vessels have msp greater than highest failure rate; and with AFR approx 15-17%.
When going for overhaul no vessel is being resupplied, planet has excess in maintenance facilities needed to overhaul with MSP available to resupply all vessels.
Currently each vessel is overhauling at various times, completing and going back into overhaul without restocking MSP. Removed condition with one geo survey and surveying with no MSP onboard.
It also appears that MSP is being taken but not appearing to be loaded onto said vessels.

Thank you for the properly formatted bug report but it appears you are using a comma for your decimal separator, this can cause many issues so to help track down the bug please follow this guide http://aurora2.pentarch.org/index.php?topic=11139.msg129305 once you have followed it and you have changed your separator, please try to reproduce this bug and if you are able to then edit your post accordingly and I will look at it further.

[Cosinus]

Under some very specific circumstances, you can design a particle beam weapon with vastly reduced range, compared to what it should have.

The window affected: components design, view technology, class design
What you were doing at the time: see below
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
The rest: N/A

Steps I used to reproduce (some might be redundant):

• new TN game
• Instant research some techs, in my case particle beam range 200000, Beam fire control range 48000, Beam FC Tracking 3000
• design a beam fire control, 24000 range, 12000 TS, I also designed some random gauss turret
• create a new ship class put Beam FC and Gauss turret on it
• create a particle beam prototype with strength 2, range 200000, add it to the ship
• see that the range of the particle beam is displayed as 24000 in ship design because of the fire control (this is intended afaik)
• Check the technology window and see that the particle beam has 24000 range there also (this is the bug)
• Design a beam fire control 192000 range, 3000TS add it to the ship -> Range of particle beam is still 24000, while it should be 192000
• particle beam now permanently has wrong range

DB Attached (game is called TESTGAME).

PS: Did you miss my previous bug report in this thread?

[Bughunter]

Missile launchers with 0.4x size/20x reload rate have significantly less crew requirement than missile launchers with 0.3x size/100x reload rate.
The crew requirement of missile launchers increases with increasing size (This makes sense). Missile launchers with the above specifications seem to be an exception to this rule (this is very likely a bug)

The window affected: Components design
What you were doing at the time: Designing a missile launcher
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Trivial. Choose a larger missile size for greater effect.
The rest: N/A

Reproduced, will move to confirmed. Thanks for the reminder.

[Shodan13]

The option to choose a random name from a specific theme for ship classes does not save and thus work as intended.     

Version 1.  9.  4 from 1.  9.  3

The function number - N/A
The complete error text - N/A
The window affected - Class Design
What you were doing at the time - Trying to get my ship classes to use random names from a theme list.     
Conventional or TN start - TN start
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? - Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - No length at all, can happen immediately

Steps to reproduce - Start a game, go to Class Design screen, go to miscellaneous tab, pick any theme and click the "select random name from theme" button and create a few new classes.       Notice how they are alphabetical rather than random.       Going back to the miscellaneous tab will show that neither the theme nor "select random name from theme" has not been saved.   


PS.  Is the bug with movement orders being lost on joining fleets already reported e. g.  when using tugs? 

[Inglonias]

The option to choose a random name from a specific theme for ship classes does not save and thus work as intended.     

Version 1.  9.  4 from 1.  9.  3

The function number - N/A
The complete error text - N/A
The window affected - Class Design
What you were doing at the time - Trying to get my ship classes to use random names from a theme list.     
Conventional or TN start - TN start
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? - Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - No length at all, can happen immediately

Steps to reproduce - Start a game, go to Class Design screen, go to miscellaneous tab, pick any theme and click the "select random name from theme" button and create a few new classes.       Notice how they are alphabetical rather than random.       Going back to the miscellaneous tab will show that neither the theme nor "select random name from theme" has not been saved.   


PS.  Is the bug with movement orders being lost on joining fleets already reported e. g.  when using tugs?

The theme selection in the Misc. tab is for naming ships of that class, not for naming new classes. It works as intended. (If it didn't, I would be very upset, because I use that feature for all my ships)

[Bughunter]

Under some very specific circumstances, you can design a particle beam weapon with vastly reduced range, compared to what it should have.

The window affected: components design, view technology, class design
What you were doing at the time: see below
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
The rest: N/A

Steps I used to reproduce (some might be redundant):

• new TN game
• Instant research some techs, in my case particle beam range 200000, Beam fire control range 48000, Beam FC Tracking 3000
• design a beam fire control, 24000 range, 12000 TS, I also designed some random gauss turret
• create a new ship class put Beam FC and Gauss turret on it
• create a particle beam prototype with strength 2, range 200000, add it to the ship
• see that the range of the particle beam is displayed as 24000 in ship design because of the fire control (this is intended afaik)
• Check the technology window and see that the particle beam has 24000 range there also (this is the bug)
• Design a beam fire control 192000 range, 3000TS add it to the ship -> Range of particle beam is still 24000, while it should be 192000
• particle beam now permanently has wrong range

DB Attached (game is called TESTGAME).

PS: Did you miss my previous bug report in this thread?

Reproduced, it happens both with prototypes and (SM) researched components. Will add to confirmed.

[xenoscepter]

Requested Data:

The function number - Not Applicable.
The complete error text - Not Applicable.
The window affected - Class Design.
What you were doing at the time - Design Ship Classes.
Conventional or TN start - Trans-Newtonian Start.
Random or Real Stars - Known Star Systems.
Is your decimal separator a comma? - Nope.
Is the bug is easy to reproduce, intermittent or a one-off? - The bug can be reproduced, but it is very specific.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Not Applicable, Jan. 1st, 2025

IMPORTANT STUFF - READ THIS FIRST:

 --- This bug was produced both on 1.9.3 and in 1.9.4 with the save carried over. The DB attached has several copies of the Class Design used to trigger the bug, along with several screenshots of the bug. The copies of the design were made after triggering the bug. The steps to reproduce are long, so I will include them in an Off-Topic drop down to avoid taking up too much space. SM Mode was "On" the entire time for this bug, both in the 1.9.3 and 1.9.4 iterations. The bug in question involves Maintenance Storage Bay - Fighter taking up only 2 Tons instead of 3 Tons; I would chalk this up to a rounding thing, but C# rounds up in all instances as far as I known.

Steps to Reproduce:

 - Step One:

Off-Topic: show

(Turn on SM Mode)

Insta-Research the following Techs:
    - 0.75x Size Reduction / 4x Recharge (Laser)
    - 12cm Laser Calibre
    - Capacitor 2 & 3
Design & Insta-Research the following Components:
    - 5-Ton (0.1HS) Res 60 Active Sensor
    - 10-Ton (0.2HS) EM & Thermal Passive Sensors (1 of each, both are 10-Tons)
    - 375-Ton Nuclear Thermal Engine (1.00x Power, 1.0 Fuel Consumption, 100% Thermal Output)
    - 12cm C0.75 Infrared Laser (0.75x Reduction, Capacitor 3)
    - Triple Turret Mount w/ 12cm C0.75 Infrared Laser (Tracking Speed for Turret Gear is 0 km/s)
    - Pressurized Water Reactor massing 108 Tons (?) and putting out 6.1 Power.
    - Beam FCS with 2x Range and 1x Tracking Speed
    - 150-Ton (3HS) Shield Generator (Alpha Strength, Regen 1)

 - Step Two:

Off-Topic: show

Create a New Design and add the following Components:
    - Add 2 of the Engines
    - Add 125,000 Litres of Fuel Storage (2X Fuel Storage, 2x Fuel Storage - Small, 1x Fuel Storage - Tiny)
    - Add 1 each of the Active Sensor, EM Passive Sensor and Thermal Passive Sensor
    - Add 2 of the Triple Turrets, 2 of the Beam FCS, and 2 of the Shield Generators.
    - Add 1 Reactor
    - Add 3 Engineering Spaces

 - Step Three:

Off-Topic: show

Now add the following Components to trigger the bug:
    - Add 1 Engineering Spaces - Tiny
    - Add 1 Maintenance Bay - Fighter
    - Add another Maintenance Bay - Fighter, this bay should weigh only 2 Tons instead of three, bring the mass up from 3,117 to 3,119.
    - That's the bug, pain in the arse innit?

...Edited because the headers were obnoxious. I found this bug last night while porting over an old corvette design. I recall there was other weirdness with the Fighter Fuel Storage and the Fighter Engineering Spaces, but I cannot confirm it. I stumbled upon this by chance, but while it is onerous to reproduce the method is straightforward and consistent. I mention the weirdness with the other components only because that information may be of use.

[bankshot]

SM mode random ruins:  when repeatedly hitting "random ruin" in an attempt to get a particular ruin type the Alien Installation type locks.  The installation remains present even when selecting "random ruin" again to delete the ruin.  And the installation does not appear to change. If you get say Ground 50% installation that is permanent even when you repeatedly re-roll the ruin.  This is different than the behavior in 1.5.1 where the installation was also deleted upon deletion of the ruin. 

Minor display bug: the ruin text does not update after deletion, you have to close and re-open the window to see that is deleted.  The text will update with the new ruin type if you reroll the ruin again.


Version: 1.9.4

The function number: no error
The complete error text: N/A
The window affected: System Generation and display
What you were doing at the time: Repeatedly pressing "random ruin" in SM mode
Conventional or TN start: TN
Random or Real Stars: read
Is your decimal separator a comma? no
Is the bug is easy to reproduce, intermittent or a one-off? easy

Thank you for following the formatting, I have confirmed that you are not able to delete the ruins and also the bonus stays the same, though the installation does appear to change, either way this is a bug of somekind and will be logged in confirmed, thank you for the report.

Actually the ruins do properly delete.  The optional installation (which provides a permanent research bonus) does not.  The ruins not appearing to delete is a display bug - if you close and reopen the screen the ruins are no longer there, but the installation remains.  You can then open the economics screen to confirm the installation bonus is still present. 

In case it matters - this was done on Mars on a new game with no time elapsed.   

Also - I can confirm Iceranger's Science Officer rank report.  Regardless of the rank of the Captain the science officer must be an R7 to hold the position.  Upon promotion the officer is automatically removed from the post.  If you check the "Senior C.O.' then only R6 officers can be selected for the post.  After assigning an R6 officer you can then demote to R7 without the officer being removed. 

[skoormit]

Jump Point exploration is very clearly not creating the expected number of links to existing systems.
I made a non-known stars game with max systems = 1000, local chance = 95% and spread = 5.
I used SM to perform full grav surveys, then explored each new jump point with a fleet.
I continued until I had explored to a distance of 4 jumps from Sol.

The results:
41 systems explored.
Exactly two of those had links to existing systems.
Both of those links led back to the system that had originally led into that system.

Also of note:
After the naming theme runs out of names, the usage of the "System #X" template has problems.
The value of X is always either very close to 0, or very close to 1000, and in many cases the same X is used for multiple systems.
Of the 24 systems with this name template, there are only 15 distinct names. Here are the values of X:
0 0 0
1
2
3 3
4
5 5 5
6
7
987
990 990
994
996
997 997 997
998 998
1000

A cursory examination of the database indicates that these values of X match the system number for these systems.
From this data, I think that this is what is happening:
When a link to a local system is generated, the SystemNumber is correctly selected at random from within the specified local range.
If that SystemNumber matches an existing number, the code makes a new system with the same number instead of linking to the existing system.
The exception to this is when the SystemNumber matches a system that the current system already has a link to, in which case a new link is created, resulting in a double link between the systems.

DB is attached.

TN start
Random Stars
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent or a one-off? Easy

[Shodan13]

The option to choose a random name from a specific theme for ship classes does not save and thus work as intended.     

Version 1.   9.   4 from 1.   9.   3

The function number - N/A
The complete error text - N/A
The window affected - Class Design
What you were doing at the time - Trying to get my ship classes to use random names from a theme list.       
Conventional or TN start - TN start
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? - Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - No length at all, can happen immediately

Steps to reproduce - Start a game, go to Class Design screen, go to miscellaneous tab, pick any theme and click the "select random name from theme" button and create a few new classes.        Notice how they are alphabetical rather than random.        Going back to the miscellaneous tab will show that neither the theme nor "select random name from theme" has not been saved.     


PS.   Is the bug with movement orders being lost on joining fleets already reported e.  g.   when using tugs?

The theme selection in the Misc.  tab is for naming ships of that class, not for naming new classes.  It works as intended.  (If it didn't, I would be very upset, because I use that feature for all my ships)

Ok thanks, is there a way to make the game pick random names for classes rather than alphabetical ones?

[Bughunter]

Requested Data:

The function number - Not Applicable.
The complete error text - Not Applicable.
The window affected - Class Design.
What you were doing at the time - Design Ship Classes.
Conventional or TN start - Trans-Newtonian Start.
Random or Real Stars - Known Star Systems.
Is your decimal separator a comma? - Nope.
Is the bug is easy to reproduce, intermittent or a one-off? - The bug can be reproduced, but it is very specific.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Not Applicable, Jan. 1st, 2025

IMPORTANT STUFF - READ THIS FIRST:

 --- This bug was produced both on 1.9.3 and in 1.9.4 with the save carried over. The DB attached has several copies of the Class Design used to trigger the bug, along with several screenshots of the bug. The copies of the design were made after triggering the bug. The steps to reproduce are long, so I will include them in an Off-Topic drop down to avoid taking up too much space. SM Mode was "On" the entire time for this bug, both in the 1.9.3 and 1.9.4 iterations. The bug in question involves Maintenance Storage Bay - Fighter taking up only 2 Tons instead of 3 Tons; I would chalk this up to a rounding thing, but C# rounds up in all instances as far as I known.
...

This can be reproduced by just creating a new class and adding nothing but Fighter maintenance bays. Most of the time it will add 3 tons to the total, but every once in a while it will only go up 2 tons.

The reason this happens is the real size of the component is 2.5 tons (0.05 HS), but is rounded to show as 3 tons in the component window. Since rounding is done upwards and there is also a tiny bit of weight added for armour it will also add 3 tons most of the time. By increasing armour on the design I got it to vary between 3-4 tons in weight added for every component.

For such small components the rounding does misrepresent the size, but I would say this is technically not a bug. Maybe we should still suggest to Steve to show the decimal for <10 ton components?

[Iceranger]

Requested Data:

The function number - Not Applicable.
The complete error text - Not Applicable.
The window affected - Class Design.
What you were doing at the time - Design Ship Classes.
Conventional or TN start - Trans-Newtonian Start.
Random or Real Stars - Known Star Systems.
Is your decimal separator a comma? - Nope.
Is the bug is easy to reproduce, intermittent or a one-off? - The bug can be reproduced, but it is very specific.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Not Applicable, Jan. 1st, 2025

IMPORTANT STUFF - READ THIS FIRST:

 --- This bug was produced both on 1.9.3 and in 1.9.4 with the save carried over. The DB attached has several copies of the Class Design used to trigger the bug, along with several screenshots of the bug. The copies of the design were made after triggering the bug. The steps to reproduce are long, so I will include them in an Off-Topic drop down to avoid taking up too much space. SM Mode was "On" the entire time for this bug, both in the 1.9.3 and 1.9.4 iterations. The bug in question involves Maintenance Storage Bay - Fighter taking up only 2 Tons instead of 3 Tons; I would chalk this up to a rounding thing, but C# rounds up in all instances as far as I known.
...

This can be reproduced by just creating a new class and adding nothing but Fighter maintenance bays. Most of the time it will add 3 tons to the total, but every once in a while it will only go up 2 tons.

The reason this happens is the real size of the component is 2.5 tons (0.05 HS), but is rounded to show as 3 tons in the component window. Since rounding is done upwards and there is also a tiny bit of weight added for armour it will also add 3 tons most of the time. By increasing armour on the design I got it to vary between 3-4 tons in weight added for every component.

For such small components the rounding does misrepresent the size, but I would say this is technically not a bug. Maybe we should still suggest to Steve to show the decimal for <10 ton components?

The armor calculation is actually done based on the exact class size (top right corner). The tonnage is just a round-up to integer of that. So the jump in tonnage is actually irrelevant of how the ship size is calculated.

[SpikeTheHobbitMage]

version 1.9.4
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 ship
Conventional or TN start: N/A
Random or Real Stars: N/A
Is your decimal separator a comma? Period.
Is the bug is easy to reproduce, intermittent or a one-off? Trivial
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: N/A

Ships with commercial engines can no longer use military jump drives, but no warning is given if such a ship is equipped with such a drive.  Edit: This also means that we can't build fuel efficient self-jumping jump tenders to support military engined ships.

This can be reproduced by just creating a new class and adding nothing but Fighter maintenance bays. Most of the time it will add 3 tons to the total, but every once in a while it will only go up 2 tons.

The reason this happens is the real size of the component is 2.5 tons (0.05 HS), but is rounded to show as 3 tons in the component window. Since rounding is done upwards and there is also a tiny bit of weight added for armour it will also add 3 tons most of the time. By increasing armour on the design I got it to vary between 3-4 tons in weight added for every component.

For such small components the rounding does misrepresent the size, but I would say this is technically not a bug. Maybe we should still suggest to Steve to show the decimal for <10 ton components?

The core problem is using units of 0.01 HS in some places but tons in others.  I would suggest ditching HS entirely and just using tons everywhere.

[Bughunter]

The core problem is using units of 0.01 HS in some places but tons in others.  I would suggest ditching HS entirely and just using tons everywhere.

Yes maybe, but lets take that over to suggestions instead.