Author Topic: v2.1.1 Bugs Thread  (Read 39349 times)

0 Members and 1 Guest are viewing this topic.

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2975
  • Thanked: 2237 times
  • Radioactive frozen beverage.
Re: v2.1.1 Bugs Thread
« Reply #135 on: March 16, 2023, 09:07:58 AM »
There seems to be something wrong with the calculations for fleets meeting up.
To reproduce do the following: Have a fleet(F1) following another fleet(F2) and then you give a 3rd fleet(F3) the order to join F1.

I think the issue is that the speed of F1 in this case is the fleets max speed and not the speed for F2 which it is following. In my case F2 is a lot slower then F1 and F2 and F3 have the same speed.
So it seems like its calculating the meeting point to be somewhere very far ahead.
See attached screenshot for an example.

Edit:
It looks like it sort of fixes itself once F3 gets in front of F1, it will then turn back around to join F1. So its mayube not as big of a problem as I first thought. It just mens the fleet thats trying to join will make a sort of swing around the fleet its joining insted of heading straight for it. and so will use quite a bit more time then it maybe could have.

It's not so much a bug as the calculation is a bit screwy. Basically it only looks at the heading and speed of the destination fleet and computes an intercept based on that - the game doesn't try to follow the rabbit hole of the destination fleet's orders to make a more accurate prediction, which is probably fair as I imagine Steve would tell you this way lies bugs and disappointments as he usually does when the orders list is involved.  ;)
 
The following users thanked this post: punchkid

Offline boolybooly

  • Lieutenant
  • *******
  • Posts: 171
  • Thanked: 87 times
Re: v2.1.1 Bugs Thread
« Reply #136 on: March 17, 2023, 10:21:17 AM »
if you set a waypoint at a planet and launch a probe (i.e. a missile with active sensor operating in flight not a buoy), to the waypoint, the waypoint orbits with the planet and the probe hits, stays with the planet a few days and vanishes as expected

if you delete the waypoint, the probe stops orbiting with the planet and stops dead in space which is unexpected, I would expect it to stay in orbit like buoys

Code: (Example Probe) [Select]
Missile Size: 1 MSP  (2.5 Tons)     Warhead: 0    Radiation Damage: 0    Manoeuvre Rating: 10
Speed: 3,200 km/s     Fuel: 100     Flight Time: 1,305 hours     Range: 15,037.7m km
Active Sensor Strength: 0.29   EM Sensitivity Modifier: 11
Resolution: 10    Maximum Range vs 500 ton object (or larger): 2,170,967 km
Cost Per Missile: 0.484     Development Cost: 110
Chance to Hit: 1k km/s 32.0%   3k km/s 10.7%   5k km/s 6.4%   10k km/s 3.2%
 

Offline LiquidGold2

  • Petty Officer
  • **
  • L
  • Posts: 16
  • Thanked: 9 times
Re: v2.1.1 Bugs Thread
« Reply #137 on: March 17, 2023, 04:39:38 PM »
I started a new 2. 1. 1 game a few days ago with mostly default setting, and so far everything has been normal.  But as I was grav surveying one of the initial Sol-connected systems, I noticed I was seeing 2,3,4 "new jump point" messages in a single time interval.  There were multiple ships working in there though, so I thought nothing of it.  But then it happened again.  And then again.  And again.  I looked closer: single ships were finding multiple JPs at once.
At present, there are 26 unexplored JPs in the Cyclops system.  Of the 30 Survey locations, 18 of them have been surveyed.

This has to be a bug, right? Save file is attached. 

SJW: As nuclearslurpee points out below, a black hole system can have a LOT of jump points.
« Last Edit: July 13, 2023, 02:31:17 PM by Steve Walmsley »
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2975
  • Thanked: 2237 times
  • Radioactive frozen beverage.
Re: v2.1.1 Bugs Thread
« Reply #138 on: March 17, 2023, 08:04:38 PM »
I started a new 2. 1. 1 game a few days ago with mostly default setting, and so far everything has been normal.  But as I was grav surveying one of the initial Sol-connected systems, I noticed I was seeing 2,3,4 "new jump point" messages in a single time interval.  There were multiple ships working in there though, so I thought nothing of it.  But then it happened again.  And then again.  And again.  I looked closer: single ships were finding multiple JPs at once.
At present, there are 26 unexplored JPs in the Cyclops system.  Of the 30 Survey locations, 18 of them have been surveyed.

This has to be a bug, right? Save file is attached.

