v2.5.0 Bugs Thread

[Steve Walmsley (OP)]

There is definitely something odd going on, but its not quite as simple as above. I'm in the fourteenth year of a large campaign with several carriers and one fleet just lost its squadrons somehow. However, this is the first time I have seen it and I can't recreate it by detaching and deleting fleets. There must be some rare sequence of steps that results in this problem.

Has anyone else been able to reliably recreate this problem?

I have not personally encountered this issue, but I recall that the earliest reports of this issue were related to fleets under tow by tractor beams, and I know there were some changes to tractor beams recently, so that might be the first place to look?

My own fleet that was affected wasn't tractored. It was three different carriers in the same fleet, so it seems to be a problem at the fleet level, not ship. What was unusual is that I detached them from a fleet, then detached everything else from the same original fleet and then deleted that original fleet. However, I don't know for certain if that was the cause because that was a couple of months previously in game time and I don't have  backup at that point to check it. Also, doing the same thing with other fleets doesn't result in the same problem. There is probably some other step involved, which I need to figure out. It most be a fairly rare step because of the rarity of the bug.

[lumporr]

I have reproduced the squadron bug after doing the following:

1. Drag ships into the squadron of another ship (Ship A).
2. Tractor Ship A.

After doing this and advancing time, Ship A and its squadron appear in the tug's fleet, but there will also be an empty fleet that used to contain Ship A. If you click on this empty fleet and go to "transported items", you can see that Ship A's original empty fleet still contains the squadron's parasites, despite showing No Ships Present in the Fleet screen. Deleting this empty fleet will result in the deletion of the squadron's parasites.

SJW: Fixed now. See post below. Its the transfer between fleets and subsequent deletion that is the problem. It's not related to tractors per se.

[Steve Walmsley (OP)]

There is definitely something odd going on, but its not quite as simple as above. I'm in the fourteenth year of a large campaign with several carriers and one fleet just lost its squadrons somehow. However, this is the first time I have seen it and I can't recreate it by detaching and deleting fleets. There must be some rare sequence of steps that results in this problem.

Has anyone else been able to reliably recreate this problem?

I have not personally encountered this issue, but I recall that the earliest reports of this issue were related to fleets under tow by tractor beams, and I know there were some changes to tractor beams recently, so that might be the first place to look?

My own fleet that was affected wasn't tractored. It was three different carriers in the same fleet, so it seems to be a problem at the fleet level, not ship. What was unusual is that I detached them from a fleet, then detached everything else from the same original fleet and then deleted that original fleet. However, I don't know for certain if that was the cause because that was a couple of months previously in game time and I don't have  backup at that point to check it. Also, doing the same thing with other fleets doesn't result in the same problem. There is probably some other step involved, which I need to figure out. It most be a fairly rare step because of the rarity of the bug.

Found and Fixed!

v2.2 had various performance improvements. One of these involves how the composition of fleets was tracked. Originally, each ship had a reference to its parent fleet object. To return the ships in a fleet, the program returned all the ships with the reference of that fleet. The advantage of this is that the information is only stored in one location, which means less scope for bugs. This type of bug avoidance was a key principle of programming for C# Aurora. However, the downside is the overhead of running a LINQ query every time I need know the ships in a fleet. As games get larger, this becomes more pronounced.

For v2.2, I also started keeping a list of ships in a collection within the Fleet object for easy reference, so when I needed the list I no longer needed the LINQ query. I accepted the higher risk of bugs because there is a very limited number of places in the code where ships are created or change fleets. For example, there is a single function that is called for each ship that changes fleet - to handle the change itself, plus any other issues such as parasites, tractor links, shipyard tasks, updated fleet speeds, etc.

Unfortunately, while the fleet link for parasites was correctly moved from one fleet to another, they remained in the above 'ship list' collection for the original fleet. This wasn't visible in the Fleet window because the fleet treeview displays parasites by squadron and the squadron is linked to the mothership, which is in the correct fleet (and the parasite's own 'fleet object' was also correct). Furthermore, this problem was fixed as soon as you closed and re-opened the game, because the 'ship list' is purely an in-memory construct and the save and load function for ships uses the original fleet object, which places them all in the correct 'fleet ship list' when the game loads.

So the bug will happen if you detach a ship with parasites and then delete the original fleet, without loading the game in-between. Fixed for v2.5.1, which I will look at releasing next week due to the severity of this bug, even if it is rare.

[lumporr]

Happy days! Bugs squished!

[simast]

If you check the "Supply Ship" checkbox on a military ship class and put it in a training command - the maintenance clock will not increase (but the ship will get fleet training).

[sisso]

I am on 6 year of standard start.  One civilian ship is stopping every tick with "Orders not possible: . . .  standing order (Move to Gas Giant with Sorium and 10m Pop)".

Looking into Planet Gas Giant (Uranus, Jupiter, Saturms), none of them have Sorium.  I didn't survey Neptune yet.  Anyway, I will certainly not have 10m pop there.

SJW: Problem as described in posts below. Fixed for v2.5.1

[nuclearslurpee]

I am on 6 year of standard start.  One civilian ship is stopping every tick with "Orders not possible: . . .  standing order (Move to Gas Giant with Sorium and 10m Pop)".

Looking into Planet Gas Giant (Uranus, Jupiter, Saturms), none of them have Sorium.  I didn't survey Neptune yet.  Anyway, I will certainly not have 10m pop there.

I think the 10m pop refers to a system, not a gas giant as the latter cannot have populations.

I suspect Neptune has sorium and the civilians built a fuel harvester in anticipation of that even though they shouldn't know that yet. There was a similar bug a while ago with standing orders.

[sisso]

I am on 6 year of standard start.   One civilian ship is stopping every tick with "Orders not possible: .  .  .   standing order (Move to Gas Giant with Sorium and 10m Pop)". 

