Author Topic: v1.12.0 Bugs Thread  (Read 69431 times)

0 Members and 1 Guest are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11677
  • Thanked: 20470 times
Re: v1.12.0 Bugs Thread
« Reply #345 on: January 09, 2021, 10:41:46 AM »
Quote from: TheTalkingMeowth link=topic=11945.  msg144947#msg144947 date=1608578995
Quote from: ivangorin21 link=topic=11945.  msg144945#msg144945 date=1608578569
I think there was a warning when I was saving, but it saved successfully.    I don’t remember what it was exactly, is there a log or warnings/errors?

I don't think errors are logged anywhere. 

If there was an error message while saving, that was probably related to whatever weirdness deleted all these ship classes. 

Does the game give an error if you try to save again?

I have started a new game, and this error appeared after a few 30 day skips.   Do you think it could be related to the previous game bug? I think it is similar to the message I got when saving before

That function number is for calculation of orbit. I could only see that error appearing if the parent star had somehow been deleted.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11677
  • Thanked: 20470 times
Re: v1.12.0 Bugs Thread
« Reply #346 on: January 09, 2021, 11:45:47 AM »
Ships with destroyed components such as box launchers and magazines are able to load the respective ammo resulting in a percentage of ordnance higher than 100%.

The correct behaviour should be that such ships shouldn't be able to load any ordnance for destroyed components (>100% damage on damage control screen)

It is okay for damaged ones (<100% damage on damage control screen)

How did you load the ordnance. From a colony or a collier?
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11677
  • Thanked: 20470 times
Re: v1.12.0 Bugs Thread
« Reply #347 on: January 09, 2021, 11:59:33 AM »
I'm not sure if this is a known issue, but if a fire control is destroyed while set to open fire, it can't be told to cease fire, leading to endless 5 second increments forcing you to SM repair it and turn it off again.

I can't reproduce this one - anyone else having similar problems?

There is existing code to set any destroyed fire to cease fire.
 

Offline xenoscepter

  • Vice Admiral
  • **********
  • Posts: 1157
  • Thanked: 318 times
Re: v1.12.0 Bugs Thread
« Reply #348 on: January 09, 2021, 02:15:50 PM »
I'm not sure if this is a known issue, but if a fire control is destroyed while set to open fire, it can't be told to cease fire, leading to endless 5 second increments forcing you to SM repair it and turn it off again.

I can't reproduce this one - anyone else having similar problems?

There is existing code to set any destroyed fire to cease fire.

 - Is it Beam FCS or Missile FCS?
 

Offline yourITguy

  • Petty Officer
  • **
  • y
  • Posts: 20
  • Thanked: 16 times
Re: v1.12.0 Bugs Thread
« Reply #349 on: January 09, 2021, 02:33:38 PM »
Quote from: TheTalkingMeowth link=topic=11945. msg142375#msg142375 date=1603907025
Quote from: Ektor link=topic=11945. msg142372#msg142372 date=1603904182
I'm not sure whether this was already posted, but the conditional order "Refuel, Resupply and Overhaul at Colony" gives off errors #722 and #730 "Object reference was not set to instance of an object" when the conditions trigger.  This leads the fleet that takes the order to return to a colony and overhaul, however they don't refuel and resupply.

The specific situation if you want to replicate the bug is the following: I had a jump capable survey ship with both geo and grav modules set on the following standing orders: 1.  Survey next system body 2.  Survey next survey location 3.  If fuel less than 40% - Refuel at colony or hub (all) 4.  When deployment time exceeded - Refuel, Resupply and Overhaul at Colony.

It's been posted, but a little extra information would be useful.  Can you describe how this interacts with stabilized jump points? We're not sure if it happens if the path back is fully stabilized.

I've experienced this bug as well.  In my case, I had jump capable survey ships in other systems with no JP stabilization yet (early game).  I lost two of the initial three due to lack of MSP before I noticed that the refuel and resupply order wasn't being added to the orders list when the error happens.

Edit: The order works fine as long as the colony it is going to overhaul from is in the same system.
« Last Edit: January 09, 2021, 04:00:36 PM by yourITguy »
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2991
  • Thanked: 2248 times
  • Radioactive frozen beverage.
Re: v1.12.0 Bugs Thread
« Reply #350 on: January 09, 2021, 03:21:46 PM »
The game assigns a main function to a ship class for auto-assignment. The code checked for weapons before checking for survey sensors. I've now changed it so a ship will be classed as a survey ship if the size of survey sensors exceeds the size of weapons. I've also added a line to the class summary so you can see the class function for assignment purposes.

