Author Topic: v1.12.0 Bugs Thread  (Read 69372 times)

0 Members and 1 Guest are viewing this topic.

Offline Demetrious

  • Warrant Officer, Class 2
  • ****
  • D
  • Posts: 65
  • Thanked: 40 times
Re: v1.12.0 Bugs Thread
« Reply #105 on: October 25, 2020, 03:43:15 PM »
Quote from: Droll link=topic=11945.  msg142262#msg142262 date=1603652554
That answers capital to ground but I'm asking the reverse.  In my case it seems like precursor AA Decurions can one shot (or two shot) fighters with 4 layers of armor

I'd assume that you can just invert that equation to translate ground weapons to capital scale.  It'd be nice to have a firmer grasp on it though, because as you note spoilers tend to be very shooty and accounting for tech disparities like that is hard to do without a better idea of how their known capital weaponry translates to ground capability. 
 

Offline jtgasv

  • Leading Rate
  • *
  • j
  • Posts: 14
  • Thanked: 5 times
Re: v1.12.0 Bugs Thread
« Reply #106 on: October 27, 2020, 12:15:17 PM »
conventional start, real stars, 200+yrs

orbital habitats allow population to exceed the orbital/planetary population cap
occurring on both luna and mars.

for some reason I was unable to post when attaching the database file.
 

Offline bankshot

  • Lieutenant
  • *******
  • b
  • Posts: 191
  • Thanked: 48 times
Re: v1.12.0 Bugs Thread
« Reply #107 on: October 27, 2020, 02:27:42 PM »
Civilian Fuel harvesters do not respect planetary bans

TN start, civilian fuel harvesters checked.  My geosurvey found sorium in Jupiter (5M, .6 acc), Saturn (4M, .8 acc), and Minerva (150K, .7 acc).   I banned Saturn to reserve it for my own harvesters, but left Jupiter and Minerva open for civilian harvesting.  I selected "no" to ban the moons, and Saturn is now listed as Saturn(B) confirming the ban was applied. 

The first civilian harvester was created 5 years later, and moved to Saturn.

SJW: Fixed
« Last Edit: November 28, 2020, 12:38:32 PM by Steve Walmsley »
 

Offline Froggiest1982

  • Gold Supporter
  • Vice Admiral
  • *****
  • F
  • Posts: 1335
  • Thanked: 592 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: v1.12.0 Bugs Thread
« Reply #108 on: October 27, 2020, 05:08:59 PM »
I am quite sure ice used to melt at -17 degrees celsius however in this game I am playing now, the ice on Mars melt at -27.9???

Bug?

Any feedback?

EDIT: The wiki mentions -18 Celsius, still far away from -28... http://aurorawiki.pentarch.org/index.php?title=Terraforming

EDIT 2: As a result, even the Water Vapour is different due to different pressure. It used to be 0.0003 but now it's 0.0002.

SJW: It's always been -28C. That is on the low side compared to reality though.
« Last Edit: November 28, 2020, 11:56:52 AM by Steve Walmsley »
 

Offline jtgasv

  • Leading Rate
  • *
  • j
  • Posts: 14
  • Thanked: 5 times
Re: v1.12.0 Bugs Thread
« Reply #109 on: October 28, 2020, 02:05:58 AM »
conventional start, real stars, 200+ yrs.
reproducible in a fresh game with both real and non-real stars.

deep space tracking ranges seem to "wrap around" where the 10,000 range resets to a smaller value,  then the 1,000.  then the 10,000.  etc, as the number of stations, or tech levels grow.  sometimes the 10,000 range disappears entirely. im not sure if its a display issue on the system map or a range limit.

reproduceable by sm mode.  give yourself a high planetary sensor strength tech (2000 was my test). 
turn on passive vs signature 1,000 and 10,000.
then add deep space tracking centers a few at a time.

seems to happen around 11-12m km range

SJW: Fixed
« Last Edit: November 29, 2020, 07:00:30 AM by Steve Walmsley »
 

Offline Ektor

  • Lieutenant
  • *******
  • E
  • Posts: 191
  • Thanked: 103 times
