Author Topic: v1.9.5 Bugs Thread  (Read 39975 times)

0 Members and 1 Guest are viewing this topic.

Offline Bughunter

  • Bug Moderators
  • Rear Admiral
  • ***
  • Posts: 929
  • Thanked: 132 times
  • Discord Username: Bughunter
Re: v1.9.5 Bugs Thread
« Reply #150 on: May 10, 2020, 09:04:11 AM »
Is your decimal separator a comma? What decimal separator?

Your OS settings, check the example here and look up what you have it set to:
https://resrequest.helpspot.com/index.php?pg=kb.page&id=279
 
The following users thanked this post: IAMTHEONE

Offline mike2R

  • Lieutenant
  • *******
  • m
  • Posts: 180
  • Thanked: 117 times
Re: v1.9.5 Bugs Thread
« Reply #151 on: May 10, 2020, 01:21:48 PM »
This is slightly hard to explain, but there is a problem with selecting items on the Ground Forces window > STO Targeting tab, which causes problems with adjusting STO Targe Type values.

If you click on an STO formation in the Parent Formation column, one of two things happens.

1) If the value of that STO's Target Type column matches what is already selected in the target type drop down list, then everything works as expected.  The STO is selected (it is highlighted). And if you change the value of the target type drop down list, it updates that STO's Target Type column as you would expect.

2) But if the two values do not match, then the STO is not highlighted, and all that happens is that the selected item in the target type drop down list changes to match what is currently in the Target Type column for that STO.  Changing the value of the target type drop down list does not update the Target Type column for that STO (since it is not highlighted, presumably no STO is selected as far as the game is concerned).  Clicking on it again will select it properly (since the target types now match), but it is confusing behaviour and I do not believe it is intended (there is simply no reason you would ever want the list value to change to match an existing STO).

This is obviously trivial to workaround once you know you have to click twice, but its actually quite confusing until you do - the changing value of the dropdown list gives feedback that you have clicked on the item correctly, and a lot of other items in the game do not show a visible highlight when selected, so it feels like the control is just broken.

The function number NA
The complete error text NA
The window affected Ground Forces window > STO Targeting tab
What you were doing at the time Adjusting STO target types
Conventional or TN start Conventional
Random or Real Stars Real
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent or a one-off? Easy to reproduce
 

Offline Salva

  • Leading Rate
  • *
  • S
  • Posts: 7
Re: v1.9.5 Bugs Thread
« Reply #152 on: May 10, 2020, 02:02:42 PM »
Quote from: Salva link=topic=11298.  msg132154#msg132154 date=1589056219
Hi,

i am playing 1.     9.     5, real stars.      Decimal Separator is a dot.   
There are 4 NPRs (2 i created and 2 other from game setup) as well as activated Acients, Star Swarm and Invaders.   