The system in question appears to be a black hole (according to the DB; I've examined it but not loaded it up in-game). Black holes, per Steve:
Black holes with a mass of 20 or more gain a fixed number of additional jump points, with that number depending on mass. This is in addition to the higher chance of jump points associated with massive stars.

Their main game impact will be the creation of systems that are hard to survey but generally have more jump points.

The listed mass in the DB is 60, so I assume it is capable of generating quite a massive number of jump points indeed! Not a bug, though.
 
The following users thanked this post: LiquidGold2

Offline LiquidGold2

  • Petty Officer
  • **
  • L
  • Posts: 16
  • Thanked: 9 times
Re: v2.1.1 Bugs Thread
« Reply #139 on: March 17, 2023, 09:00:27 PM »
I started a new 2. 1. 1 game a few days ago with mostly default setting, and so far everything has been normal.  But as I was grav surveying one of the initial Sol-connected systems, I noticed I was seeing 2,3,4 "new jump point" messages in a single time interval.  There were multiple ships working in there though, so I thought nothing of it.  But then it happened again.  And then again.  And again.  I looked closer: single ships were finding multiple JPs at once.
At present, there are 26 unexplored JPs in the Cyclops system.  Of the 30 Survey locations, 18 of them have been surveyed.

This has to be a bug, right? Save file is attached.

The system in question appears to be a black hole (according to the DB; I've examined it but not loaded it up in-game). Black holes, per Steve:
Black holes with a mass of 20 or more gain a fixed number of additional jump points, with that number depending on mass. This is in addition to the higher chance of jump points associated with massive stars.

Their main game impact will be the creation of systems that are hard to survey but generally have more jump points.

The listed mass in the DB is 60, so I assume it is capable of generating quite a massive number of jump points indeed! Not a bug, though.

I think you might be right. This is my first time seeing one pop up; I'd forgotten they were a thing. Thanks.
 

Offline boolybooly

  • Lieutenant
  • *******
  • Posts: 171
  • Thanked: 87 times
Re: v2.1.1 Bugs Thread
« Reply #140 on: March 20, 2023, 07:09:25 AM »
When a ship joins a fleet or sub-fleet of a fleet which is set to travel below maximum speed, the fleet reverts to maximum speed.

Expected behaviour would be the fleet joining adopts the speed orders for the fleet it is joining.

e.g. I set a sensors ship fleet also containing a tanker and FAC subfleets to follow LP1 at 18 km/s because this is about the average speed of the planet it is following. I want to keep LP1 in sensors range because I am using a Raider scout wreck on the other side of a long jump to LP2, following an orbit around the second star of a binary system, as bait to lure a raider salvage fleet and cull the predators. This LP represents a system choke point they will need to use. When a reinforcement FAC joins the FAC subfleet of the sensor fleet, the speed of the fleet immediately jumps from 18 to 4508 which is the maximum fleet speed. This is because while the "use maximum speed" box is unchecked the set speed has reverted to maximum for the sensors ship which is currently the core ship of the fleet.

It also does this, i.e. resets max speed, if you (manually detach and) manually add ships to the fleet in the same location.
 
The following users thanked this post: Snoman314, nuclearslurpee

Offline LiquidGold2

  • Petty Officer
  • **
  • L
  • Posts: 16
  • Thanked: 9 times
Re: v2.1.1 Bugs Thread
« Reply #141 on: March 20, 2023, 02:15:55 PM »
When a ship joins a fleet or sub-fleet of a fleet which is set to travel below maximum speed, the fleet reverts to maximum speed.
[...]
It also does this, i.e. resets max speed, if you (manually detach and) manually add ships to the fleet in the same location.

Relatedly, a fleet with less than max speed set will reset to max speed after overhauling. This has been especially annoying when trying to tune escorted tanker speeds (sidenote, it would be great to have an order equivalent to "Load All Minerals Until Full" for fuel).
 

Offline Laurence

  • Warrant Officer, Class 1
  • *****
  • L
  • Posts: 92
  • Thanked: 15 times
Re: v2.1.1 Bugs Thread
« Reply #142 on: March 22, 2023, 02:35:11 PM »
I'd like to add my weight to the Local System Generation issue.

Me as well... Two different games with Known Stars not seeing any loops with ~100 systems explored in each. In one, I had two starting NPRs set for 25-50 LY distance, haven't seen them.  Two discovered NPRs doing their own exploring that I can't see, but no reconnections to my areas.

Did a quick test with these settings (does the max number of systems/local chance even matter for Known Stars)?
Max Systems 10
Local Chance 100%
Local Spread 5
No NPRs

Attaching screenshots of some of the settings, plus the map I got using SM to explore.

SJW: Known Stars are working fine in all my own games, so likely RNG rather than bug
« Last Edit: July 13, 2023, 02:42:57 PM by Steve Walmsley »
 

Offline hammer58

  • Petty Officer
  • **
  • h
  • Posts: 21
  • Thanked: 1 times
Re: v2.1.1 Bugs Thread
« Reply #143 on: March 22, 2023, 04:33:24 PM »
Not sure if this has been reported yet? When a jump point stabilization module is combined with a tractor beam on the same ship, the ship will not do the jump point stabilize function.
Is this intentional? 
 

Offline LiquidGold2

  • Petty Officer
  • **
  • L
  • Posts: 16
  • Thanked: 9 times
Re: v2.1.1 Bugs Thread
« Reply #144 on: March 24, 2023, 12:09:40 PM »
If the main window is shrunk down or resized, the zoom/center point stays in the same location (pixel offset?), as opposed to moving to the new true center of the window. This is annoying if you don't want the main window taking up your entire display for one reason or another, or if you have a multi-monitor setup with different resolution monitors.

Relatedly, the main window seems to always open on the main display in a multi-monitor setup (and always fullscreen), instead of remembering what display it was last open on.
 

Offline Exultant

  • Petty Officer
  • **
  • E
  • Posts: 28
  • Thanked: 17 times
Re: v2.1.1 Bugs Thread
« Reply #145 on: March 29, 2023, 07:49:31 PM »
This isn't an error message, but nuclearslurpie mentioned that this is likely unintended behavior and a bug, so I am posting hit here to hopefully be addressed:

Behavior of escorting fleets using Formation Orders:

Rules as derived through experimentation:

1.) Escorts must be in their own fleet. You assign an 'anchor fleet' to the escorting fleet, and a distance and bearing.

2.) Bearing is relative to the toggles of Specific Threat, Nearest Hostile Warship/Contact, or Anchor Fleet destination

