v2.1.1 Bugs Thread

[Kaiser]

I don't know if it is a bug or not, but let's say I moved 20 terraformer installations from Earth to Mars (so I have a supply contract on Earth and demand contract on Mars), years later I want move 10 terraformer installation from Mars to another planet. When I create the supply contract on Mars, the contract goes to the existent demand contract instead and it keep adding it as if you are editing the demand contract.

In the end, deleting the terraformer demand contract on Mars, solve the issue and I can create the correct supply contract.

The issue appears also on other bodies, except Luna where first in the game the transformers were brought in and later moved elsewhere.

I think it has something to do with the percentages, for example on Luna even if it now shows me 0 terraformers (but it shouldn't show if they are 0), when I try to edit the old demand contract it shows me like 0.0000000002

Known issue and should be already fixed for next version - Garfunkel

[rainyday]

This is related to recent fights with the Star Swarm in my AAR:


The standard swarm of FACs is a bit toothless at the moment because of how easy it is to disable one of their engines. This drops them all to 1 km/s until the damaged one is killed. It might make sense for NPRs to hold formation around a damaged ship but doesn't really fit the image of a ravenous swarm. If they were able to detach injured units and continue chasing you at full speed they would be properly terrifying at low tech.

[nuclearslurpee]

When issuing orders with an order delay, if the order involves a LP transit, the order delay is applied to the order following the LP transit, when the desired behavior is (probably) to delay the movement towards the LP instead. Example in the image below:



In this case, the desired behavior was to remain in orbit of the body for 24 hours after arrival, instead the ship will immediately move to the LP, transit, and then wait a day at this otherwise unimportant point in space.

[nakorkren]

When transferring a fleet to an NPC (admittedly in version 2.0.2, but haven't seen this addressed in the change lists), three error messages occur:

First, a single instance of 2.02 Function #5: Object reference not set to an instance of an object.
Second, multiple instances of 2.02 Function #2328: Object reference not set to an instance of an object.
Third, a single instance of 2.0.2 Function #11: Object reference not set to an instance of an object.

I got into this situation because the Raiders were about to attack my stationary fuel harvester. I figured I'd surrender it, since there was no chance of defending it and they'd just blow it up. Since the harvester is stationary, I figured they wouldn't be able to (and/or aren't programmed to) bring it a tug fast enough to move it before I could try to retake it with boarders who could arrive in a few days. I was excited to try that, since it's a fun and novel situation engendered by the new NPC and my own laxity in defending my new harvester. I'll repost after I figure out if the bugs are going to continue after I recapture the harvesters, which would be too annoying to prevent me from going back to my last save and just letting them blow up the harvesters.

Update: After I recaptured the fuel harvesters, the error messages went away. I also captured the Raider ship and sent it home to my scrapyards. I do love my heavily armored sprint-destroyers full of marines

SJW: Its not really worth reporting bugs from older versions (see first post in this thread).

[nakorkren]

As part of dealing with the Raider incursion discussed below, I used some smallish (7k) civie tugs to tug my fast destroyers (used for boarding) out to the system of interest since the destroyers don't have the range to get there with their highly boosted engines. During that movement, the ships being tugged consumed their fuel, which was annoying but expected since, as I understand it, that's WAI.

However, the other ship I tugged out there, a destroyer with particle beams for fighting Raiders, did NOT consume its fuel while being tugged. Clearly one or the other behavior is a bug. Personally I hope it's the fuel consumption of the ship under two, since I'd like to be able to use tugs to move faster ships to their destination (e.g. a combat area or a planet for garrison duty) without having to keep filling up their tanks and/or getting Out of Fuel notices.

[superstrijder15]

Right now I constantly have a popup saying "2.1.1 Function #917: Value either too large or too small for an Int32." as an error. Most recent save attached, which happened after the first time it happened but before it became continous. (inbetween I have only given a single move order to the fleet that finished a grav survey in the most recent time increment) I think it became continous when I clicked somewhere on the solar system map.

TN start, real stars, seperator is... the right thing, I've already had to change that earlier. Have not tried to reproduce or stop the game (am going to have to task manager kill it because the popup doesn't let me close it). Campaign length so far is only ~20 years.

