Author Topic: v1.9.2 Bugs Thread  (Read 8816 times)

0 Members and 1 Guest are viewing this topic.

Offline DoctorDanny

  • Warrant Officer, Class 1
  • *****
  • D
  • Posts: 79
  • Thanked: 11 times
Re: v1.9.2 Bugs Thread
« Reply #15 on: April 30, 2020, 12:56:54 AM »
Quote from: Waldschrat link=topic=11159.   msg129286#msg129286 date=1588202959
I have the same issues with troop transports.     
I'm using a fleet of 5 transport ships with 15,000 carrying capacity each to transport units with size of 15,000 per unit.       First i tried to specify 5 of these units to be loaded which gave the errors (not for the first transport ship though) and only one was picked up, then i tried only loading one unit which gave the same error messages but again not for the first transport ship and the unit got picked up, then i detached one transport ship and loaded one unit which gave no error messages and got picked up successfully.     


edit: Version 1.     9.     2 (not a fresh save though but was an issue in 1.     9.     0 as well)
decimal seperator: .   

Sounds to me like its loading the first unit into the first ship, then since there is room left in the first ship it tries to put the next unit in there too, but errors out cause there is not enough room

Same for me. Reported this in the 1.8.0 thread allready.
 

Offline JANXOL

  • Able Ordinary Rate
  • J
  • Posts: 3
Re: v1.9.2 Bugs Thread
« Reply #16 on: April 30, 2020, 02:19:52 AM »
I have encountered a bug with PPV calculations.  It first started happening in 1. 6, but I thought i misunderstand the mechanics.  After talking to people on discord, apparently it is a bug.

I have designed a ship which shows a PPV of 36.  A fleet of 6 of them provides 32PPV total.  No components are damaged, the ships are less than two months old.  Removing one ship from the fleet results in a PPV of 27.  The colony view also shows protection of 32, but clearly that doesn't correspond to 6*36.  Below is the ship design and screenshot of the fleet view.

Code: [Select]
Hatsuharu class Missile Boat      996 tons       22 Crew       143.3 BP       TCS 20    TH 88    EM 0
4394 km/s      Armour 1-8       Shields 0-0       HTK 8      Sensors 6/4/0/0      DCR 0      PPV 36
Maint Life 7.44 Years     MSP 84    AFR 16%    IFR 0.2%    1YR 3    5YR 40    Max Repair 43.75 MSP
Magazine 36   
Lieutenant Commander    Control Rating 1   
Intended Deployment Time: 12 months    Morale Check Required   

Xiao Aero Engines M-INPE-5-175  EP87.50 (1)    Power 87.5    Fuel Use 401.06%    Signature 87.5    Explosion 17%
Fuel Capacity 100 000 Litres    Range 4.5 billion km (11 days at full power)

Yamamoto-Matsuki SSN-6-1 "Toge" Missile Launcher (6)     Missile Size: 6    Hangar Reload 122 minutes    MF Reload 20 hours
Hicks-Stevens FC45-R100-0.8 Missile Fire Control (1)     Range 45.9m km    Resolution 100
Yamamoto-Matsuki SSN-6-1 "Toge" Anti-Ship Missile (6)    Speed: 14 933 km/s    End: 50.3m     Range: 45.1m km    WH: 4    Size: 6    TH: 104/62/31

Hicks-Stevens AS-1B S128-2.5-R100-40M Sensor Array (1)     GPS 3000     Range 40.6m km    Resolution 100
Parker Electronics R-1 EM8-0.5 Warning Receiver (1)     Sensitivity 4     Detect Sig Strength 1000:  15.8m km
Gadgil-Asani TH1.0-6 Thermal Sensor (1)     Sensitivity 6     Detect Sig Strength 1000:  19.4m km

Missile to hit chances are vs targets moving at 3000 km/s, 5000 km/s and 10,000 km/s

This design is classed as a Military Vessel for maintenance purposes
 

Offline Demonius

  • Warrant Officer, Class 1
  • *****
  • Posts: 83
  • Thanked: 25 times