Re: v1.12.0 Bugs Thread
« Reply #110 on: October 28, 2020, 11:56:22 AM »
I'm not sure whether this was already posted, but the conditional order "Refuel, Resupply and Overhaul at Colony" gives off errors #722 and #730 "Object reference was not set to instance of an object" when the conditions trigger. This leads the fleet that takes the order to return to a colony and overhaul, however they don't refuel and resupply.

The specific situation if you want to replicate the bug is the following: I had a jump capable survey ship with both geo and grav modules set on the following standing orders: 1. Survey next system body 2. Survey next survey location 3. If fuel less than 40% - Refuel at colony or hub (all) 4. When deployment time exceeded - Refuel, Resupply and Overhaul at Colony.
« Last Edit: October 28, 2020, 12:05:28 PM by Ektor »
 

Offline TheTalkingMeowth

  • Captain
  • **********
  • T
  • Posts: 494
  • Thanked: 203 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.12.0 Bugs Thread
« Reply #111 on: October 28, 2020, 12:43:45 PM »
I'm not sure whether this was already posted, but the conditional order "Refuel, Resupply and Overhaul at Colony" gives off errors #722 and #730 "Object reference was not set to instance of an object" when the conditions trigger. This leads the fleet that takes the order to return to a colony and overhaul, however they don't refuel and resupply.

The specific situation if you want to replicate the bug is the following: I had a jump capable survey ship with both geo and grav modules set on the following standing orders: 1. Survey next system body 2. Survey next survey location 3. If fuel less than 40% - Refuel at colony or hub (all) 4. When deployment time exceeded - Refuel, Resupply and Overhaul at Colony.

It's been posted, but a little extra information would be useful. Can you describe how this interacts with stabilized jump points? We're not sure if it happens if the path back is fully stabilized.
 

Offline Ektor

  • Lieutenant
  • *******
  • E
  • Posts: 191
  • Thanked: 103 times
Re: v1.12.0 Bugs Thread
« Reply #112 on: October 28, 2020, 05:14:19 PM »
It happens regardless of the points being stabilized or not. I've had it happen with both stabilized and unstabilized points.
 

Offline TheTalkingMeowth

  • Captain
  • **********
  • T
  • Posts: 494
  • Thanked: 203 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.12.0 Bugs Thread
« Reply #113 on: October 28, 2020, 05:44:09 PM »
It happens regardless of the points being stabilized or not. I've had it happen with both stabilized and unstabilized points.

Has the path back been fully stabilized? I've never seen it happen without at least one unstabilized point in the path.
 

Offline Ektor

  • Lieutenant
  • *******
  • E
  • Posts: 191
  • Thanked: 103 times
Re: v1.12.0 Bugs Thread
« Reply #114 on: October 28, 2020, 06:02:15 PM »
It was only one JP away from said colony, but yeah, the JP was stabilised.
 

Offline jtgasv

  • Leading Rate
  • *
  • j
  • Posts: 14
  • Thanked: 5 times
Re: v1.12.0 Bugs Thread
« Reply #115 on: October 28, 2020, 11:22:59 PM »
conventional start, real stars, 200+ yrs.
reproducible in a fresh game with both real and non-real stars.

deep space tracking ranges seem to "wrap around" where the 10,000 range resets to a smaller value,  then the 1,000.  then the 10,000.  etc, as the number of stations, or tech levels grow.  sometimes the 10,000 range disappears entirely. im not sure if its a display issue on the system map or a range limit.

reproduceable by sm mode.  give yourself a high planetary sensor strength tech (2000 was my test). 
turn on passive vs signature 1,000 and 10,000.
then add deep space tracking centers a few at a time.

seems to happen around 11-12m km range

first occurs at 215,000 tracking station strength ~11.58m range
and again at 644,000
and 1,074,600
and 1,503,000

etc etc at ~430,000x+215,000 tracking strength.  each time the passive vs signature 10,000 range resets.


« Last Edit: October 28, 2020, 11:25:41 PM by jtgasv »
 

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 641
  • Thanked: 200 times
Re: v1.12.0 Bugs Thread
« Reply #116 on: October 29, 2020, 11:41:25 AM »
conventional start, real stars, 200+ yrs.
reproducible in a fresh game with both real and non-real stars.

