Author Topic: Official v6.20 Bugs Thread  (Read 63820 times)

0 Members and 1 Guest are viewing this topic.

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: Official v6.20 Bugs Thread
« Reply #240 on: June 15, 2013, 01:55:36 AM »
F9 System Generation and Display
New systems are always generated with all jump points visible.  'No JP Survey' button does not work.

Pre-TN, non-Sol start. Game created with starting System Body and Jump Point surveys turned off.

[edit]
Also occurs creating a new system in an TN game.
[/edit]

[edit2]
This applies to both Jump Survey and Planet Survey, but it seems to only happen sometimes.  I'm not quite sure of the pattern, but Aurora seems to get confused about which empire it should apply the survey buttons to.  Also, sometimes some buttons will work but not others.  Changing the default race, restarting Aurora, and renaming the system all seem to have effects.  Oddly, it worked once in a custom start game with two player empires, but didn't work in a single empire, normal start game.
[/edit2]
« Last Edit: June 17, 2013, 12:15:30 PM by SpikeTheHobbitMage »
 

Offline Person012345

  • Captain
  • **********
  • Posts: 539
  • Thanked: 29 times
Re: Official v6.20 Bugs Thread
« Reply #241 on: June 16, 2013, 12:53:56 AM »
Were those automatically added at the beginning? Or did you Fast OOB them in? In the first case, there is a known bug with them, that one in fact.

Automatic. Is the over-loss of crew a separate bug?
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5654
  • Thanked: 366 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 v6.20 Bugs Thread
« Reply #242 on: June 16, 2013, 02:42:01 AM »
Automatic. Is the over-loss of crew a separate bug?

It's related. For a conventional start, don't automatically add the missile bases. Use the Fast OOB to add them, after making sure they are okay in the design screen.
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: Official v6.20 Bugs Thread
« Reply #243 on: June 17, 2013, 12:53:24 PM »
Building a PDC does not lock the design.  The design can then be modified while the PDC is being built without affecting the build cost.  Adding new construction sees the new build cost.  The design can also be deleted while under construction.  If both the Industry tab and the Ship Design window are open, it is then possible to add new construction at 0 cost.
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: Official v6.20 Bugs Thread
« Reply #244 on: June 17, 2013, 04:59:34 PM »
Refitting a ship does not update its speed to the new [edit]lower[/edit] maximum.
« Last Edit: June 18, 2013, 01:31:03 PM by SpikeTheHobbitMage »
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: Official v6.20 Bugs Thread
« Reply #245 on: June 18, 2013, 01:37:54 PM »
Error 3201 in AutomatedDesign
"You cannot add or change a record because a related record is required in table 'Tech Systems'"

This occurred about 5 months after I researched Nuclear Thermal Engine when my shipping companies tried to build their first ships.  The second line build their first F1 Freighter, but the first line failed to build anything.

I suspect my civs were trying to build a C1 Colonizer before I researched Cryogenic Transport.

[edit]And again 2x 5 day steps later, Error 3201, line 2 build another F1 Freighter and line 1 failed to build anything.[/edit]
[edit2]That is 3 for 3 now.  This time line 1 built an L1 Liner.  Line 2 is broke, so they couldn't build anything.[/edit2]
[edit3]My lack of Cargo Handling System might be a factor too ;D[/edit3]
« Last Edit: June 18, 2013, 01:56:36 PM by SpikeTheHobbitMage »
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: Official v6.20 Bugs Thread
« Reply #246 on: June 19, 2013, 12:32:54 AM »
Teams can be moved onto civilian ships, but cannot be moved off.  The only way to recover is to find and individually remove each member from the team using the Leaders screen.
 

Offline shoobs

  • Petty Officer
  • **
  • s
  • Posts: 25
Re: Official v6.20 Bugs Thread
« Reply #247 on: June 19, 2013, 12:36:01 AM »
Is there any way to figure out what is causing the OrbitalMovement divide by Zero bugs?
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: Official v6.20 Bugs Thread
« Reply #248 on: June 19, 2013, 01:48:26 AM »
Time and distance display when heading to a Lagrange Point is wrong.  This occurs both on F3 System Map and in F12 Task Groups.  It appears to be showing the distance from the ship to the primary instead of to the LP.  All Orders distance and time is calculated correctly.
 