Looking into Planet Gas Giant (Uranus, Jupiter, Saturms), none of them have Sorium.   I didn't survey Neptune yet.   Anyway, I will certainly not have 10m pop there.

I think the 10m pop refers to a system, not a gas giant as the latter cannot have populations.

I suspect Neptune has sorium and the civilians built a fuel harvester in anticipation of that even though they shouldn't know that yet.  There was a similar bug a while ago with standing orders.

Correct.  Doing survey on neptune fix the issue.  thx

[Therewolfmb]

Hi, this game is amazing and I wanted to help it's development by reporting some things I think are bugs:

When a single jump drive ship to standard transit a fleet larger than the squadron size, the game will 1st create an error event saying the fleet cannot transit.   But if left alone for 30minutes the fleet will then transit successfully.   I think it should not generate the error message.  (Also in 2. 4 it sometimes does not throw that error, but I know that's a previous version and I haven't been able to recreate that behavior in 2. 5)

I am in v2.  50, and here's a screen shot.

SJW: This is probably just inability to transit due to jump shock, which wears off after a few minutes

A second bug:

Any fleet can be assigned "perform x survey" standing order.   After the fleet completes it's current command, the survey order will be issued and the fleet will attempt.   If it doesn't have the correct sensors, the fleet will just sit there idly without any error messages being generated.   I would think this should throw an error when the standing order attempts to assign the incompatible action. 

Sorry if these are both WAI, but they seem like bugs or at least QoL issues to me. 

SJW: This is working as intended. The fleet is trying to survey but doesn't have any capability to do so. I agree this could be flagged, but checking every fleet for its capability to handle any standing or condition order issued is a lot of code and therefore unlikely to make it to the top of my 'to do' list.

Again, thanks for sharing this amazing game with everyone!

[ExecCrawfish]

Bodies in SM-deleted systems still produce results in the mineral search window. 

[Therewolfmb]

Hi Steve,

Regarding the inability to just due jump shock, is it supposed to happen before the jump happens? I've seen the jump shock prevent jumps after standard transit when trying to immediately go back to the previous system, but this message is happening before the jump.

[Steve Walmsley (OP)]

Hi Steve,

Regarding the inability to just due jump shock, is it supposed to happen before the jump happens? I've seen the jump shock prevent jumps after standard transit when trying to immediately go back to the previous system, but this message is happening before the jump.

It can happen if the fleet just transited a previous jump point. If fleets were having trouble with normal jumps, there would be a lot of bug posts on that subject. I've checked the code and the only two situations where that message is generated is either the jump drive is too small, or it is suffering from jump shock, so if the problem resolves itself within a few minutes of game time, it is almost certain to be the latter.

[db48x]

Hi Steve,

Regarding the inability to just due jump shock, is it supposed to happen before the jump happens? I've seen the jump shock prevent jumps after standard transit when trying to immediately go back to the previous system, but this message is happening before the jump.

It can happen if the fleet just transited a previous jump point. If fleets were having trouble with normal jumps, there would be a lot of bug posts on that subject. I've checked the code and the only two situations where that message is generated is either the jump drive is too small, or it is suffering from jump shock, so if the problem resolves itself within a few minutes of game time, it is almost certain to be the latter.

I’ve asked before, but does that really need to be an interrupt? If it does, can you change the message to indicate definitively which of the two (three? four?) cases it actually is? (I see four cases: ship class(es) have no jump drive, ship has destroyed jump drive, ship has a jump drive but it is too small, and ship has a jump drive that would work but it is recharging; try again later.)

Also, it would be really nice if the ship would just automatically retry the order. Instead of removing the order to jump from the fleet’s order list, perhaps you could insert a delay of the appropriate length to the order. Then it wouldn’t spam the player.

[Steve Walmsley (OP)]

Hi Steve,

Regarding the inability to just due jump shock, is it supposed to happen before the jump happens? I've seen the jump shock prevent jumps after standard transit when trying to immediately go back to the previous system, but this message is happening before the jump.

It can happen if the fleet just transited a previous jump point. If fleets were having trouble with normal jumps, there would be a lot of bug posts on that subject. I've checked the code and the only two situations where that message is generated is either the jump drive is too small, or it is suffering from jump shock, so if the problem resolves itself within a few minutes of game time, it is almost certain to be the latter.

I’ve asked before, but does that really need to be an interrupt? If it does, can you change the message to indicate definitively which of the two (three? four?) cases it actually is? (I see four cases: ship class(es) have no jump drive, ship has destroyed jump drive, ship has a jump drive but it is too small, and ship has a jump drive that would work but it is recharging; try again later.)

Also, it would be really nice if the ship would just automatically retry the order. Instead of removing the order to jump from the fleet’s order list, perhaps you could insert a delay of the appropriate length to the order. Then it wouldn’t spam the player.

Which version are you on? The following was introduced in v2.2:

"Added a new 'Transit Delay' event. This doesn't cause an interrupt and will be used in place of the current 'Transit Failure' event when the reason for failure is jump shock."

The message is "Fleet Name cannot conduct a transit as there are one or more ships suffering from jump shock". The ship just maintains orders and transits on the next increment.

[db48x]

Which version are you on? The following was introduced in v2.2:

"Added a new 'Transit Delay' event. This doesn't cause an interrupt and will be used in place of the current 'Transit Failure' event when the reason for failure is jump shock."

The message is "Fleet Name cannot conduct a transit as there are one or more ships suffering from jump shock". The ship just maintains orders and transits on the next increment.

Ooh, nice. I must have missed that in the changelog. Sadly, I haven’t been able to play lately either. I upgraded vmware and it broke all of my windows virtual machines.

Another suggestion: compile the game for Linux! How hard could it possibly be?