Author Topic: v2.1.0 Bugs Thread  (Read 14754 times)

0 Members and 1 Guest are viewing this topic.

Offline IanInCanada

  • Able Ordinary Rate
  • I
  • Posts: 1
Re: v2.1.0 Bugs Thread
« Reply #75 on: August 25, 2022, 11:21:25 AM »
Quote from: pwhk link=topic=13050. msg161693#msg161693 date=1661438804
1.  Enable Spacemaster Mode
2.  Show Event Window
3.  Enable "Show All Races" from Event Window
4.  Press Ctrl-F2 to bring up Event Window
5.  Increment time
6.  Unexpected behavior: Events for all other NPRs can be seen, and other NPRs can be selected from the main window dropdown.

I was actually going to report this bug myself.  Spacemaster Mode doesn't need to be enabled to cause this, just steps 2-6 work to reproduce.  I could see an argument for all races being visible from SM mode, but without it, I assume this is unintended.

SJW: The "Show All Races" checkbox is hidden unless you are in SM mode.
« Last Edit: September 04, 2022, 06:16:13 PM by Steve Walmsley »
 

Offline Snoman314

  • Sub-Lieutenant
  • ******
  • Posts: 127
  • Thanked: 39 times
Re: v2.1.0 Bugs Thread
« Reply #76 on: August 25, 2022, 08:09:19 PM »
I've just properly played around with the formations system for the first time, and it's great, except for seeming to be slightly broken.

Basically the 'Recall Escorts' button is not showing up where it should, according to the original post about it.

I've got my scout boats travelling in formation in front of the task force, so they're definitely set correctly. When I have them attached as individual sub-fleets I can hit 'Detach Escorts' and they'll form separate fleets and rush off ahead.

However once they're deployed, the 'Recall Escorts' button is not there, where is says it should be from that forum post above.

