Author Topic: Bug Reports (Version 138 and up)  (Read 44734 times)

0 Members and 1 Guest are viewing this topic.

Offline Kyle (OP)

  • Moderator
  • Captain
  • *****
  • K
  • Posts: 472
  • Thanked: 973 times
  • Quasar4x dev
Re: Bug Reports (Version 138 and up)
« Reply #30 on: August 10, 2021, 04:57:36 AM »
- I seem to have my "Queue" Option locked in the Research Window if I make a prototype component. Easy to test / re-produce, just start a new game, make a prototype, then try to queue up some Research. I have not ruled out that I may have inadvertently disabled them somehow, but I'd figured I'd shout out about it here anyway just in case it is a bug. :)

Fixed for next version


VB6 Parity bug: in VB6, you can make military designs that have no engineering spaces, with all the maintenance problems that comes with (particularly vital to designing short combat fighters). In Quasar presently, the "Freighters require at least one Engineering Spaces module" design error blocks you even if you're making a military design, or a fighter.

As in VB6 you have to add at least one military component for the design error to go away


VB6 Parity bug: The cost of fire control (and maybe active sensors?) seems to deviate very hard from how VB6 does it. One very intense example is CIWS, where I have an identical system costing three times as much in quasar as it does in VB6, with all of that new cost being uridium.

The Uridium cost on CIWS (and total costs) have been fixed for next version. 

Note that there is still a difference that I am keeping: In VB6, your choice for Turret Rotation Gear rating is ignored and has no effect on the stats of the CIWS.  Calculations are done as if you picked your best possible gear tech.  In Q4X you can design CIWS with a lower rotation gear tech if you want, even though it just makes the component more expensive with no benefit.

Beam Fire Control costs in Q4X are a third of what they are in VB6 7.1.  This was a change Steve had planned for 7.2.


Actual bona-fide bug: Missile warheads cost nothing when allocated in values less than 0.5 MSP. This makes small-warhead missiles extremely brokenly cheap to manufacture. There may be additional rounding-style errors somewhere in there too.

Fixed for next version


Ships in orbit cannot fire their energy weapons due to atmosphere as if they were PDCs. I'm not sure if this is about whether the ship firing or the target ship as I just created two fleets in orbit of Earth and tried to have them fire at each other.

Fixed for next version


Atmospheric retention is still wonky at least for the moons (didn't check the dwarf planets). There is no screenshot due to gravity/planet type and greenhouse factor being too far away from each other to fit on a screen.

You can select a cell in the F9 window and use the arrows in the bottom left to move the selected column :)


