Updates to the Sol System

[Steve Walmsley (OP)]

Today's Sol update includes an additional fifty moons, split between the following planets (new total in parantheses):

Jupiter: 7 (22)
Saturn: 15 (29)
Uranus: 16 (28)
Neptune: 5 (14)
Pluto: 2 (3)
Quaoar: 1 (1)
Orcus: 1 (1)
Haumea: 2 (2)
Eris: 1 (1)

I have replaced the random Sol comets with 25 real comets. The furthest point of their orbit from the Sun is correct for all the real comets but the current distance in that orbit will be randomised for each game. There are now 619 distinct system bodies in Sol, including planets, moons, asteroids and comets. All of these are real-life objects.

The first screenshot shows a few of the comets. The asteroids scattered between Jupiter and Uranus are Centaurs. The line of the asteroids in the top right are Neptune's leading Trojans, scattered around the L4 Lagrange point. Neptune is outside the field of view, which is why there is no orbital path. The second screenshot is of the inner system and includes several more comets. As you can see, the inner Sol system is looking a lot more interesting than before.





Steve

[schroeam]

Wow Steve, that is a ton of work.  Great Job and thank you.

Adam.

[Steve Walmsley (OP)]

Three more changes for v5.70.

Trojan asteroids can now appear in systems other than Sol in the L4 and L5 points of gas giants and super-jovians. The chance of Trojans being generated and the number generated is based on the cube root of the associated planet's mass.

I've corrected the problem in system generation that can sometimes lead to missing numbers in the roman numerals assigned to planets. For example, in v5.60 you might see Sirius I, Sirius II and Sirius IV as the first three planets in a system. In v5.70, all the planet numbers should be consecutive.

I've changed the ordering of system bodies in the F9 window. Because of the proliferation of asteroids in systems, displaying them in a meaningful way in relation to planets is problematic. Therefore, all asteroids in a system will now appear in one group after all planets and moons. The asteroids will be in order of distance from the star. Comets will appear in one group after asteroids.

Steve

[Garfunkel]

Sweet jesus this is awesome. 

[Mel Vixen]

Steve: With the new Moons, trojans and dwarfplanets is the TN-Mat amount and distribution in sol going to change too? I mean in significant ways.

[Steve Walmsley (OP)]

Steve: With the new Moons, trojans and dwarfplanets is the TN-Mat amount and distribution in sol going to change too? I mean in significant ways.

I have been thinking about impact of the changes on mineral availability. There are no coding changes so any change will be as a result of the increased number of bodies in the system. I think there may be more sources of accessible minerals but probably no greater number of very large deposits.

Steve

[Marthnn]

Question. Asteroid modules currently operate on asteroids and comets only. Will they work on trojans, dwarfplanets, moons the size of an asteroid? It might be relevant to use a criteria based on the size of body. Your thoughts?

[Steve Walmsley (OP)]

Question. Asteroid modules currently operate on asteroids and comets only. Will they work on trojans, dwarfplanets, moons the size of an asteroid? It might be relevant to use a criteria based on the size of body. Your thoughts?

An interesting point. At the moment they work on comets and asteroids only, which includes Trojans as they are just asteroids located in the L4/L5 lagrange points (and named asteroid #1, asteroid #2, etc. in non-Sol systems). Comets are included because they are similar to asteroids. In fact, some objects (known as Centaurs) could be classed as both an asteroid and a comet. These are all classed in astronomy terms as Minor Planets. The asteroid modules don't work on dwarf planets or larger. The only actual change is that they used to work on Ceres and now they don't.

There are some moons smaller than some asteroids though, especially since I added the extra moons. My concern about making them work on a size basis is that the current system is nice and clear. Asteroid modules work on asteroids - they don't work on planets or moons.

We could change them to perhaps Orbital Mining Modules and have a tech progression based on the maximum radius of the target body - perhaps tied to lasers as a pre-requisite. The issue now is that players would have to check the size of every body before making decisions about their deployment. They would want to see that size in a lot of places. On survey ship/team reports, the minerals sidebar of the system map, on the Geological Survey window, maybe even the actual graphical system map and certainly on individual colony summaries. All of that is possible and probably not that difficult. I guess the question is whether players want that extra level of micromanagement. Anyone have strong opinions on this?

The technobabble supporting the asteroids-only method is that asteroids are fragments of unformed planets and therefore the TN Minerals are not at the core and are easier to access, even for larger asteroids. Of course, some small moons are captured asteroids

Steve

[wilddog5]

What about having it depend on the bodys gravity less than 0.1 Asteroid modules work, more they don't, tec babble is that i takes to much power/fuel to hold over a body for a long period of time if the grav is to high

[xeryon]

I don't mind asteroid modules only working on asteroids/comets.  Needing to check sizes all the time would be an extra burden.  Having the efficiency of the modules be a research line would be a nice touch though.

[Mel Vixen]

I too would go with gravity based (instead of size) for this. But i wouldnt mind if you keep the old system.

[chrislocke2000]

Personally i would leave as is otherwise, as you state, it becomes serious micro management.

One other thing for 5.7 - any chance you can tweak the AI so NPRs leave there AM sensors on and also give them a minimum range for both sensor and fire control? This should substantially increase the challenge of all hostiles encountered and remove the ease of gaming an NPR with large volleys.

[Steve Walmsley (OP)]

What about having it depend on the bodys gravity less than 0.1 Asteroid modules work, more they don't, tec babble is that i takes to much power/fuel to hold over a body for a long period of time if the grav is to high

Possible, but take the micromanagement concern above and replace every reference to size with a reference to gravity and the same issue remains.

Steve

[Steve Walmsley (OP)]

One other thing for 5.7 - any chance you can tweak the AI so NPRs leave there AM sensors on and also give them a minimum range for both sensor and fire control? This should substantially increase the challenge of all hostiles encountered and remove the ease of gaming an NPR with large volleys.

This isn't straightforward because all sensors on a ship are on or off at the moment. I agree it is a good idea though so I will try to find a way to keep NPR AM sensors on even when their search sensors are off for v5.70.

Steve

[Elouda]

This isn't straightforward because all sensors on a ship are on or off at the moment. I agree it is a good idea though so I will try to find a way to keep NPR AM sensors on even when their search sensors are off for v5.70.

Steve

Steve, a thought since I know Ive mentioned the 'individual sensor toggle' thing before and you've explained why its hard to do - what about just splitting sensors into 2 categories, AMM (res 1) and others (res >1). That way we could have some finer control, and the AI could keep their AMM sensors on as suggested.

Thanks for all the great stuff, cant wait. ^^