Official v6.30 Bugs thread

[Xeluc]

This has probably been mentioned, but on Earth, there is a projected use of Sorium for the fuel refineries even though I have deactivated the industry. I'm not building anything that would need Sorium. Also the projected use correlates with what my refineries would produce.
EDIT: As far as I know this doesn't actually detract the Sorium from Earth.

[joeclark77]

Through espionage against an NPR, I discovered a new system that had connections to three systems I had already charted.  Two bugs emerged after this:

1. The new system is not accessible from the pull-down menu on the system map. This bug is easy to solve: quit Aurora and open it again, and the new system will be in the menu. (Edit: also just closing the system map and hitting F3 again fixes it.)

2. When opening the galaxy map, I get a series of errors:
2.a. At first no map is drawn and an error pops up saying "ERROR: WP Link not found in GetWarpPointData"
2.b. After I click OK, the "network" of orange and green connecting lines appears but the stars are not yet drawn. A second error pops up with the heading Error in DisplayWP: "Error 5 was generated by Aurora; Invalid procedure call or argument; Please report to...".
2.c. I click OK and the second error repeats itself once.
2.d. I click OK again and the map is drawn normally.
2.e. If I click or shift-click-drag on a star, or if I scroll the map using the arrow buttons, on mouse-up the stars disappear (leaving the links) and we go back to 2.b.  I click "OK" twice and the map is back to normal.

[joeclark77]

More on above bug:
The galaxy map does NOT display correctly after the errors, as far as I can tell.
The star map says the new system (call it "Q") has links to X, Y, and Z.
In systems X and Y, there are JPs now labeled as connecting to Q.  These were previously unexplored JPs.
In system Q, the other side of these JPs are visible.

However, there's a JP in system Q that goes to another system I'm familiar with (call it "P"), but it's not Z.
In Z, there's no JP leading to Q.
In P, there's no JP leading to Q.

There is one unexplored JP in each of Q and Z.  Ships are en route to check them out now.  I'll update again in a few minutes.
Edit 1: the unexplored JP in Z doesn't lead to Q, but to a new system.
Edit 2: transiting the JP from Q to P appears to work (my ship is in P), but does not reveal a JP in P.  I will re-survey to see if it is actually there.
Edit 3: the unexplored JP in Q doesn't lead to Z, but to a new system. oddly the system has a name already (same theme as Q, presumably named by the NPR)

In summary:
Star Q was discovered by espionage.
Galaxy map shows links from Q to X and Y, both of which are seen also on star maps, and work fine.
Galaxy map also shows a link between Q and Z, which is not visible on the star map in either system.
Star map in Q shows a JP to P.  This JP works, at least one-way, but is not shown on the galaxy map.
When opening or modifying the galaxy map, a bunch of annoying errors occur.

RESOLUTION:
Upon re-survey of star P, the other side of the jump connection to Q was discovered.  Now there's no more bug in the galaxy map.  The true link from Q to P is now shown, the false link from Q to Z is no longer shown, and the annoying error messages no longer pop up.

[Cripes Amighty]

I was playing a conventional start game and went to go a design my first laser with very minimal tech. 10cm, infrared wavelength, capacitor 2, and no research into spinal mounts. With only these settings, the output read:

Damage Output 10     Rate of Fire: 10 seconds     Range Modifier: 1
Max Range 100,000 km     Laser Size: 3 HS    Laser HTK: 1
Power Requirement: 3    Power Recharge per 5 Secs: 2
Cost: 3    Crew: 9
Materials Required: 0.6x Duranium  0.6x Boronide  1.8x Corundium

Development Cost for Project: 30RP

I thought that looked a little too powerful and checking back on the other versions, it was only giving out a damage output of 3. I haven't tested to see if it is actually causing 10 damage, in case it was just displaying higher numbers than it actually is.

[MarcAFK]

That range doesn't look right either.

EDIT: This one might be a bug, I can't find anywhere listed the amount of starting research points remaining, as far as I can remember, I have never been able to find where this is displayed, shouldn't it be on the research screen?
Yeah sorry, ignore that, I made a mistake.

Edit, wait a minute, I see what is happening now, if I start a conventional game, starting research points aren't displayed at all, whereas they show up fine for a transnewtonian game.
This would actually be a bug. :p

[Steve Walmsley (OP)]

That range doesn't look right either.