3.) When multiple toggles are selected, priority given to higher ones on the list.

For example, if distance is set to 1mkm, bearing is set to 0, and Nearest Hostile Contact and Use Anchor Destination are both set to yes, the escorting fleet will attempt to position itself 1mkm out from the anchor fleet first in the direction of the nearest hostile contact then, if no hostile contacts are known, 1mkm out toward the anchor fleets current movement destination.

The problem is that if the anchor fleet is not moving, and a hostile target isn't visible, the escorts return to 0 distance from the anchor fleet.

This means, if you want to have sensor escorts that form a ring of detection around your main fleet to take advantage of the efficiency of smaller sensors, it will only work if you already see hostile craft (which means you don't need the sensor escorts). If you are not moving and do not already have hostile contacts (such as using a carrier group that doesn't want to close on potential targets when you first jump into a potentially hostile system), the escorts will stay at distance 0 defeating the purpose of using a sensor net instead of one massive large passive in the parent fleet.

TL;DR The system as-is will work when moving your main fleet, but once you have your fleet where you want them, you have no ability to maintain the escort unless already detecting hostiles.

Current Jury-rigged solution: Fleets following Formation Orders and 'Use Anchor Fleet Destination' will maintain their bearing and range as long as the game sees the anchor fleet as moving. A follow command is considered movement, even if no distance was traveled during the last pulse. This works whether you are following another fleet or a planet or a DSP. You can emulate desired behavior (escorts always maintain distance and bearing, even when stationary) by having the parent fleet issue a 0 distance follow order on a stationary object. Currently, the best way I've determined this to work is to create a temporary Deep Space Population where I want my parent fleet to situate (You can't issue a follow order on a waypoint). This adds additional micromanagement whereby I need to clean up DSPs after combat.

The tactical downside of this is that bearing is relative to the target destination while moving, but then reverts to Bearing 0 = 'Due East' once the anchor fleet arrives at the DSP. This can create the unlikely but potential situation where an anchor fleet traveling 'due west' on the tactical map arrives at its destination, whereby all escorting fleets now switch sides relative to the anchor fleet (as Bearing 0 is now 'due east' instead of 'due west') and during this transition time, where escorts are out of position, hostile contacts stumble on the anchor fleet.