Update: Issue keeps occuring on reload but I guess I did something different because I did not get the constant popups even after running a time increment, just one per increment.

Big Update: I just saw that Freighter Fleet 2, a fleet moving to bring some mines to an asteroid in the Kuiper belt, has "Error" for its Distance to travel and ETA, so I think they might be the issue. I looked at their specific orders and the distance said "7.558,2 b km" and a travel time of "86.187 days" I didn't realize it was this far when I created the colony. It must have gotten mineral surveyed on game start. I think that these huge distances and times may have been the problem? The object (C2017 K2) is literally the furthest from the sun from everything in Sol by an order of magnitude (and 2 orders of magnitude from #3). Perhaps a fix can be to simply delete it?

[dgibso29]

I've done some searching in the discord server & forums but haven't hit on anything useful, so apologies if this is a known issue.

I am running into an issue consistently in which destroying what I presume to be a raider ship (the first one I have seen or destroyed) results in a large number of repeating errors (attached) when its fellows arrive shortly thereafter. These errors appear tied to the sensor check, as they don't occur when I disable sensors in system via SM. I have been able to replicate this consistently by reverting to a backup before engaging the vessel.

As it's a null-ref error, I assume this is probably a game breaker, but any insight appreciated! I would rather delete the raiders entirely if possible (or just their presence on Sol) if it solves the problem, so guidance there would also be welcome.

Info for Steve:
Function Numbers: 1954, 1943, 478
Complete error text for all three: Object reference not set to an instance of an object.
Window Affected: System View / Main Game Thread
What I was doing: As stated above!
Conventional Start
Real Stars
Decimal separator is a period
As noted, this is consistently reproduceable. I have attached the database from shortly *before* destroying the ship in question.
This is year 47 of the campaign.





Thanks!

[Treahblade]

I have a odd one.
I moved a repair shipyard from earth to Mars which is another colony and once it arrived it spawned another shipyard for a new race which has the same race portrait and everything as me with the highest diplomacy rating.
You will get a notification that a new race has been detected after the order to move the yard is complete and the new one spawns in.
Another odd thing is that if you then move time along it wont move with the planet on the 5th day but will snap back to the planet if you increment time by 5 seconds or something, like it has engines.

Attached are 2 screenshots of the issue.

This is a Real Stars game and is 53 years in.
I was running the AuroraPatch mod with the Solaris Theme orginally but did test this out on a Vanilla version and had the same thing occur.

Steps to reproduce.
Build a repair shipyard
Tow it to another colony.
It will spawn a new one either when it arrives or while in transit.

Another person on discord also tried this and had the same result.

SJW: I can't reproduce this one.

[Jeltz]

I think this is the right place for post...

At a certain point in the game, if I open the Create Research Project window and select Jump Engines, the error "Function #1050" is generated (screenshot in  attachment).
As you can see, the drop down text box relating to the Engine Size is empty: if I click OK in the error message and choose a Jump Engine Size value, the error is not generated and the game seems to continue normally.

I did some testing: the problem seems *certainly* caused when it is discovered the "Minimum Squadron Jump Engine Size - 8" technology:
- until it is completed the error does not occur,
- as soon as the technology is completed the error is generated,
- if I pause the development of the technology the error is not generated ...

The error is easily reproducible (I can supply the database) simply by allowing the necessary time to pass.


Complete error text: "2.1.1 Function #1050: Object reference not set to an instance of an object"

System:
Windows 10 21H2
Decimal separator: dot
Aurora version: 2.1.1 vanilla, no mod. (added only some flags an ribbons)
Conventional start
Real star

Regards
-J-

SJW: Fixed for v2.21 - just ran into this myself.

[nuclearslurpee]

I've been unable to generate a new game with random stars. Game freezes after player race creation, and when I reload I just get a blank screen where clicking on anything throws an error from Function $155. With real stars turned on it works okay. DB attached, I don't believe I've done any modding beyond tweaking a few tech or component names/values. I recall there was a bug about this in v2.0 - maybe something in that wasn't completely fixed?

