Author Topic: v1.13.0 Bugs Thread  (Read 89949 times)

0 Members and 1 Guest are viewing this topic.

Offline Ancalagon

  • Lieutenant
  • *******
  • A
  • Posts: 187
  • Thanked: 41 times
Re: v1.13.0 Bugs Thread
« Reply #375 on: May 27, 2021, 06:54:48 PM »
Jump Gates can be used instantly, over and over, with no jump delay. This has the annoying (but not game-breaking) side effect of causing a game of cat-and-mouse with an enemy fleet where you jump into an enemy gatecamp with overwhelming forces, and they decide to run by jumping through the gate, and you chase them back on the next 5-second interval but they jump back instantly to the original system, over and over (until you decide to split your forces). I've seen other players report this as well. I assume the lack of delay on jump gate usage was originally intended, but maybe not the instant back-and-forth, cat-and-mouse behavior that NPR fleets can exhibit.

You can also make multiple jumps forward and back, over and over, in the same 5-second interval. I just made 131,072 transits in a single 5-second interval, although this is probably not as important.
« Last Edit: May 27, 2021, 07:19:14 PM by Ancalagon »
 

Online nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2960
  • Thanked: 2222 times
  • Radioactive frozen beverage.
Re: v1.13.0 Bugs Thread
« Reply #376 on: May 27, 2021, 07:29:48 PM »
Jump Gates can be used instantly, over and over, with no jump delay. This has the annoying (but not game-breaking) side effect of causing a game of cat-and-mouse with an enemy fleet where you jump into an enemy gatecamp with overwhelming forces, and they decide to run by jumping through the gate, and you chase them back on the next 5-second interval but they jump back instantly to the original system, over and over (until you decide to split your forces). I've seen other players report this as well. I assume the lack of delay on jump gate usage was originally intended, but maybe not the instant back-and-forth, cat-and-mouse behavior that NPR fleets can exhibit.

Believe it or not, this isn't a bug, but rather is a mechanical concession to the NPRs to make up for their poor AI. it is, however, extremely irritating and frequently the cause of increment slowdowns and interrupts.

Quote
You can also make multiple jumps forward and back, over and over, in the same 5-second interval. I just made 131,072 transits in a single 5-second interval, although this is probably not as important.

This one...might be a bug? I'm not sure. I thought jump gates were subject to the same jump shock effects as any other jump point, except for the NPR exception.
 

Offline Density

  • Warrant Officer, Class 1
  • *****
  • D
  • Posts: 98
  • Thanked: 44 times
Re: v1.13.0 Bugs Thread
« Reply #377 on: May 28, 2021, 01:44:15 AM »
You can also make multiple jumps forward and back, over and over, in the same 5-second interval. I just made 131,072 transits in a single 5-second interval, although this is probably not as important.

This one...might be a bug? I'm not sure. I thought jump gates were subject to the same jump shock effects as any other jump point, except for the NPR exception.

Still not a bug. Jumping through a stabilized jump point causes jump shock. But shock doesn't prevent jumping, it briefly prevents sensors and jump engines from working. But the jump point is still there, and still stabilized, and it itself didn't jump. The same situation also wouldn't be a bug if a ship were jumped back and forth by another ship that wasn't itself jumping (i.e. a jump tender).
It would be a bug if say, a ship with a jump engine made a standard transit through a stabilized/tended jump point and immediately made a squadron transit back through the same jump point. But that isn't the case here.
 

Offline IanD

  • Registered
  • Commodore
  • **********
  • Posts: 725
  • Thanked: 20 times
Re: v1.13.0 Bugs Thread
« Reply #378 on: May 28, 2021, 05:38:59 AM »
Planetary Invasion Update 2

A nuclear strike destroyed the last remaining solder, after that the normal surrender mechanics ensued.

Is this a similar problem to that seen in VB versions when units in bases could only loose half of their strength ad infinitum? But instead of leaving a fraction the value could not go below 1? Probably rubbish,

