4.26 Bugs

[Thorgarth]

Generally run with the event screen and the F2 econ screen.  Should I not have the F2 screen up on the 5th day increments?

Having the F2 window open is fine. I was just trying to pin down where the bug was happening. I think it is the wealth tab throwing the error when it updates, possibly because you have spent wealth in a a lot of different areas. I had already encountered a similar problem in my own game and corrected it. When the wealth tab was working, did you notice if the list of expenditures was full? I think the limit for v4.26 is only 12 different types. Unlimited in v4.3.

Steve

My expenditures list was full.  Any work around, or should I wait on 4.3?

[IanD]

Steve
Think this may be a new one. I transported a PDC in 7 sections to Proxima Centauri II. It unloaded fine, but when I went to assemble it  it I got a couple of  error messages, 3021 was generated by DOAfield. No current record. followed by Error 3021 was generated by DAO.dataset. No current record. I appeared to be unable to cancel the error messages after repeated attempts and had to use Task manager to close Aurora. Imagine my surprise when I reopened Aurora to find the planet was now going to assemble 17 PDCs all from the original 7 components I delivered .  I have replicated this bug. If you ask the construction queue to construct at least one more PDC than you have components for you get a series of errors, one set for each PDC. If you then cancel these errors the queue then adds that number of PDCs to be assemblked to the construction queue. If you specify a number of PDC for which there are sufficient parts all is well. Somehow in my initial error the queue must have been set to >16, and I cancelled at least 16 error sets.

Regards

[Steve Walmsley]

Generally run with the event screen and the F2 econ screen.  Should I not have the F2 screen up on the 5th day increments?

Having the F2 window open is fine. I was just trying to pin down where the bug was happening. I think it is the wealth tab throwing the error when it updates, possibly because you have spent wealth in a a lot of different areas. I had already encountered a similar problem in my own game and corrected it. When the wealth tab was working, did you notice if the list of expenditures was full? I think the limit for v4.26 is only 12 different types. Unlimited in v4.3.

Steve

My expenditures list was full.  Any work around, or should I wait on 4.3?

Unfortunately the only workaround is to delete all the wealth data or at least all the wealth data for the extra types from the WealthData table. it's an annoying bug because I could have avoided it. I originally created the grid control to hold the number of different expenditures types at that time and it never occurred to me to change it, or make it dynamic, when I added extra expenditure types. That's one of the problems with such a complex program. I can test the immediate changes but the unforeseen consequences usually trip me up.

Steve

[jfelten]

I unfortunately deleted the saved game that gave me that original population Error 11 but I started a new game and, after a year or so, I get about 5 "Error 11" windows every time I advance the clock.

Error in GetBodySuitability
Error 11 was generated by Aurora
Division by zero

Did I do something wrong?

I'm not sure. It's not been reported before, which suggests it is something specific to your campaign but it could simply be a rare bug rather than something you did. The only two places in that function where a division takes place involves the maximum racial atmospheric pressure and the racial temperature deviation. Could you open the F9 system generation window and tell what the values are for Temperature and Pressure in the Environmental Tolerances section in the top right.

. . .

Yes, you are right. fdelstanches, did you apply the data patch and the v4.26 patch to your full installation?

Steve

I encountered this error with a new 4.26 game with mdb patch.  What happened was I created Geo and Warp Point survey task groups and gave them the usual orders to split up and survey.  The problem is that I included a scout in each task group without Geo or WP survey sensors, but when the TG divided, it automatically was assigned the primary default order to survey.  So the scout was trying to survey but it didn't have survey sensors, which triggered the divide by zero error when it reached the item to survey.  I think ships without survey sensors should ignore the default survey orders since they can't survey.  

This kind of messes up the automated divide/survey combination.  Even if I delete the survey order for the scout after they split, it goes right back unless I also cancel the default survey order.  For whatever reason, the scouts ended up in the first split fleet.  So when I merge them all together again, I'll probably have to manually put the default order back.  Follow?

Update:  I started getting this error again in the next system despite deleting the survey orders for the scout ship.  I'm not sure what is causing it now, other than it seems related to Geo surveying.  I have 3 Geo survey ships that per their default orders are surveying the moons of a gas giant in a quad star system.  I have to "OK" past this error 6 times every 5 days.  I assume that is 2 errors per Geo survey ship.  I hope this helps.

[welchbloke]

I unfortunately deleted the saved game that gave me that original population Error 11 but I started a new game and, after a year or so, I get about 5 "Error 11" windows every time I advance the clock.

