Author Topic: v1.13.0 Bugs Thread  (Read 13653 times)

0 Members and 37 Guests are viewing this topic.

Offline skoormit

  • Captain
  • **********
  • Posts: 591
  • Thanked: 219 times
Re: v1.13.0 Bugs Thread
« Reply #195 on: May 09, 2021, 07:20:39 AM »
This has been around for a while, but I'm not sure if I've ever seen it reported:

If I use the Civilian Economy tab of the Economies window to set my capital to supply a quantity of an installation, and then set multiple demands at different colonies that add up to the same quantity, I always end up with some colonies getting more than they ask for, and others getting less or none.

In fact I reported a slightly different version just a few days ago.

The cause is that the "Assigned" amount on the demand side decreases by one every time a freighter finishes loading for that contract at the supply site.

I'm glad I'm not the only one running into this. I was starting to wonder if I was going crazy.

It makes civilian contracts far less useful than they could be.
You can still use them, but if any installation type has more than one open demand contract at a time, you get unpredictable results.

SJW: Fixed for v1.14
« Last Edit: May 15, 2021, 01:33:49 PM by Steve Walmsley »
 
The following users thanked this post: mike2R

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 10550
  • Thanked: 13346 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #196 on: May 09, 2021, 07:22:11 AM »
Forgot to say what the issue amounts to: if you want to start as conventional then there is no way to make NPR conventional, so you are forced to generate 0 at start and rely only on exploration generation, because if you don't - then you get absolutely steamrolled by the starting NPR due to progress difference. At low research speed games you likely won't even end your conventional era by the time NPR finds and exterminates you.

That is working as intended. A Conventional Start is intended as 'hard mode'.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 10550
  • Thanked: 13346 times
    • http://www.starfireassistant.com
Re: v1.13.0 Bugs Thread
« Reply #197 on: May 09, 2021, 07:23:09 AM »
Civilian Shipping Contracts are overfilling.

After a civilian ship loads an installation at the supply location, the "Assigned" amount of the demand contract reduces by 1.
If a new supply contract for this installation is created before this ship finishes unloading at the destination, the civvies will use that supply to fulfill the original demand contract again.
This can happen over and over for a single demand contract.
A civ ship will eventually deliver the installation, causing that demand contract to be deleted. But all the others en route will finish their delivery.

Steps to reproduce:

0) Ensure that a shipping company exists and that no supply or demand contracts currently exist.
1) Create a supply contract for 1 installation at Colony A (make sure Colony A has at least 1 such installation).
2) Create a demand contract for 1 of the same installation at Colony B (must be in same system as Colony A, or a jumpgate route must exist from A to B).
3) Advance time until a civilian freighter has been assigned to deliver the installation. Note that the "Assigned" amount has changed to 1 for both the supply and the demand contract.
4) Advance time until the civilian freighter has finished loading the installation at Colony A and begun moving to B. Note that the supply contract has disappeared, and the "Assigned" amount has changed back to 0 for the demand contract.
5) Create a new supply contract for 1 of the same installation at Colony A. Do not create any matching demand contract.
6) Advance time. If/when a civilian freighter becomes available before the original freighter has unloaded the installation at B, the newly available freighter will be assigned to deliver the installation from A to B. The supply and demand contract "Assigned" amounts will change to 1 and the ship will move to A, load the installation (which reduces the "Assigned" amount on the demand contract back to 0), and begin moving to B.
7) If you like, go back to step 5 and do it again. See how many civvies you can get loaded up before the original freighter finally delivers the installation.

Any luck with this one? It greatly hampers the use of civilian shipping contracts. I'm happy to test specific scenarios if that helps track it down.

Not yet. I suspect a lot of investigation needed, so waiting till I have the time to get into properly.
 
The following users thanked this post: mike2R, skoormit

Offline ChubbyPitbull

  • Gold Supporter
  • Sub-Lieutenant
  • *****
  • C
  • Posts: 107
  • Thanked: 16 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
Re: v1.13.0 Bugs Thread
« Reply #198 on: May 09, 2021, 08:25:59 PM »

