v2.1.1 Bugs Thread

[Steve Walmsley (OP)]

Bug: If a fleet of beam-armed ships is ordered to sync fire, they will not fire even when all ships are ready to fire. Every ship in the fleet will indicate that it "is waiting for other ships in the same fleet to confirm their readiness before firing."

I'm guessing this occurs because the Sync Fire control only checks if ships are ready to fire missiles, since it is almost never used for beam fire.

The code is checking the beam ships, but never actually checks if the delay is zero before creating the event

Fixed for v2.2.

[Steve Walmsley (OP)]

https://i.    imgur.    com/TICq8yN.   png

"2. 1. 1 Function #917: Value was either too large or too small for an Int32. "

Occurred when setting a civilian contract to move automines to C/2017 K2, which is quite a far distance away from Earth actually.     This appears thousands of times and renders the game unplayable, forcing deletion of the game.     Actually, since the default behavior is to load your most recent game, I had to reinstall the entire game.     I couldn't stomach going through 4,000 message box prompts to see if there was a way to fix this.   

I think it is probably some type of check that is failing due to overflow because of the huge distance involved.   

This is a weird one because there aren't any int variables in the function, which is used to calculate time to destination. Anything odd about the civilian ships? Are they very slow for example?

[Steve Walmsley (OP)]

The same game as before, I'm drawing heavily on a swarm of small (1k-sized) survey ships for all geo and grav survey duties. I designed a (cheap) jump tender for their size, and placed one at every jump point, and clicked the "Assume Fleet is Jump-Capable". However, the surveyors entered a system whose JP was being stabilized, and when they finished their work they couldn't find their way out. I checked that the jump tender was placed at the entry point, tried again, and they continued complaining. I ordered them to move elsewhere and they went through the JP with no problem at all. I believe this "Assume Fleet is Jump-Capable" setting is not working. I wasn't tracking where the surveyors went so I can't be absolutely sure, but it seems they only plotted routes through JPs that were at least partially stabilized.

I couldn't find any report about this, either as a bug or feature. I'll try to reproduce this later in a new clean game.

EDIT: The surveyors are all using default orders to either geosurvey bodies in the system or do gravsurvey, according to their type, then proceed to another system needing surveying. That's my attempt to automate the surveying, with a dozen of FAC-sized survey craft of each type in a 10% survey speed game. However, when all survey is done in a border system, the survey craft ignore the jump tender in the JP and complain they can't apply the default orders, no matter whether the "Assume Fleet is Jump-Capable" is set or not.
I've also verified that when one survey craft completed their job and chose another system to go to, they'd cross my entire map for months to go to another system through a path connected with stabilized JPs, rather than cross a single JP with a jump tender available.
Adding a standard jump engine would require a full redesign and lots of refits, and would go counter the idea I'm following in this game. So, in order to avoid lots of micromanaging surveyors, I've now edited the DB (oops) to have a new miniaturized jump engine specifically for the survey craft, SM-edited their designs to include it, and I'm now waiting to see if they'll finally go to the closest system to do their jobs.

It's quite possible I misunderstood the meaning of the "Assume Fleet is Jump-Capable", and that it wasn't meant to apply to default orders... If so, please, Steve, could you consider it for a future version?

"Assume Fleet is Jump-Capable" is used to filter potential destinations when using Fleet Auto-route.

[Steve Walmsley (OP)]

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.

Screenshot shows 45 systems, so 44 explored. The ones directly connected to Sol will not have a chance of connection, so there is about a 6% chance of no connections after 41 subsequent systems explored (based on the 6.67% chance of connection to an existing system). That 6% is a little higher in reality due to the 'Avoidance of Closed Universe' change in v2.1.1, which will ignore the chance of connection if you explore the last open jump point.

Max Systems, Local Chance and Local Spread have no effect in Known Stars games. If you mouse over these options on the Game window, the information section at the bottom explains these do not affect Known Stars games.

[Steve Walmsley (OP)]

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?

Do you mean it won't carry out the order, or you can't give it the order?

[Ragnarsson]

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.

