v2.5.0 Bugs Thread

[DawnMachine]

Officers in the Retired/Died section are not saved between restarts of the game, even with the Story character mark. Is this how it should work?

SJW: Yes, working as intended. They are deleted on restart unless you flag them to be saved.

[Ragnarsson]

Disassembling a Combat Information Centre assigns the expected research point gain to the Science Department tech, rather than Combat Information Centre. Screenshot of the event screen of this happening is attached. I also confirmed my Combat Information Centre tech had no progress, with 8000 research points remaining.

It may or may not be relevant, but I was researching the Science Department tech at the time, but it obviously had not yet completed until I disassembled the captured Combat Information Centre.

[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.

Hope I'm not being annoying, but I'm pretty sure it's not jump shock induced as this is happening on the 1st jump by the fleet in the entire game.  Here's the Db if you're interested.   In the attached DB, I have 2 fleets moving towards jump point and you will see the behavior after incrementing the time.

It seems to be happening when a Military jump ship with Commercial Engines tries to provide a standard transit for a fleet containing military ships.  The 1st attempt will fail to transit with that event message, but then successfully reattempt and make the jump.  If the fleet is stationary on the jump point when ordered to jump it will make the jump without complaint.  I do not have the same issue when having a military fleet jump using a military jump ship that has military engines.

Thanks for the quick responses!

You were right to persist. It is a bug.

The code was checking the list of military-engined ships in the fleet for a military jump drive and then checking for other eligible ships in the same location. On the first attempt, the code missed the fleet's commercial-engined ship with a military jump drive, because it was ignoring commercial engined-ships and it wasn't on the jump point yet. On the second attempt, it was picked up by the 'any other ships on the jump point' check.

The reason this has taken so long to come to light is that commercial-engined ships with military jump drives are unusual and when they do appear they are usually tenders stationed on a jump point, which would have been picked up anyway. This only happens when the fleet relies on a commercial-engined ship with a military drive that doesn't start the sub-pulse on the jump point. Fixed for v2.5.1.

[tastythighs]

I've had many (30+) NPR commercial and civilian ships enter an empty system adjacent to Sol through a hidden jump point in 1s and 2s without any escort, and proceed to enter Sol only to be destroyed. I checked out the database and they have empty colonies on both Earth and Luna with civilian orders to move LG infrastructure and refuelling stations there.
I don't have ground forces on Luna, but I do on Earth.

Is it intentional that NPRs will try to colonise your worlds even when you've shown repeatedly that you have military presence in the system and they have -8000 diplo rating with you?
Do NPR commercial ships and civvies not check danger rating? If they do, is danger rating being ignored because they're travelling through a hidden JP? Is there anything I can do short of editing the DB to remove these empty colonies?

[Garfunkel]

Definitely not intentional. I have never seen such behaviour, ie where they persist sending transports (survey ships are a different matter). Smells like something went wrong for the AI code.

[db48x]

This is something that has always bothered me. While I’ve seen it mentioned, I don't think that I have ever seen it mentioned as a bug. And yet it definitely is a bug. I think that there is an off–by–one bug when determining when the current construction cycle ends, and it is easily demonstrated.

I am running a very casual game at the moment. In this game I have sent some colonists to Mars, and they are getting restive. Obviously I need to make a ship with a weapon, or send some troops over there, to prevent them from having unrest. Since I haven't done that yet, there is a message at the end of every single construction cycle that tells me that the unrest is increasing. This is not the bug, it is merely the means to demonstrate the bug.

I have my construction cycle length set to one day, or 86400 seconds. Naturally, this means that I expect to see the unrest on Mars increase every single day without fail. What else could I expect, when the length of the construction cycle is a single whole day?

Yet here is the Events window that I actually see:



If you look carefully, you’ll see that the orange log message only happens every other day. This is annoying.The button to advance the game by a day correctly moves forward in time by 86400 seconds, but the game doesn’t think that the construction cycle has actually ended until at least one more second has passed:



Here you can see that I pressed the “1 Day” button, then the “5 Seconds” button, and the cycle only ended after the extra 5 seconds had passed.

One way to work around this, of course, is to set the cycle length to 86399 seconds instead:



This compensates for the bug, and results in the unrest message happening after every single day.

Does this matter? I guess not very much. As I understand it, what really happens is that construction cycles are variable length. No matter what button you push to advance time, only one construction cycle really happens. Whatever time it is at the end of that process, a single construction cycle of that length is performed, provided that more than the length of a construction cycle has passed. So with it set to 86400, advancing by a day doesn’t pass the test and no cycle is completed. The next time I advance by a day, the length will be greater than the cycle length, so a cycle consisting of 86400*2 seconds worth of construction, research, planetary movement, etc is processed. If I had pressed the “30 day” button instead, then it would have processed a cycle of 86400*30 seconds worth of stuff happening. This is a good implementation because it prevents this bug from being more serious; the right amount of stuff is still happening; it is merely less granular than I intended.

But it’s actually pretty irritating. Leaving aside the fact that I can’t type in “1 day” or “24 hours” or “2 weeks” and have it compute the right value, having it be off by one from whatever I do type in is just uncomfortable. And the fact that log messages alternate days (or weeks) must certainly be confusing to new players.

And it seems to me that the fix ought to be really easy, just a matter of changing one greater–than to a greater–than–or–equal–to test.

Please?

[joshuawood]

I have a ship that is having maintenance problems and killing commanders but doesn't actually exist in a fleet:

https://media.discordapp.net/attachments/402321466839793664/1195013489639567491/AuroraPatch_2024-01-11_14-36-55.png?ex=65b2720a&is=659ffd0a&hm=8475abe47534045b496f9a60e8b7ba2f12f2e2e068f7ae7308bda8221c6dd51c&=&format=webp&quality=lossless

https://media.discordapp.net/attachments/402321466839793664/1195013489316601886/image.png?ex=65b2720a&is=659ffd0a&hm=0d2d831dfafaace6b1b3dff648ae352fd47b4da0459e589db0067c0ab2e0c0ff&=&format=webp&quality=lossless

https://media.discordapp.net/attachments/402321466839793664/1195013489006231592/image.png?ex=65b2720a&is=659ffd0a&hm=7297c9ee5ad7e169572cda2e314068c0203ac70000e879a41c9ea5755bc6514c&=&format=webp&quality=lossless&width=1440&height=584

It gives this error when one of the commanders dies:

https://images-ext-2.discordapp.net/external/4geXrMywTWgnjIq_KVxPceHaCxB1zieIkWzH07FJGfg/https/i.imgur.com/z1L7oGh.png?format=webp&quality=lossless

It exists in the "ships in class" list but not in any fleet in the fleet organization window.


Reloading the game fixed it.

Find DB attached with events.

[nuclearslurpee]

This is something that has always bothered me. While I’ve seen it mentioned, I don't think that I have ever seen it mentioned as a bug. And yet it definitely is a bug. I think that there is an off–by–one bug when determining when the current construction cycle ends, and it is easily demonstrated.

...

And it seems to me that the fix ought to be really easy, just a matter of changing one greater–than to a greater–than–or–equal–to test.

I wonder if the issue is actually that this is yet another case of Weird Aurora Rounding™, which I suspect is probably due to something in the C# language and how it handles decimal-type values (which are different from the usual floating-point types). For the record, the game time entry at least in the DB (FCT_Game) is a double and not an integer, which suggests that it is a decimal type in-game.

You see similar phenomena where, for example, 0.5 will be rounded to 0, 1.5 will be rounded to 2, 2.5 will be rounded to 2, 3.5 will be rounded to 4, etc. - this is common in many of the ship component design windows and I think in the past also affected the MR calculation from agility in missile design.

If Steve wants to fix this, probably the solution is to represent game time by a 64-bit unsigned integer type instead of a decimal, which should allow representing game times up to 2^64 - 1 seconds which allows up to 59 billion years of game time - well over the 9999 years limit imposed by the C# DateTime that Steve uses for, you know, dates and times. However, (1) I don't know if this would work with the C# DateTime functionality - it may require decimal time input, and (2) I don't know (but presume) if C# allows specifying such a type in a 32-bit executable. And of course I don't know if the scope of this change would be more complicated than it sounds otherwise - but it should fix the problem since integer types are not subject to weird rounding.

I have a ship that is having maintenance problems and killing commanders but doesn't actually exist in a fleet:

...
Reloading the game fixed it.

Find DB attached with events.

This is probably the same bug that Steve fixed for 2.5.1 related to ships in a fleet disappearing under specific circumstances - it sounds similar, notably the part where reloading the game fixed it. Since reloading fixes it, there is probably not anything in the DB that will help but hopefully it is already corrected anyways.

[Louella]

STO units assigned to shoot at shipyards generate error after target is destroyed.

Error window says "Function #311. Object reference not set to instance of object". One instance of this window, regardless of number of STOs firing.

The error stops happening when the STOs orders are changed.

Looking at the DB, the target shipyard has negative number of slipways after the STOs shot at it, but the shipyard was not deleted.

two databases.
One from before the Martians complete a shipyard they are building. Martians complete a shipyard 5 days after the save in "STO_error_before.zip". The STOs are set to fire on shipyards.
Other is from after they shot at the shipyard, and it continues to throw errors until the orders of the STOs are changed. DB shows negative number of slipways for the targeted shipyard.

[db48x]

I’m about to design my first jump drive, but I am missing a tech. The tech design window mistakenly puts “Sensor Size: 1.0” where in previous versions there was an empty dropdown. Presumably it’s just from the most recent active search sensor I designed. The tech name wasn’t reset either.

[captainwolfer]

Bug Report
The function number: #2186
The complete error text: 2.5.0 Function #2186: Attempted to divide by zero
The window affected: Colony Summary
What you were doing at the time: I open up the colony summary. I then click on Altair I and the error shows up. Nothing seems wrong after closing the error, and I can tab through the various tabs on Altair 1. Clicking on another colony then clicking back on Altair 1 causes the error to show up again.
Other Information: Altair 1 has no population, but has a surveyed ancient construct and a ruined settlement, which I have ground units restoring installations from. 5 installations are left to restore. Restarting the game has no effect, the error still appears. Save attached
Conventional or TN start: TN
Random or Real Stars: Real Stars
Time since start: 11 years in game

Edit: I think I just figured out what happened: I had ordered a ground force division to be constructed via the Ground Forces Organization Tab. However, what I didn't realize at the time is that it defaulted to Altair 1 instead of Earth. And since Altair had no population, it didn't show the ground forces in the construction queue. I just brought colonist to Altair, which allowed the ground force construction facility to start operating. And now that there is people on Altair, the error is no longer showing up.

[kyonkundenwa]

When a beam fire control is damaged it is removed from the ship's fire control list in the ship combat tab but assigned weapons remain assigned, making them inaccessible for reassignment to a different fire control. The only way I can see to get them back (besides repairing the BFC) is to unassign those weapons on a different ship of the same class and use one of the various system/all/fleet/etc assignment options to effect the change on the ship with the damaged fire control. They can then be reassigned to other fire controls and continue fighting.
More desirable behavior would be to automatically unassign weapons from a damaged fire control. Alternatively, leave the fire control visible in the ship combat tab so they can be unassigned manually.

[Garfunkel]

When a beam fire control is damaged it is removed from the ship's fire control list in the ship combat tab but assigned weapons remain assigned, making them inaccessible for reassignment to a different fire control. The only way I can see to get them back (besides repairing the BFC) is to unassign those weapons on a different ship of the same class and use one of the various system/all/fleet/etc assignment options to effect the change on the ship with the damaged fire control. They can then be reassigned to other fire controls and continue fighting.
More desirable behavior would be to automatically unassign weapons from a damaged fire control. Alternatively, leave the fire control visible in the ship combat tab so they can be unassigned manually.

Are you absolutely sure that you're playing on 2.5.0? I'm asking because this bug has been reported and fixed in the past already.

[tastythighs]

When switching which system is viewed on the main screen, I'm encountering an occasional bug where the game switches to a different system (not the one I selected) and then locks on that system, refusing to switch off of it by any means.

Restarting the game clears the lock and I can change which system is viewed again.

Ok, I've learned a bit more about this.
Sometimes when I have the naval organisation window open and a fleet selected, and I try to switch to a system which does not contain that fleet, it will switch instead to the system in which that fleet is located. If I close the naval organisation window, the main view remains stuck on that system. If I select a different fleet and try to change system, it will switch to the system the newly selected fleet is in.

Will try to work out why it's only sometimes.

[db48x]

I switched to a different system and got a message box with the name of one of my ships in it:



The named ship is actually surveying that system (Barnard’s Star) at the moment. It happens whenever I switch to Barnard’s Star, which is going to be annoying.

Here's a screenshot of the Barnard’s Star system, in case that’s useful:



I seem to recall something like this happening in an earlier version, though I can’t find it now.