My test run had me explore the first neighbor system (DX-Cancri), and i immediately found a battle on a comet (comet #1).      Whatever goes on there, i cannot see it, only see lots of weapon impacts and secondary explosions (like: 430x Weapon Strength 3 Impact and multiple more).     

Additionally the following errors occur (reproducable, but not always all of those or at the same time): (i translate from german error report)
- Function #1957: Object reference not set to an instance of an object
- Function #1954: Object reference not set to an instance of an object
- Function #1943: Object reference not set to an instance of an object
- Function #478: Object reference not set to an instance of an object
- Function #327: Object reference not set to an instance of an object (i guess related to destroyed combatants, because it pops up and afterwards there are a bit less weapons fired)
- Function #1816: Object reference not set to an instance of an object

I twice tried to SM a colony on one of the system bodies and move the fleet there, or SM Add some deep space tracking stations to see whats going on there, resulting in an endless loop of the following errors: (was unable to continue)
- Function #1957: Object reference not set to an instance of an object
- Function #1954: Object reference not set to an instance of an object
- Function #1943: Object reference not set to an instance of an object
- Function #478: Object reference not set to an instance of an object

database attached

best regards
Salva

Hi again. 

The situation still occurs, the battle has quieted down, however i am stuck in 5s increments, each round ~5 Weapon impacts.   As soon as i spot the battle (i.  e.   using Deep Tracking Stations SMed in) i get the 4 errors loop mentioned in my ealier post.   I believe it is a spoilers battle, but i cannot confirm. 

To adress the standard questions:
The function number: see quoted post
The complete error text: see quoted post
The window affected: default main window
What you were doing at the time: spotting the enemy
Conventional or TN start: TN
Random or Real Stars: Real
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent or a one-off? Easy

best regards
Salva
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2849
  • Thanked: 677 times
Re: v1.9.5 Bugs Thread
« Reply #153 on: May 10, 2020, 03:04:37 PM »
A potential bug or at most an oversight i in how empire minerals and planetary minerals are counted.

This is in 1.9.5.

The mining report is not showing incoming changes to the daily change in stockpile from mass-drivers and mass-driver show "0" even though resources are coming in. You also see this in the Empires tab as it also does never account for mineral coming in through mass-drivers. So it might show a -53 while the empire stockpile increase say +13 every 5 day tick.

I noticed this early in my conventional campaign when I colonised Venus and started sending allot of Automated mines there to primarily mine Corundium. Venus are sending 66t per 5 day tick and Earth show a -53 SP change and "0" on the mass-driver column... the correct values should be 13 tons of Corundium plus per 5-day at Earth. Eerth stockpile does go up with 13 tons of Corundium every 5 day tick, so it is adding properly so I don't loos any minerals.

I can also verify this by stop sending minerals to Earth from Venus... then the next tick the Empire tab show that I go +13 tons of Corundium every 5 day tick, exactly as it should.


My conclusion is that incoming mass-driver packages are registered as "0" at the receiving end which make the SP per 5 day tick ignore it and this also effect the empire tab as they take the values from the mass-driver column and add that to what is used every 5 day tick.
« Last Edit: May 10, 2020, 03:48:38 PM by Jorgen_CAB »
 

Offline Conscript Gary

  • Lt. Commander
  • ********
  • Posts: 292
  • Thanked: 27 times
Re: v1.9.5 Bugs Thread
« Reply #154 on: May 10, 2020, 03:05:32 PM »
The function number: 311
The complete error text: 1.9.5 Function #311: Object Reference not set to an instance of an object.
The window affected: Tactical, Fleet
What you were doing at the time: Attacking known STO forces with beam-armed warships
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent or a one-off? Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 31 years

All ships in orbit have the STO contacts on a planet set as their target. Upon killing the last STO units, the error pops up. Every 5 seconds past that the error repeats, as well as another energy weapon contact from the ships firing at (presumably) nothing. The error vanishes if the attacking ships' targets are cleared.
In the attached DB the relevant fleets are Combat Group and 3rd Squadron, in the Mawu system.

The DB, my internet is particularly slow today so forum attaching isn't feasible

Already confirmed, but thanks for details
« Last Edit: May 10, 2020, 03:37:14 PM by Bughunter »
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: v1.9.5 Bugs Thread
« Reply #155 on: May 10, 2020, 03:11:17 PM »
Window: During new game creation, immediately after accepting player race.
TN start
Random stars
Separator: '.'
Random High chance with local system chance 0.

1.9.5 Function #3232: Object reference not set to an instance of an object.
1.9.5 Function #1609: Object reference not set to an instance of an object.
1.9.5 Function #1608: Object reference not set to an instance of an object.
1.9.5 Function #1562: Object reference not set to an instance of an object.
1.9.5 Function #1423: Object reference not set to an instance of an object.
Database then auto-saved normally.

This bug dates back to 1.9.0 and should already be on Steve's round tuit list.  Just confirming that it is still present in 1.9.5.
Previous report:  http://aurora2.pentarch.org/index.php?topic=11135.msg129172#msg129172

Edit: Also reconfirming the 'hangs at 100% CPU after accepting player race' bug.

Edit2: 5 new games in a row either hung or threw errors with Local System Chance: 0.  I think reproducibility just became a thing here.

Local system chance: 0
Known Stars: off
NPRs activate Ancient Races: on
Commander Political Bonuses: on
No Maintenance: on
Allow Civilian Harvesters: off
Number of Non-Player Races: 3

Failures:  2 with the #3232 error, 2 hung at 100%, and one Luminosity Key Count is 11.
AFAIK, Steve knows this hasn't been fixed, but hasn't gotten around to fixing it yet.
Did you get a game generated that you could load into? I've run into this error, but it seemed to work fine after.
The three that didn't freeze generated games.  I didn't attempt to play them as I was trying to generate a game without errors.  After 5 out of 5 failures I then tried with 100% local and that worked on the first try.  At the time that I posted I only found mention that Steve was still trying to reproduce it, but as you say it is now listed as fixed in 1.10.0.

In a random stars game, one of my systems has a jump point connection to itself...

I know jump point connection issues have been a thing a lot of people have already reported, so IDK if I should bother providing more info, if so let me know and I'd be happy to provide the database or whatever other info might be required.

EDIT: Attaching DB. There are now two issues:

1) As mentioned previously, system Shanghai has a jump connection to itself. When JP7 (at the time JP3) in Shanghai was explored, it connected to unexplored JP2 (at the time JP1)
2) Subsequently, many systems have connected to Shanghai. I believe this is probably related to the known issue "Local Chance" bug, with Shanghai replacing the previously deleted Sol.

