v1.12.0 Bugs Thread

[Alno]

Ok, in conclusion:
Changing the "long date" format of my OS fixed the research finish dates not fitting.     
And the OS decimal separator must be a dot when creating a new game, or things break.  It was not the mod that broke things afterall.  Also, don't forget to reboot after changing the decimal separator, or you will sit there like a moron and wonder why your research rates are still nuts.  Not gonna name anyone here.  *sideeyes mirror*

[pwhk]

I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

(snip)

I can confirm I am also getting a similar issue, on a conventional start with real stars, 70 years in, continued for multiple in-game years. One save file also getting a lot of "Out of fuel" messages from NPR ships. Also have database handy.

[Potat999]

I'm playing a game with two player races, which have neutral but overall positive relations (~500) and a trade agreement.

I just finished researching Microwave Focusing 5 with Race #1. 
Race#2 received Microwave Focusing Technology 1 from Race #1.

These two races do not have a research data agreement.  It shows as "Not Available" on both races. 

Is this an intended feature - ideas slowly spreading between friendly races via trade?  Or just a bug that should not have happened without research data sharing?

SJW: That is working as intended. Trade relations will result in the transfer of tech systems that are very low level compared to your current tech.

[nuclearslurpee]

I'm playing a game with two player races, which have neutral but overall positive relations (~500) and a trade agreement.

I just finished researching Microwave Focusing 5 with Race #1. 
Race#2 received Microwave Focusing Technology 1 from Race #1.

These two races do not have a research data agreement.  It shows as "Not Available" on both races. 

Is this an intended feature - ideas slowly spreading between friendly races via trade?  Or just a bug that should not have happened without research data sharing?

Someone else who knows better can chime in, but I remember as far back as VB6 there was a mechanic for which races that were far behind in the tech tree could passively receive outdated techs from other races just by being generally aware of each other. The case I remember is a player-created race spawned in the middle of the game received low-tier armor tech from another player race that had a higher level of armor tech. I don't know the detailed mechanics but it sounds like this is what happened.

[pwhk]

I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

(snip)

I can confirm I am also getting a similar issue, on a conventional start with real stars, 70 years in, continued for multiple in-game years. One save file also getting a lot of "Out of fuel" messages from NPR ships. Also have database handy.

Fed up with this, I decided to try investigate myself

Looks like some NPR fleets (which is construction fleet) keep jumping back and forth at a jump point, keep triggering hostile contacts for another NPR. The other NPR, not to be outdone by hostilities, also have another fleet jumping back and forth at the same jump point.
 
I edited the DB to take control, SM delete the offending ships, and put control back (edit DB again). This appears to fix the issue.

[Froggiest1982]

I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

(snip)

I can confirm I am also getting a similar issue, on a conventional start with real stars, 70 years in, continued for multiple in-game years. One save file also getting a lot of "Out of fuel" messages from NPR ships. Also have database handy.

Fed up with this, I decided to try investigate myself

Looks like some NPR fleets (which is construction fleet) keep jumping back and forth at a jump point, keep triggering hostile contacts for another NPR. The other NPR, not to be outdone by hostilities, also have another fleet jumping back and forth at the same jump point.
 
I edited the DB to take control, SM delete the offending ships, and put control back (edit DB again). This appears to fix the issue.

The peeking NPR affects players as well. Not sure if Steve was doing something about it as I remember sever posts talking about the event.

Next time you may download this tool: http://aurora2.pentarch.org/index.php?topic=11780.0 and deactivate the issue. Just remember to keep an eye on your event log!

[TheBawkHawk]

I did a bit further digging inspired by your post, and I examined the last several increments. Turns out not only were these military ships unable to complete their orders, there were also some survey ships bouncing back and forth at a jump point like you had suggested. In addition, there were also at least 4 NPR civilian ships unable to load cargo, because they were already full. How all of this happened at the same time I have no idea, but the issue has been solved. I had to take manual control of the NPR's like you said, and delete the civilians and the survey ships.

