v1.9.5 Bugs Thread

[Froggiest1982]

Nori - This is a known bug that Steve hasn't figured out yet.

All roads lead to Sol. After meeting 2 NPRs surveying Sol within the first six months of a new game I figured something was up so I made a test game and SM-explored a bunch of jump points. Sol has 9 JPs and counting as almost every system has connected to it on the first outbound exploration. The attached test game was made in a fresh install, 1.00->1.9.0->1.9.5. I had high hopes for 1.9.5 fixing connections for random stars but it looks like we're not quite there yet.

What you were doing at the time: SM-exploring JPs.
TN start
Random Stars
Decimal
Trivial to reproduce: start a random stars game and explore some JPs. If you prefer, start the game with a couple TN NPRs and run a couple 30-day increments, you'll see them exploring Sol in short order as their first JP will probably connect to it.

It seems that every time a jump point tries to connect to a non-local system, it instead connects to system 0, which is Sol.

I don't know about that but I hope Steve is reading.

I know exactly when this started. I don't remember the reason why though.

So there was a rant regarding system generation numbers and after reading that Steve changed the Sol system from being system 0 to system 1 (so this part It seems that every time a jump point tries to connect to a non-local system, it instead connects to system 0, which is Sol it's not correct).

After that was done the Double Sol bug appeared. It didn't take long for the multiple Sol connection to appear as well.

Maybe I am wrong but if you use an Aurora installation prior to that change there is no problem (connections are fine and no double Sol). I will try to find it again so you can run test on before and after and I will edit this post if I manage to do that.

[skoormit]

Nori - This is a known bug that Steve hasn't figured out yet.

All roads lead to Sol. After meeting 2 NPRs surveying Sol within the first six months of a new game I figured something was up so I made a test game and SM-explored a bunch of jump points. Sol has 9 JPs and counting as almost every system has connected to it on the first outbound exploration. The attached test game was made in a fresh install, 1.00->1.9.0->1.9.5. I had high hopes for 1.9.5 fixing connections for random stars but it looks like we're not quite there yet.

What you were doing at the time: SM-exploring JPs.
TN start
Random Stars
Decimal
Trivial to reproduce: start a random stars game and explore some JPs. If you prefer, start the game with a couple TN NPRs and run a couple 30-day increments, you'll see them exploring Sol in short order as their first JP will probably connect to it.

It seems that every time a jump point tries to connect to a non-local system, it instead connects to system 0, which is Sol.

I don't know about that but I hope Steve is reading.

I know exactly when this started. I don't remember the reason why though.

So there was a rant regarding system generation numbers and after reading that Steve changed the Sol system from being system 0 to system 1 (so this part It seems that every time a jump point tries to connect to a non-local system, it instead connects to system 0, which is Sol it's not correct).

After that was done the Double Sol bug appeared. It didn't take long for the multiple Sol connection to appear as well.

Maybe I am wrong but if you use an Aurora installation prior to that change there is no problem. I will try to find it again so you can run test on before and after and I will edit this post if I manage to do that.

In kyonkundenwa's db, Sol's system number is 0.

[Froggiest1982]

Nori - This is a known bug that Steve hasn't figured out yet.

All roads lead to Sol. After meeting 2 NPRs surveying Sol within the first six months of a new game I figured something was up so I made a test game and SM-explored a bunch of jump points. Sol has 9 JPs and counting as almost every system has connected to it on the first outbound exploration. The attached test game was made in a fresh install, 1.00->1.9.0->1.9.5. I had high hopes for 1.9.5 fixing connections for random stars but it looks like we're not quite there yet.

What you were doing at the time: SM-exploring JPs.
TN start
Random Stars
Decimal
Trivial to reproduce: start a random stars game and explore some JPs. If you prefer, start the game with a couple TN NPRs and run a couple 30-day increments, you'll see them exploring Sol in short order as their first JP will probably connect to it.

It seems that every time a jump point tries to connect to a non-local system, it instead connects to system 0, which is Sol.

I don't know about that but I hope Steve is reading.

I know exactly when this started. I don't remember the reason why though.

So there was a rant regarding system generation numbers and after reading that Steve changed the Sol system from being system 0 to system 1 (so this part It seems that every time a jump point tries to connect to a non-local system, it instead connects to system 0, which is Sol it's not correct).

After that was done the Double Sol bug appeared. It didn't take long for the multiple Sol connection to appear as well.

Maybe I am wrong but if you use an Aurora installation prior to that change there is no problem. I will try to find it again so you can run test on before and after and I will edit this post if I manage to do that.

In kyonkundenwa's db, Sol's system number is 0.

Then something is wrong. I also remember to have argued for that request of change because I suspected it would have created issues.

Here the chain of events

First requests random to change something in system generation with Steve acknowledging to have Sol has the system 0 http://aurora2.pentarch.org/index.php?topic=10902.msg125714#msg125714 and this was back in 1.6.3 without double Sols etc

After that in 1.7 Steve did this change http://aurora2.pentarch.org/index.php?topic=10934.msg126124#msg126124

Shortly after we had Multiple Sols and all roads lead to Sol bug http://aurora2.pentarch.org/index.php?topic=10962.msg126268#msg126268 this was just 1.7.2 Nobody noticed in 1.7.1 because it was a short-lived version.

To be noted the absolute first bug report is the double sol.

[Nori]

Ok I moved it to the confirmed bugs. I checked and didn't see it in known bugs anymore so it seems this is a new(er?) issue.

[StevioM]

First post and very new player.  .  .   so this may just be me being derpy. 

I was playing around with the ‘universal freighter’ concept from ship design.   I’ve set the cargo containers to ‘conscript’ which as I understand should stop officers being assigned.   But they are still assigned. 

Not sure if something that is generally known or new for this version. 

Conventional start
Real stars
Not comma decimal


Ta!

WAI

[QuakeIV]

The random dwarf names was meant to be a commander name theme rather than a class name theme (pretty minor one).

[Foolcow]

The function number:  None given
The complete error text  "Error:  Luminosity Key Count is 11"
The window affected:  New game information screen
What you were doing at the time:  Starting a new real stars game with 70 starting NPRs.
Conventional or TN start:  TN
Random or Real Stars:  Real Stars
Is your decimal separator a comma?  No
Is the bug is easy to reproduce, intermittent or a one-off?  Easy to reproduce

After setting up the game parameters and creating the race in Sol, the error "Luminosity Key Count is 11" appears several times, with a few seconds in between each instance.  However, the game does finish initializing after a minute or so and I'm able to start giving commands as normal.

Failed to reproduce

[Foolcow]

Often, when starting a random stars game with a large number of NPRs, version 1.9.5 freezes up while initializing.  No error messages are given, the program simply does nothing for hours after the "Create Race" button is clicked for the player race in Sol.

The bug is intermittent, and seems to be more likely to happen as the number of NPRs is increased.  I've attempted to start about 50 random stars games so far.  When I set the number of NPRs to 3, the problem has never happened.  When I set it to 14, this issue happens about 70% of the time.  I've never managed to start a game with 70 starting NPRs.

This problem only happens with Random Stars, not Real Stars.  With real stars games and all other parameters the same, the game starts up successfully with the number of starting NPRs set to 70, as mentioned in my post directly above this one.

I am starting with a fresh installation of 1.9.5 each time.  I unzip 151Full into an empty directory, then replace the contents with what is in 190, followed by 195.


The function number:  N/A
The complete error text  N/A
The window affected:  New game information screen
What you were doing at the time:  Starting a new random stars game with 70 starting NPRs.
Conventional or TN start:  TN
Random or Real Stars:  Random Stars
Is your decimal separator a comma?  No
Is the bug is easy to reproduce, intermittent or a one-off?  Intermittent, though it seems to happen more frequently with increasing numbers of starting NPRs

Confirmed

[Cosinus]

Minor error: Renaming a ground unit clears its Field position.

The window affected: Ground forces/Order of Battle
What you were doing at the time: see below
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
The rest: N/A

Steps to reproduce:

• Create a ground unit formation with some units (e.g. Battalion)
• Set the unit to e.g. "Frontline Attack" or "Rear Echelon" field position.
• Rename the unit. The unit is now in the default "Frontline Defense" position

Confirmed

[mike2R]

I’ve set the cargo containers to ‘conscript’ which as I understand should stop officers being assigned.   But they are still assigned. 

Conscript is about crew rather than commanders.  If you check the Acadamies tab on the Race Infomation window, you'll see a figure for "Crewman and Junior Officers", which are generated by your Military Acadamies along with officers etc. (quantity vs quality can be decided by the Training Level control lower down).  These are subtracted from to crew your ships, unless you tick "Conscript" for a class in which case I guess you just get randoms off the street - the Crew Grade for ships of this class will start negative.

[Jobran180]

Conscript is about crew rather than commanders.   If you check the Acadamies tab on the Race Infomation window, you'll see a figure for "Crewman and Junior Officers", which are generated by your Military Acadamies along with officers etc.  (quantity vs quality can be decided by the Training Level control lower down).   These are subtracted from to crew your ships, unless you tick "Conscript" for a class in which case I guess you just get randoms off the street - the Crew Grade for ships of this class will start negative.

Is there a way to check how many Crewmen you have in "reserve"? or is that just hidden until you hit your cap?

[mike2R]

Conscript is about crew rather than commanders.   If you check the Acadamies tab on the Race Infomation window, you'll see a figure for "Crewman and Junior Officers", which are generated by your Military Acadamies along with officers etc.  (quantity vs quality can be decided by the Training Level control lower down).   These are subtracted from to crew your ships, unless you tick "Conscript" for a class in which case I guess you just get randoms off the street - the Crew Grade for ships of this class will start negative.

Is there a way to check how many Crewmen you have in "reserve"? or is that just hidden until you hit your cap?

Yeah you get a figure on the Race Information window > Acadamies tab.

[Elvin]

The function number: 3255
The complete error text: 1.9.5 Function #3255: Object reference not set to an instance of an object.
The window affected: Main view, every increment ( 5 second to 5 day inclusive)
What you were doing at the time: Just finished designing new ships, lots of prototypes, also just found new star system
Conventional or TN start: TN
Random or Real Stars: Real
Is your decimal separator a comma?: Default UK settings
Is the bug is easy to reproduce, intermittent or a one-off?: Seems to happen every increment for me
If this is a long campaign: Year is 2056 from default start time.

Additional info: This was a 1.9.3 save, now running 1.9.5. It also seems somewhat intermittent, as saving - loading - saving - loading seems to make the problem disappear.

Sorry if this is unreproduceable...

Reproduction should be as simple as loading the attached DB and progressing time.

[Foolcow]

Conscript is about crew rather than commanders.   If you check the Acadamies tab on the Race Infomation window, you'll see a figure for "Crewman and Junior Officers", which are generated by your Military Acadamies along with officers etc.  (quantity vs quality can be decided by the Training Level control lower down).   These are subtracted from to crew your ships, unless you tick "Conscript" for a class in which case I guess you just get randoms off the street - the Crew Grade for ships of this class will start negative.

Is there a way to check how many Crewmen you have in "reserve"? or is that just hidden until you hit your cap?

Yeah you get a figure on the Race Information window > Acadamies tab.

That shows the number you get annually at your current training level, not the current number of available trained crewmembers.

[mike2R]

Conscript is about crew rather than commanders.   If you check the Acadamies tab on the Race Infomation window, you'll see a figure for "Crewman and Junior Officers", which are generated by your Military Acadamies along with officers etc.  (quantity vs quality can be decided by the Training Level control lower down).   These are subtracted from to crew your ships, unless you tick "Conscript" for a class in which case I guess you just get randoms off the street - the Crew Grade for ships of this class will start negative.

Is there a way to check how many Crewmen you have in "reserve"? or is that just hidden until you hit your cap?

Yeah you get a figure on the Race Information window > Acadamies tab.

That shows the number you get annually at your current training level, not the current number of available trained crewmembers.

Ah...