Decimal separator, random stars, conventional start.
Self connections are WAI but are supposed to be rare.  As Nori pointed out the all-roads-lead-to-Sol bug should be fixed in the next version.
 

Offline amschnei

  • Petty Officer
  • **
  • a
  • Posts: 20
  • Thanked: 12 times
Re: v1.9.5 Bugs Thread
« Reply #156 on: May 10, 2020, 03:36:04 PM »
Not a bug, exactly, but probably not WAI:

Troop Transport Bay - VS requires half as much Mercassium as Duranium and Neutronium, while the Standard and Large versions require 2x as much Mercassium as the other resources.

Seems like a possible non-WAI, reported to Steve
« Last Edit: May 10, 2020, 03:44:16 PM by Bughunter »
 

Offline Bughunter

  • Bug Moderators
  • Rear Admiral
  • ***
  • Posts: 929
  • Thanked: 132 times
  • Discord Username: Bughunter
Re: v1.9.5 Bugs Thread
« Reply #157 on: May 10, 2020, 03:51:41 PM »
Not sure if this has been reported before but it seams every time I reload my game I have to redo primary  standing orders.  The conditional ones seam to work ok but the others seam to get reset.  This is a TN start that is sitting at about 50+ years in.  I notice this mostly on my tankers that seam to default back to NONE for primary and secondary standing orders.  I know that when you look at them while the game is running that these can disappear or just not show on the fleet -> standing orders screen, but after a reload the No Order is highlighted even tho I saved them with orders.  Maybe its related?

You say mostly tankers, how often does it happen? Is there some scenario where you can always trigger it? If you had a db where it can be set, saved and reloaded to see it disappearing it would be great for finding it.

Do you use any mods?
Anyone else who have seen this happen?
« Last Edit: May 10, 2020, 03:53:37 PM by Bughunter »
 

Offline Conscript Gary

  • Lt. Commander
  • ********
  • Posts: 292
  • Thanked: 27 times
Re: v1.9.5 Bugs Thread
« Reply #158 on: May 10, 2020, 03:57:34 PM »
The function number: N/A
The complete error text: N/A
The window affected: Tactical, Fleet
What you were doing at the time: Attacking Precursor ships and STO forces
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma? No
Is the bug is easy to reproduce, intermittent or a one-off? I'm having trouble reproducing it from the save, but the event logs show it.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 31 years

When closing to attack the planet mentioned in my last post, a rather strange thing happened. My ships came under fire from the Vancouver-class platform in orbit, suffering severe damage. The issue there is that the Vancouver was a wreck. I destroyed her like five years ago. Attachment 1 shows the screenshot I took at the time before realizing what was happening (I though it was more STO fire at first). Attachment 2 shows a firing message from the very dead ship from the DB linked in my last post.

When attempting to reproduce this bug, I got a similar result from a different dead ship. In the third attachment, note how there's only one surviving Ottawa class ship. The other, Ottawa 001, was destroyed hours before by missile fire. Despite that, in the final attachment here it is firing on my ships as though nothing were wrong. Here's the DB for that moment in time.

I suspect that the ghost station helped contribute to missile defense during my last two excursions too, but I can't be sure.
 

Offline Bughunter

  • Bug Moderators
  • Rear Admiral
  • ***
  • Posts: 929
  • Thanked: 132 times
  • Discord Username: Bughunter
Re: v1.9.5 Bugs Thread
« Reply #159 on: May 10, 2020, 04:00:54 PM »

Looks like this is a more longstanding issue which was present in previous versions: the advance time buttons on the galactic map do not work when auto turns are selected.  With auto turns deselected they work fine. 


Could not see any problem. If you load up the default game from a clean install, what are the exact steps and increments you use to reproduce it?

See two others also had it so must be an issue, but any additional detail would help to pin it down.
« Last Edit: May 10, 2020, 04:09:41 PM by Bughunter »
 

Offline Bughunter

  • Bug Moderators
  • Rear Admiral
  • ***
  • Posts: 929
  • Thanked: 132 times
  • Discord Username: Bughunter
Re: v1.9.5 Bugs Thread
« Reply #160 on: May 10, 2020, 04:05:33 PM »
...

I would love ghost ships, if they were WAI. But this was an odd one. Did you do any database editing or use any mods? Was the game started on 1.9.5? If not do you remember the patch level at the time the wrecks became wrecks?
« Last Edit: May 10, 2020, 04:11:19 PM by Bughunter »
 

