Official v5.50 Bugs Thread

[Steve Walmsley (OP)]

This exchange reminds me of a similar issue I first ran into in 5. 52 or 5. 53, and just reproduced in 5. 54.  It took me a bit to realize exactly what was happening, but it's obscure enough I realize why I'd completely forgotten about it until just now. 

I'm not too great at mental math (and was unaware that there's a box in the Task Group screen that tells you total tonnage of that TG), and as my doctrine relies on mixed FAC-sized forces, I was making heavy use of the 'Land on Mothership' commands for groups of FACs.  As it turns out, if you use this with a task group whose tonnage exceeds that of the bays, the event log throws an error that reads "Unable to Land - [ship name] cannot dock as the assigned or specified mothership does not have sufficient hangar space. " for each ship that can't fit and then "Loading Problem - [Task Group Name] failed to land on [Carrier Name].  Any additional orders will be on hold until the problem is resolved". 

The problem here is [Task Group Name] has already been deleted, and the named ships blink out of existence - disappearing from the Individual Unit List and everything.  Not only do you lose the ship, but valuable crew grade and task force training.

Found it. The problem occurred because the fleet with the FACs was being flagged for deletion due to a successful landing of the first FAC but not being unflagged due to other FACs in the same TG being unable to land. Fixed for v5.55

Steve

[Marc420]

I think there's a bug in the "launch missile at" command for a tg.  The endurance clock of the buoys is incorrect in some instances.

