By my calculations, the planet in question appears to have a density of 2. 2 g/cm³ which seems reasonable.  Mars is 3. 9 g/cm³ for comparison.

Quick maths:
    M = (a_g * D²) / (4 * G)    where G = 6. 67E-11 in SI units.
    V = (PI / 6) * D³
  rho = M / V = (3 * a_g) / (2 * PI * G * D)


Mars: rho = (3 * 0. 38 * 9. 81) / (2 * PI * 6. 67E-11 * 6. 8E6) = 3. 9 g/cm³.
Tau Ceti VII: rho = (3 * 0. 91 * 9. 81) / (2 * PI * 6. 67E-11 * 29E6) = 2. 2 g/cm³.

Note that the gravity isn't actually the same as Mars (0. 91 Gs vs 0. 38 Gs), but if it were the density would still be a comfortable 0. 92 g/cm³.

You can also check the density in SM mode by selecting the body and clocking the "Modify Body" button in the lower-right panel.  I'm fairly sure this density is used to compute the gravity, not vice-versa, so you can be assured that the range of values is reasonably realistic.   

You're right, I was meaning Venus and typing too late at night.  And its density is indeed . 4 of Earth's, which is 2. 2g/cm³ as you say.  I think I was just thrown off a bit by the 62b max population, which is about three times higher than the next largest I've seen, at a lower gravity than Earth's.

