v1.13.0 Bugs Thread

[Steve Walmsley (OP)]

Are normal NPRs supposed to know the secrets of "Swarm Extraction Module"? I got this upon capturing an NPR's homeworld. This is the NPR that originally spawned at game start.

I mean, it's kinda neat from an RP perspective. Maybe their backstory is they were performing experiments on the Swarm.... or maybe they are, in fact, the progenitors of the Swarm as a genetic project gone wrong?

No idea where the NPR managed to get it, but it shouldn't have access. Good idea on the lore though

[Geeptoon]

Might be a bug.  Seem to have the increment length always at a lower level than what I have selected.   Started after an npr must have been haveing a battle with another npr.  If I have 30 days selected it runs 6 hour increments.  If I have 5 days selected it runs 2hour increments.  8hour increments were 2mins I think.   Anyways this went on until I started goofing around with the sub pulses by keeping the increment at 1 day and changing the sub pulse one step lower.  now everything is back to normal.   Before that I had tried turning detection off with no results and saveing  and reloading with no change.  The npr has even had a few battles with out the abnormal behavior.

[Andrew]

I dragged a beam fire control on top of another but I can't reproduce the bug you specified. #2147 is the display of population contacts on the tactical map and #463 is another tactical map contact display function. The only key referenced in both functions is RaceID so not sure why those functions would be affected by a problem with fire control assignment. #357 is the combat information on the fleet window though. It is possible those first two are incorrect error numbers?

While experimenting, I did cause a problem by dragging a fire control on to the point defence node, so I fixed that

I think I misdiagnosed the problem. I have created it in several games, the problem seems actually to be giving Ground combat units to an NPR and then deleting the Player race who provided them, probably doing something that weird is quite rare. One of the symptoms is not seeing the fire controls and the game crashed on that screen before the error first occurred. A db with the error occurring is attached, not the first time the error occurred but a later game. I accidentally deleted the original error

[Ancalagon]

I think this is a bug, but not sure. It was my understanding that Orbital Habitat population is considered 100% Manufacturing population. However, in this example below (where I'm trying to kickstart some terraformers), they are not contributing 100% to manufacturing.

[Steve Walmsley (OP)]

- New bug on v1.13.0, but very minor. Cosmetic, really. On the Ground Forces window, the "Base Unit Type" above "Infantry" is a selectable field. Easy enough to reproduce, just... go to the Ground Forces window and click on the "Base Unit Type" field and viola! Bug du jour.

You can click on it but it doesn't do anything. You can do the same thing on many different lists.

[Steve Walmsley (OP)]

Logistics Bonus not working as expected.

I have a freighter class with a load time (per the design screen) of 5:18:53.
The class has a bridge.
I have only standard cargo shuttles--I have not researched TN shuttles.

I have a fleet consisting of one of these freighters, with no commander.
The fleet is under the root admin command. The admin commander has no logistics bonus.
I give the fleet orders to load at a population with no planet governor, no sector governor, no spaceport, and no cargo shuttle station.

In this situation, which has no bonuses applying to loading time, I expect the load order to take 5:18:53.
And it does. Good.

Now I assign a ship commander with a 5% logistics bonus.
It is reasonable to expect that the load would now take 95% as long as the base load time.
Instead, the load takes 92.91% as long (5:09:02).

Swapping this commander out for others with various bonuses, here are the results:

commander bonus                      5%                10%         15%        20%         30%        50%
result (pct of base time)             92.91%          86.57%   80.88%   75.76%   66.89%   46.67%
effective bonus                           7.09%           13.43%   19.12%   24.24%   33.11%   53.33%
load time as pct of expected       97.8%           96.2%     95.2%     94.7%      95.6%      93.3%


Something odd is going on here, but I can't quite identify it.
Neither the error magnitude nor percentage are constant.
The error percentage seems to be marginally decreasing until 20% commander bonus, then increasing, then decreasing again.

I suspect that for very high aggregate bonus levels (from stacking admin commands, governors, and spaceports), the error is negative--that is, that load times in those circumstances are longer than expected.

The problem was two-fold. Firstly, only half the commander logistics bonus was being applied because I mistakenly called the function that returned a ship bonus (used for situations where a second officer provides the primary bonus), rather than the commander bonus. Secondly, the full commander logistic bonus was being used a modifier to the number of cargo shuttle bays on the ship. Both are fixed for v1.14. I also checked the whole program to ensure I wasn't using the ship bonus incorrectly anywhere else (I wasn't).

The full calculation is:

Cargo Handling Modifier = Number of Cargo Shuttle Bays * Admin Command Bonus * Commander Logistics Bonus * Race Cargo Shuttle Load Modifier
(If there are one or more spaceports or cargo handing stations on the planet, that adds a single extra cargo shuttle bay)

The normal loading time is then divided by the Cargo Handling Modifier.

[Steve Walmsley (OP)]

So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".

I wonder if that's the behavior Steve intended, or if it perhaps is a bug.

It was intended as self-jump only. However, I think the unintended behaviour is actually a better option.

I've changed the 'Self-Jump' text to 'No Squadron Jump' and I have changed the 'Minimum Jump Engine Size' tech line to 'Minimum Squadron Jump Engine Size'.

[Droll]

So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".

I wonder if that's the behavior Steve intended, or if it perhaps is a bug.