Ended up having to abandon this game, game saving continued to take longer and longer with more of the Function #3239 errors; last attempt took ~15 minutes. Game is also stuck in permanent 2 hour time pulses, as best I can tell in the game log this is due to NPR fleets unable to complete their standing orders and/or NPR civilian shipping unable to load structures for requested shipments. Final DB attached.

#3239 is saving installations in cargo. The object reference error might be caused by trying to save cargo that originated in a population that no longer exists. I'll add some code to handle that. In the meantime, the workaround would be to delete records from the FCT_ShipCargo table that have a cargo type of 2.

Thanks Steve, I went back to this game and deleted all the FCT_ShipCargo records with cargo type of 2. This solved the #3239 error and saving the game takes the normal amount of time now. However, the game is still stuck in 2 hour sub-pulses even with auto-subpulse set. Automated Turns of 5 days just sit there chugging along in two hour blocks. The game log includes lots of these records for the NPR races:

"DDG Lome II 005 is unable to carry out its primary standing order: Join Operational Group"
"Stabilisation Squadron 006 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point"
"SS Spider 004 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)"
"Salvage Squadron 003 is unable to carry out its primary standing order: Salvage Nearest Wreck"

etc.

Could one of them be causing the interrupts? Logs are also still in the DB I provided previously.
 

Offline ChubbyPitbull

  • Gold Supporter
  • Sub-Lieutenant
  • *****
  • C
  • Posts: 107
  • Thanked: 16 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
Re: v1.13.0 Bugs Thread
« Reply #199 on: May 11, 2021, 12:12:56 PM »
"Update all formations with same replacement template" checkbox has no effect.
Extra checkbox in Change Replacement Template window for ground units.

Game: TN Start
Stars: Random
Decimal Seperator: Period
Reproducibility: Everytime I updated a template for an Infantry Regiment
Campaign Length: 17 years
Mods or DB changes: None

I've been working on designing the next series of ground units. Thanks to some help from nuclearslurpee he directed me to Steve's post here http://aurora2.pentarch.org/index.php?topic=11593.msg140370#msg140370 about how to handle Ground Unit replacement templates.

My original units used the formation template "Infantry Regiment," and I designed a new template "2042 Infantry Regiment" using the upgraded units. I then went to my Ground Unit OOB to update the existing "Infantry Regiment"'s to use the new "2042 Infantry Regiment" as their replacement template. I am able to update each unit one by one, but I saw there was a "Update all formations with same replacement template" checkbox in the Change Replacement Template Window, which I assume would mean that in one go I can change anything currently using the "Infantry Regiment" replacement template to use the "2042 Infantry Regiment" replacement template. However, this appears to not be the case, and checking this box does not have any effect on any other infantry regiments. There also appears to be a second floating checkbox in the window (screenshot attached), and I tested checking 1 box alone, the other box alone, both boxes at once, and neither box, and all had the same behavior where no other unit's replacement templates were changed. DB attached, game name is "New 13."



SJW: Fixed for v1.14
« Last Edit: May 15, 2021, 01:27:31 PM by Steve Walmsley »
 

Offline Remilian

  • Petty Officer
  • **
  • R
  • Posts: 15
  • Thanked: 18 times
Re: v1.13.0 Bugs Thread
« Reply #200 on: May 11, 2021, 03:36:17 PM »
In DIM_SystemAge table, first entry has a really weird Age2 column value.  No idea where it is used, if at all, but might wanna check that one out.

SJW: Fixed for v1.14
« Last Edit: May 15, 2021, 09:46:09 AM by Steve Walmsley »
 

Offline Remilian

  • Petty Officer
  • **
  • R
  • Posts: 15
  • Thanked: 18 times
Re: v1.13.0 Bugs Thread
« Reply #201 on: May 11, 2021, 03:54:41 PM »
Gas "None" can be added to the atmosphere with "SM: Set Atm"

SJW: Fixed for v1.14
« Last Edit: May 15, 2021, 09:46:17 AM by Steve Walmsley »
 

Offline xenoscepter

  • Rear Admiral
  • **********
  • Posts: 882
  • Thanked: 174 times
Re: v1.13.0 Bugs Thread
« Reply #202 on: May 12, 2021, 01:00:44 AM »
 - 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.
 