Weird thing is, if I click a sub-fleet the Recall button _is_ there (which doesn't make sense: I need to recall to the fleet, not a sub-fleet). In this case the button does nothing though.

SJW: Fixed for v2.1.1
« Last Edit: September 04, 2022, 06:46:20 PM by Steve Walmsley »
 

Offline xenoscepter

  • Vice Admiral
  • **********
  • Posts: 1159
  • Thanked: 320 times
Re: v2.1.0 Bugs Thread
« Reply #77 on: August 26, 2022, 09:39:52 PM »
Potential Description Error:
 --- I thought these were reduced to 50 tons of capacity apiece?



SJW: Text fixed for next database release.
« Last Edit: September 04, 2022, 06:49:18 PM by Steve Walmsley »
 

Online nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 3051
  • Thanked: 2340 times
  • Radioactive frozen beverage.
Re: v2.1.0 Bugs Thread
« Reply #78 on: August 26, 2022, 10:32:43 PM »
Potential Description Error:
 --- I thought these were reduced to 50 tons of capacity apiece?



http://aurora2.pentarch.org/index.php?topic=10638.0
 

Offline Snoman314

  • Sub-Lieutenant
  • ******
  • Posts: 127
  • Thanked: 39 times
Re: v2.1.0 Bugs Thread
« Reply #79 on: August 26, 2022, 11:30:46 PM »
There's a bug in the squadrons feature somewhere, that's deleting my strike craft.

I first noticed when I had a fleet containing a carrier with squadrons all set up, join another fleet as subfleet. At this point, all the strike craft were no longer listed under their squadrons, and instead were sitting in the subfleet structure at the same level as their carrier. Weird.

Dragging them back into their squadrons didn't work, so I deployed one from each squadron, then dragged their squadron-mates across to form the squadrons up as deployed groups. Then I ordered each one to land back on the carrier, to their assigned squadron, or as their assigned squadron. Typically only some of the strike craft would then show up in the squadron aboard the carrier after refreshing the naval view. Weird again.

Now I can drag the strike craft from the deployed fleets back into their squadrons, so I do so. Finally: everything back where it was before I had the carrier join a fleet. Just need to delete the now-empty strikecraft fleets. As soon as I do so, and refresh the view, most or all of the strike craft that used to be in those fleets are deleted as well, even though they were no longer showing as being in those fleet. Bugger.

Sorry this is a bit vague. I feel like there's more than one thing going wrong though, and I can't quite pin it all down. Hopefully the steps above help reproduce the bug.
 

Offline boolybooly

  • Gold Supporter
  • Lieutenant
  • *****
  • Posts: 172
  • Thanked: 87 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
Re: v2.1.0 Bugs Thread
« Reply #80 on: August 27, 2022, 10:29:28 AM »
Not sure if this qualifies as a bug but it seems not the expected outcome so worth mentioning.

If you set an order for a tug to release tractored ships to a fleet which is in orbit, the releasing ship is not in orbit after completing the order.

Screens show the orders given and the result one construction period after completion, where the ship in question is left behind by the movement of the planet.

SJW: Fixed for v2.1.1
« Last Edit: September 04, 2022, 06:55:21 PM by Steve Walmsley »
 

Offline skoormit

  • Rear Admiral
  • **********
  • Posts: 838
  • Thanked: 339 times
Re: v2.1.0 Bugs Thread
« Reply #81 on: August 27, 2022, 11:02:33 AM »
Not sure if this qualifies as a bug but it seems not the expected outcome so worth mentioning.

If you set an order for a tug to release tractored ships to a fleet which is in orbit, the releasing ship is not in orbit after completing the order.

Screens show the orders given and the result one construction period after completion, where the ship in question is left behind by the movement of the planet.

I believe this happens for other (possibly all) orders that target a fleet in orbit of a body.

I also believe it only happens when a construction cycle completes during the same subpulse that the ship completes the order.
 
The following users thanked this post: boolybooly

Offline boolybooly

  • Gold Supporter
  • Lieutenant
  • *****
  • Posts: 172
  • Thanked: 87 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
Re: v2.1.0 Bugs Thread
« Reply #82 on: August 27, 2022, 11:29:49 AM »
Not sure if this qualifies as a bug but it seems not the expected outcome so worth mentioning.

If you set an order for a tug to release tractored ships to a fleet which is in orbit, the releasing ship is not in orbit after completing the order.

Screens show the orders given and the result one construction period after completion, where the ship in question is left behind by the movement of the planet.

I believe this happens for other (possibly all) orders that target a fleet in orbit of a body.

I also believe it only happens when a construction cycle completes during the same subpulse that the ship completes the order.

I see, thanks, that makes sense, worth knowing for replication and workarounds. I am simply putting refuel resupply orders last now.

I felt I should mention that the order completion report discombobulatingly states the fleet ~ "has completed orders. Orbiting Earth" when sometimes it is not.
 

Offline paolot

  • Sub-Lieutenant
  • ******
  • p
  • Posts: 111
  • Thanked: 13 times
Re: v2.1.0 Bugs Thread
« Reply #83 on: August 27, 2022, 05:59:52 PM »
In the System Generation and Display window, if you change star, to one that has no orbiting bodies, apart the jump points, all the other data are not updated and remain the ones of the last body selected.
They change only when new data can overwrite the previous ones.
Is it as intended?

SJW: Fixed for v2.1.1
« Last Edit: September 04, 2022, 07:27:36 PM by Steve Walmsley »
 

Offline Desdinova

  • Lt. Commander
  • ********
  • D
  • Posts: 280
  • Thanked: 282 times
Re: v2.1.0 Bugs Thread
« Reply #84 on: August 27, 2022, 11:46:52 PM »
I've encountered a nasty fatal db error on startup. When I go to open my game, I get:

I get: #1170: Object cannot be cast from DBNull to other types.

And then infinitely:
Function #3040: Object reference not set to an instance of an object.

Until I end task. Db is attached.

SJW: It seems to be caused by records in the FCT_SystemBody table that have null values in the MeanOrbitalSpeed table. I've added code to handle the problem, although I don't know what caused it.
« Last Edit: September 04, 2022, 07:04:28 PM by Steve Walmsley »
 

Offline dsedrez

  • Warrant Officer, Class 2
  • ****
  • d
  • Posts: 64
  • Thanked: 16 times
Re: v2.1.0 Bugs Thread
« Reply #85 on: August 28, 2022, 10:38:07 AM »
Spoiler race starting tech points do not seem to conform to rule

I wanted to start a new game with the unmodded DB and mostly default settings to test some things, with three NPRs, and I was annoyed by how few points my player race was getting, so I gave it 2 million points for a quick start. Then I used the bug to check non-player races, and saw that the NPRs, including spoilers, have *not* increased their starting RP points according to the rule in http://aurora2.pentarch.org/index.php?topic=12523.msg154574#msg154574 . It's very easy to check by starting a new game giving a lot of RPs to the player race, using the bug to see NPRs and looking at their starting ship designs. I don't think this is WAI, since giving enough RPs on start to the player race, its designs can easily outtech even the Invaders if they don't change accordingly.

I created a couple other test games, varying research speed, starting player race population and/or starting RP points, and I haven't yet noticed any change in the starting NPR/spoiler races tech levels. I've even used a SQL query to count the RPs used by the starting techs for all races, and they don't seem to change significantly between games:

-- Calculate how many research points a race has spent in tech already
Select FCT_RaceTech.GameID, RaceName, FCT_RaceTech.RaceID, SUM(DevelopCost)
   from FCT_RaceTech, FCT_TechSystem, FCT_Race
   where FCT_RaceTech.TechID = FCT_TechSystem.TechSystemID
   and FCT_RaceTech.RaceID = FCT_Race.RaceID
   GROUP BY FCT_RaceTech.RaceID;


It's possible I haven't triggered yet whatever it is that changes the starting RPs for the NPRs. It's also very strange how few points the player race is getting at start, which doesn't seem to change with research speed, only with starting population.

[EDIT] The maximum RPs a player race is getting is the same as in the previous version. And the starting RP points of the NPR/spoiler races (upon start) also don't seem to scale with the starting RP points of the player race in v.1.13. I don't know if later the rule is being followed, when finally meeting the spoiler races or creating new NPRs by stumbling upon them, in the new version.

SJW: Fixed for v2.1.1. Although I would add that 2m points to start is a huge amount for a player race and you will probably miss out on a lot of the game.
« Last Edit: September 05, 2022, 05:54:22 AM by Steve Walmsley »
 

Online nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 3051
  • Thanked: 2340 times
  • Radioactive frozen beverage.
Re: v2.1.0 Bugs Thread
« Reply #86 on: August 28, 2022, 11:15:21 AM »
Spoiler race starting tech points do not seem to conform to rule

I wanted to start a new game with the unmodded DB and mostly default settings to test some things, with three NPRs, and I was annoyed by how few points my player race was getting, so I gave it 2 million points for a quick start. Then I used the bug to check non-player races, and saw that the NPRs, including spoilers, have *not* increased their starting RP points according to the rule in http://aurora2.pentarch.org/index.php?topic=12523.msg154574#msg154574 . It's very easy to check by starting a new game giving a lot of RPs to the player race, using the bug to see NPRs and looking at their starting ship designs. I don't think this is WAI, since giving enough RPs on start to the player race, its designs can easily outtech even the Invaders if they don't change accordingly.

I created a couple other test games, varying research speed, starting player race population and/or starting RP points, and I haven't yet noticed any change in the starting NPR/spoiler races tech levels. I've even used a SQL query to count the RPs used by the starting techs for all races, and they don't seem to change significantly between games:

-- Calculate how many research points a race has spent in tech already
Select FCT_RaceTech.GameID, RaceName, FCT_RaceTech.RaceID, SUM(DevelopCost)
   from FCT_RaceTech, FCT_TechSystem, FCT_Race
   where FCT_RaceTech.TechID = FCT_TechSystem.TechSystemID
   and FCT_RaceTech.RaceID = FCT_Race.RaceID
   GROUP BY FCT_RaceTech.RaceID;


It's possible I haven't triggered yet whatever it is that changes the starting RPs for the NPRs. It's also very strange how few points the player race is getting at start, which doesn't seem to change with research speed, only with starting population.

[EDIT] The maximum RPs a player race is getting is the same as in the previous version. And the starting RP points of the NPR/spoiler races (upon start) also don't seem to scale with the starting RP points of the player race in v.1.13. I don't know if later the rule is being followed, when finally meeting the spoiler races or creating new NPRs by stumbling upon them, in the new version.

NPRs do not follow the same RP rules as player races, because they do not research individual systems like a player race does. Rather once they have accumulated enough RPs they will develop a tech level and a set of components at that tech level. Because of this, you can't really see the NPR RPs in the DB as they are used instantly on race generation to set the initial tech level. As such, NPR and player race RPs do not directly relate with each other. The same is true for BPs, incidentally, NPRs start with fleets very much in excess of what a player can build on default settings, this is also by design to make the NPRs competitive as they frankly are abhorrent at tactics and need the weight of numbers to pose any threat at all.

There should however be a change in place so that NPRs with over 1.25b starting population will be able to start with more than 50 labs, which directly affects the future RP generation.

Basically if you want a balanced game, don't give the player race 2m RPs unless you are prepared to develop a workaround (e.g., run the game for a few decades with a hands-off player race to let the NPRs grow).
 

Offline dsedrez

  • Warrant Officer, Class 2
  • ****
  • d
  • Posts: 64
  • Thanked: 16 times
Re: v2.1.0 Bugs Thread
« Reply #87 on: August 28, 2022, 11:48:43 AM »
NPRs do not follow the same RP rules as player races, because they do not research individual systems like a player race does. Rather once they have accumulated enough RPs they will develop a tech level and a set of components at that tech level. Because of this, you can't really see the NPR RPs in the DB as they are used instantly on race generation to set the initial tech level. As such, NPR and player race RPs do not directly relate with each other. The same is true for BPs, incidentally, NPRs start with fleets very much in excess of what a player can build on default settings, this is also by design to make the NPRs competitive as they frankly are abhorrent at tactics and need the weight of numbers to pose any threat at all.

There should however be a change in place so that NPRs with over 1.25b starting population will be able to start with more than 50 labs, which directly affects the future RP generation.

Basically if you want a balanced game, don't give the player race 2m RPs unless you are prepared to develop a workaround (e.g., run the game for a few decades with a hands-off player race to let the NPRs grow).

I understand that, but then the rule as stated is confusing, because it doesn't refer to RP progress during game, but to starting RPs. The Precursor/Invader/Raider designs are created upon start, regardless of the player race's population, number of labs or RPs, or the game's research speed. I don't know when/if they're updated during game. Maybe they are, but then why does the rule mention their starting RPs and any proportion to player races' RPs? Swarm and Rakhas seem to be spawned during game, just as any newly created NPRs, so maybe the rule does apply to them.

I'm starting a new v.2.1 game with basic settings, where I hope to meet all the spoilers and test this.

 

Online nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 3051
  • Thanked: 2340 times
  • Radioactive frozen beverage.
Re: v2.1.0 Bugs Thread
« Reply #88 on: August 28, 2022, 12:14:58 PM »
I understand that, but then the rule as stated is confusing, because it doesn't refer to RP progress during game, but to starting RPs. The Precursor/Invader/Raider designs are created upon start, regardless of the player race's population, number of labs or RPs, or the game's research speed. I don't know when/if they're updated during game. Maybe they are, but then why does the rule mention their starting RPs and any proportion to player races' RPs? Swarm and Rakhas seem to be spawned during game, just as any newly created NPRs, so maybe the rule does apply to them.

That rules does not apply to the player's starting RPs but the difficulty modifier, specifically if it is less than 100% in which case the NPR and spoiler starting tech levels are reduced (but not below the stated minima for spoilers).
 
The following users thanked this post: dsedrez

Offline bankshot

  • Lieutenant
  • *******
  • b
  • Posts: 194
  • Thanked: 48 times
Re: v2.1.0 Bugs Thread
« Reply #89 on: August 28, 2022, 02:01:11 PM »
I found a minor bug in min/max colony cost calculation.  If you have a terraforming fleet in orbit removing greenhouse gas (which lowers the temperature) it looks like the maximum temperature and associated perihelion colony cost is updated prior to the effects of terraforming which set the current temperature.  I've attached a game where the current temp/CC is higher than the maximum temp/CC.

I've included a screenshot highlighting the error on the economics/environment screen along with the db.   

SJW: Fixed for v2.1.1. The max was being calculated during orbital movement, which is before terraforming. I have added the max check to terraforming as well.
« Last Edit: September 05, 2022, 06:21:48 AM by Steve Walmsley »