Planets with too low gravity cannot retain atmosphere which is represented by having a greenhouse factor set permanently to 0 (at least in Quasar, don't know about Aurora). The way it works in Aurora the game checks for gravity, if ti's less than 0.1 it cannot have an atmosphere. Quasar however seems to check for body type, at least in the case of the moons. Those are some of the moons that have been generated in one of the systems:
Large moon, gravity 0.11, greenhouse factor=0
Small terrestrial moon, gravity 0.086, greenhouse factor=1
Small terrestrial moon, gravity 0.16, greenhouse factor=1
Large moon, gravity 0.15, greenhouse factor=0
Overall it seems that rather than checking for gravity, Quasar simply gives greenhouse factor=0 for any moon that isn't classified as small terrestrial or terrestrial irrespective of the actual gravity.
Thank you for your time.

In order to make system generation as faithful to VB6 as possible I generated over 3700 systems in VB6 and compared the results to a similarly sized batch of systems generated by Q4X.  I haven't seen any evidence that 0.1 gravity plays such a role.  VB6 seems to check first and foremost what the body type is.

Below is the distribution of atmospheric pressure and greenhouse factor by body type in my sample from Aurora VB6.  Note that this comes from a 1-to-1 export from mdb to sqlite so I can run queries on it.  The Body Types are:  1 = Asteroid, 2 = Terrestrial Planet, 3 = Dwarf, 4 = Gas, 5 = Jovian, 7 = Small Moon, 8 = Moon, 9 = Large Moon, 10 = Small Terrestrial Moon, 11 = Terrestrial Moon, 14 = Comet.  Also note that each row is showing statistics for all gravities, both above and below 0.1




Above is VB6. Here's the same query run against a batch of 3700 systems I generated in Quasar4x just now:




So I believe Q4X is correct in this area, as far as mirroring how A4X behaves anyway.

--

Thanks for the reports!  I'll be doing some final testing then releasing the next version with the fixes this evening.
« Last Edit: August 10, 2021, 05:00:37 AM by Kyle »
 
The following users thanked this post: iceball3

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: Bug Reports (Version 138 and up)
« Reply #31 on: August 10, 2021, 05:27:02 AM »
Planets with too low gravity cannot retain atmosphere which is represented by having a greenhouse factor set permanently to 0 (at least in Quasar, don't know about Aurora). The way it works in Aurora the game checks for gravity, if ti's less than 0.1 it cannot have an atmosphere. Quasar however seems to check for body type, at least in the case of the moons. Those are some of the moons that have been generated in one of the systems:
Large moon, gravity 0.11, greenhouse factor=0
Small terrestrial moon, gravity 0.086, greenhouse factor=1
Small terrestrial moon, gravity 0.16, greenhouse factor=1
Large moon, gravity 0.15, greenhouse factor=0
Overall it seems that rather than checking for gravity, Quasar simply gives greenhouse factor=0 for any moon that isn't classified as small terrestrial or terrestrial irrespective of the actual gravity.
Thank you for your time.

In order to make system generation as faithful to VB6 as possible I generated over 3700 systems in VB6 and compared the results to a similarly sized batch of systems generated by Q4X.  I haven't seen any evidence that 0.1 gravity plays such a role.  VB6 seems to check first and foremost what the body type is.

Below is the distribution of atmospheric pressure and greenhouse factor by body type in my sample from Aurora VB6.  Note that this comes from a 1-to-1 export from mdb to sqlite so I can run queries on it.  The Body Types are:  1 = Asteroid, 2 = Terrestrial Planet, 3 = Dwarf, 4 = Gas, 5 = Jovian, 7 = Small Moon, 8 = Moon, 9 = Large Moon, 10 = Small Terrestrial Moon, 11 = Terrestrial Moon, 14 = Comet.  Also note that each row is showing statistics for all gravities, both above and below 0.1



Above is VB6. Here's the same query run against a batch of 3700 systems I generated in Quasar4x just now:


So I believe Q4X is correct in this area, as far as mirroring how A4X behaves anyway.

--

Thanks for the reports!  I'll be doing some final testing then releasing the next version with the fixes this evening.
There might be something funky with how VB6 determines greenhouse factor. I'm checking VB6 Sol right now and there's a significant collection of small moons that have a GH factor of 1, alongside the ones that have zero. For example, Adrastea.

This could be Sol having some funky mechanics though.
Now that I actually check a freshly generated system, I'm almost certain it's sol having it's values a bit messed up.
 

Offline Kyle (OP)

  • Moderator
  • Captain
  • *****
  • K
  • Posts: 472
  • Thanked: 973 times
  • Quasar4x dev
Re: Bug Reports (Version 138 and up)
« Reply #32 on: August 10, 2021, 12:12:00 PM »
Planets with too low gravity cannot retain atmosphere which is represented by having a greenhouse factor set permanently to 0 (at least in Quasar, don't know about Aurora). The way it works in Aurora the game checks for gravity, if ti's less than 0.1 it cannot have an atmosphere. Quasar however seems to check for body type, at least in the case of the moons. Those are some of the moons that have been generated in one of the systems:
Large moon, gravity 0.11, greenhouse factor=0
Small terrestrial moon, gravity 0.086, greenhouse factor=1
Small terrestrial moon, gravity 0.16, greenhouse factor=1
Large moon, gravity 0.15, greenhouse factor=0
Overall it seems that rather than checking for gravity, Quasar simply gives greenhouse factor=0 for any moon that isn't classified as small terrestrial or terrestrial irrespective of the actual gravity.
Thank you for your time.

In order to make system generation as faithful to VB6 as possible I generated over 3700 systems in VB6 and compared the results to a similarly sized batch of systems generated by Q4X.  I haven't seen any evidence that 0.1 gravity plays such a role.  VB6 seems to check first and foremost what the body type is.

Below is the distribution of atmospheric pressure and greenhouse factor by body type in my sample from Aurora VB6.  Note that this comes from a 1-to-1 export from mdb to sqlite so I can run queries on it.  The Body Types are:  1 = Asteroid, 2 = Terrestrial Planet, 3 = Dwarf, 4 = Gas, 5 = Jovian, 7 = Small Moon, 8 = Moon, 9 = Large Moon, 10 = Small Terrestrial Moon, 11 = Terrestrial Moon, 14 = Comet.  Also note that each row is showing statistics for all gravities, both above and below 0.1



Above is VB6. Here's the same query run against a batch of 3700 systems I generated in Quasar4x just now:


So I believe Q4X is correct in this area, as far as mirroring how A4X behaves anyway.

--

Thanks for the reports!  I'll be doing some final testing then releasing the next version with the fixes this evening.
There might be something funky with how VB6 determines greenhouse factor. I'm checking VB6 Sol right now and there's a significant collection of small moons that have a GH factor of 1, alongside the ones that have zero. For example, Adrastea.

This could be Sol having some funky mechanics though.
Now that I actually check a freshly generated system, I'm almost certain it's sol having it's values a bit messed up.

Yeah I was debating whether to mention Sol.  All the values for Sol are predetermined and stored in a fixed SolSystemBodies table, and do not all adhere to the random sys gen rules.
 

Offline Haji

  • Captain
  • **********
  • Posts: 442
  • Thanked: 53 times
Re: Bug Reports (Version 138 and up)
« Reply #33 on: August 10, 2021, 06:50:16 PM »
So I believe Q4X is correct in this area, as far as mirroring how A4X behaves anyway.

I've done some additional digging and this is gonna be interesting.
Remember the game you converted for me some time back? I had a colony there on a moon and after conversion it had negative population growth and significant infrastructure deficit because in Aurora it had greenhouse factor but it did not have it in quasar. After additional digging I found out that you are correct about Q4x and AVB checking for body type to set up greenhouse factor however AVB had a bug - even though greenhouse factor was set to 0 as soon as you added any atmosphere it was immediately raised to 1.
So here is fun question - if Aurora VB had a bug do you preserve the bug for parity or do you fix it (it's currently fixed)?
 

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: Bug Reports (Version 138 and up)
« Reply #34 on: August 10, 2021, 11:41:50 PM »
So I believe Q4X is correct in this area, as far as mirroring how A4X behaves anyway.

I've done some additional digging and this is gonna be interesting.
Remember the game you converted for me some time back? I had a colony there on a moon and after conversion it had negative population growth and significant infrastructure deficit because in Aurora it had greenhouse factor but it did not have it in quasar. After additional digging I found out that you are correct about Q4x and AVB checking for body type to set up greenhouse factor however AVB had a bug - even though greenhouse factor was set to 0 as soon as you added any atmosphere it was immediately raised to 1.
So here is fun question - if Aurora VB had a bug do you preserve the bug for parity or do you fix it (it's currently fixed)?
Parity need not be completely perfect. At this point it's really just a question of whether atmospheres on small-bodies is a desired outcome and i get the impression that it wasn't, given the desire to put it as a mechanic in the first place. Much I want to turn all asteroids into tiny bubble planets haha
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Bug Reports (Version 138 and up)
« Reply #35 on: August 11, 2021, 06:13:09 AM »
I can't create a new game in V147...



When clicking on "Create Game" nothing happens and no error message appears...
 

Offline Haji

  • Captain
  • **********
  • Posts: 442
  • Thanked: 53 times
Re: Bug Reports (Version 138 and up)
« Reply #36 on: August 11, 2021, 08:10:49 AM »
Parity need not be completely perfect. At this point it's really just a question of whether atmospheres on small-bodies is a desired outcome and i get the impression that it wasn't, given the desire to put it as a mechanic in the first place. Much I want to turn all asteroids into tiny bubble planets haha

For the most part I agree, however here's the thing - the mechanic only stops you from changing the temperature of the planet, it does not stop you from making those bodies habitable if the gravity/temp is right. As such it seems rather pointless to me.
To be honest my biggest peeve is that I misunderstood the mechanic. I have no problem with low gravity bodies not having an atmosphere, but that's not how it works, it just checks for body type, no matter the actual gravity which made me colonize bodies and then be unable to terraform them.
 

Offline Kyle (OP)

  • Moderator
  • Captain
  • *****
  • K
  • Posts: 472
  • Thanked: 973 times
  • Quasar4x dev
Re: Bug Reports (Version 138 and up)
« Reply #37 on: August 11, 2021, 11:41:52 AM »
I can't create a new game in V147...


When clicking on "Create Game" nothing happens and no error message appears...

It just worked for me on version 149 with those exact settings.  Can you try deleting %APPDATA%\Roaming\Godot\app_userdata\Quasar4x\quasar4x.sqlite and running the game again?
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Bug Reports (Version 138 and up)
« Reply #38 on: August 11, 2021, 12:29:24 PM »
It just worked for me on version 149 with those exact settings.  Can you try deleting %APPDATA%\Roaming\Godot\app_userdata\Quasar4x\quasar4x.sqlite and running the game again?
Yes, deleting that file makes it work  :)
 

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: Bug Reports (Version 138 and up)
« Reply #39 on: August 11, 2021, 06:15:47 PM »
Potential parity bug, but more of a question really: does anyone know if steve changed how FTR beam fire control costed with his uridium cost reduction? In VB6 it increased the tracking speed of a fire control without actually increasing the cost, I'm not sure if that changed with the same change that made fire control cheaper overall. Presently in quasar, it increases the cost by the same amount a similar tech-related increase of tracking speed would.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Bug Reports (Version 138 and up)
« Reply #40 on: August 11, 2021, 07:17:38 PM »
When the "Event Updates" is in front and you want to advance time in the "Population and Production" window, the amount of time that is advanced is taken from the last action you took, but not the actual one. I misclicked on the "5 days" button but time was advanced "30 days" - as I had done before that. I then put the focus back to the "Events Update" and clicked on the "30 days" and got a 5 days advance... .

Add On: it looks like that that behavior happens all the time - also when the focus is on the "Population and Production" window.
« Last Edit: August 11, 2021, 07:20:23 PM by TMaekler »
 

Offline Kyle (OP)

  • Moderator
  • Captain
  • *****
  • K
  • Posts: 472
  • Thanked: 973 times
  • Quasar4x dev
Re: Bug Reports (Version 138 and up)
« Reply #41 on: August 12, 2021, 01:14:42 AM »
When the "Event Updates" is in front and you want to advance time in the "Population and Production" window, the amount of time that is advanced is taken from the last action you took, but not the actual one. I misclicked on the "5 days" button but time was advanced "30 days" - as I had done before that. I then put the focus back to the "Events Update" and clicked on the "30 days" and got a 5 days advance... .

Add On: it looks like that that behavior happens all the time - also when the focus is on the "Population and Production" window.

I can't reproduce this.  The Event Updates window scrolls to the bottom every UI update, but maybe it's scrolling wrong for you and it's showing the second-to-last increment at the bottom?  You can verify the correct amount of time is incremented by watching the date change at the top of the Population window
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Bug Reports (Version 138 and up)
« Reply #42 on: August 12, 2021, 07:11:56 AM »
I can't reproduce this.  The Event Updates window scrolls to the bottom every UI update, but maybe it's scrolling wrong for you and it's showing the second-to-last increment at the bottom?  You can verify the correct amount of time is incremented by watching the date change at the top of the Population window
Yeah, I misread the log entries. They represent the LAST cycle. Sorry.
 

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: Bug Reports (Version 138 and up)
« Reply #43 on: August 14, 2021, 01:08:01 AM »
Possible bug: In the system map, Passive Sensor Ranges and Show Signature Detection Range don't update when you change the values, only when you toggle them off and back on again.
A VB6 parity thing, also, is that the Signature Detection Range option doesn't seem to apply to populations.
« Last Edit: August 14, 2021, 01:45:22 AM by iceball3 »
 

Offline Kyle (OP)

  • Moderator
  • Captain
  • *****
  • K
  • Posts: 472
  • Thanked: 973 times
  • Quasar4x dev
Re: Bug Reports (Version 138 and up)
« Reply #44 on: August 14, 2021, 01:52:31 PM »
Possible bug: In the system map, Passive Sensor Ranges and Show Signature Detection Range don't update when you change the values, only when you toggle them off and back on again.
A VB6 parity thing, also, is that the Signature Detection Range option doesn't seem to apply to populations.

Fixed the range updates in the currently released version.

Didn't see the part about populations, I'll take a look
 
The following users thanked this post: iceball3