Also noticed that Shipyards were 2/-12. This is probably because once you have destroyed the actual shipyards you are able to continue firing on them without any shipyards present. SM function can resolve this.
« Last Edit: May 28, 2021, 05:44:39 AM by IanD »
IanD
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2781
  • Thanked: 1048 times
Re: v1.13.0 Bugs Thread
« Reply #379 on: May 28, 2021, 11:32:18 AM »
Planetary Invasion Update 2

A nuclear strike destroyed the last remaining solder, after that the normal surrender mechanics ensued.

Is this a similar problem to that seen in VB versions when units in bases could only loose half of their strength ad infinitum? But instead of leaving a fraction the value could not go below 1? Probably rubbish,

Also noticed that Shipyards were 2/-12. This is probably because once you have destroyed the actual shipyards you are able to continue firing on them without any shipyards present. SM function can resolve this.
Yeah both are known issues, reported before. I think Steve fixed the shipyard one already but I'm not 100% sure.
 

Offline Ancalagon

  • Lieutenant
  • *******
  • A
  • Posts: 187
  • Thanked: 41 times
Re: v1.13.0 Bugs Thread
« Reply #380 on: May 29, 2021, 09:16:51 AM »

"Earth" and "Luna" reappear after they have been destroyed due to the disaster.



Steps to reproduce:

1) Let Earth be destroyed by the disaster (download attached save file, and skip time forward 30 days)
2) Save game
3) Close game
4) Reopen game, and zoom in on the sun to see Sol-A III and its moon suddenly in close orbit around the sun.
5) Sol III will be destroyed in a couple months again if you leave the disaster enabled. If you disable the disaster, Sol III will survive forever close to the sun.


I just wanted to touch base on this bug again, since I didn't see it fixed on the changelog or in the thread. Earth and Luna reappear after destruction when you save, close, and then reopen the game.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11649
  • Thanked: 20350 times
Re: v1.13.0 Bugs Thread
« Reply #381 on: May 29, 2021, 10:49:35 AM »
I just wanted to touch base on this bug again, since I didn't see it fixed on the changelog or in the thread. Earth and Luna reappear after destruction when you save, close, and then reopen the game.

It is fixed and it is in the change log from a while ago.
 
The following users thanked this post: Ancalagon

Offline Ancalagon

  • Lieutenant
  • *******
  • A
  • Posts: 187
  • Thanked: 41 times
Re: v1.13.0 Bugs Thread
« Reply #382 on: May 29, 2021, 12:40:03 PM »
I just wanted to touch base on this bug again, since I didn't see it fixed on the changelog or in the thread. Earth and Luna reappear after destruction when you save, close, and then reopen the game.

It is fixed and it is in the change log from a while ago.

I don't think it's on the changelog. The only related entry I can find is for a different bug:   "Fixed #1552 Object Not Found error by ending Death Spiral scenario once Earth crashes into the Sun. Workaround is to manually turn this off."

I just wanted to make sure that one hadn't slipped through the cracks.
 

Offline Black

  • Gold Supporter
  • Rear Admiral
  • *****
  • B
  • Posts: 868
  • Thanked: 218 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
    2024 Supporter 2024 Supporter : Donate for 2024
Re: v1.13.0 Bugs Thread
« Reply #383 on: May 29, 2021, 02:55:12 PM »
Select Alien Class Hull window (Intelligence and Foreign Relations - Set Class Hull) has checkbox with following text: Set all Formations with Same Template at Same Population.
 

Offline ISN

  • Sub-Lieutenant
  • ******
  • I
  • Posts: 103
  • Thanked: 30 times
Re: v1.13.0 Bugs Thread
« Reply #384 on: May 29, 2021, 06:37:48 PM »
Related question: How do you set the distance at which missile second stages will separate? I set the separation range to 1700k km but they seem to be separating at about twice that, roughly 3400k km.

What is the range of the 1st stage? Does it happen to be roughly 3400k km?