Offline ChubbyPitbull

  • Gold Supporter
  • Sub-Lieutenant
  • *****
  • C
  • Posts: 138
  • Thanked: 27 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Official v6.20 Bugs Thread
« Reply #249 on: June 25, 2013, 02:06:19 PM »
Bug #1: Found this accidentally, playing a game with an NPR and I in adjacent systems. AI sent a large invasion fleet early on, then only 1-2 ships every few months, for a few years. They sent a new one through, and I was getting stuck with the 60 second "increment adjusted due to ship in firing range" bug, despite having no ship in firing range (and no message about NPRs fighting). I turned on SM mode and even looked around in designer mode, but couldn't find any combat. In fact, I made myself every race, and had no contacts in any system for any race, other than the one ship the NPR had jumped through. I was defending the jump point with 2 stations, each with 19 12 cm lasers on turrets, range 160,000 km, and 13 Particle Beams, range 200,000 km. Additionally, the stations each have 12 missile launchers with an MFC good out to about 50m km. The enemy ship moved out of beam range but I still got the 60 second increment, was the MFCs causing this? I was saving missile and did not want to fire them. EDIT: After a protracted fight, my defensive stations were destroyed in a hail of size 1 missile fire; however, I am still stuck at 60 second increments because "Increment length adjusted as a ship is within firing range."

Bug #2. While poking around trying to find the reason for Bug #1, I saw the NPR race had for every increment getting an error (it's scrolled out of the log so I don't have the exact quote) "2nd Alpha Squadron is attempting to transit Jump Point with a task group size of 7, but the highest jump rating is 5." I changed over to controlling the NPR, and split 2nd Alpha Squadron into a task group of 5 and a task group of 2 ships. I switched back to my player race, and after advancing time the NPR jumped 30 ships into my system. So the AI getting stopped from jumping the one task group through was apparently holding up its entire fleet.

Bug #3. After the enemy fleet finally transited, my 2 defense stations opened fire trying to do what they could. I only have one ECCM on each station, so I assign it to the Particle Beam Fire control when they fire, then assign it to the 12 cm lasers fire control while the Particle Beams recharge. After the first volley, when it came time to fire again I didn't see the log message that the Particle Beams fired, hit, or missed. In the F8 Combat Assignments Window, I saw the fire control on both stations no longer had any Particle Beams assigned to it. Figuring I mis-clicked, I reassigned them all back to the Fire Control. However, I still didn't see the Particle Beams shooting. Looking through the logs, I get the log message of the Particle Beam fire control targeting the enemy, within range. I see the log message "Particle Beam (x13) recharging, 5 power in capacitor, 15 power required to fire", but the only hit/miss messages are for the 12 cm lasers. On the next 15 second cycle, it does appear that the particle beams fire again.
« Last Edit: June 25, 2013, 03:43:26 PM by ChubbyPitbull »
 

Offline ChubbyPitbull

  • Gold Supporter
  • Sub-Lieutenant
  • *****
  • C
  • Posts: 138
  • Thanked: 27 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Official v6.20 Bugs Thread
« Reply #250 on: June 26, 2013, 03:14:19 PM »
"Error in ExecuteOrders: Error 5 was generated by Aurora. Invalid procedure call or argument."

Current game is hosed due to this, hitting "OK" on this error causes it to pop up again forever; pretty sure I know how I caused it though.

I had 3 wings of bombers trying to chip away at the enemy fleet from my previous post. To speed reloads, I had a task group of Colliers "CO Peregrine-B 001" set to move to a nearby asteroid. After the 3 bomber wings had expended their ordnance, I had set the first one to empty to "Absorb CO Peregrine-B 001", for eventual reload, and the other two bomber wings were set to "Move to CO Peregrine-B 001". After some time passed, the first bomber wing reached and absorbed "CO Peregrine-B 001", which I assume deleted the task group. Without advancing the time increment, I reloaded each bomber from the F6 window from the TG Colliers. I then detached the first collier, "CO Peregrine-B 001", thus recreating the previous task group "CO Peregrine-B 001", and used the Task Group window to add the remaining colliers in the bomber wing task group to "CO Peregrine-B 001". The bomber wing was ordered to again pursue the enemy fleet, and "CO Peregrine-B 001" was ordered to "Join" the second bomber wing incoming for reloads. I did not change the "Move to CO Peregrine-B 001" orders of the other two bomber wings. When I advanced time (1 hour increment I believe), the Error in Execute Orders: Error 5 popped up and now will not go away. I had to kill Aurora.exe in Task Manager to exit.