Re: v1.9.2 Bugs Thread
« Reply #17 on: April 30, 2020, 02:46:45 AM »
Quote from: Waldschrat link=topic=11159.   msg129286#msg129286 date=1588202959
I have the same issues with troop transports.     
I'm using a fleet of 5 transport ships with 15,000 carrying capacity each to transport units with size of 15,000 per unit.       First i tried to specify 5 of these units to be loaded which gave the errors (not for the first transport ship though) and only one was picked up, then i tried only loading one unit which gave the same error messages but again not for the first transport ship and the unit got picked up, then i detached one transport ship and loaded one unit which gave no error messages and got picked up successfully.     


edit: Version 1.     9.     2 (not a fresh save though but was an issue in 1.     9.     0 as well)
decimal seperator: .   

Sounds to me like its loading the first unit into the first ship, then since there is room left in the first ship it tries to put the next unit in there too, but errors out cause there is not enough room

But it also creates a "pickup failed" message  - and then still loads the unit - when loading a single 937 ton test unit, which is below the 1000 tons of a single Standard troop Transport module. (of which my design has 10)
I mean, the functionality itself does net seem to be imparied but the creation of the error message is faulty.
 

Offline UberWaffe

  • Chief Petty Officer
  • ***
  • U
  • Posts: 40
  • Thanked: 22 times
Re: v1.9.2 Bugs Thread
« Reply #18 on: April 30, 2020, 03:08:36 AM »
...

But it also creates a "pickup failed" message  - and then still loads the unit - when loading a single 937 ton test unit, which is below the 1000 tons of a single Standard troop Transport module. (of which my design has 10)
I mean, the functionality itself does net seem to be imparied but the creation of the error message is faulty.

It happens for me if I have multiple troop transports in the fleet.

In my case, I have 4 troop transports with 10 000t capacity each.
I tell the fleet to load a GU of total size 9980t.
The GU gets loaded in the first ship without problem.
Three of the ships complain they do not have capacity. <--- I think the error is caused by them not being able to find the GU to load, and then the calculation mucks up.
 

Offline mike2R

  • Lieutenant
  • *******
  • m
  • Posts: 180
  • Thanked: 117 times
Re: v1.9.2 Bugs Thread
« Reply #19 on: April 30, 2020, 03:09:52 AM »
Quote from: Steve Walmsley
Quote from: Steve UberWaffe
Sidenote:
I haven't worked with C# forms in ages, but it should be possible to force the language / culture info for your game globally.
It should overwrite system settings, at least for output to UI. (Input to UI still depends on the user using the correct character.)

Code: [Select]
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("en-GB");
From this thread:
https://stackoverflow.com/questions/3135569/how-to-change-symbol-for-decimal-point-in-double-tostring
That is true. But even if I force the game to use periods, it still doesn't stop someone typing in commas :)

At some point I will write code to route every player interaction through a single function that checks all of the formatting in and out, which will include forcing the separator. Until then (which depends on my enthusiasm for a grind task), the safest option is to use the period separator.

Just replying to a comment you made on the 1.9.1 Bugs thread. 

I don't think that is really a problem - people will be used to using '.' as the decimal separator in other unlocalised apps, especially in English.  And if they do use a comma, they'll get an error immediately - as soon as you feed their input into double.TryParse or whatever.  This approach would front-load the error to where it can be dealt with at the point where it was made, and stop it propagating through to appear later in more subtle ways. 

And save you from spending your time playing whack-a-mole with localisation errors :)

Edit: Well crap, double.TryParse just ignores a comma, unless you pass it NumberStyles.Float as an argument.  That's annoying.
« Last Edit: April 30, 2020, 05:12:46 AM by mike2R »
 

Offline unkfester

  • Silver Supporter
  • Warrant Officer, Class 1
  • *****
  • Posts: 79
  • Thanked: 1 times
  • Discord Username: unkfester
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2023 Supporter 2023 Supporter : Donate for 2023
    2024 Supporter 2024 Supporter : Donate for 2024
Re: v1.9.2 Bugs Thread
« Reply #20 on: April 30, 2020, 03:27:51 AM »
Since v1.9.0 I am getting "Error #1617 object not set to an instance of an object" every time I load/start game. It started on v1.9.0 and I got same in v1.9.2 here is screen shot. and DBs, (DB copy is V1.90) second is V1.9.2   Game plays okay after I press okay and have found no issues yet.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11680
  • Thanked: 20475 times
Re: v1.9.2 Bugs Thread
« Reply #21 on: April 30, 2020, 04:59:41 AM »
Water vapor is a potent greenhouse gas. Look it up. But in the game it is treated like a "normal" gas.

