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

0 Members and 1 Guest are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11019
  • Thanked: 16855 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #735 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
 
The following users thanked this post: db48x, skoormit

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11019
  • Thanked: 16855 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #736 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.
 
The following users thanked this post: skoormit

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11019
  • Thanked: 16855 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #737 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.
 
The following users thanked this post: skoormit

Offline db48x

  • Captain
  • **********
  • d
  • Posts: 547
  • Thanked: 173 times
Re: v1.13.0 Bugs Thread
« Reply #738 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…
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11019
  • Thanked: 16855 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #739 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.
 

Joshua Wood

  • Guest
Re: v1.13.0 Bugs Thread
« Reply #740 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.
« Last Edit: August 02, 2022, 03:40:11 AM by Steve Walmsley »
 

Offline Garfunkel

  • Registered
  • Vice Admiral
  • **********
  • Posts: 2426
  • Thanked: 797 times
Re: v1.13.0 Bugs Thread
« Reply #741 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.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11019
  • Thanked: 16855 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #742 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.
 
The following users thanked this post: mike2R, serger, punchkid, BAGrimm, skoormit, nuclearslurpee

Offline ExChairman

  • Bronze Supporter
  • Commodore
  • *****
  • E
  • Posts: 600
  • Thanked: 23 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 #743 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.
Veni, Vedi, Volvo
"Granström"

Wargame player and Roleplayer for 33 years...
 

Offline nuclearslurpee

  • Vice Admiral
  • **********
  • Posts: 2000
  • Thanked: 1415 times
  • Radioactive frozen beverage.
Re: v1.13.0 Bugs Thread
« Reply #744 on: August 02, 2022, 08:17:29 AM »
TLDR: Gauss turrets are now kinetic research.

Best change in patch.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11019
  • Thanked: 16855 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #745 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();
« Last Edit: August 02, 2022, 09:01:07 AM by Steve Walmsley »
 

Offline Kiero

  • Bronze Supporter
  • Warrant Officer, Class 1
  • *****
  • Posts: 80
  • Thanked: 43 times
  • Bronze Supporter Bronze Supporter : Support the forums with a Bronze subscription
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.13.0 Bugs Thread
« Reply #746 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
 

Offline ExChairman

  • Bronze Supporter
  • Commodore
  • *****
  • E
  • Posts: 600
  • Thanked: 23 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 #747 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...
Veni, Vedi, Volvo
"Granström"

Wargame player and Roleplayer for 33 years...