A possible bug, though it may also be `the wonders of space': I've found a planet of unusually low density - included in the attached screenshot, it has the same gravity as Mars but over 13 times the volume.  By my calculations, it has a density of a little under 0. 29g/m³.  For comparison, pumice has a density of 0. 25 g/m³.  Maybe it's a Naboo-style planet with a cave system at its centre?

Quote from: IceKobold on September 13, 2023, 09:05:27 AM

I'm not sure if this is a bug, or just something I don't understand.   But I have a group of hostile contacts which I keep losing contact with each pulse (regardless of length)  and then re-establishing contact with 5 seconds into the next pulse. . . even when they're deep inside my active sensor range.   It's too quick for them to be transiting an unknown warp point and coming back, right?  Let me know if there's anything else that'd be useful.

This is not a bug. These are Raiders; looks like they are popping into the system through their super-sneaky not-a-jump-point, seeing your active sensor, getting scared, and immediately jumping out.

Steve - It might make sense to change this AI behavior even though it's not a bug. This is the same kind of thing as the AI jumping through a jump gate every 5 seconds and that was changed as it leads to a similarly poor gameplay experience. Maybe this is already fixed in 2.2 though, I recall there is a change so the AI remembers contacts for a while now.

I've added some new Raider mechanics to address this:
http://aurora2.pentarch.org/index.php?topic=13090.msg166201#msg166201

"2.1.1 Function #1954: Object reference not set to an instance of an object."
"2.1.1 Function #1943: Object reference not set to an instance of an object."
"2.1.1 Function #478: Object reference not set to an instance of an object."

The error codes relate to identifying alien ships. This is relatively short code that runs all the time without issue, so there must be something unusual in this case. The only option seems to be that the attempt to identify is looking at a ship without either a parent class or a parent race somehow. It could be related to your manual creation of the ships, but even that is not particularly unusual.

Unfortunately, I don't have a v2.1 version of the code to test this on and your current DB won't work with the v2.2 code.

Stuck in never-ending loop of "2.1.1 Function #1954, #1943 and #478: Object reference not set to an instance of an object." errors.

EDIT: After searching a bit better, saw Steve's post about it maybe being related to detection. I opened the game again and SM-moved my two Player Empire surveillance ships which were approaching the Cylon colonies back to Earth, and now I can advance time without the errors appearing. Sending even one ship back to the planets causes the errors to start appearing as time advances; once the ship arrives on station in detection range the error loop continues forever. Re-opening again, and turning the active sensors off on the Mk. II Cylon BDB's still triggers some errors, but they stop after holding down Enter for a second or two and time advances.

In a second test, I SM-ed away my surveillance frigates (which carry thermal sensors, EM sensors, and an ELINT module. I then sent a commercial Tug to within 1m KM of the new Cylon colonies, and no errors appeared. It wasn't until I sent a surveillance ship to join the Tug that the error cycle returned. Surveillance ships at older Cylon colonies in Sol do not have the issue.

In a third test, deleting the Mk. II Cylon BDB's allowed the surveillance ship to get within 1km of the colony without errors. Insta-building a Mk. II Cyclon BDB into a fleet located at the colony the Surveillance ship was within 1km of caused the error cycle to begin again.

Last update, it seems as if a surveillance frigate approaches a Mk. II Cylon BDB the errors begin. I instead insta built 4 of the original Cylon BDB desisgns at the colon 1M by the frigate, and no errors occur.

DATABASE MODIFICATION: All Particle Beam sizes (except for PB-2) set to a size of 300 tons prior to game creation, similar to the upcoming v2.2.0

TN Start
Random Stars (Starting Sol System)
86000 Construction Cycle Time
20% Research Speed
Local System Gen chance 50%
Local System Generation spread 15%
NPR Generation Chance (by Player) 75%
NPR Generation Chance (by NPR) 10%
Ruin Generation Chance 50%
All spoiler generation enabled for Player and NPR
One Second Sub Pulse Enabled

Game in the DB is titled "Waiting for 2 dot 2" and is just shy of 13 years into a play-through with 2 Human players, one main empire and then 1 general boogeyman (Cylons) that I use to spawn a defense colony with a ton of ground forces on newly discovered planets with minerals or alien ruins. I also generated 1 NPR at game creation, but have not encountered an NPR yet in game. Maybe about 5-years into the game, I also imported Froggiest1982's excellent medal pack from here: https://aurora2.pentarch.org/index.php?topic=11424.0 , and it has been working great auto-awarding medals.

I recently explored my JP #1 in the starting Sol system. When I first tried to explore it, the game hung processing, and after ~15 minutes I used end task to stop. I restarted the game and explored JP#1 again, generating the new Proxima Centauri system. I then used Space Master to switch to the Cylon empire and did the following:

1. Explored the same Jump Point for the Cylons to see the new system (2 Planets, 1 Dwarf Planet with 1.9 colony cost).
2. Spawned a ruin and HW minerals on the Dwarf Planet.
3. Created Colonies on 1 planet with a large amount of minerals (Proxima Centauri I-A) and the dwarf planet (Proxima Centauri II-A).
4. SM-edited the environments of both planets to be habitable from the Economics window.
5. Edited the Diameter of the dwarf planet (Proxima Centauri II-A) in the System window using "Modify Body" to first change it from 400 to 500, then 500 to 600.
6. Went through the Civilian tab of Proxima Centauri I-A to spawn a pile of colony buildings, including auto mines, military academies, naval HQ, financial centers, etc.
7. Used "Edit Pop" to set a I-A's colony pop to 50M.
8. Used the GU training tab in Economics to build a large army (~55 formations).
9. Used instant research to increase Cylon technology in Particle Beam strength and armor.
10. Copied the Cylon "Salamander" Beam Defense Base Class to create an updated Mk. II version of the class with the new PL-9 beams, updated the armor, and added a power plant.
11. Went to Cylon Fleet Organization and created 2 new Defense fleet for Proxima Centauri I-A and II-A, used the miscellaneous tabs to move the empty fleets to their respective planets
12. Insta-built 2 BDB Salamander Mk. II's into the Proxima Centauri I-A's defense fleet, and 1 into Proxima Centauri II-A's defense Fleet.
13. Enabled Active Sensors and shields for the two new defense fleets.
14. Went to the Civilian tab of Proxima Centauri II-A to spawn a pile of colony buildings, including auto mines, military academies, naval HQ, financial centers, etc.
15. Used "Edit Pop" to set II-A's colony pop to 50M.
16. Used the GU Training tab to build a large army (~30 formations)
17. Edited I-A's Pop up to 75M.
18. Went to the ground units tab and designed v2 versions of the Cylon ground forces to use the new armor and racial weapon score.
19. Marked the original ground force versions as obsolete
19. Created v2 versions of the Cylon Ground Formations, did not obsolete the original ground formations.
20. Insta-GU-trained a limited number of the v2 formations on all existing Cylon Colonies in Proxima Centauri and Sol.
21. Switched back to Player Empire, sent two surveillance frigates to set up positions 1M km from Proxima Centauri I-A and II-A.
22. Advanced time, got a few pop-ups of "Object reference not set to instance of object" errors until time stopped with the enemy Cylon pops being detected.
23. Saved
24. Now attempting to advance time even 5 seconds produces a constant cycle of the following errors. I can hold down enter as long as I want and the errors never stop, I need to "End Task" to exit Aurora. Re-opening Aurora and trying to advance time repeats the same series of errors.

"2.1.1 Function #1954: Object reference not set to an instance of an object."
"2.1.1 Function #1943: Object reference not set to an instance of an object."
"2.1.1 Function #478: Object reference not set to an instance of an object."

Yes, there is no doubt that loops are possible in Random Stars, at least if Local generation chance is cranked up to 95+.   In Known Stars however I strongly suspect they are not

SJW: Jump loops are fine in Known Stars

Hello, I would like to post some additional considerations and add some more test results to this report.  Thank you Steve for taking the time to review this, I wouldn't want my post to look like i'm denying your expertise, rather i would like to think that i'm adding new information to this search.

I have run a further several tests, by using a version of Aurora patched (exe+db replacement) to 2. 1. 0.  I have it set up with two executables:
the 2. 1. 1 . exe from 6. 9. 22, and
the 2. 1. 0 . exe dated 16. 8. 22.
I have used those 2 executables, running them from the same aurora folder, to generate several Known Stars maps (50 stars each).  The 2. 1. 0 executable generates looped maps quite reliably, but the 2. 1. 1 executable does not, instead it always creates a new system for every jump point, with the amount of tries that i think should at this point exclude considering RNG as a reason.
I'm attaching 2 sample maps, and here are my numbers:
the 210 executable was used to generate 50 systems, and made 3 connections to pre-existing ones, remarkably close to the 0. 065 rate.
the 211 executable was used to generate 177 systems in the last test, creating 0 loops.  If the rate of looping back to known system was indeed 0. 065, the chance of this happening can be calculated as (1-0. 065)^177, a very small number close to 7/1000000
related or not, another thing i never observed it creating are deadends
Thank you again for taking time to look into this matter Steve.

STOs on a planet without DST installations do not display weapon range.

This is the same issue I raised as a question not worth its own thread.
http://aurora2.pentarch.org/index.php?topic=11545.msg165953#msg165953

I dont know if this is a bug or intentional but my reasoning is that since STOs have their own active sensors and passive sensors (in DSTs) do not contribute to the function of weapons you would expect weapon ranges to display for STOs with active sensors regardless of whether or not there was a DST at the same pop.

So I am reporting it as a bug, FYI, just in case.

SJW: Yes it's a bug. Fixed for v2.2

Quote from: boolybooly on October 09, 2023, 12:20:26 PM

Is anyone else noticing that when you display fire controls the text label reports 20x their range? (Plus it uses a k for units.) e.g. FC range 128,000 km  reports as 2560000k.

I can confirm this.

OK, thanks that is useful to know. I was beginning to worry about my instal.

It would probably be worth mentioning this is BFCs, MFC range display seems to be functioning as expected.