3.0 Bugs

[sloanjh]

I have noticed the occasional "zip across the system" problem as well but unfortunately because it's intermittent it's very difficult to pin it down. I will keep looking.

That's odd - it was fairly reproducible for me.  It seems like whenever there's a big asteroid belt it kicks in (at least that's where I noticed it), and it fixates on the ones it wants to zip about to.  It's acting like the sort routine is ignoring the position of the ship after the 1st nearest body is calculated.  If I clear the bad orders, survey the nearest, then let it look for the next "5 nearest", it finds a new (presumably correct) "nearest" to survey first, but 2-4 are the same ones it wanted to hit before.

John

Whats probably hapenning is that the code is evaluating the 5 nearest to the start position of the TG, in one query.  These may well be in different directions from the origin point, resulting in the zigzag across the system.

You might be close, but I'm pretty sure that's not quite it.  One of the cases happened at a distant binary with a (very small radius) asteroid belt, where the primary also had an asteroid belt.  It found one (the first candidate) survey target, and then said that no others were close enough.  After surveying the first, it found the next one, and said that no others were close enough.  If it were behaving as you suspect, it would have found five candidates around the binary, but the path might have zipped back and forth in the vicinity of the position when the search was performed.

I have a strong suspicion that you've got it right that somehow the start position for calculations 2,3,4,5 are wrong - my guess that it's using something like the position of the primary sun (i.e. 0,0) or the first body to come out of the query or something like that.

What needs to happen is for the routine to evaluate the 2nd nearest using the origin point of the 1st, then the 3rd using the origin point of the 2nd and so on.  This will probably be prohibitive in processing (5 queries instead of one).

I actually wouldn't mind the behavior you suspect (as long as the optimization was only turned on in the "lots of unsurveyed bodies" case).  It would be a little bit locally sub-optimal (since you might zip back and forth past the search point for the next 5), but it might be an improvement globally - it might pick up "stragglers" that got missed out by the "next closest" algorithm.  No algorithm we're going to see here is going to be perfectly optimal, since finding the optimal solution is equivalent to solving the traveling salesman problem, which I don't think Steve really wants to code up

I suspect that the real solution is not to use the "next 5", and have each unit evaluate its next target as it finishes the current one.  Note that if you do this you will tend to have a wave of surveyors moveing through the system, all of them turning up at one planet and surveying 1 or 2 moons then all moving to the next, rather than send one surveyor to each planet, who then surveys the planet & moons, this increasing the efficiency of the survey (which is what I suspect Steve was tring to do with the "next 5" idea.)

I suspect this would put us back in the old, slow performance mode, since (I think) the amount of calculations needed to survey the belt is the same as in the old way of doing it (essentially 1 query/calculation per body).  The pauses would be shorter since only one target would be calculated at a time, but there'd be 5 times as many of them.

That being said, I also think it would be nice if it would do what you describe here (evaluate the next contact while doing the sensor check) - right now I'm taking 3-hour timesteps so that my survey ship isn't in a mode of "spend 2 hours surveying an asteroid and 22 waiting to calculate my next target" when I do a 1-day update.  I'm pretty sure Steve has said that (unfortunately)  there are problems with trying to do this though, given the details of how the turn sequence is processed.

Caio fer now,
John

[sloanjh]

There seems to be a "leak" somewhere in the calculation of "Recent Stockpile +/-" on the Mining tab of the F2 screen.  I don't have an freighters docking, mass drivers, etc., but it's claiming a run rate of -8 on Gallacite and -17 of Duranium, when in fact the stockpiles went down by -12 and -24, respectively (I didn't check the others - I suspect they're the same).  I do have a maintenance facility with lots of ships in orbit - I suspect that this mineral cost isn't being counted.

The odd thing is that I haven't noticed this in previous versions with maintenance facilities.

John

[Steve Walmsley]

Error in SetupSensorChecks

Error 3058 was generated by DAO.Recordset
Index and ?basic?/?fundamental? key cannot contain Null value.

Second line (shows on my computer in Polish) is  translated. As I do not work with Access, I do not know which word should be there.
Step 1 day - error shows every 5 days. Step 5 days - the same. Step 30 days - only 1 error.

Nothing serious - does not affect game play so far, but strange.

I got this one too. It happened after I created some fighters without having a base for them. (I was expecting them to be "crated" like 2.5)

Finally tracked this down, It is related to fighters but not in the way you might expect. When you first build fighters, if you haven't setup a destination fleet the program creates one called New Fighters - <popname>. Unfortunately the program sets this fleet up without setting a RaceID. During each 5-day the program checks to see if more than one race is in a system. It does this by seeing how many distinct race IDs can be found in the list of populations and fleets for each system. Unfortunately, that means it picks up the null Race ID for the New Fighters fleet and treats it as a separate race. Then it tries to use that null Race ID to setup sensor checks for that system for the non-existent race, which a different part of the program doesn't like and therefore throws the above error.

It is fixed in v3.1. The workaround for v3.0 is to delete the New Fighters fleet and select a new fleet into which fighters will be built.

Steve

[Steve Walmsley]

I tried deleting and reinstalling Aurora, and made sure that my VB runtime was fully updated. Any other suggestions?

Did you hit the "New" button on the F5 screeen yet?  When the game first starts, IIRC, there are zero classes in the DB and you get these kinds of errors.

I started to fix this by generating a blank class so you wouldn't need to hit new to avoid the error but then I got slightly more involved

When a new race is generated in future the program will create designs for large and small freighters, large and small colony ships, a geological survey ship and, depending on available tech, a grav survey ship, a terraformer and a fuel harvester. To accomplish this the program will create an engine design and some passive sensor designs. There will be some variation in the number of engines, the number of geo/grav sensors and the presence and size of any passive sensors on the survey ships.

This should save a little time and give new players some help. Existing players should save some time as well as they will be able to modify designs rather than starting from scratch.

Steve

[Haegan2005]

Yes! Thank you. This will save me a lot of time.

I tried deleting and reinstalling Aurora, and made sure that my VB runtime was fully updated. Any other suggestions?

Did you hit the "New" button on the F5 screeen yet?  When the game first starts, IIRC, there are zero classes in the DB and you get these kinds of errors.

I started to fix this by generating a blank class so you wouldn't need to hit new to avoid the error but then I got slightly more involved

When a new race is generated in future the program will create designs for large and small freighters, large and small colony ships, a geological survey ship and, depending on available tech, a grav survey ship, a terraformer and a fuel harvester. To accomplish this the program will create an engine design and some passive sensor designs. There will be some variation in the number of engines, the number of geo/grav sensors and the presence and size of any passive sensors on the survey ships.

This should save a little time and give new players some help. Existing players should save some time as well as they will be able to modify designs rather than starting from scratch.

Steve

[Pete_Keller]

Copy orders does not copy conditional order a.

[James Patten]

I have a task group which tried to join itself and disappeared from the map.

Let me explain.  I had a task group, Survey 1, which had itself as a superior task group.  This was done so that when I manually split off survey ships they would have Survey 1 was their superior group.

I had the order set so that when fuel reached under 20%, the subordinate groups would join the superior group.  This order was set for Survey 1.  This happened during a 5-day increment.  I had other ships set to join Survey 1, and got error messages about a missing task group.  When control was returned to me, neither Survey 1 nor any ships belonging to it existed.  At all. The task group was missing from the map, from the task group list, and in the ship list all its ships were missing.  The ships that had one of the disappeared ships as a mothership no longer had that ship as a mothership.

I figure a mini black hole ate them up or something.

[Cassaralla]

A fairly minor text error.

On Reduced Size Launcher 0.75 Size / 2xReload

A modification to missile launchers that reduces their size by removing part of the reloading mechanism, dramatically reducing the reload time

Shouldn't that be dramatically 'increasing' reload time?

[James Patten]

Along the same lines as an earlier error with task groups, I had separated a ship which was a parasite ship from the mother ship's group into it's own TG.  Then in the mother ship's TG, before this parasite had gone anywhere, I unthinkingly told the mother ship to recover parasites.  The mother ship recovered the parasite that was in the separate TG, but the old TG was still there and when I went into it I got an error message.  It also showed the ships from the original TG in this TG.

I tested removing the TG by going in from another TG that had a ship that I could spare.  This ship got deleted when the error prone TG got deleted.

I noticed when I had a similar problem that when I advanced 5 days and revisited the TG window, the problem TG had gone away.

[Shinanygnz]

[quote="Steve Walmsley
When a new race is generated in future the program will create designs for large and small freighters, large and small colony ships, a geological survey ship and, depending on available tech, a grav survey ship, a terraformer and a fuel harvester. To accomplish this the program will create an engine design and some passive sensor designs. There will be some variation in the number of engines, the number of geo/grav sensors and the presence and size of any passive sensors on the survey ships.

This should save a little time and give new players some help. Existing players should save some time as well as they will be able to modify designs rather than starting from scratch.

Steve[/quote]
Thank you muchly for this.  Asked for it some time ago and it'll make life a lot easier.  Now if you could just add some warship design themes and "generate" buttons...  

Stephen

[Erik L]

When awarding medals -

Shows the history line as "January 1, 500Awarded..." Other lines read "January 1, 500: Assigned..."

Should add the colon and space for conformity.

[Erik L]

Very bizarre happening...

Created Gauss cannons. Named them "Solon Magnetic Gauss Cannon", but they show up as "Gauss Cannon R1-100", nor can I rename them on the Tech Report.

[Erik L]

I created some images for medals I wanted to create. I gave them descriptive names such as M_SurveyPip.jpg. The program throws an error saying it cannot find Medals/yPip.jpg.

However I can go into the DB and put in the proper filename and it gets recognized.

[Erik L]

I had a battle in which one side never fired, even though event log entries show a 100% chance to hit. The ship designs in the fight were

Side one

Code: [Select]

Tatsumaki class Destroyer Escort    4550 tons     319 Crew     491 BP      TCS 91  TH 125  EM 240
1373 km/s     Armour 3-24     Shields 8-225     Sensors 5/5/0/0     Damage Control 0-0     PPV 39
Replacement Parts 5    

Kuat Drives NT Engine (5)    Power 25    Efficiency 0.90    Signature 25    Armour 0    Exp 5%
Fuel Capacity 50,000 Litres    Range 22.0 billion km   (185 days at full power)
Solon Magnetics Class B Shield Generator (5)   Total Fuel Cost  68 Litres per day

Quad Gauss Cannon R2-100 Turret (1x8)    Range 20,000km     TS: 10000 km/s     Power 0-0     RM 2    ROF 5        1 1 0 0 0 0 0 0 0 0
HCD PD Suite (1)    Max Range: 48,000 km   TS: 12800 km/s     79 58 38 17 0 0 0 0 0 0

HCD Close Search Scanner (1)     GPS 12     Range 120k km    Resolution 1
HCD Thermal Scanners (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km
HCD EM Scanner (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km



Code: [Select]

Alacorn class Missile Destroyer    4100 tons     463 Crew     453 BP      TCS 82  TH 125  EM 240
1524 km/s     Armour 3-22     Shields 8-225     Sensors 5/5/0/0     Damage Control 0-0     PPV 24
Magazine 204    Replacement Parts 5    

Kuat Drives NT Engine (5)    Power 25    Efficiency 0.90    Signature 25    Armour 0    Exp 5%
Fuel Capacity 50,000 Litres    Range 24.4 billion km   (185 days at full power)
Solon Magnetics Class B Shield Generator (5)   Total Fuel Cost  68 Litres per day

Racheta Medium Missile Launcher (4)    Missile Size 6    Rate of Fire 90
HCD Missile Control Suite (1)     Range 14.4m km    Resolution 40
AS-1 Glaive (34)  Speed: 10000 km/s   End: 27.8 minutes    Range: 16.7m km   Warhead: 10    MR: 12    Size: 6

HCD Class 12 Active Search Scanner (1)     GPS 1200     Range 12.0m km    Resolution 100
HCD Thermal Scanners (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km
HCD EM Scanner (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km

6 Tatsumaki and 2 Alacorn

Side 2

Code: [Select]

Woden class Cruiser    3700 tons     348 Crew     323 BP      TCS 74  TH 125  EM 300
1689 km/s     Armour 3-21     Shields 10-300     Sensors 5/5/0/0     Damage Control 0-0     PPV 10
Replacement Parts 5    

Nuclear Thermal Engine E10 (5)    Power 25    Efficiency 1.00    Signature 25    Armour 0    Exp 5%
Fuel Capacity 50,000 Litres    Range 24.3 billion km   (166 days at full power)
Alpha R300/10 Shields (10)   Total Fuel Cost  100 Litres per day

Thermal Torpedo R6 C1 (2)    Range 20,000km     TS: 1689 km/s     Power 5-1    ROF 25        2 2 2 2 2 2 0 0 0 0
Fire Control S01 10-1000 (1)    Max Range: 20,000 km   TS: 1000 km/s     50 0 0 0 0 0 0 0 0 0
Pebble Bed Reactor Technology PB-1 AR-0 (1)     Total Power Output 15    Armour 0    Exp 5%

Active Search Sensor S12-R100/100 (1)     GPS 1200     Range 12.0m km    Resolution 100
Thermal Sensor TH1-5/100 (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km
EM Detection Sensor EM1-5/100 (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km


3 Woden

Initial range was 45k with the Hathari (Side 1), orbiting a moon of the Darkmoor planet (Side 2). The Hathari opened fire with 2 salvoes of 4 AS-1 Glaive. At that point, the Darkmoor opened fire and closed to 20,000 km. The Tatsumaki were configured for PD. With no fire from the Wodens, the Darkmoor closed to 0 km. After the first Woden blew, the Tatsumaki were reconfigured to fire offensively. Neither the Wodens or the Tatsumakis ever fired once even though Active sensors were active on both sides, and firing orders were given, along with targeting information.

Both sides could see each other, as I kept getting tech scan events. The Darkmoors collected around 400pts on Fuel Efficiency 1 during the battle.
Is there something I'm missing completely, or is this some bizarre bug?

[Erik L]

Did a refit, stripped out slow (90sec refire) missile launchers to be replaced with faster ones. The F8 combat screen and event logs show both the older, and the newer ones, though the F5 screen only shows the newer launchers, as does the F6 screen.