Offline skoormit

  • Captain
  • **********
  • Posts: 591
  • Thanked: 219 times
Re: v1.13.0 Bugs Thread
« Reply #203 on: May 12, 2021, 07:58:16 AM »
Oxygen not showing "(F)" when frozen?

A planet in my game with surface temp -107.034C (165.966k) shows the following atmospheric gases:

GasAtm
Nitrogen 1.2128
Carbon Dioxide (F)0.1499
Oxygen 0.018

The total displayed for Atmospheric Pressure is 1.213.
The CO2 and Oxygen are being ignored in this total.
I believe the "(F)" on the CO2 line means it is frozen, and therefore not contributing to atmospheric pressure.
I suspect the Oxygen is also frozen, but it does not have the indicator.
« Last Edit: May 12, 2021, 08:44:24 AM by skoormit »
 

Offline serger

  • Silver Supporter
  • Captain
  • *****
  • Posts: 452
  • Thanked: 67 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: v1.13.0 Bugs Thread
« Reply #204 on: May 12, 2021, 08:15:47 AM »
Oxygen not showing "(F)" when frozen?

A planet in my game with surface temp -107.034C (165.966k)

It's not a bug - oxygen's temperature of melting is about -220C.
 

Offline skoormit

  • Captain
  • **********
  • Posts: 591
  • Thanked: 219 times
Re: v1.13.0 Bugs Thread
« Reply #205 on: May 12, 2021, 08:42:45 AM »
Oxygen not showing "(F)" when frozen?

A planet in my game with surface temp -107.034C (165.966k)

It's not a bug - oxygen's temperature of melting is about -220C.

In that case, the bug is that the oxygen is not being counted in the total atmospheric pressure.
 

Offline villaincomer

  • Petty Officer
  • **
  • v
  • Posts: 17
  • Thanked: 8 times
Re: v1.13.0 Bugs Thread
« Reply #206 on: May 12, 2021, 02:09:38 PM »
Running without mods, tinkered with numbers at start to give myself a bit of a head start.   

35 years into the game on start-up I get:
1.   13.   0 Function #1168:  The given key was not present in the dictionary.   

I can ok it and get in.     
Background:
I had recently occupied a precursor and recovered some installations on their planet.     Some installations have gone to the colony which my landed army is sitting.     Some installations recovered to the subjugated colony.     
Im assuming its that.     

Q:  Is there a way I can merge those colonies in SM to see if that fixes it?
Some people have emigrated so population isnt empty

*Edit:  I have tried deleting the subjugated planet entirely.   Saved and the game loads ok without errors.   Assuming this confirms my cause hypothesis.  However it would be nice to be able to fix/tinker so I can play from here if at all possible. 

Also:
Earlier in the game I got another error (~cant div by zero ) but I thought it had been caused by a ruin recovery where I was transporting terraformers off planet via the civilian economy while the ruins where still being explored.     At one point there was a fraction of an installation to >10 decimal places.   
I used SM to round it back to a whole number and didn't experience that error again.   

Happy to zip db copy at this point if its of use.   
p.   s  Love the game :)
« Last Edit: May 12, 2021, 02:44:15 PM by villaincomer »
 

Offline skoormit

  • Captain
  • **********
  • Posts: 591
  • Thanked: 219 times
Re: v1.13.0 Bugs Thread
« Reply #207 on: May 12, 2021, 02:20:02 PM »
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.

SJW: Fixed for v1.14
« Last Edit: May 15, 2021, 03:52:42 PM by Steve Walmsley »
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1237
  • Thanked: 338 times
Re: v1.13.0 Bugs Thread
« Reply #208 on: May 12, 2021, 04:00:37 PM »
I suspect that the problem

umm... did you forget something?
 

Offline skoormit

  • Captain
  • **********
  • Posts: 591
  • Thanked: 219 times
Re: v1.13.0 Bugs Thread
« Reply #209 on: May 12, 2021, 04:07:05 PM »
I suspect that the problem

umm... did you forget something?

Of course I did. I forgot a final proofread.
I've deleted that line...it was supplanted by the prior passage.

Thanks for the heads up.
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78