As an aside, I do wish that there would be a way to set the separation range based on distance to target since contacts might be moving towards (separates too late) or away (separates too early) from the missile.

No, the first stage is long-range, around 150m km. The second stage has a range of around 2m km. I tested setting the separation range down to 1m km, and now they're separating at around 2m km. (I'm testing this in SM mode.) I can't tell if this is a bug or if I'm just doing this wrong -- I haven't used missiles in C# yet, and I barely used them in the old VB version.

EDIT: To clarify, they're separating at 2m km from the target.

Try keeping the sep range 1m km, but now make the second stage have a range of 4M km. I want to see if for some reason there's a bug where the separation range is being multiplied by the second stage range.

It seems that when targeted at waypoints the separation distance works correctly, which makes me suspect there's a bug here -- although I haven't seen any bug reports to that effect. Have other people seen something like this? I'd previously been using the friendly neighborhood spoiler race as target practice, but their habit of shooting down my missiles and my ships is making testing difficult. I'm going to make a more cooperative race to test this on.

I think I've figured out what's going on. It turns out that what's happening is that the missile, when deciding when to release the second stage, is taking into account the motion of the ship being targeted; so if the target is moving away the second stage will appear to be released late, while if the target is moving towards the missile the second stage will appear to be released early. So far so good. However, if the target is following something stationary, then it may be moving back and forth even if it appears stationary, which can cause the second stage to be released early or late. Not sure whether this should be classed as a bug or not. The second issue, though, is definitely a bug: as far as I can tell, the first stage uses its own speed, rather than the speed of the second stage, when calculating when to release the second stage. Thus the relatively small correction needed for the fast second stage to catch up to an enemy ship becomes a much larger correction for the slow first stage to catch up.

Since at least one of these issues seems to be a genuine bug, I'm going to post this in the bugs thread.
 
The following users thanked this post: Gabrote42

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: v1.13.0 Bugs Thread
« Reply #385 on: May 30, 2021, 07:24:02 PM »
An NPR generated when I was playing on 260% difficulty 80 years in.

I get that the size of NPR populations is dependent on the above factors in order to give some sort of challenge.
But what just happened is that the game spawned 30bn aliens on a world that can only accommodate 8bn population (they have 100% population density).

I think what should happen is either:
- Game respects the carrying capacity of the body
- Game creates designs of colossal orbital habitats in such a way that the carrying capacity + orbital capacity is sufficient to house the population.


EDIT: I should also mention this world had dangerous levels of CO2 as well which I had to SM replace with aesthesium.
EDIT: For the problem I pointed out in the edit, the game should, once it's decided that the planet in question will have an NPR, modify the body to actually have 0 cost for whatever alien it's decided to put there.

SJW: Max pop for NPR will now be the capacity of the planet. Also fixed dangerous gas problem.
« Last Edit: June 11, 2021, 08:03:11 AM by Steve Walmsley »
 
The following users thanked this post: BigBacon, Foxxonius Augustus, nuclearslurpee

Offline ChubbyPitbull

  • Gold Supporter
  • Sub-Lieutenant
  • *****
  • C
  • Posts: 138
  • Thanked: 27 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.13.0 Bugs Thread
« Reply #386 on: May 30, 2021, 09:43:40 PM »
After a long drawn-out battle with lots of ship captures that left an alien planet cleared of space-defenses but left with STO and ground units, I seem to be stuck in 5-second increments because "increment adjusted due to combat or open fire controls with no targets." I see no warnings about any of my ships having fire controls open, and I opened the database and checked FCT_GameLog but I see no logs for other races in combat, just repeating lines of "increment adjusted" logs since I turned on auto turns and let the game go through a long set of 1 day increments auto-adjusted down to 5 seconds. Typically I would have expected to see the NPR still trying to fire or other NPRs still in combat in these logs as the source of the issue.