Error in GetBodySuitability
Error 11 was generated by Aurora
Division by zero

Did I do something wrong?

I'm not sure. It's not been reported before, which suggests it is something specific to your campaign but it could simply be a rare bug rather than something you did. The only two places in that function where a division takes place involves the maximum racial atmospheric pressure and the racial temperature deviation. Could you open the F9 system generation window and tell what the values are for Temperature and Pressure in the Environmental Tolerances section in the top right.

. . .

Yes, you are right. fdelstanches, did you apply the data patch and the v4.26 patch to your full installation?

Steve

I encountered this error with a new 4.26 game with mdb patch.  What happened was I created Geo and Warp Point survey task groups and gave them the usual orders to split up and survey.  The problem is that I included a scout in each task group without Geo or WP survey sensors, but when the TG divided, it automatically was assigned the primary default order to survey.  So the scout was trying to survey but it didn't have survey sensors, which triggered the divide by zero error when it reached the item to survey.  I think ships without survey sensors should ignore the default survey orders since they can't survey.  

This kind of messes up the automated divide/survey combination.  Even if I delete the survey order for the scout after they split, it goes right back unless I also cancel the default survey order.  For whatever reason, the scouts ended up in the first split fleet.  So when I merge them all together again, I'll probably have to manually put the default order back.  Follow?

I've had a similar error, but I haven't had to remove the default order.  I use detach non-survey and then divide fleet orders for my fleets; the scout ships (in the non-survey group) get the order to survey next 5 (or which ever order the main fleet had as default).  As soon as they get the order the non-survey group drops to speed zero and sits there with a number of uncompleted survey orders which I have to remove from the order queue.  I don't get any errors messages though.

[jfelten]

I get this error whenever an empty Task Group occurs and I have the Task Groups window open.  The empty TG's occur when I use orders like "join".  This leaves an empty TG behind for as long as the TG window is open, and causes the error every update.  If I close and reopen the TG window, the empty TG's are gone and the errors stop.  Unfortunately these empty TG's occur frequently when surveying.  

---------------------------
Aurora
---------------------------
No Record of task group in cboFleets_Click
---------------------------
OK  
---------------------------

How are people automating surveying while avoiding such errors?

[welchbloke]

I get this error whenever an empty Task Group occurs and I have the Task Groups window open.  The empty TG's occur when I use orders like "join".  This leaves an empty TG behind for as long as the TG window is open, and causes the error every update.  If I close and reopen the TG window, the empty TG's are gone and the errors stop.  Unfortunately these empty TG's occur frequently when surveying.  

---------------------------
Aurora
---------------------------
No Record of task group in cboFleets_Click
---------------------------
OK  
---------------------------

How are people automating surveying while avoiding such errors?

I only have the window open to issue orders and close it straight away specifically to avoid this error.

[jfelten]

Keeping the TG window closed does help that problem.  Unfortunately I'm now getting 6 GetBodySuitability errors every 5 days no matter what I do.  Quite annoying.  I'm still trying to find what is causing those.

[Steve Walmsley]

I get this error whenever an empty Task Group occurs and I have the Task Groups window open.  The empty TG's occur when I use orders like "join".  This leaves an empty TG behind for as long as the TG window is open, and causes the error every update.  If I close and reopen the TG window, the empty TG's are gone and the errors stop.  Unfortunately these empty TG's occur frequently when surveying.  

---------------------------
Aurora
---------------------------
No Record of task group in cboFleets_Click
---------------------------
OK  
---------------------------

How are people automating surveying while avoiding such errors?

When time is updated, the task group window is refreshed. However, for performance reasons it only refreshes the current fleet - it doesn't reload all fleets. Therefore if you have the window open and the fleet currently selected doesn't exist at the end of an increment then you will receive a message stating "No Record of task group in cboFleets_Click". it isn't really an error as the program is doing what it is supposed to do - informing you if the fleet you have selected doesn't exist. I have changed the message to ""The currently selected fleet does not exist"" so it looks less like an error.

Steve

[Steve Walmsley]

Keeping the TG window closed does help that problem.  Unfortunately I'm now getting 6 GetBodySuitability errors every 5 days no matter what I do.  Quite annoying.  I'm still trying to find what is causing those.

Have you applied the data patch to v4.26?

Steve

[jfelten]

Keeping the TG window closed does help that problem.  Unfortunately I'm now getting 6 GetBodySuitability errors every 5 days no matter what I do.  Quite annoying.  I'm still trying to find what is causing those.

