Author Topic: v1.13.0 Bugs Thread  (Read 91828 times)

0 Members and 2 Guests are viewing this topic.

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #720 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.
 
The following users thanked this post: skoormit

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #721 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.
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2991
  • Thanked: 2247 times
  • Radioactive frozen beverage.
Re: v1.13.0 Bugs Thread
« Reply #722 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.
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #723 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 :)
« Last Edit: August 01, 2022, 05:51:48 AM by Steve Walmsley »
 
The following users thanked this post: Vandermeer, db48x, skoormit

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #724 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.
 
The following users thanked this post: skoormit

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #725 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?
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.
 
The following users thanked this post: skoormit, nakorkren

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #726 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.
 
The following users thanked this post: nuclearslurpee

Offline Kiero

  • Bronze Supporter
  • Lieutenant
  • *****
  • Posts: 175
  • Thanked: 118 times
  • In space no one can hear you scream.
  • Bronze Supporter Bronze Supporter : Support the forums with a Bronze subscription
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
    2024 Supporter 2024 Supporter : Donate for 2024
Re: v1.13.0 Bugs Thread
« Reply #727 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.
 

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 641
  • Thanked: 200 times
Re: v1.13.0 Bugs Thread
« Reply #728 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]
« Last Edit: August 03, 2022, 11:16:32 PM by db48x »
 

Offline ExChairman

  • Bronze Supporter
  • Commodore
  • *****
  • E
  • Posts: 614
  • Thanked: 26 times
  • Bronze Supporter Bronze Supporter : Support the forums with a Bronze subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.13.0 Bugs Thread
« Reply #729 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
Veni, Vedi, Volvo
"Granström"

Wargame player and Roleplayer for 33 years...
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #730 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.
 

Offline ExChairman

  • Bronze Supporter
  • Commodore
  • *****
  • E
  • Posts: 614
  • Thanked: 26 times
  • Bronze Supporter Bronze Supporter : Support the forums with a Bronze subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.13.0 Bugs Thread
« Reply #731 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...
Veni, Vedi, Volvo
"Granström"

Wargame player and Roleplayer for 33 years...
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20458 times
Re: v1.13.0 Bugs Thread
« Reply #732 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.
 

Offline skoormit

  • Rear Admiral
  • **********
  • Posts: 804
  • Thanked: 324 times
Re: v1.13.0 Bugs Thread
« Reply #733 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?
 

Offline skoormit

  • Rear Admiral
  • **********
  • Posts: 804
  • Thanked: 324 times
Re: v1.13.0 Bugs Thread
« Reply #734 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.  :)