EDIT: This one might be a bug, I can't find anywhere listed the amount of starting research points remaining, as far as I can remember, I have never been able to find where this is displayed, shouldn't it be on the research screen?
Yeah sorry, ignore that, I made a mistake.

Edit, wait a minute, I see what is happening now, if I start a conventional game, starting research points aren't displayed at all, whereas they show up fine for a transnewtonian game.
This would actually be a bug. :p

There are no starting research points in a conventional game.

Steve

[MarcAFK]

Shields aren't working.
I've been running skirmishes between individual ships equipped with different weapons, and haven't seen a single damage absorbed by shields, from any type of weapon.
Version is 6.30, technology is Beta shields, regeneration 1.5, fuel consumption .8.
I'm certain I'm using the shields correctly as I have used them in the past. I used spacemaster to add them to the test ships, turned them on with the "raise shields" button, waitied untill they were fully charged, recieved messages on the events log to that effect, and the shields are showing on the system map to both test empires. Yet every weapon is failing to score a single hit to shielding, even high powered microwaves miss.

[joeclark77]

I used spacemaster to add them to the test ships

I suspect this is your problem.  I have used shields in my current game and they worked.  Have you gone into the ship detail window and looked at each of the ships in detail?  Typically when you re-design an existing ship via spacemaster mode, the changes don't actually "load" until you go and make the game pull up the ship's data directly.

Try building some ships with shields in their initial, locked design, and see if they work then.

[MarcAFK]

I thought it might be this, but I had used shields in this way in other games. I'll do more checking.
Well you're right,Using FAST OB for the test ships fixed the problem.
I think I remember somewhere being told that with various systems you may need to lock the design after modifying them in SM mode to make them work correctly.

[ZimRathbone]

I thought it might be this, but I had used shields in this way in other games. I'll do more checking.
Well you're right,Using FAST OB for the test ships fixed the problem.
I think I remember somewhere being told that with various systems you may need to lock the design after modifying them in SM mode to make them work correctly.

If you build a ships of a particular class, and then change the class design using SM abilities, then any new units built (either by regular method or Fast OB) will have the properties of the updated class, but any pre-existing units will have the properties of the old class.  This is because the ship records in the database (which holds all sort of data like current max speed, number of shields, crew requirements etc) are not updated when you change the associated class record. 

You can get the pre-exiting units to update to the new class design by viewing each one in the F6 (Individual Unit Details) window, which does refresh the ship record.  This can result in some rather strange effects if the unit in question has been damaged, as the damaged component record will remain even though there is now no associated ship component.

The class does not need to be locked for this to happen (although its good practice to do this after making changes) .

[alex_brunius]

Ground PDCs does not seem to update their ability for beam weapons to penetrate an atmosphere after the atmosphere pressure has changed.

Tested with a Ship and PDC firing at each-other, after a 5 day update from SM editing the atmosphere away the ship could fire but not the PDC that still got "cannot penetrate atmosphere with a pressure of 1.00" message.

Edit: I can also note that partial atmospheres does not seem to reduce beam damage as intended for weapons fired from range, only from weapons fired with 0km distance to target.

[alex_brunius]

The Intel Update: "... is streaming atmosphere" is erroneously given when a ship takes shock damage (it has not had it's Armour pierced).

This also seem to cause a wrong Intel estimation of Armour Strength.

[Steve Walmsley (OP)]

The Intel Update: "... is streaming atmosphere" is erroneously given when a ship takes shock damage (it has not had it's Armour pierced).

This also seem to cause a wrong Intel estimation of Armour Strength.

Fixed for v6.40

Steve

[Steve Walmsley (OP)]

This has probably been mentioned, but on Earth, there is a projected use of Sorium for the fuel refineries even though I have deactivated the industry. I'm not building anything that would need Sorium. Also the projected use correlates with what my refineries would produce.
EDIT: As far as I know this doesn't actually detract the Sorium from Earth.

Fixed for v6.40

Steve

[alex_brunius]

Boarding combat on a PDC continues after the battle is over throwing up error messages (Error 11, division by zero).

Possible causes:
The attacked PDC had room for 5 battalions but was only garrisoned with 2.
Right after combat ended I advanced time enough to trigger a 5 day update.
All of the crew being killed off before the garrisoned battalions.

Boarding combat on the above PDC tick each 5 seconds (or whatever time advance chosen) instead of the intended every 300 seconds.

Boarding combat against a ship seem to adhere to the 300 second clock, even if the combat right after breaching hull was allowed to tick twice before clock delay. After this it worked fine.