This instantly becomes my favorite change of 1.13 and all my future admirals in charge of BuPers thank you from the bottom of their warmongering peaceful scientific and exploration-loving little hearts.

However I do want to note that the actual bug I was noting was that placing a Cargo Hold on a survey ship, with no other changes, caused the ship to be recognized as a warship despite lacking any weapons, rather than either a survey ship (preferred behavior) or a freighter requiring a Logistics commander (not preferred but makes sense).

I suspect the listed fix here probably resolves that as well but I wanted to clarify just in case.

(Also on a side note if you'd like to adjust the priorities while you're in that bit of the code so that my OMPs with a cargo hold to tote a mass driver around are recognized as miners rather than freighters I would not be unappreciative...  ;) )
« Last Edit: January 09, 2021, 03:27:22 PM by nuclearslurpee »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11677
  • Thanked: 20470 times
Re: v1.12.0 Bugs Thread
« Reply #351 on: January 09, 2021, 05:09:47 PM »
The game assigns a main function to a ship class for auto-assignment. The code checked for weapons before checking for survey sensors. I've now changed it so a ship will be classed as a survey ship if the size of survey sensors exceeds the size of weapons. I've also added a line to the class summary so you can see the class function for assignment purposes.

This instantly becomes my favorite change of 1.13 and all my future admirals in charge of BuPers thank you from the bottom of their warmongering peaceful scientific and exploration-loving little hearts.

However I do want to note that the actual bug I was noting was that placing a Cargo Hold on a survey ship, with no other changes, caused the ship to be recognized as a warship despite lacking any weapons, rather than either a survey ship (preferred behavior) or a freighter requiring a Logistics commander (not preferred but makes sense).

I suspect the listed fix here probably resolves that as well but I wanted to clarify just in case.

(Also on a side note if you'd like to adjust the priorities while you're in that bit of the code so that my OMPs with a cargo hold to tote a mass driver around are recognized as miners rather than freighters I would not be unappreciative...  ;) )

It can't be recognised as a warship without weapons. I suspect it was recognised as a freighter and just happened to gain a commander with bonuses that could be used for warships. When all commanders with the right bonuses have been assigned, the automated assignment does three more runs through all military ships without commanders, using reaction, engineering and tactical bonuses. So the ship would have been classed as a freighter but no commanders with logistics were available, but then it would also have been treated as a military ship without a commander and assigned one of the remaining available commanders.
 
The following users thanked this post: nuclearslurpee

Offline Cosinus

  • Warrant Officer, Class 2
  • ****
  • C
  • Posts: 69
  • Thanked: 23 times
Re: v1.12.0 Bugs Thread
« Reply #352 on: January 10, 2021, 09:54:23 AM »
[...] There seems to be an issue with the pathfinding algorithm. I have not tracked down where it comes from exactly, but I just noticed this behaviour in one location in a big multi star system.
I noticed that in this specific location, when setting 2 fleets to go to the location of the other, the pathfinding algorithm lets them end up in the middle of nowhere.



As you can see, the ships do not go towards each other in a straight line, but rather go in a completely different direction.
DB is here: https://drive.google.com/file/d/16U8NyUzBkcZ9gkN58JsPP6CGa4nXBDb7/view?usp=sharing
To reproduce, set the Pacifica to go to the location of the Triton, and vice versa. Then advance time.

SJW: Working as intended. When you give a fleet orders to move to another fleet, it sets an intercept course to move to where the target fleet will be in the future, rather than where it is now.

I disagree that this is working as intended. When you intercept a single fleet, the algorithm works, because the target of the intercept has an unchanging course.
In this situation, both fleets are trying to intercept each other with no initial velocity and are thus changing their course to meet the other fleet, which causes the other fleet to change course and so on. There should be a special case in the pathfinding algorithm for this, that prevents this loop and just sets the ships on a straight course towards each other. As you can see in my example, currently they take massive detours.
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2991
  • Thanked: 2248 times
  • Radioactive frozen beverage.
Re: v1.12.0 Bugs Thread
« Reply #353 on: January 10, 2021, 12:32:02 PM »
I disagree that this is working as intended. When you intercept a single fleet, the algorithm works, because the target of the intercept has an unchanging course.
In this situation, both fleets are trying to intercept each other with no initial velocity and are thus changing their course to meet the other fleet, which causes the other fleet to change course and so on. There should be a special case in the pathfinding algorithm for this, that prevents this loop and just sets the ships on a straight course towards each other. As you can see in my example, currently they take massive detours.

I have to agree. If both fleets start at rest (or 1 km/s) they should start off in a straight line toward each other. This shouldn't even be a special case: fleet A should see that fleet B is not moving and set a direct course, then fleet B should plot the intercept and set...a direct course.