Screenshot shows 45 systems, so 44 explored. The ones directly connected to Sol will not have a chance of connection, so there is about a 6% chance of no connections after 41 subsequent systems explored (based on the 6.67% chance of connection to an existing system). That 6% is a little higher in reality due to the 'Avoidance of Closed Universe' change in v2.1.1, which will ignore the chance of connection if you explore the last open jump point.

Max Systems, Local Chance and Local Spread have no effect in Known Stars games. If you mouse over these options on the Game window, the information section at the bottom explains these do not affect Known Stars games.

I can't speak to Known Stars, but on Random Stars there is a definite issue with having no connections to existing systems (loops), or dead-ends. To demonstrate, I loaded up a fresh copy of 2.1.1, started a new game with the only alteration to system generation being to set it to Random Stars. I then SM explored 150 systems. Attached is the screenshot of what the system map looked like. As you can see, there are no loops and there are no dead-ends.

In 150 systems, this is... highly improbable, in the absence of some kind of system generation and selection issue.

EDIT: In the image, System#891 appears to be a dead-end; this is merely a display issue due to it being the final system I SM explored and the galaxy map not updating to show it. I checked and it does indeed have an unexplored jump point.

[Hari]

I built a ship with mobile repair bays. I sent it to a DSP : all is fine, shipyard is present at DSP.

Then I deleted the DSP. The shipyard was deleted too : ship remains, with its mobile repair bay, but when I move it to any location, there is no shipyard anymore. Deleting the population (DSP) seems to also delete the "shipyarding" capacity of the repair bay.

Not tested at other population type, maybe the same.

[serger]

http://aurora2.pentarch.org/index.php?topic=11298.msg134165;topicseen#msg134165

Not a bug report but rather a note: this old inconsistent WAI is still here. That is: sometimes towed ships are using their engines, sometimes they aren't, depending on a tug design and some other factors I cannot catch (the testing shows that for the first try they usually aren't, contrary to the explained WAI, yet with the subsequent designes of tugs they usually are).

[Steve Walmsley (OP)]

I can't speak to Known Stars, but on Random Stars there is a definite issue with having no connections to existing systems (loops), or dead-ends. To demonstrate, I loaded up a fresh copy of 2.1.1, started a new game with the only alteration to system generation being to set it to Random Stars. I then SM explored 150 systems. Attached is the screenshot of what the system map looked like. As you can see, there are no loops and there are no dead-ends.

In 150 systems, this is... highly improbable, in the absence of some kind of system generation and selection issue.

EDIT: In the image, System#891 appears to be a dead-end; this is merely a display issue due to it being the final system I SM explored and the galaxy map not updating to show it. I checked and it does indeed have an unexplored jump point.

Assuming 1000 stars, with Local Chance at 50 and Local Spread at 15, there is a 50% chance that the JP will connect to a system number within 15 of the start system. That doesn't mean it will connect to an existing system - just to that number. It will only connect to a system if one is already occupying that system number slot.

There are also some restrictions on connections. A jump point can't connect to a system if the two systems are already connected - which affects exploration from both systems. Also, the last unlinked jump point can't connect to an existing system.

So 50% of the time, any system from 1-1000 will be chosen. Early on, that means a very low chance of connection. The other 50% of the time, it will be a system within a 30-system-number range centered on the existing system, but again unless those numbers contain existing systems there won't be a connection. Of course, every time you don't get a local chance hit, you move to a new area with none of the 30 local spread slots filled in. As you are moving around 50% of the time, most of the time you are in fairly barren local spreads. In fact, the second system within any local spread won't connect to the first one - because the connection already exists, so you are more likely to be in a new local spread before the current one can connect. Plus every time you hit a new system, the 'local spread' moves to include new unexplored slots. Even after 150 systems, you have only filled in 15% of the total slots, so the result you have is unlikely but possible.

For known systems, there is a fixed chance of finding a connection, but in random systems the total number of systems plays a large part. With 1000 systems, the chance of randomly hitting one of the filled-in slots is pretty low.

I just ran a similar experiment to yours, tracking all the generated system numbers and stepping through the code. I didn't find any links in 45 systems. Changed to 100% local chance (so I am not jumping around the whole 1000 systems) and hit a connection within 4 attempts.

[Steve Walmsley (OP)]

