Author Topic: v4.9 Bugs Thread (no longer current)  (Read 26652 times)

0 Members and 1 Guest are viewing this topic.

Offline boggo2300

  • Registered
  • Rear Admiral
  • **********
  • Posts: 895
  • Thanked: 16 times
Re: Official v4.9 Bugs Thread
« Reply #30 on: January 23, 2010, 05:00:26 PM »
Quote from: "Steve Walmsley"
So does this only appear after a hang? I wonder if the hang is actually an endless loop and the endless loop is what is creating the huge amount of orders. That would make sense but the question becomes why does it only happen occasionally?

EDIT: I notice that everyone mentioning this bug so far has mentioned Earth and Mars. That could be just a coincidence but it is worth taking into account. The next time this happens, check if it is affecting a cycle between Earth and Mars and also check if Earth and Mars are close together in their orbits.

Steve


OK Steve after clearing it up, I recreated the cycle orders to pick up and deliver infrastructure, Earth -> Mars  

All was fine until mars got to about 3-4 degrees behind Earth in its orbit, then a turn cycle started taking ages.

I didn't interrupt, just copied the database and looked, and lo & behold lines and lines and lines of the dupe'd orders.

So it LOOKS like it happens when Earth and Mars are very close together.

I'm sending you a copy of my dbase that is currently in fill up the db mode (It's 29.6mb though so attachment may  bounce) hmm OK my ISP has max attachment size so it wont let me send it

Matt
The boggosity of the universe tends towards maximum.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20466 times
Re: Official v4.9 Bugs Thread
« Reply #31 on: January 23, 2010, 06:39:25 PM »
Thanks for the information everyone has been gathering on the cycle orders problem. It does appear to be related to the situation where an entire list of cycled orders is being completed in less than one increment. As a workaround while I find and fix this I suggest using day-long increments when Earth and Mars are close together.

Steve
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11675
  • Thanked: 20466 times
Re: Official v4.9 Bugs Thread
« Reply #32 on: January 23, 2010, 10:38:04 PM »
Quote from: "Steve Walmsley"
Thanks for the information everyone has been gathering on the cycle orders problem. It does appear to be related to the situation where an entire list of cycled orders is being completed in less than one increment. As a workaround while I find and fix this I suggest using day-long increments when Earth and Mars are close together.
Finally fixed I think. The problem was that the order object for the newly cycled order (but not the DB record) was retaining an 'Arrived' flag and a 'Time Required' value that are set when the fleet arrives to unload (or load) cargo. This meant that if the cycled order was carried out during the same increment in which it was created, the newly cycled load or unload never happened (because the program thought the fleet had already arrived) and the time required for unload was therefore never set. Instead, the code went down the route for a fleet that was mid-unload using the last time required value from the previous cycle of the same order. As the time required value diminishes during the unload process that value was often a very small one when it was inadvertently passed into the next cycle (and would potentially get still smaller as the loop continued). Because the order now required only a small amount of time, it could be carried out thousands of times in a long increment, such as 30 days. So the hang wasn't really a hang but was an increment that was taking a really long time to complete. The database records containing the thousands of orders are only tidied up at the end of the increment so if a player Ctrl-Alt-Deletes out during this really long increment those records remain in the DB, causing overflow errors when you try to select the affected fleet in the Fleet window.

Because this data error was only in the order objects and not the DB, the problem would not occur if a new increment was started before the cycled order was reached (because data is refreshed from the DB at the start of the next increment). So in order for this error to happen, it had to be a task involving loading or unloading cargo and it had to be a situation where all the orders in the cycled order list could all be completed within one increment. Which meant a rare scenario such as Earth and Mars in close proximity plus a long increment time.