When both fleets start from zero and go off at an odd angle it makes no sense and requires ticky-tacky micromanagement to solve, i.e. set one fleet to intercept, advance 5s, then give the other fleet its orders. Easy by itself, but also very easily lost in the shuffle of a dozen other events on that turn.
 

Offline Squigles

  • Chief Petty Officer
  • ***
  • S
  • Posts: 40
  • Thanked: 11 times
Re: v1.12.0 Bugs Thread
« Reply #354 on: January 10, 2021, 02:08:13 PM »
1.12, no mods, conventional start.

Not actually sure if this is a bug.

Was playing a reduced tech conventional start. By the time I researched Trans-Newtonian technology and Nuclear Thermal Engines, I had established thriving colonies on Luna and Mars with "Luxury Passenger Accomodation" (incidentally, it's spelled Accommodation, but that's not the bug) equipped ships.

The civilian sector promptly kicked into gear and began building civilian ships. The "bug" is that those civilian ships included cryogenics equipped colony ships despite the technology for that not yet existing.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: v1.12.0 Bugs Thread
« Reply #355 on: January 10, 2021, 03:46:39 PM »
1.12

Fleets created under an admin command that is not on earth will spawn on the correct body with the HQ, however they will not remain in orbit unless you use SM teleport to teleport them to the orbit - kind of defeating the point.

SJW: Fixed
« Last Edit: January 11, 2021, 04:12:05 AM by Steve Walmsley »
 

Offline StarshipCactus

  • Lt. Commander
  • ********
  • S
  • Posts: 262
  • Thanked: 87 times
Re: v1.12.0 Bugs Thread
« Reply #356 on: January 11, 2021, 06:39:46 AM »
I have a strange bug, not game breaking, nor does it create an error. It is just mildly annoying.

The function number: No error message.
The complete error text : see above.
The window affected: As far as I can tell, only the system display window.

What you were doing at the time: I was trying to set up a multi faction alien game. I used SM to edit the system and some of the minerals. To edit the minerals, I clicked the button that gives one faction a full geo survey for that system. When I was done for the day, I clicked the button to forget the Geo survey, clicked the button to survey one body (The homeworld of course.) While I was making these edits, I was viewing the system from the perspective of just one nation. (Faction_1 for now.) When I came back the next day to keep editing, I noticed that the whole system was surveyed. I though I had forgotten to forget the geo survey, so I ignored it. It kept happening though, every time I close the game, the entire system is surveyed for Faction_1 and only Faction_1. The other factions are fine. Could it be that forgetting the geo survey button does not make the correct DB edit?

Conventional or TN start: Conventional.
Random or Real Stars: Random
Is your decimal separator a comma?: My decimal separator is correct.
Is the bug is easy to reproduce, intermittent or a one-off?: I have not tried to reproduce it.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: It happened before I had progressed any time. I have progressed a few years and it still happens.

Edited to make it easier to read.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: v1.12.0 Bugs Thread
« Reply #357 on: January 13, 2021, 04:16:08 AM »
Not sure if anyone mentioned this but Sub-fleets don't seem to remember being attached to sub-fleets after you close and restart the game. All the sub-fleets are directly attached to the fleet and not whichever sub-fleet it was attached to once you save and restart.

Or I'm doing something wrong in my game,  but I usually have deep sub-fleet systems just don't close Aurora down all that often so I never bothered reporting it before.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: v1.12.0 Bugs Thread
« Reply #358 on: January 13, 2021, 04:19:49 AM »
Not sure if anyone mentioned this but Sub-fleets don't seem to remember being attached to sub-fleets after you close and restart the game. All the sub-fleets are directly attached to the fleet and not whichever sub-fleet it was attached to once you save and restart.

Or I'm doing something wrong in my game,  but I usually have deep sub-fleet systems just don't close Aurora down all that often so I never bothered reporting it before.

I can at least second this but just know that in general aurora is bad at handling multi-layer sub-fleet hierarchies. That's why I try to avoid such OOBs.
 

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.12.0 Bugs Thread
« Reply #359 on: January 13, 2021, 05:17:11 AM »
Not sure if anyone mentioned this but Sub-fleets don't seem to remember being attached to sub-fleets after you close and restart the game. All the sub-fleets are directly attached to the fleet and not whichever sub-fleet it was attached to once you save and restart.

Or I'm doing something wrong in my game,  but I usually have deep sub-fleet systems just don't close Aurora down all that often so I never bothered reporting it before.

This is unfortunately bugged from beginning, I reported it in previous versions, but it either got lost between other bugs, or Steve never got to implementing fix for this.