This is a frustrating NPR behavior which I've been going back and forth on whether it is a bug or merely an undesired behavior, but I think this is a poor enough game experience since v2.0, for reasons given below, that it should be considered a bug:

I've noticed in several instances that NPR ships/fleets which appear to have an objective set that requires them to go to a particular planet have a janky interaction if they detect a player ship or fleet at that planet which they deem sufficiently threatening, usually when hostilities exist between the two races. What happens is the following:

• NPR ship on approach to the planet detects the player's ship or fleet.
• NPR ship changes course to retreat.
• NPR ship apparently "forgets" that they have a known contact for the player fleet at that planet.
• NPR ship approaches the planet and detects player's ship or fleet.
• Repeat ad infinitum.

This creates a situation where the player must either (1) attack and destroy, or at least chase off, the NPR ship, or (2) use short increments ad infinitum until the player is in a position to do (1). For various reasons, including roleplay, (1) may not be possible or desirable which forces the negative play experience of (2) unless the player prefers to use SM/DB means to resolve the issue. For example, in my current game this is occurring near a colony which is guarded by one ship, and while my knowledge of the NPR AI tells me that it is fine to go attack and destroy the other ship, in-character it wouldn't make sense to leave the planet unguarded in the face of a possible bait-and-switch trap, thus I am gritting my teeth and using automatic increments to advance time slowly but surely.

I have noticed this behavior in the past but it is significantly more common since the introduction of the Raiders in v2.0, as the Raider scouts absolutely love to do this kind of thing all the time, since they are naturally hostile to every other race and have rock-checking missions hardcoded into their AI. This leads me to seriously question if I want to play with Raiders active, simply because I don't enjoy having to pass between construction cycles using 5-minute increments. I have also noticed complaints about this phenomenon on the subreddit.

Note that if the player does not use a short increment, the NPR ship will at some point cover sufficient distance to reach the planet from "out of sensor range" in one big step, so just using a large increment is not a workaround.

My suggested fix is that NPRs should remember the sensor contact for the player's fleet for an appropriate amount of time (8 hours, 1 day, or 5 days all seem reasonable to me) and behave as if it expects there to be an enemy ship there, instead of getting surprised again every two increments. Alternatively or additionally, NPRs could increment their danger level for a system if they detect a player fleet and consider them hostile, which should eventually convince them to either retreat and try again somewhere else, or else commit a force to battle instead of dancing back and forth at the edge of sensor range.

I've added some extra code to the AI. This is a tricky area and will require playtesting, but in essence once a fleet decides to run away it will maintain that state for a few days unless the balance of forces changes in the system. The length of time it will run has a random element, plus modifications for Xenophobia (longer) and Determination (shorter). It will prevent fleets checking out points of interest while in this state, or moving to a central location, but will not prevent them attacking if they judge things to be in their favor.

[Steve Walmsley (OP)]

Not sure if it has been reported here yet or if I am doing something wrong my occasionally my Naval admin command will switch their minimum rank requirements to Ground force ones and reassign ground force commanders, which naturally causes them to provide no bonus. I have seen this happen most often with a training type admin command and have been able to fix it by deleting the old one and remaking it but its still odd and requires me to constantly check to make sure things are working in my admin commands

It's been reported a few times, but I hadn't tracked it down. However, I just found something that could cause it, so potentially fixed now.

[Steve Walmsley (OP)]

I built a spacestation and it was assigned to a civilian fleet.

Ive searched the forum and see this is previously reported bug from many versions ago (1.5.1).

Ive just experienced it in v 2.1.1

I had a quick look at the 1.5.1 bug reports but couldn't find it. Also, it would probably be reported a lot over the last intervening three years if it was a common problem. Is the civilian fleet set as your space station destination fleet? Are there any mods running, or have there been any DB edits?

[nuclearslurpee]

I can't speak to Known Stars, but on Random Stars there is a definite issue with having no connections to existing systems (loops), or dead-ends. To demonstrate, I loaded up a fresh copy of 2.1.1, started a new game with the only alteration to system generation being to set it to Random Stars. I then SM explored 150 systems. Attached is the screenshot of what the system map looked like. As you can see, there are no loops and there are no dead-ends.