SJW: Fixed for v2.2

[Ragnarsson]

I've been unable to generate a new game with random stars. Game freezes after player race creation, and when I reload I just get a blank screen where clicking on anything throws an error from Function $155. With real stars turned on it works okay. DB attached, I don't believe I've done any modding beyond tweaking a few tech or component names/values. I recall there was a bug about this in v2.0 - maybe something in that wasn't completely fixed?

I think this is an intermittent problem with all system generation in random stars games. I reported a similar bug in v2.0.2 that I believe to be a different manifestation of the exact same issue, and I don't think it was ever addressed.

http://aurora2.pentarch.org/index.php?topic=13028.msg161111#msg161111

SJW: This should also be fixed now

[nuclearslurpee]

When trying to set a minimum rank for automated assignment to naval admin commands, it seems that setting the rank is trying to select the ground commander rank instead of the (listed) naval commander rank, which then fails to work with automated assignment. See attached image for visual explanation - no, my abbreviation for Admirals is not "GG", this is the abbreviation for my equivalent ground commander rank (Grand General). Same happens for lower ranks, but Grand Admiral (rank 7) and higher seem to work okay, as do R2 through R4 - so whatever is happening seems very inconsistent.

Save, quit, and restart does not correct this. I've searched and have not seen a report or 2.2.0 bugfix for this.

EDIT: Looking at the FCT_Ranks table in the DB, it looks like the issue is happening where the ground commander rank (RankType 1) has a lower RankID than the equivalent naval commander rank (RankType 0), which is the case for my R5 and R6 ranks where I am having the problem. Guess that means the workaround is to delete and re-make the R5 and higher ground commander ranks, and the fix is to select only RankType 0 in whatever routine is handling this.

[Gyrfalcon]

I'm also experiencing this same exact issue.

[Ghrathryn]

I'm not sure if this has been spotted and reported before or not, but I've got two issues at present.

Firstly designing a prototype using 'next tech' seems to result in the prototype not detecting that the missing research to allow it has been completed leaving it forever as a 'Future Prototype' even when you can recreate it without any extra theoretical tech. It can be worked around by recreating the exact settings for a new research project/prototype, but it means that you can't tell the previous itteration to be made into a research project for your queue.

The second one I believe has been spotted, or at least there's a couple of threads on something similar. UK officer ranks, some organisation set up with the various Admin Commands having their lowest rank as Commodore (rank 4). Currently no ships requiring above Rank 1 resulting in the admin commands not having anybody taking control because nobody is reaching Commander (Rank 2), much less Captain or Commodore. Realisitic promotions on and it's around 50 years in.

Hopefully issue 2 will self-resolve soon since I'm close to building ships requiring Commanders and likely not too far from needing active Captains since I believe this is from the rank ups as required change in the program still needing some tweaks.

If you want them, I've dropped a copy of the save (Commonwealth Rising) and a screen of the prototype issue on the post.

[lumporr]

Found an odd bug.

In attempting to make a save of a specific scenario to revisit, I found that hostile ground forces would cease to oppose mine if I copied the DB, renamed it, and then copied it back to the Aurora folder and renamed it back to AuroraDB.db.

I have reproduced this bug three times in a row. Each time, I confirmed the opposing NPR was indeed hostile and fired on them using STOs, at which point they retaliated with ship-based weapons, but never with ground forces. Eventually, the population surrenders (or in the case of insufficient occupation forces, shows the relevant message), even though I confirmed in the database that enemy ground forces were present. To clarify - upon creation of the NPR, hostile ground forces oppose mine as normal - however upon saving, moving the file and reloading, they do not.

I have attached the database after the moving, renaming, and re-renaming, if that would be of any help, but the bug is easily and consistently reproducible, so one could test it on their own if they'd like. (The scenario I'm working on is pretty cool though, and has a lot of work put into it, so you could check that out if you're inclined - it's mostly why I felt the need to post this bug - because I want to eventually want to share it without incident, while being able to name the file something other than AuroraDB).

v2.1.1, unmodded.