So the issue I had posted earlier is solved, and I believe that Steve said he has already found a workaround for the civilian one, I'm not sure about the ships bouncing back and forth at jump points though. Although, the NPR ships unable to complete their orders haven't done anything for a while, so it would appear that something might be up with the NPR order assignments.

[Cosinus]

The function number: #787
The complete error text:  The sequence contains no elements (roughly translated)
The window affected: tactical view.
What you were doing at the time: Advancing time in 2h increments, which seems to be a common problem among several posters above (see e.g. reply #271 here)
Conventional or TN start: TN
Random or Real Stars: random
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: reproducible with the attached DB
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: roughly 50 years

More info: This is a game with several nearby NPRs which had a large fight just 1 year before this DB date (see "Yalta" system). After that the game only incremented in 2h increments and ran REALLY slow, to the point where it was basically impossible to play (several minutes for 1 in-game day) and I just let it run in the background while playing Slay the Spire. After roughly 1 in-game year of these 2h increments the game showed me this error and incredibly after that, the game started to run a lot faster and use 5 day increments again. I'm curious for the reason. Fortunately I had a savefile from just before the bug occurred (thanks autobackup feature).
To reproduce: Load the attached DB, select autoturns and 5 day increments and let it run for a while. After a few days (in game date 25.10.2052) the error should happen. I reproduced this once (from 1 attempt) and interestingly the error occurred on the 26th

EDIT: After writing all of this I can't seem to post it. I get redirected either to "create new post" or to "500 internal server error". I try to post it without the DB now, to see if that works.
EDIT2: The attachments seems to be the issue. Maybe the forum is broken or something. Anyway here is the DB: https://drive.google.com/file/d/1n5YjyD1R0cOWSVG6vEaAYQ5r5WH21Ush/view?usp=sharing

[Droll]

The function number: #787
The complete error text:  The sequence contains no elements (roughly translated)
The window affected: tactical view.
What you were doing at the time: Advancing time in 2h increments, which seems to be a common problem among several posters above (see e.g. reply #271 here)
Conventional or TN start: TN
Random or Real Stars: random
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: reproducible with the attached DB
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: roughly 50 years

More info: This is a game with several nearby NPRs which had a large fight just 1 year before this DB date (see "Yalta" system). After that the game only incremented in 2h increments and ran REALLY slow, to the point where it was basically impossible to play (several minutes for 1 in-game day) and I just let it run in the background while playing Slay the Spire. After roughly 1 in-game year of these 2h increments the game showed me this error and incredibly after that, the game started to run a lot faster and use 5 day increments again. I'm curious for the reason. Fortunately I had a savefile from just before the bug occurred (thanks autobackup feature).
To reproduce: Load the attached DB, select autoturns and 5 day increments and let it run for a while. After a few days (in game date 25.10.2052) the error should happen. I reproduced this once (from 1 attempt) and interestingly the error occurred on the 26th

EDIT: After writing all of this I can't seem to post it. I get redirected either to "create new post" or to "500 internal server error". I try to post it without the DB now, to see if that works.
EDIT2: The attachments seems to be the issue. Maybe the forum is broken or something. Anyway here is the DB: https://drive.google.com/file/d/1n5YjyD1R0cOWSVG6vEaAYQ5r5WH21Ush/view?usp=sharing

Did you try to compress your DB into a zip file? I've found that with large files the forum likes to error out.

[Cosinus]

Did you try to compress your DB into a zip file? I've found that with large files the forum likes to error out.

It's already 7z compressed. It's 20MB so way below the file size limit.

[Garfunkel]

I'm playing a game with two player races, which have neutral but overall positive relations (~500) and a trade agreement.

I just finished researching Microwave Focusing 5 with Race #1. 
Race#2 received Microwave Focusing Technology 1 from Race #1.

These two races do not have a research data agreement.  It shows as "Not Available" on both races. 

Is this an intended feature - ideas slowly spreading between friendly races via trade?  Or just a bug that should not have happened without research data sharing?

Someone else who knows better can chime in, but I remember as far back as VB6 there was a mechanic for which races that were far behind in the tech tree could passively receive outdated techs from other races just by being generally aware of each other. The case I remember is a player-created race spawned in the middle of the game received low-tier armor tech from another player race that had a higher level of armor tech. I don't know the detailed mechanics but it sounds like this is what happened.

Races/factions that share a planet will "bleed" non-cutting edge tech to each other.

[Cosinus]

(Not using the normal format since there is no error code, but yes I use 1.12 unmodded with dot separator.)

3 maybe related bugs with displaying alien ship contacts:

First issue: There are some glitches in the "contacts list". In my game, there is an Alien NPR known as the Saratov Aliens. However since communication was established, they are known as the Saad Alliance. This leads to some issues, as the game rapidly glitches between those two names. To replicate: Go to the attached DB, tactical window, "contacts" tab and select the "saratov aliens 224" in the drop down menu for "display single race contacts only". The name will flicker between saratov aliens and saad alliance. Expected behaviour: Just use Saad alliance everywhere after communications is established.

This leads right to the second issue. As you can see, if you disable "lost contacts" there are no contacts displayed for any race in Saratov, even though there are 4 ships right next to my Survey ship at Saratov B1. Expected behaviour: Unless I severely misunderstand the purpose of this list, the list of contacts should show all current contacts so you can easily find them.

Third Issue: This has to do with drawing contacts on the tactical map. As you can see in the DB, I have several Deep space tracking stations on Saratov B1 and passive sensors in orbit on the CVS Athena. The alien ships are in orbit as well and thus have a distance of zero to my passive sensors. However, the passive sensors can't detect them, even though they have a thermal signature. When you turn active sensors off, the ships just vanish, even though they are right next to my ship. Expected behaviour: Passive thermal sensors and deep space tracking stations should always detect a nonzero thermal emission at zero range. Same for other sensors.

The DB is here (7z format, 22MB), as I couldn't upload before: https://drive.google.com/file/d/1kYL4ssDl2xuqpz3JhQfWCdQDZO8McBUt/view?usp=sharing

[Cosinus]

Bug: Fighters ignore naming themes.
To reproduce: Design a fighter (<500 tons), select a naming theme in the "miscellaneous" tab and select "pick random name from theme".
Build a few fighters. They will be named A 001, A 002, etc where A is your class name and will not follow your chosen naming theme.
To double check, go to the "ships in class" tab in the class design window and select "rename all". All fighters of that class will be renamed according to your selected naming theme.

Expected behaviour: Fighters should behave just like ships and be named according to the naming theme selected from the start.

You can see this problem in the DB posted in my previous report with the "Eye" class.

[Cosinus]

(Sorry to report a lot of bugs lately, but I keep finding more )

There seems to be an issue with the pathfinding algorithm. I have not tracked down where it comes from exactly, but I just noticed this behaviour in one location in a big multi star system.
I noticed that in this specific location, when setting 2 fleets to go to the location of the other, the pathfinding algorithm lets them end up in the middle of nowhere.



As you can see, the ships do not go towards each other in a straight line, but rather go in a completely different direction.
DB is here: https://drive.google.com/file/d/16U8NyUzBkcZ9gkN58JsPP6CGa4nXBDb7/view?usp=sharing
To reproduce, set the Pacifica to go to the location of the Triton, and vice versa. Then advance time.

SJW: Working as intended. When you give a fleet orders to move to another fleet, it sets an intercept course to move to where the target fleet will be in the future, rather than where it is now.

[nuclearslurpee]

Bug: Fighters ignore naming themes.
To reproduce: Design a fighter (<500 tons), select a naming theme in the "miscellaneous" tab and select "pick random name from theme".
Build a few fighters. They will be named A 001, A 002, etc where A is your class name and will not follow your chosen naming theme.
To double check, go to the "ships in class" tab in the class design window and select "rename all". All fighters of that class will be renamed according to your selected naming theme.

Expected behaviour: Fighters should behave just like ships and be named according to the naming theme selected from the start.

You can see this problem in the DB posted in my previous report with the "Eye" class.

This one is technically WAD but perhaps not WAI. If you build fighters or stations from the Construction tab they will not use the naming scheme, as there is nowhere in that interface to actually name the thing you're building. The names only work if you build them from a shipyard which does have a space on the interface for naming things.