Offline mike2R

  • Lieutenant
  • *******
  • m
  • Posts: 180
  • Thanked: 117 times
Re: v1.9.5 Bugs Thread
« Reply #161 on: May 10, 2020, 04:28:57 PM »

Looks like this is a more longstanding issue which was present in previous versions: the advance time buttons on the galactic map do not work when auto turns are selected.  With auto turns deselected they work fine. 


Could not see any problem. If you load up the default game from a clean install, what are the exact steps and increments you use to reproduce it?

See two others also had it so must be an issue, but any additional detail would help to pin it down.

Thanks for looking into this.  Issue replicates on a clean install on my machine.

I downloaded the 1.5.1 full install, patched it to 1.9.0, and patched that to 1.9.5 (did not open the game until patches had been applied).

Game opens into Steve's game.  I opened the galaxy map, pressed the auto-turn button (the galaxy map one) so that the icon turns green, and pressed one of the advance time buttons on the galaxy map.  Clicking one of those buttons highlights it in the normal way, but time does not advance.  No events appear in the event log.  Cursor does not change.  Top menu buttons appear to work fine. 

Advance time works fine on the system map with auto turns selected.

Turn off auto turns, and the advance time buttons on the galaxy map work fine.

My system is pretty ordinary, no mods installed now or ever, I'm in the UK so my settings should be very close to Steve's.  I am running Windows 8.1, which I imagine is uncommon. Tried updating my .Net runtime with no change.

~Nori - I've confirmed this and will move to confirmed bugs
« Last Edit: May 10, 2020, 09:04:58 PM by Nori »
 

Offline Conscript Gary

  • Lt. Commander
  • ********
  • Posts: 292
  • Thanked: 27 times
Re: v1.9.5 Bugs Thread
« Reply #162 on: May 10, 2020, 04:41:05 PM »
...

I would love ghost ships, if they were WAI. But this was an odd one. Did you do any database editing or use any mods? Was the game started on 1.9.5? If not do you remember the patch level at the time the wrecks became wrecks?

No mods or database editing. It was started on an earlier 1.9 version, can't recall if it was .3 or .4. Based on the date, the Vancouver was wrecked in 1.9.4, while the Ottawa was wrecked in 1.9.5.
 

Offline Demonius

  • Warrant Officer, Class 1
  • *****
  • Posts: 83
  • Thanked: 25 times
Re: v1.9.5 Bugs Thread
« Reply #163 on: May 10, 2020, 05:38:13 PM »
Bug or missing feature -
1.9.5, Galaxy created in 1.9.0 with dot as separatzor, 40 years in the Campaign.

I builtl a third Level of Sector command on Terra and moved it in 0.25 increments to a different planet with a 10m+ Population. On the new planet it now lists a size 1 range 1 sector HQ. However, in the sectors window, there is only the Sol sector. I can't assign a leader, I can't assign the neighbouring Systems. Sector window only has "rename" as an Option. Passing a few days changes Nothing, new year, Nothing. Where is the "create new sector from sector command" function?

Confirmed
« Last Edit: May 11, 2020, 04:53:50 PM by Bughunter »
 

Offline Second Foundationer

  • Warrant Officer, Class 1
  • *****
  • Posts: 94
  • Thanked: 34 times
Re: v1.9.5 Bugs Thread
« Reply #164 on: May 10, 2020, 08:04:21 PM »
1.9.5, conventional, real stars start going back to 1.9, periodistic decimal numbers.
Function #1420: Object reference not set to an instance of an object. upon discovery of a new star system 35 years into the campaign

Possibly related to identical error messages http://aurora2.pentarch.org/index.php?topic=11298.msg131799#msg131799 and [1.9.4 bugs thread] http://aurora2.pentarch.org/index.php?topic=11231.msg130360#msg130360, both related to swarm generation, but I don't know yet if this was, and no SM mode was involved here. It was in-game system generation through exploration, so I cannot reproduce or offer database immediately before. But db immediately after is backed up and could be provided if helpful.

Edit: Briefly looked into the db with a somewhat more wakeful mind now, and while I know little about it except from bughunting and can't spot any problem that would be obvious to me, I conclude from RaceSysSurvey table that Swarm is probably involved and it's not unlikely to be related to the other reports. Will attach db. System involved is SystemID 2120/Van Biesbroeck's Star and Race involved as far as I can tell: RaceID 195/Star Swarm #195. – Somewhat spoils my surprise when that survey ship goes to pieces, but I'd rather have 100 future universes error-free. I hope it helps to get closer to that.

Confirmed, thanks for checking and linking the other posts
« Last Edit: May 12, 2020, 10:06:33 AM by Bughunter »
 
The following users thanked this post: Bughunter