Yes, I know. Working as intended though so it doesn't complicate the evaporation and condensation cycle. Gameplay > Realism in this case.
 
The following users thanked this post: BAGrimm, UberWaffe, skoormit

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11680
  • Thanked: 20475 times
Re: v1.9.2 Bugs Thread
« Reply #22 on: April 30, 2020, 05:04:05 AM »
I have accidentally reproduced a bug reported by smoelf in the 1. 9. 0 thread hxxp: aurora2. pentarch. org/index. php?topic=11135. msg129111#msg129111.  From your reply I conclude that it isn't solved.  Maybe this helps to sort it out.

1. 9 conventional start/upgraded to 1. 9. 2 some way in.  Designed a ground unit, clicked Create.  Then, I realized that a thing with the boastful title "Tank Destroyer" should have stronger armour.  So, I deleted the unresearched tech in the planetary Economics/Research tab.  Designed a new unit with the right armour, and with the same name as the original.  Researched it.  After that, I suddenly had two units with the same name.  For a second I thought that I had accidentally designed and researched the same thing twice; but they are two different units with different armour, and I verified in the event log  that I only researched it once.  I can rename them separately without trouble, but when I obsolete one, it automatically obsoletes the other.  I looked it up in the db's GroundUnitClass table: Two different GroundUnitClassIDs, but identical TechSystemID as in the original report.

Of course, I don't really know what's involved here; but from the behaviour, I'd guess that the Delete Tech for race-designed tech does not work properly.

Thanks for the detailed description. I suspect what happened is that after you deleted the first tech, the game used the same (now available) ID for the second tech and both units ended up linked to it.

I probably need to change delete tech so it removes any associated missiles, components and ground units (with a suitable warning).
 

Offline zatomic

  • Petty Officer
  • **
  • z
  • Posts: 27
  • Thanked: 11 times
Re: v1.9.2 Bugs Thread
« Reply #23 on: April 30, 2020, 05:04:55 AM »
No event is generated when alien ruins are found by a geo-survey missile.

I noticed it in a conventional start and re-tested in a TN start. I was using a missile with a geo-survey buoy second stage. It detects minerals and generates events for minerals found without a problem. Finding ruins does not generate an event (whether or not there are minerals along with it). The ruins are detected and become visible in the system view once the survey is complete. It's only the event that appears to be missing.

Tested in 1.9.2 on a fresh game
Decimal separator is '.'
Easy to reproduce
 

Offline noodles590

  • Able Ordinary Rate
  • n
  • Posts: 3
  • Thanked: 2 times
Re: v1.9.2 Bugs Thread
« Reply #24 on: April 30, 2020, 05:06:15 AM »
Version :1. 9. 2
TN Start
Real Stars
Decimal as separator
30 years into game

When creating an engine.  I dropped the Thermal Reduction to Signature 50% Normal.  As soon as that was selected I received a Function #2617:Object reference not set to an instance of an object.

I'm unable to switch it back or change any other setting within that window.  It's not even letting me close the Create Research Project window.  Every click within the window get's the same error. 

I can still open other windows and advance through time.  Seems localised to the create research window.

I closed the game and reopened.  It didn't seem to do it once I reloaded so not sure if a bug or just something on my end.  I will update if I see it again.
 

Offline Zhatelier

  • Chief Petty Officer
  • ***
  • Posts: 46
  • Thanked: 19 times
Re: v1.9.2 Bugs Thread
« Reply #25 on: April 30, 2020, 05:19:40 AM »
The communication bug still persists.
I started a fresh game in 1.9.2 to test if it's still there.
Mostly the regular starting settings aside from no NPRs ('.', Real Stars). I Had one race at Earth and made a second player race at Mars (with an additional colony on Mercury for testing trade once more).
I start passing time and the races try to establish communications as per usual. After a little while, the race on Earth establishes communications with Mars, while the Mars race starts getting a "Communication attempts with the Sol Aliens #191 are stalled as they are refusing to exchange information." from that construction cycle onwards. (pic attached)

I suspect this is merely an oversight of the conditions for establishing communications where established communications no longer fulfil the conditions for the second race to establish communications on their end. Alternative fix, once one side essentially translates the counterpart's language, it could establish communications for both simultaneously.
« Last Edit: April 30, 2020, 05:21:49 AM by Zhatelier »
 