I was just learning how to use this command.  So, for awhile I'd been flying to jp's and manually firing a sensor buoy.  Then as I started to learn how this command works (after firing a couple of salvos of short range combat missles into space , I've been starting to use this command to have my ships go to each jp and drop one of my sensor buoys there.

The bug occurs when a ship goes to a jp where this "launch missiles at" command had been used to place a buoy, and where the buoy is still active.  The situation was one where I saw my buoys were running down.  My one ship in the system had three left, so I told it to go ahead and drop buoys on three of the jp's then head back to Sol to reload.

Thus I had a ship with buoys loaded fly to a jp that still had a buoy with about 25 days left on it active.  The ship then executed a 'launch missiles at" command to the jp.  

The bug is that instead of a new buoy appearing with a new 6.7 month endurance clock starting to run, I instead got a label on the screen telling me that I now had 2x of the buoys there, but with only the 25 day endurance clock of the expiring buoy.  And, sure enough, some 25 days later, both of the buoys expired and now I have no buoys at the jp.

The buoys are of the same design.
The ship laying the buoy is of the same class I'm sure.  It does not appear to be the exact same ship.  But I wouldn't be totally sure of that.  I've got three of this class flying around.  This did happen on two consecutive jp's, and on the second jp that's still active for a few more days, it says it was ship #003 that laid the 2x buoys that are now there, while its ship #001 that I see now flying back towards Sol for a re-up on the buoys.

The jp's where I'd previously manually fired the buoys are working fine.  When a ship arrives there and deploys a new buoy with the 'launch missiles at' command, I get two separate buoys with two separate endurance clocks.  Thus, the expiring clock runs down and I'm left with the new buoy I laid just like I wanted.  It seems to be only the case where I use the 'launch missiles at' command at a jp where I already had a still active buoy from a previous 'launch missiles at' command where I get the mistake of having the new buoy just added to the soon expiring group of existing buoys.

[Steve Walmsley (OP)]

On a lighter note, it's worth noting that if the bays are already full, the game just doesn't care - you wind up with completely different space-warping properties.  While trying to replicate the issue, I managed to stuff two FAC wings and a full loadout of dropships (total tonnage being three times the mothership's hangar capacity). 

This turned out to be a fairly significant bug

The function that checks for the existing parasites on a mothership was checking the landing task group instead of the mothership task group for those parasites. Which means that this function always returned zero, regardless of the parasites on the carrier. However, as each FAC/fighter in a TG lands it is picked up in the capacity check for the next  FAC/fighter in the same TG (because although the correct fleet was being updated in the database, it hadn't been updated in the in-memory collection class being used to check capacity). So any task group landing on an empty carrier would be treated correctly but any task group landing on a carrier that had parasites already on board, would not be aware of those parasites, resulting in the bug you spotted.

During the investigation I also found that some fighter sizes were being rounded up, so in certain circumstances you couldn't fit the strikegroup on a carrier that you should be able to fit. 

All fixed for v5.55

Steve

[Steve Walmsley (OP)]

The bug occurs when a ship goes to a jp where this "launch missiles at" command had been used to place a buoy, and where the buoy is still active.  The situation was one where I saw my buoys were running down.  My one ship in the system had three left, so I told it to go ahead and drop buoys on three of the jp's then head back to Sol to reload.

When this happened, was it exactly the same ship that launched both the old buoy and the new buoy? If yes, then I think this is fixed. The code assumes that two missiles fired in the same location, by the same fire control on the same ship are part of the same salvo. In the case of launching a missile by use of an order, the fire control ID is zero. This function didn't compare the launch times of the two missiles though which would have led to the bug you described.

Steve

[Steve Walmsley (OP)]

A suggested interface behavior: when clicking "delete all" in task group orders, clear "cycle moves" too.   In general, it would be nice to catch or be robust against all sources of tight, infinite update-loops.  .  .   but I imagine that's no easy task! However, this little interface change would prevent "cycle moves" from being a scary option for me.   Mind you, I'm not sure if I ever had a corrupted database from this one.  .  .   every time I'm certain a freeze was due to this I've been able to reload the database fine and clear the darn flag!

I've done as you suggested. Delete All now clears the cycle moves checkbox. Also, if you remove the last order using the Remove button, the cycle moves checkbox is also cleared.

Finally, I have added a check to the code that moves an order to the end of the list during movement if the cycle moves flag is set. If a fleet with cycle moves set has only a single order, an event is generated as a warning to the player and the cycle moves flag is automatically switched off.

Steve

[Marc420]

When this happened, was it exactly the same ship that launched both the old buoy and the new buoy? If yes, then I think this is fixed. The code assumes that two missiles fired in the same location, by the same fire control on the same ship are part of the same salvo. In the case of launching a missile by use of an order, the fire control ID is zero. This function didn't compare the launch times of the two missiles though which would have led to the bug you described.

Steve

Correction to my original post.  It was the same ship that laid the original buoys and the next round of buoys six months later. 

Sorry for the incorrect info in the original post.  I've got two ships doing this right now, and one is in clear space where I can read it easily, and the other is in the midst of a bunch of labels and traffic near Earth.  So, I got confused and I thought it was the ship I could see easily at first, but when I checked the current orders of each ship in this class, I can now see that its the exact same ship that launched the original buoys and the second round of buoys.  #003 of the class laid the original salvo according to the buoy label, and its #003 that's almost made it back to Earth to reload more buoys before returning to that system to lay more.

[Steve Walmsley (OP)]

If you shut down fuel refineries, their sorium consumption still shows up in the predicted usage panel/ produces a red highlight.

Is that the case whether or not you have fuel production switched on?

Steve

[Steve Walmsley (OP)]

Correction to my original post.  It was the same ship that laid the original buoys and the next round of buoys six months later. 

Sorry for the incorrect info in the original post.  I've got two ships doing this right now, and one is in clear space where I can read it easily, and the other is in the midst of a bunch of labels and traffic near Earth.  So, I got confused and I thought it was the ship I could see easily at first, but when I checked the current orders of each ship in this class, I can now see that its the exact same ship that launched the original buoys and the second round of buoys.  #003 of the class laid the original salvo according to the buoy label, and its #003 that's almost made it back to Earth to reload more buoys before returning to that system to lay more.

Thanks for letting me know. This bug is fixed for the next update.

Steve

[Marc420]

BTW ... thank you very much for the quick reply to this.  Because of that, I can easily adjust by having my ships swap regions and lay over top the other ships buoys. So, there's an easy work around now that I know what's going on.  Thanks!

[Steve Walmsley (OP)]

New v5.55 patch is available with the recent bug fixes

Steve

[TheDeadlyShoe]

Is that the case whether or not you have fuel production switched on?

with 232 active fuel refiniries, fully staffed, plus some shipyard work i had 3427 sorium consumption under 'projected usage'. After advancing time 5 days i had +27 stockpile listed.

if i deactivate them in the civ/ind status tab and press refresh all . they disappear from employment, the industry tab still says 6.7 million /year production, and the mining tab still says 3427 consumption. advance time five days, recent sp says +74, consumption says 3426, industry tab still says 6.7 million. 

advance time thirty days, recent sp says +441, consumption says 3417, industry tab says 6.7 million, and total fuel stocks have gone up. 

[Vanigo]

Got a weird one. Recovering ruins, I got this error:
Error in Engines
Error 3201 was generated by DAO.Field
No current record

And I recovered 31 "Nuclear Thermal Engine E0"s. They don't show up on my class design screen, and, of course, an E0 engine is crazy talk. It's a TL2 ruin, if that makes a difference.

Edit: Oh, this was in 5.54

[Steve Walmsley (OP)]

with 232 active fuel refiniries, fully staffed, plus some shipyard work i had 3427 sorium consumption under 'projected usage'. After advancing time 5 days i had +27 stockpile listed.

if i deactivate them in the civ/ind status tab and press refresh all . they disappear from employment, the industry tab still says 6.7 million /year production, and the mining tab still says 3427 consumption. advance time five days, recent sp says +74, consumption says 3426, industry tab still says 6.7 million. 

advance time thirty days, recent sp says +441, consumption says 3417, industry tab says 6.7 million, and total fuel stocks have gone up. 

I don't think I phrased the question very well

There is a Stop button in the Fuel Production section at the bottom of the Industry tab of the F2 windows. What happens if you press that Stop button? Does it remove the projected fuel production from the Mining tab? If so, then this is working as intended.

Steve

[Theeht]

My current game has a few.
1) I have a shipyard (commercial, 11000 tons), plenty of resources, and plenty of labor, and it is ordered to retool.   It says it is retooling,  but date keeps changing by however much I increment the time, and the % completed remains at zero.   It is not paused.
Nevermind, it was paused, the name was too long to display it.

2) My planet also says that every 5 day increment, it has loses 5  Duranium under the SP +/- column.   Looking at the stockpiled number, it increases by 12 each 5 days.   The -5 changes depending on what I am building, but does not reflect the actual income.   I think it is not counting the input from mass drivers, because the Mass Driver +/- column is showing zero on all minerals on all colonies, including those firing mass drivers to earth, and I can see the packets on the System View.

[metalax]

I don't think I phrased the question very well

There is a Stop button in the Fuel Production section at the bottom of the Industry tab of the F2 windows. What happens if you press that Stop button? Does it remove the projected fuel production from the Mining tab? If so, then this is working as intended.

Steve

Just tested this by SMing an empty colony with a stockpile of 10000 sorium, 0 fuel reserve, 100 fuel refineries and enough pop to work them.

In the normal situation the mining tab shows an expected usage of 1000 and the annual production on the industry tab shows 2,000,000. Advancing time 5 days gives a production of 27,800 liters as expected.

If the stop button on the industry tab is pushed(and refresh all pushed), the expected usage drops to 0 however the annual production figure remains at 2,000,000. Advancing time 5 days gives 0 fuel production.

Hitting start again resumes production as expected. Hitting shut down of fuel refineries on the civilian/ind status tab leaves an expected usage of 1000 on the mining tab and annual production of 2,000,000 on the industry tab. Advancing time 5 days gives 0 fuel production and no sorium usage.

The main bugs seems to be the displayed sorium usage not getting removed when the fuel refineries are shut down from the civilian/ind stastus tab and projected fuel doesn't seem to get zeroed regardless of the means used to shut off fuel production.

This was tested on 5.54.