Have you applied the data patch to v4.26?

Steve

Well, I initially replied that yes, I was certain I had applied the patch.  Then I started double checking.  Help/About showed 3.1.0 which must have been wrong.  <Ctrl>I showed 4.2 in the upper right hand corner.  Aurora.exe was 18,202,624 bytes / md5 = 2ff8a87332cfc4ea98c77a9b7c049349 which matched the Aurora.exe in AuroraUpdate.zip.  But the Aurora.exe in Aurora426.zip was 18,243,584 bytes / md5 3f267383401bdce9d7b94df2d904bbb2.  So I copied that one over.  I also re-ran DBUpdate101.exe for good measure since its posting implied it wouldn't hurt anything.  Now <Ctrl>I shows 4.25 and Help/About 4.2.6.  

When I restarted I couldn't see the population and production window.  Acted like it was "off the screen". Tried the Miscellaneous / Reset Windows Positions but that didn't help.  Right clicked on the P&P entry in the task bar, then used the arrow keys to move the window on to the screen (you can't use the mouse despite the cursor change, which is a bit of windows weirdness, not Aurora).  Odd.

Sadly, I still get this error 6 times per 5 day update.:  

---------------------------
Error in GetBodySuitability
---------------------------
Error 11 was generated by Aurora
Division by zero
Please report to viewforum.php?f=11
---------------------------
OK  
---------------------------

I spent hours designing starting ships.  I hope I don't have to restart.  Nothing compared to the time you invest of course.  I just have so many time demands these days.

[sloanjh]

Sadly, I still get this error 6 times per 5 day update.:  

---------------------------
Error in GetBodySuitability
---------------------------
Error 11 was generated by Aurora
Division by zero
Please report to viewforum.php?f=11
---------------------------
OK  
---------------------------

"The patch" is DBUpdate101.exe.  It fixes some corrupt planets in the DB.  The corruption isn't initially bad - bad things only happen if a race happens to be generated on one of those planets.  IIRC, the patch does not fix those bad races, so once you start getting the error, running the patch won't stop it.  So the behavior you're seeing is consistent with the patch not having been run.  This does not mean that your errors are coming from the bug the patch fixes, however.  I suspect that the reason Steve asked if you'd applied the patch was so that he could determine whether your bug was a known (and fixed) issue, or whether it was something new that he'd have to worry about.

  So the important question is:

I also re-ran DBUpdate101.exe for good measure since its posting implied it wouldn't hurt anything.

How sure are you about the "re-" in re-ran?  Did you have to download it to re-run it, or was it already on your computer?  If the latter, then I suspect it truly was a re-run; if the former then you probably hadn't applied the patch.

Assuming that you neglected to run the patch the first time, then Steve will have to tell you if there's a way to fix your DB at this point.  Good luck!!

The other option for you (besides repairing the DB) is just to accept the "click a few times every 5-day".  I've been in this boat before - it's not that bad....

STEVE - Is there a reason not to rebuild the 4.20 package to include a DB which has had the patch run on it?  I forget the various issues that it fixes - I think there were two of them.

John

[jfelten]

I'm pretty sure I ran the dbupdate, but I was also pretty sure I had installed the 4.26 upgrade and obviously I had not.  

Is there a reasonably simple way to manually fix the database?  I ran my 3.x game for many years of game time and I don't think I could manage that clicking 6 times every 5 days.

It would be a nice feature to be able to export/import ship designs.  People could then swap them, although matching the technology might make that impractical.  

Hey, I saved a copy of the .mdb before I started advancing time.  What if I ran the dbupdate on that?  Would it prevent this problem from recurring?  I would loose the progress I've made so far, but at least I wouldn't loose the ship designs.

[sloanjh]

Is there a reasonably simple way to manually fix the database?  I ran my 3.x game for many years of game time and I don't think I could manage that clicking 6 times every 5 days.

I think you'd have to delete the offending NPR.

Hey, I saved a copy of the .mdb before I started advancing time.  What if I ran the dbupdate on that?  Would it prevent this problem from recurring?  I would loose the progress I've made so far, but at least I wouldn't loose the ship designs.

If the evil NPR in question hadn't been generated yet, then I think it would work.  You can always try....

John

[jfelten]

Well, I tried going back to the mdb file I had saved before advancing time and restarting from there, but about 13 days in I started getting this error again.  

---------------------------
Error in GetBodySuitability
---------------------------
Error 11 was generated by Aurora
Division by zero
Please report to viewforum.php?f=11
---------------------------
OK  
---------------------------