I am able to recreate this infinite ExecuteOrders error reliably by absorbing a fleet other fleets have move orders to, and detaching a ship re-creating a fleet of the same name as the move orders on the same increment. I loaded up the Space 1899 game that comes in the DB, incremented time to ensure everything was smooth, and detached OWP Khan 001-004 from the Battle Task Group into their own task groups. I used SM mode to put OWP Khan 001 and OWP Khan 002 on Mercury, then gave OWP Khan 003 and OWP Khan 004 move orders to OWP Khan 001. I incremented time 5 seconds to ensure everything was still good, I then gave OWP Khan 002 orders to absorb OWP Khan 001. Incrementing time an hour, OWP Khan 002 absorbed OWP Khan 001, removing the OWP Khan 001 task group. On the same turn I then detached OWP Khan 001 from OWP Khan 002, re-creating the OWP Khan 001 task group. Incrementing time again an hour, I now get the "Error in ExecuteOrders: Error 5" forever until I use task manager to kill Aurora.exe.


EDIT: If I resume the game after force quitting Aurora due to this error and increment time, the ExecuteOrders Error 5 returns and I have to force quit again. If I resume the game, and remove the "Move to OWP Khan 001" orders from the OWP Khan 003 and OWP Khan 004 task groups, I can increment time normally, and then re-add the "Move to OWP Khan 001" order without issue.
« Last Edit: June 26, 2013, 03:23:49 PM by ChubbyPitbull »
 

Offline Charlie Beeler

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1381
  • Thanked: 3 times
Re: Official v6.20 Bugs Thread
« Reply #251 on: June 26, 2013, 04:00:17 PM »
@ChubbyPitbull   That's not a bug, it's a user error.  Even though you "recreated" the TG name it's not the same TG.  The tables store id's numericly and each new TG gets the next sequenial id. 
Amateurs study tactics, Professionals study logistics - paraphrase attributed to Gen Omar Bradley
 

Offline ChubbyPitbull

  • Gold Supporter
  • Sub-Lieutenant
  • *****
  • C
  • Posts: 138
  • Thanked: 27 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Official v6.20 Bugs Thread
« Reply #252 on: June 26, 2013, 05:00:37 PM »
@ChubbyPitbull   That's not a bug, it's a user error.  Even though you "recreated" the TG name it's not the same TG.  The tables store id's numericly and each new TG gets the next sequenial id.  

I believe that is what's happening as well. The reason this is a bug is because these actions cause the program to get stuck in an infinite error loop that requires a force-quit of the program to recover from, in addition to the user having to manually fix the error condition to continue playing the specific game.

My expectation would have been that in this situation the deleted task group would have caused a "Destination Not Found" message for the task groups with move orders, rather than the error loop. Similar to how task groups with orders to follow an enemy contact respond to said contact being destroyed or falling out of contact.
 

Offline shoobs

  • Petty Officer
  • **
  • s
  • Posts: 25
Re: Official v6.20 Bugs Thread
« Reply #253 on: June 27, 2013, 02:07:48 AM »
Getting a constant "No ranks found" error upon year 42 in a conventional start game.  I also had an overflow bug some time back, could this be related?
 

Offline Charlie Beeler

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1381
  • Thanked: 3 times
Re: Official v6.20 Bugs Thread
« Reply #254 on: June 27, 2013, 08:02:53 AM »
I believe that is what's happening as well. The reason this is a bug is because these actions cause the program to get stuck in an infinite error loop that requires a force-quit of the program to recover from, in addition to the user having to manually fix the error condition to continue playing the specific game.

My expectation would have been that in this situation the deleted task group would have caused a "Destination Not Found" message for the task groups with move orders, rather than the error loop. Similar to how task groups with orders to follow an enemy contact respond to said contact being destroyed or falling out of contact.

This gets reported from time to time and it's been around since inception.  Steve has not considered it to be a big enough issue to murphy proof the occurance. Thus when it is posted as a bug the response is that it is a user error.  No, that is not an ideal response. 
Amateurs study tactics, Professionals study logistics - paraphrase attributed to Gen Omar Bradley