deep space tracking ranges seem to "wrap around" where the 10,000 range resets to a smaller value,  then the 1,000.  then the 10,000.  etc, as the number of stations, or tech levels grow.  sometimes the 10,000 range disappears entirely. im not sure if its a display issue on the system map or a range limit.

reproduceable by sm mode.  give yourself a high planetary sensor strength tech (2000 was my test). 
turn on passive vs signature 1,000 and 10,000.
then add deep space tracking centers a few at a time.

seems to happen around 11-12m km range

first occurs at 215,000 tracking station strength ~11.58m range
and again at 644,000
and 1,074,600
and 1,503,000

etc etc at ~430,000x+215,000 tracking strength.  each time the passive vs signature 10,000 range resets.

That's clearly integer overflow. With the new passive sensor model, the formula for the range is Detection Range = SQRT(Passive Sensor Strength * Target Signature ) * 250,000 km.

215,000 * 10,000 > 2^31-1, so it doesn't fit into a signed 32-bit integer. Using an unsigned 32-bit integer would delay the overflow until the sensor strength was 430,000. At the highest tech level, the range wraps around after 57 deep space tracking stations. This gives a maximum tracking range of 11.58 bkm, or 77.4 au.

Using an unsigned 64-bit number instead would delay the inevitable until the sensor strength was 1.844×10¹?, which is a pretty big number. At the highest possible tech level that will still be more than 491 billion tracking stations. Even then, I would specifically check for overflow so that I could use the maximum usable tracking strength instead of wrapping around. Looks like that would top out at a maximum detection range of 113 light years, which is silly enough that nobody would be bothered that they can't increase it further.

Note that once that bug is fixed, there will be another overflow bug when multiplying by 250,000 km. Might as well fix both at the same time. I don't know C# or .Net very well, but perhaps there are library functions for checked multiplication, or for saturating multiplication. Using them would do most of the work.

Bonus points for actually allowing detection of units in other star systems if the detection range is big enough…
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: v1.12.0 Bugs Thread
« Reply #117 on: October 29, 2020, 01:20:53 PM »
I would specifically check for overflow so that I could use the maximum usable tracking strength instead of wrapping around. Looks like that would top out at a maximum detection range of 113 light years, which is silly enough that nobody would be bothered that they can't increase it further.

Bonus points for actually allowing detection of units in other star systems if the detection range is big enough…

This would be brilliant in the suggestion thread. I think an interesting extension would be to add JP listening which would allow you to use a small % of your sensor sensitivity to "peek" through the other end of a JP.
 

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 641
  • Thanked: 200 times
Re: v1.12.0 Bugs Thread
« Reply #118 on: October 29, 2020, 01:39:43 PM »
I would specifically check for overflow so that I could use the maximum usable tracking strength instead of wrapping around. Looks like that would top out at a maximum detection range of 113 light years, which is silly enough that nobody would be bothered that they can't increase it further.

Bonus points for actually allowing detection of units in other star systems if the detection range is big enough…

This would be brilliant in the suggestion thread. I think an interesting extension would be to add JP listening which would allow you to use a small % of your sensor sensitivity to "peek" through the other end of a JP.

Heh, I was actually being a little bit facetious. At the maximum of 3750 sensor strength per tracking station, it would take 687,842,178 tracking stations to be able to see into the Proxima Centauri system. Good luck mining the 137.6 billion uridium you'll need.

But letting radar go through stable wormholes would be a welcome addition, I think.
 

Offline Ektor

  • Lieutenant
  • *******
  • E
  • Posts: 191
  • Thanked: 103 times
Re: v1.12.0 Bugs Thread
« Reply #119 on: October 29, 2020, 08:51:33 PM »
I've just gotten a weird bug. I was fighting some precursors on a planet, when my HQ got overrun. The game throwed a divide by zero error and my units that were within the formation that got its HQ overran disappeared from the ground forces window. The only way I could retrieve them was to load them up on my transports, after a messy loading process where they had to be loaded more than once, all the while the game threw several errors, they reappeared inside the transports.