In 150 systems, this is... highly improbable, in the absence of some kind of system generation and selection issue.

EDIT: In the image, System#891 appears to be a dead-end; this is merely a display issue due to it being the final system I SM explored and the galaxy map not updating to show it. I checked and it does indeed have an unexplored jump point.

I just ran a similar experiment to yours, tracking all the generated system numbers and stepping through the code. I didn't find any links in 45 systems. Changed to 100% local chance (so I am not jumping around the whole 1000 systems) and hit a connection within 4 attempts.

I usually change the random stars generation settings to 60 and 12 to encourage loop formation, I haven't done it too often lately because of the bug Steve mentioned earlier, but to my recollection this worked reasonably well.

I've added some extra code to the AI. This is a tricky area and will require playtesting, but in essence once a fleet decides to run away it will maintain that state for a few days unless the balance of forces changes in the system. The length of time it will run has a random element, plus modifications for Xenophobia (longer) and Determination (shorter). It will prevent fleets checking out points of interest while in this state, or moving to a central location, but will not prevent them attacking if they judge things to be in their favor.

Thanks Steve! This should make the new spoilers a lot less frustrating in 2.2+! 

[Steve Walmsley (OP)]

When towing a ship (or presumably any other object e.g. a space station etc) with no engine (i.e. a speed of 1km/s), if the towed ship takes any fire from an enemy, it is "detached from parent fleet due to damage". This is presumably due to the normal logic of detaching ships which lose their engines in combat so as not to cause the rest of the fleet to stop. However, in this case the towed ship had shields and didn't even take any damage to armor or components, just some light shield damage, and it was still booted from the fleet.

Context: I was experimenting with building a floating point defense barge to be towed towards spoilers with strong missile capability. The idea was that I'd normally park these things near my capital and/or big colonies as PD, but upon need could tow them out to soak up ASMs and AMMs from spoilers. Doesn't work that well if they stop dead in their tracks any time they take a stray shield hit from a pidly AMM.

Update: I did some experimenting by turning on SM and adding a small engine to my PD barge so it's speed wasn't 1km/s. Any damage still results in getting kicked out of the fleet. I think it must be because it's under tow. I assume this is still not intended behavior?

I've changed the tractor rules. They should be simpler overall and will eliminate this problem.
http://aurora2.pentarch.org/index.php?topic=13090.msg165464#msg165464

[Ragnarsson]

Assuming 1000 stars, with Local Chance at 50 and Local Spread at 15, there is a 50% chance that the JP will connect to a system number within 15 of the start system. That doesn't mean it will connect to an existing system - just to that number. It will only connect to a system if one is already occupying that system number slot.

There are also some restrictions on connections. A jump point can't connect to a system if the two systems are already connected - which affects exploration from both systems. Also, the last unlinked jump point can't connect to an existing system.

So 50% of the time, any system from 1-1000 will be chosen. Early on, that means a very low chance of connection. The other 50% of the time, it will be a system within a 30-system-number range centered on the existing system, but again unless those numbers contain existing systems there won't be a connection. Of course, every time you don't get a local chance hit, you move to a new area with none of the 30 local spread slots filled in. As you are moving around 50% of the time, most of the time you are in fairly barren local spreads. In fact, the second system within any local spread won't connect to the first one - because the connection already exists, so you are more likely to be in a new local spread before the current one can connect. Plus every time you hit a new system, the 'local spread' moves to include new unexplored slots. Even after 150 systems, you have only filled in 15% of the total slots, so the result you have is unlikely but possible.

For known systems, there is a fixed chance of finding a connection, but in random systems the total number of systems plays a large part. With 1000 systems, the chance of randomly hitting one of the filled-in slots is pretty low.

I just ran a similar experiment to yours, tracking all the generated system numbers and stepping through the code. I didn't find any links in 45 systems. Changed to 100% local chance (so I am not jumping around the whole 1000 systems) and hit a connection within 4 attempts.

I'm familiar with the math.

Attached below, the same experiment continued onward up to 302 systems. Still no loops or dead-ends. The map layout is different than the previous simply due to having to fit an additional 152 systems. I shall continue on and do it up to 500 systems later today, if I have the time and if it's necessary.