Post reply

Warning - while you were reading 325 new replies have been posted. You may wish to review your post.
Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted 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...
Posted 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
Posted 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();
Posted by: nuclearslurpee
« on: August 02, 2022, 08:17:29 AM »

TLDR: Gauss turrets are now kinetic research.

Best change in patch.
Posted 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.
Posted 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.
Posted 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.
Posted 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.
Posted 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.
Posted 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…
Posted 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.
Posted 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.
Posted 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
Posted 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.  :)
Posted 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?