Offline Eretzu

  • Warrant Officer, Class 2
  • ****
  • E
  • Posts: 52
  • Thanked: 22 times
Re: v1.9.2 Bugs Thread
« Reply #26 on: April 30, 2020, 05:19:55 AM »
Conversion halted, Situation when conventional industry runs out does not interrupt.

This means that you can end up running a while with industry doing nothing.
 

Offline Noriad

  • Petty Officer
  • **
  • N
  • Posts: 23
  • Thanked: 8 times
Re: v1.9.2 Bugs Thread
« Reply #27 on: April 30, 2020, 05:23:18 AM »
Water vapor is a potent greenhouse gas. Look it up. But in the game it is treated like a "normal" gas.

Yes, I know. Working as intended though so it doesn't complicate the evaporation and condensation cycle. Gameplay > Realism in this case.

You say it like complications are a bad thing :-(  Where's the "fun" (Dwarf Fortress reference) in that?

https://dwarffortresswiki.org/index.php?title=DF2014:Fun&redirect=no
« Last Edit: April 30, 2020, 05:35:18 AM by Noriad »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11680
  • Thanked: 20475 times
Re: v1.9.2 Bugs Thread
« Reply #28 on: April 30, 2020, 05:49:02 AM »
Since v1.9.0 I am getting "Error #1617 object not set to an instance of an object" every time I load/start game. It started on v1.9.0 and I got same in v1.9.2 here is screen shot. and DBs, (DB copy is V1.90) second is V1.9.2   Game plays okay after I press okay and have found no issues yet.

#1617 just converts a number into a string. What is your decimal separator?
 

Offline Second Foundationer

  • Warrant Officer, Class 1
  • *****
  • Posts: 94
  • Thanked: 34 times
Re: v1.9.2 Bugs Thread
« Reply #29 on: April 30, 2020, 05:56:59 AM »
Quote from: Steve Walmsley link=topic=11159.   msg129338#msg129338 date=1588241045
Quote from: Second Foundationer link=topic=11159.   msg129301#msg129301 date=1588213169
I have accidentally reproduced a bug reported by smoelf in the 1.    9.    0 thread hxxp: aurora2.    pentarch.    org/index.    php?topic=11135.    msg129111#msg129111.     From your reply I conclude that it isn't solved.     Maybe this helps to sort it out.   

1.    9 conventional start/upgraded to 1.    9.    2 some way in.     Designed a ground unit, clicked Create.     Then, I realized that a thing with the boastful title "Tank Destroyer" should have stronger armour.     So, I deleted the unresearched tech in the planetary Economics/Research tab.     Designed a new unit with the right armour, and with the same name as the original.     Researched it.     After that, I suddenly had two units with the same name.     For a second I thought that I had accidentally designed and researched the same thing twice; but they are two different units with different armour, and I verified in the event log  that I only researched it once.     I can rename them separately without trouble, but when I obsolete one, it automatically obsoletes the other.     I looked it up in the db's GroundUnitClass table: Two different GroundUnitClassIDs, but identical TechSystemID as in the original report.   

Of course, I don't really know what's involved here; but from the behaviour, I'd guess that the Delete Tech for race-designed tech does not work properly.   

Thanks for the detailed description.    I suspect what happened is that after you deleted the first tech, the game used the same (now available) ID for the second tech and both units ended up linked to it.   

I probably need to change delete tech so it removes any associated missiles, components and ground units (with a suitable warning).   

Thank you.    But I'm very sorry, I may have inadvertently pointed you along the garden path with my report, it was rather late, forgive me.    Because: I made a few very quick, non-exhaustive tests right now (Design/delete/redesign/research); and I cannot reproduce it at all.    There may be something else involved in addition, or entirely separately.    Would be worth knowing if smoelf or anyone else who might have experienced the issue ever touched the Delete Tech button.   

PS edit: I did reproduce it, after all, at least partly, the duplicate units didn't reproduce at first sight; but the duplicate IDs did.   I'll try to attach the db here (don't know if that works post post), the test units are named Bug Bucket [number].

PPS edit (out of time for now): Upon quit/reload, the duplicates do show and show the "obsoleting twins" behaviour.  So, my original post was alright then.  In haste, I may just have forgotten to refresh the view with my test or there may be a comparatively minor display issue.
« Last Edit: April 30, 2020, 06:53:26 AM by Second Foundationer »