Proposed Solutions:
1.) When none of the toggles are set to Yes, Desired Bearing Offset is relative to cardinal directions on the tactical map. For example, if I have 4 escorts set to 0, 90, 180 and 270 bearing offset, I'll have escorts at the four cardinal directions, where 'up' is 'north' on the map. Currently, the game defines Bearing 0 as "due east" on the map when not relative to a specific target. This will allow for sensor nets that do not change their position relative to the anchor fleet. This is important, as a sensor net needs coverage, and moving to keep position relative to contacts can create situations where ships are busy redeploying rather than maintaining coverage if, for example, a hostile warship on the opposite side of the fleet suddenly becomes the closest contact, all escorts will redeploy relative to that new target, creating sensor gaps.

2.) Additionally, when none of the toggled options are true, or no options are toggled, escorting fleets maintain their desired distance. Thus, stationary anchor fleets who do not currently see hostile targets are capable of maintaining their escorts' positions.

2a.) If current functionality is desired (such as having non combat craft stay with the fleet during normal times, but run away from the closest hostile when they are found) implement a toggle such as "Always Maintain Distance" which will allow conversion between behaviors
 
The following users thanked this post: Droll, lumporr

Offline GhostIsGone

  • Chief Petty Officer
  • ***
  • G
  • Posts: 30
  • Thanked: 2 times
Re: v2.1.1 Bugs Thread
« Reply #146 on: April 01, 2023, 07:17:58 PM »
Troop transports don't require shuttle bays in order to transfer troops to / from a planet without a spaceport or orbital shuttle bays. As per http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591 troop bays are said to follow another rule, but I couldn't find the follow up post regarding troops bays, so I'm not sure if this is intended behaviour.

SJW: Working as intended. See Nuclearslurpee response below.
« Last Edit: July 13, 2023, 02:44:42 PM by Steve Walmsley »
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2975
  • Thanked: 2237 times
  • Radioactive frozen beverage.
Re: v2.1.1 Bugs Thread
« Reply #147 on: April 01, 2023, 08:33:31 PM »
Troop transports don't require shuttle bays in order to transfer troops to / from a planet without a spaceport or orbital shuttle bays. As per http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591 troop bays are said to follow another rule, but I couldn't find the follow up post regarding troops bays, so I'm not sure if this is intended behaviour.

They do not require cargo shuttles, but will work very slowly without them. I believe this mechanic exists to allow things like loading a boarding party after they have captured a ship, but can also be used for small marine detachments that take control of enemy sensor outposts and the like when there is no opposition but you don't want to transport a whole brigade all the way out there.
 
The following users thanked this post: GhostIsGone

Offline Laurence

  • Warrant Officer, Class 1
  • *****
  • L
  • Posts: 92
  • Thanked: 15 times
Re: v2.1.1 Bugs Thread
« Reply #148 on: April 07, 2023, 02:12:10 PM »
Apologies if I missed this being reported earlier. I searched but maybe poorly.

Multiple Player Race start on Earth, when ground combat results in a population being conquered, it is being transferred to the largest population on the planet, not the Race attacking.

Example
Races Russia & Europe fighting
Europe loses and immediately conquered by Race China, who was not involved, but is the largest in both population and ground forces, and was currently set to Friendly to Race Europe.

A second issue is that seems to be using China's ground forces to determine the actual surrender, as Russia does not seem to have sufficient ground forces remaining to force a surrender.

SJW: Fixed for v2.2
« Last Edit: July 13, 2023, 04:07:28 PM by Steve Walmsley »
 
The following users thanked this post: nuclearslurpee

Offline boolybooly

  • Lieutenant
  • *******
  • Posts: 171
  • Thanked: 87 times
Re: v2.1.1 Bugs Thread
« Reply #149 on: April 07, 2023, 03:24:43 PM »
I set a tug Tangerine Dream to follow another tug Sgt Pepper from Sol because the former had a higher speed than the latter but I wanted them to stay together so I could organise an escort at their destination but didnt want to risk messing up their tractor caravans.

When they traversed a JP with a jump tender to Wolf 359 from Sol Sgt Pepper continued with orders to travel but Tangerine dream which was following, reversed course and is heading back into the Sol system even though it still has the follow order for Sgt Pepper which is in Wolf 359.

Maybe this is another instance of the "mirror universe" bug where ships end up on the wrong side of a JP behaving as if inside the system on the other side.

Save 78Mb would not upload fyi
https://www.dropbox.com/s/7mpeutth313ggyg/AuroraDB.db?dl=0

I recall that was fixed for 2.2 but I thought I would report it anyway, just in case it is different.