In effect, this was like the Stargate episode where they get trapped in a time loop by the alien archeologist trying to see his dead wife (the one with the fruit loops!). Your cargo fleet is trapped in its own little time loop, cut off from the rest of the universe and living the same day over and over thousands of times until it finally comes out the other side (or Colonel O'Neill uses Ctrl-Alt-Delete). I guess we could call it the groundhog bug :)

I'll release the v4.91 patch shortly which should prevent this problem in the future. If you have an existing fleet with this problem then you will need to remove the problem orders. You can click through the errors on the F12 window and then use Delete All button to remove all of the orders. You might also be able to use another fleet to Absorb the affected fleet, which should delete the affected fleet but keep the ships.

Steve
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5657
  • Thanked: 372 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Official v4.9 Bugs Thread
« Reply #33 on: January 24, 2010, 01:07:56 AM »
Had a pre-designed ship come up with "Insufficient life support".
 

Offline greywolf

  • Leading Rate
  • *
  • g
  • Posts: 6
Re: Official v4.9 Bugs Thread
« Reply #34 on: January 24, 2010, 05:21:17 AM »
Quote
There are usually two reasons for these messages. The first is having PC regional settings set to a country that uses the comma for the decimal separator. If v4.77 is working fine that seems unlikely. The second is a mismatch between database and program caused by an installation problem. Make sure when you upgrade to v4.9 you confirm the overwrites of the two files.

Thanks, Steve, for pointing out clearly that it could be only a faulty installation or regional settings – the latter turned out to be the real cause. My default settings are German. When Aurora didn’t work with these settings, I simply swapped point and comma, which did the trick for 4.77 (my first installation), but apparently not for 4.8x and 4.9x. Now that I’m using English settings, Aurora works. Thanks again!
 

Offline MoonDragon

  • Warrant Officer, Class 1
  • *****
  • M
  • Posts: 81
Re: Official v4.9 Bugs Thread
« Reply #35 on: January 24, 2010, 06:28:54 AM »
After the civilians bought their first cargo ship, every time the system map refreshes I'm now getting:
Code: [Select]
Error in ShowFleetList

Error 35602 was generated by Nodes
Key is not unique in collection

If it matters, I SM created another civ shipping line as the first one seemed to not want to do much. The very next turn after I created the second one, the first bought its freighter and started causing the issue.
(@)
 

Offline Knight Otu

  • Leading Rate
  • *
  • K
  • Posts: 7
Re: Official v4.9 Bugs Thread
« Reply #36 on: January 24, 2010, 06:39:38 AM »
I'm getting a few
"Error in NPRPopPlanning
Error 91"
s when advancing time in games that don't use Real Star Systems and have a low difficulty modifier, but seemingly only at the start. In a test, Real Star Systems with pretty much the same options checked (I have different environmental tolerances in both games) does not throw that error. A game without Real Star Systems but with default difficulty also does not appear to cause that error.
 

Offline Hawkeye

  • Silver Supporter
  • Vice Admiral
  • *****
  • Posts: 1059
  • Thanked: 5 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Official v4.9 Bugs Thread
« Reply #37 on: January 24, 2010, 07:28:21 AM »
I had a situation of 4+ hours realtime with nothing but 5-second-increments.
After getting the password for designer mode (thanks Steve) I found a large group of NPR FACs sitting on top of a precursor listening post, doing nothing (they were meson armed).

I simply abandoned the precursor listening post, but that didn´t help, due to the fact that there also were 4 precursor size-24 buoys sitting in orbit over the planet. The FACs didn´t shoot those either and with a hostile contact in range, the increments would be shorted to 5 seconds forever. After ordering some of the FACs to take out the buoy, they were blastet in the next 5-second increment and from there on, everything went back to normal.

Long story short.
NPR ships hanging around hostile contacts, but not engaging them seems to cause 5-second increments forever.
I understand mesons can´t touch planets, but then the FACs should withdraw and the NPR bring in something with missiles.
Not shooting the buoys, I don´t understand. As I have been able to order them to shoot ´em down, it can´t be a detection problem.
Ralph Hoenig, Germany
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: Official v4.9 Bugs Thread
« Reply #38 on: January 24, 2010, 10:36:25 AM »
I'm running Aurora on Ubuntu 9.10 through Wine.  It was working on 4.8x, but since upgrading to 4.90 (and now 4.91) I get a "Run-time Error '13' - Type Mismatch" and Aurora crashes whenever I attempt to load the (F9) 'System Information' window, or the 'Geological Survey Results' window (whether by the'Geo Status' button on the (F2) Population & Production screen, or the button on the F3 'System Map' window).

Opening the (F3) 'System Map' throws an "Error in Show Minerals:  Run-time Error '13' - Type mismatch" but does not crash Aurora.  Opening the Ctrl-F7 'Technology Report' window generates "Error in PopulateActive:  Run-time Error '13' - Type Mismatch" but does not crash Aurora.  In fact, the windows open and appear to function normally.

I think I've checked all the other windows, and none of them show an error.  I have no idea if the error is a Linux/Wine problem, or if it's causing an otherwise-overlooked error to crash the game.
 

Offline Brian Neumann

  • Vice Admiral
  • **********
  • Posts: 1214
  • Thanked: 3 times
Re: Official v4.9 Bugs Thread
« Reply #39 on: January 24, 2010, 12:55:17 PM »
Not sure if this is really a bug or not.  When you take appart tech from another race and you do not have the theory for that tech, ei Electronic Warfare or Jump theory.  You get a specific tech, ie jump multiplier x3 or ecm-1.  You can then go ahead and research the next level in that field even though you still do not have the theory that normally unlocks the field in the first place.  

I would suggest that the theory be found first, before you get either the specific tech, or at least before you can improve what you have found.

Brian
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5657
  • Thanked: 372 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Official v4.9 Bugs Thread
« Reply #40 on: January 24, 2010, 01:52:45 PM »
Quote from: "Father Tim"
I'm running Aurora on Ubuntu 9.10 through Wine.  It was working on 4.8x, but since upgrading to 4.90 (and now 4.91) I get a "Run-time Error '13' - Type Mismatch" and Aurora crashes whenever I attempt to load the (F9) 'System Information' window, or the 'Geological Survey Results' window (whether by the'Geo Status' button on the (F2) Population & Production screen, or the button on the F3 'System Map' window).

Opening the (F3) 'System Map' throws an "Error in Show Minerals:  Run-time Error '13' - Type mismatch" but does not crash Aurora.  Opening the Ctrl-F7 'Technology Report' window generates "Error in PopulateActive:  Run-time Error '13' - Type Mismatch" but does not crash Aurora.  In fact, the windows open and appear to function normally.

I think I've checked all the other windows, and none of them show an error.  I have no idea if the error is a Linux/Wine problem, or if it's causing an otherwise-overlooked error to crash the game.

I would apply the 4.90 patch again followed by the 4.91. See if that helps. To me, it almost sounds like the upgrade didn't get applied.
 

Offline MoonDragon

  • Warrant Officer, Class 1
  • *****
  • M
  • Posts: 81
Re: Official v4.9 Bugs Thread
« Reply #41 on: January 24, 2010, 02:23:42 PM »
After installing 4.91, I still get:

Error in ShowFleetList

Error 35602 was generated by Nodes
Key is not unique in collection

every time the game attempts to redraw the system map. Is there anything I can attempt to do to fix it?
(@)
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: Official v4.9 Bugs Thread
« Reply #42 on: January 24, 2010, 02:38:32 PM »
Quote from: "Erik Luken"
Quote from: "Father Tim"
I'm running Aurora on Ubuntu 9.10 through Wine.  It was working on 4.8x, but since upgrading to 4.90 (and now 4.91) I get a "Run-time Error '13' - Type Mismatch" and Aurora crashes whenever I attempt to load the (F9) 'System Information' window, or the 'Geological Survey Results' window (whether by the'Geo Status' button on the (F2) Population & Production screen, or the button on the F3 'System Map' window).

Opening the (F3) 'System Map' throws an "Error in Show Minerals:  Run-time Error '13' - Type mismatch" but does not crash Aurora.  Opening the Ctrl-F7 'Technology Report' window generates "Error in PopulateActive:  Run-time Error '13' - Type Mismatch" but does not crash Aurora.  In fact, the windows open and appear to function normally.

I think I've checked all the other windows, and none of them show an error.  I have no idea if the error is a Linux/Wine problem, or if it's causing an otherwise-overlooked error to crash the game.

I would apply the 4.90 patch again followed by the 4.91. See if that helps. To me, it almost sounds like the upgrade didn't get applied.


It was working in 4.82, so I doubt that's the problem.  Plus the 'Game Info' screen says 'Version 4.91'.
 

Offline Vanigo

  • Lt. Commander
  • ********
  • V
  • Posts: 295
Re: Official v4.9 Bugs Thread
« Reply #43 on: January 24, 2010, 04:06:13 PM »
Quote from: "Steve Walmsley"
Thanks for the information everyone has been gathering on the cycle orders problem. It does appear to be related to the situation where an entire list of cycled orders is being completed in less than one increment. As a workaround while I find and fix this I suggest using day-long increments when Earth and Mars are close together.

Steve
Say... would it fix the problem if you put two or three copies of the orders in and cycle the whole shebang so that you never run into the same order twice (just two identical ones)?
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Official v4.9 Bugs Thread
« Reply #44 on: January 24, 2010, 05:14:03 PM »
The default sequence number for new construction is being affected by civie builds again.

I created a cargo ship design "Conestoga".  Before I started a build (I was prefabbing some components), the civies built one.  When I later went to build the first one, the name came up "Conestoga 002".  Since then, I've just finished my second one (the civies have built a total of 3) and the name for my 3rd is proposing "Conestoga 006".

I thought that the numbers were unique to the line/class combination, e.g. Harness Conestoga 001 (for the first Conestoga built by the Harkness line).

John