It was intended as self-jump only. However, I think the unintended behaviour is actually a better option.

I've changed the 'Self-Jump' text to 'No Squadron Jump' and I have changed the 'Minimum Jump Engine Size' tech line to 'Minimum Squadron Jump Engine Size'.

Often times the best way to fix a bug is to just call it a feature

[skoormit]

So if I have a ship with a self-jump drive that is stood at a JP. Would other ships be able to use that jump drive to standard transit through? Would they have to go 1-1 or does that jump drive have infinite throughput?

Yes, other ships can use that jump drive (subject to normal size and type restrictions) for standard transits. Infinite throughput.

Just replace the term "self-jump only" in your mind with "standard transit only".

I wonder if that's the behavior Steve intended, or if it perhaps is a bug.

It was intended as self-jump only. However, I think the unintended behaviour is actually a better option.

I've changed the 'Self-Jump' text to 'No Squadron Jump' and I have changed the 'Minimum Jump Engine Size' tech line to 'Minimum Squadron Jump Engine Size'.

Hooray!

I love making my early fighter-sized jump tenders to service my fighter surveyors. Glad I get to keep doing that.

[Ancalagon]

I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

[skoormit]

Total Atmospheric Pressure Incorrect with Frozen Gases

Planet has the following gases:

Nitrogen 0.3581
Oxygen 0.0952
Sulphur Dioxide (F) 0.0133

The total Atmospheric Pressure shown is 0.440.

One way to arrive at that total is to add just the Nitrogen and the Oxygen, and then subtract the Sulphur Dioxide.

The incorrect ATM total leads to an incorrect GH factor and an incorrect temperature.

[Steve Walmsley (OP)]

I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

I am sure you won't be shocked to learn that error #2184 is in Display Mining. I think you are on the right lines with the manufacturing but hard to pin down. It might be caused by extremely small but non-zero production resulting in a depletion time that is longer than a decimal can hold. Could you post a screenshot of the mining window on a turn when you don't have the error?

[Steve Walmsley (OP)]

Total Atmospheric Pressure Incorrect with Frozen Gases

Planet has the following gases:

Nitrogen 0.3581
Oxygen 0.0952
Sulphur Dioxide (F) 0.0133

The total Atmospheric Pressure shown is 0.440.

One way to arrive at that total is to add just the Nitrogen and the Oxygen, and then subtract the Sulphur Dioxide.

The incorrect ATM total leads to an incorrect GH factor and an incorrect temperature.

The atmospheric pressure calculation is incorrect (well spotted). The GH factor and temperature calculation are both working fine as they independently check non-frozen gases only and don't reference the atmospheric pressure calculation.

[Ancalagon]

I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

I am sure you won't be shocked to learn that error #2184 is in Display Mining. I think you are on the right lines with the manufacturing but hard to pin down. It might be caused by extremely small but non-zero production resulting in a depletion time that is longer than a decimal can hold. Could you post a screenshot of the mining window on a turn when you don't have the error?

I peeked inside the "Population" database table, and all the minerals on that body have a quantity of 8.2e-26 (super small). It's the only population in my 100-year game database that has a mineral quantity readout like that. Also, I have a strong suspicion this same bug might have been interacting with mass driver shipments off this planet (before I stopped them) and causing another function error from mass drivers because of it.

Here's the screenshot you asked for. I had to load an older save backup. When I loaded the game, the error happened right away, then I progressed forward 5 days, and then the error didn't happen. Here's the screenshot of the mining window from when the error did not occur:

Thanks for all your hard work tracking down our bugs!

[Steve Walmsley (OP)]

I get function error #2184 when I click on the colony "Destiny-B III". As you can see, it also has the peculiar situation of having a completely blank mining screen (it actually contains every mineral at 0.1 accessibility, so shouldn't be blank).

I think the cause of this has something to do with the extreme lack of manufacturing capacity on this planet due to its colonization cost. See screenshot 2. This bug is only repeatable/reproducible in my game on certain turns. When I progress time, on some turns the bug doesn't happen, and I don't get a function error box, and I can see the mining screen just fine. But on other turns, this bug does happen.

I am sure you won't be shocked to learn that error #2184 is in Display Mining. I think you are on the right lines with the manufacturing but hard to pin down. It might be caused by extremely small but non-zero production resulting in a depletion time that is longer than a decimal can hold. Could you post a screenshot of the mining window on a turn when you don't have the error?

I peeked inside the "Population" database table, and all the minerals on that body have a quantity of 8.2e-26 (super small). It's the only population in my 100-year game database that has a mineral quantity readout like that. Also, I have a strong suspicion this same bug might have been interacting with mass driver shipments off this planet (before I stopped them) and causing another function error from mass drivers because of it.

Here's the screenshot you asked for. I had to load an older save backup. When I loaded the game, the error happened right away, then I progressed forward 5 days, and then the error didn't happen. Here's the screenshot of the mining window from when the error did not occur:

Thanks for all your hard work tracking down our bugs!

Thanks. Given the huge mineral quantities at low accessibility and the tiny amount of produced minerals you mentioned above, I think my original guess was correct. It looks like there is a minuscule amount of production on some but not all turns. When Aurora tries to calculate the depletion time based on that production, it is exceeding the capacity of the decimal data type. I've added code so that depletion is not calculated if production is below 0.0001.