Some of the captured ships are still very slow due to damaged engines and a skeleton crew of marines, maybe the STO units on the planet detect the ships and are out of range but still trying to fire, and this isn't generating game logs but causing the five second increments? Not sure what to check.

EDIT: Ok it was apparently one of my fleets, I went through all the fleets for ships I captured as well as the main battle fleet and hit "Cease Fire Fleet," and I can now increment time normally.

EDIT #2: Also have a large number of Missile Salvos listed as Contacts in Fleet Orders, but trying to move the fleet to any of them says "Destination cannot be found."
« Last Edit: May 31, 2021, 08:37:52 AM by ChubbyPitbull »
 

Offline ChubbyPitbull

  • Gold Supporter
  • Sub-Lieutenant
  • *****
  • C
  • Posts: 138
  • Thanked: 27 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.13.0 Bugs Thread
« Reply #387 on: May 31, 2021, 08:54:55 AM »
Just made a new post because I found an *actual* bug from the above situation.

So since the game log in the database won't tell me which ship was causing the increment to auto-adjust due to combat, I looked in FCT_FireControlAssignments and found that it was still showing that one Fire Control for one of my ships, Ship ID#26734 "CA Klingon" was still on Open Fire. However, looking in game at CA Klingon, both Fire Controls showed "Green" cease fire status for CA Klingon. However, the "Cease Fire All" button was still displayed, so I clicked that and it changed back to "Open Fire All."

However, when I advanced time one day, I found that it still got auto-adjusted back down to 5 seconds due to open fire controls with no targets, and "Cease Fire All" was again displayed in CA Klingon's ShipCombat screen. This repeats all the time, I can't seem to clear Fire Control status from the UI in game. I've also tried individually opening fire on each FC so they turn Orange, an then Cease Firing the again back to green, and the increment still auto adjusts back to 5 due to Open Fire Control.

One of CA Klingon's Fire Controls (a Atalskes Phaser Corporation Weapons Console R480-TS10000) was damaged during the last battle, and had been in an "Open Fire" state when it had been damaged. I can't shut it off from the UI since it was damaged, I'm wondering if that one is stuck and keeping the increments locked. I think I can fix it by editing the database to put a 0 in for "Open Fire," but wanted to report the issue first. DB attached.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: v1.13.0 Bugs Thread
« Reply #388 on: May 31, 2021, 10:27:40 AM »
Just made a new post because I found an *actual* bug from the above situation.

So since the game log in the database won't tell me which ship was causing the increment to auto-adjust due to combat, I looked in FCT_FireControlAssignments and found that it was still showing that one Fire Control for one of my ships, Ship ID#26734 "CA Klingon" was still on Open Fire. However, looking in game at CA Klingon, both Fire Controls showed "Green" cease fire status for CA Klingon. However, the "Cease Fire All" button was still displayed, so I clicked that and it changed back to "Open Fire All."

However, when I advanced time one day, I found that it still got auto-adjusted back down to 5 seconds due to open fire controls with no targets, and "Cease Fire All" was again displayed in CA Klingon's ShipCombat screen. This repeats all the time, I can't seem to clear Fire Control status from the UI in game. I've also tried individually opening fire on each FC so they turn Orange, an then Cease Firing the again back to green, and the increment still auto adjusts back to 5 due to Open Fire Control.

One of CA Klingon's Fire Controls (a Atalskes Phaser Corporation Weapons Console R480-TS10000) was damaged during the last battle, and had been in an "Open Fire" state when it had been damaged. I can't shut it off from the UI since it was damaged, I'm wondering if that one is stuck and keeping the increments locked. I think I can fix it by editing the database to put a 0 in for "Open Fire," but wanted to report the issue first. DB attached.

As a workaround, try SM repairing the ship and turning off the now repaired FC. Should hopefully get the game going again.
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2781
  • Thanked: 1048 times
Re: v1.13.0 Bugs Thread
« Reply #389 on: May 31, 2021, 11:57:53 AM »
That bug happened before and was fixed once already. Very curious why it has made a comeback!