Aurora 4x
VB6 Aurora => VB6 Mechanics => Topic started by: Steve Walmsley on April 01, 2012, 07:46:37 PM
-
I've updated the Sol system, adding the dwarf planets and correcting the density, gravity, mass and escape velocity for all the major moons.
The new dwarf planets added are Ceres, Eris, Haumea, Makemake, Orcus, Quaoar and Sedna. As they have such long orbital periods I have used their current distance from the Sun rather than their average distance. Pluto is also now classed as a dwarf planet. Those planets and any planets that used to be listed as "Chunks" will now be listed as dwarf planets in the F9 view. I considered adding the moons for the new dwarf planets but the data on them is extremely limited so I haven't for the moment. I'll probably come back and tackle that at some point though.
There were some significant mistakes in the physical data for many of the existing moons. In fact, some were so wrong I can't imagine where I got the original information. I have used the Wikipaedia entry for each moon to source the updated information. This will result in some changes in terms of possible colonization as Titan's gravity has dropped considerably.
After Mars/Mercury at 0.38g, the highest gravity can be found on:
Io: 0.183
Luna: 0.165
Ganymede: 0.146
Titan: 0.140
Europa: 0.134
Callisto: 0.126
Eris: 0.084
Triton: 0.079
Pluto: 0.067
Haumea: 0.044
Sedna: 0.043
Makemake: 0.041
Titania: 0.039
Quaoar: 0.038
Oberon: 0.035
To make life a little more interesting, I am going to widen the range of racial gravity tolerances possible for a new race. A random race will have from 50% to 90%. Humans will start with 90%, which makes the Moon, Titan and the Galilean moons all possible colony sites and will widen human options in other systems. I've also halved the "Genome Sequence: Base Gravity" research costs.
In the past the mean surface temperature of the Earth in Aurora has been 22C. I've now changed it to the correct value of 14C. I've also increased the base human temperature range from 22C to 24C, giving a range of -10C to 38C, which seems reasonable in terms of the environments in which humans live in Earth. -10C might be a little on the chilly side but we can survive reasonably well without space-age infrastructure to assist.
Finally, I have updated the Known System data in Aurora with the work I did for Newtonian Aurora. There are now 4250 Known Systems in the database, including all known systems within 100 LY of Sol.
Steve
-
Very nice. Makes it a lot easier to do the outer system colonies vs earth/inner system game that I'd been thinking of doing.
Any chance of getting the correct images assigned to each planet/major moon? While minor and we can do it ourselves, it is a litle annoyng having to do it each time starting a new game, and I keep getting the images for the moons mixed up.
-
I really appreciate the increase in accuracy of Sol bodies. It gives a good perspective on our own home system. Having Humans as reference race is nice too. Thanks Steve.
-
In the past the mean surface temperature of the Earth in Aurora has been 22C. I've now changed it to the correct value of 14C.
Global warming my arse ;)
-
Very nice. Makes it a lot easier to do the outer system colonies vs earth/inner system game that I'd been thinking of doing.
Any chance of getting the correct images assigned to each planet/major moon? While minor and we can do it ourselves, it is a litle annoyng having to do it each time starting a new game, and I keep getting the images for the moons mixed up.
I have updated the images. There will be 3-4 new ones in the patch for those that were missing.
Steve
-
I made a custom planetjpeg folder for my games with some real images for Sol planets and most important moons. I also changed the default random planet/moon images. I will share it with you if that helps for something.
The real planet and moons are named after the first or last 3 letters of their name, as Aurora only admit 3 letters. I hope you may find it useful.
File name: Planetjpeg.rar File size: 3.49 MB (http://www.fileserve.com/file/kc6mvgq/Planetjpeg.rar)
-
I vote to keep Pluto as a major planet in the Sol System for Aurora as the IAU definition is not as widely accepted by astonomers as the IAU would like you to believe. The definition of a Dwarf Planet is flawed and not quite scientific or logical. It has been known as a planet for more than 75 years, and to change its status with a poor definition and process, is bad science. Just my 2 cents. Leave the others as Dwarf planets or Kuiper belt objects. I also think we risk upsetting the Plutonians when they find out .....After all these years and they suddenly find out they are not living on a planet ....They might turn nasty ...
-
Pluto will remain as a regular planetary object on the map, only the classification in the system details window changes. Like in real life.
The Fungi from Yuggoth do not follow out puny civilization's antics anyway.
-
Another change. It turns out that planets have been orbiting in the wrong direction all this time :)
They should orbit anti-clockwise (counter-clockwise for the US) but until now they have been orbiting clockwise - oops!
As Aurora Lagrange points are at the L5 location, they will still be following planets in their orbit but the change in orbital direction for v5.70 means they will be on the other side of the planet from where they are now (i.e clockwise from planetary location rather than anti-clockwise).
Steve
-
It's fine. We were just looking at the galactic plane from the other side.
-
It's fine. We were just looking at the galactic plane from the other side.
LOL! Excellent point!
Steve
-
Oh, these changes sound good!
-
Another Sol Update. Long ago, I created the existing Sol - Mars asteroid belt in the current Sol system by generating systems until I got a suitable asteroid belt at the right distance and then transplanting it into the Sol system in the database. Saved all the entry of asteroid data :)
However, now I am on a Update Sol campaign I decided to got for something a little better. I removed the 179 Mars - Jupiter asteroids from the DB and replaced them with over 300 actual asteroids from Sol, with the correct names, sizes, distances and physical data (gravity, escape velocity, etc.). Within these 300+ new asteroids are regular Mars - Jupiter main belt asteroids, a number of Jupiter trojans (which occupy the area around the L4 and L5 lagrange points of Jupiter, some near-Earth asteroids, such as Apophis, Apollo, Cruithne, etc., a few Neptune trojans and several Centaurs located between the orbits of Jupiter and Neptune. This makes the inner Sol system a much more interesting place.
I've spent the last two evenings entering asteroids on to a spreadsheet before importing them into Access. A serious sign of uber-geekness is that I actually enjoyed tracking down all the data :). Now I need to recharge my enthusiasm batteries before tackling the outer system objects and perhaps some real comets for Sol instead of the random ones.
Here are a couple of screenshots. The first shows the main belt, near-Earth and Jupiter Trojan asteroids. The second shows the Centaurs and the Neptune Trojans
(http://www.pentarch.org/steve/Screenshots/Asteroids.PNG)
(http://www.pentarch.org/steve/Screenshots/Asteroids2.PNG)
-
Two things:
One, I love these progress updates!
Two, I hate you for these progress updates! I want to start a new campaign, but I know that the moment I do, you'll release this update!
I am looking forward to the new Sol.
-
I removed the 179 Mars - Jupiter asteroids from the DB and replaced them with over 300 actual asteroids from Sol, with the correct names, sizes, distances and physical data (gravity, escape velocity, etc.).
*looks at screenshot*
Oh. Man. I already imagine myself trying not to mix small moons such as Saturn's Iapetus with asteroids having names like Laetita.
Another big thanks. I'll certainly start a new campaign next version. Can't wait!
-
With this much more real estate it looks like a Sol only game might even be possible. Will you be applying the modified features of Sol into the system generation algorithms? Some of these features would not be unique to our system and should randomly generate in other systems as well.
-
That looks really cool! Thanks for all the hard work.
-
Thanks for all the hard work.
This most of all. Having experienced about 11 years worth of various mods, games, maps, etc, I have seen my fair share of failed ideas, and participated in a few of them! But, Steve, you are among a select few who have a stunning level of dedication. And it's great, I love that Aurora has such history and continues to evolve.
Tl;dr, Thanks, Steve. Aurora is in my top 5 favorite games of all time, and I hope to start writing some fiction with it in the future.
-
Steve, a question: Assuming I turn off Asteroid orbits, will that mean that the Trojans won't orbit either?
If so, can you possibly separate Trojans from normal asteroids in that respect? Or turn them off when asteroid orbits are off at the start? Or just have an option to remove them at the game start? Because otherwise it would look... weird compared to other asteroids since they'll be in a line in the middle of nowhere compared to the circle that the asteroid rings are.
-
Separation of the asteroids from the planets visually is a good idea imo. Grey maybe?
-
Steve, a question: Assuming I turn off Asteroid orbits, will that mean that the Trojans won't orbit either?
If so, can you possibly separate Trojans from normal asteroids in that respect? Or turn them off when asteroid orbits are off at the start? Or just have an option to remove them at the game start? Because otherwise it would look... weird compared to other asteroids since they'll be in a line in the middle of nowhere compared to the circle that the asteroid rings are.
Yes, I am planning to separate Trojans from regular asteroids. They will orbit with the planets rather than with the asteroids.
Steve
-
Separation of the asteroids from the planets visually is a good idea imo. Grey maybe?
Yes, I agree that asteroids probably should be a different colour, or maybe planets just have larger icons. There does need to be some visual differentiation between the two. I might also add the ability to turn off dwarf planet orbital paths as they will tend to clash with the asteroid belts.
Steve
-
Another update:
At the moment, the planets, moons and asteroids in the Sol system are always at the same point in their orbit at the start of every game. From v5.70 onwards, every body in the Sol system will be assigned a random point in its orbit at the start of each new Sol-based campaign. This means every game will be unique in terms of the Sol system starting layout.
Steve
-
Yes, I am planning to separate Trojans from regular asteroids. They will orbit with the planets rather than with the asteroids.
Steve
Yay!
Another update:
At the moment, the planets, moons and asteroids in the Sol system are always at the same point in their orbit at the start of every game. From v5.70 onwards, every body in the Sol system will be assigned a random point in its orbit at the start of each new Sol-based campaign. This means every game will be unique in terms of the Sol system starting layout.
Steve
Hooray!
This just keeps getting better and better.
Anyway, I think you missed xeryon's question, Steve:
Will you be applying the modified features of Sol into the system generation algorithms? Some of these features would not be unique to our system and should randomly generate in other systems as well.
-
With this much more real estate it looks like a Sol only game might even be possible. Will you be applying the modified features of Sol into the system generation algorithms? Some of these features would not be unique to our system and should randomly generate in other systems as well.
I plan to add some of these features at some point. The most likely candidates are trojan asteroids. I may also increase the chance of asteroids appearing a long way outside the main belt.
Steve
-
More Asteroids!
I have removed the Kuiper belt (185 random objects) from the existing Sol System and replaced it with a further 161 real-life asteroids. These break down as one hundred and thirty-five Trans-Neptunian objects (TNO), eighteen more Jupiter Trojans, two more Neptune Trojans, the three known Mars Trojans, the single Earth Trojan and two more Centaurs.
Some of the TNOs have high eccentricity orbits and for the moment Aurora only supports circular orbits. Of course, this doesn't make a lot of difference in game terms because some of these eccentric orbits are thousands of years and in a normal game's timescales the body would only cover a tiny fraction of that orbit. Therefore, where I can find information on the current distance of an object, I have created a circular orbit at that distance. Where I can't find that information, I have created a circular orbit based on its semi-major axis.
Because the orbits of the new dwarf planets can be close together and are in the midst of the asteroid belts, I have made them a separate category in terms of turning off orbit paths, names, etc..
(http://www.pentarch.org/steve/Screenshots/Options.PNG)
The first screenshot shows the outer system with the updated outer asteroids. Dwarf Planet orbital paths are turned off. Note Pluto in the inner edge of the belt at about 11 o'clock. The second screenshot shows the increased number of Jupiter Trojans and the extra few inner system asteroids. Note that because the new random bearing changes that Jupiter is starting in a different point of its orbit. The bearings of the Trojan asteroids will also be randomised within a 20 degree section of arc with the midpoint in the L4 and L5 lagrange points of their parent planet (depending on whether they are L4 or L5 Trojans). In reality the Trojans cover about 26 degrees of arc but there are a lot more asteroids in reality too. The Trojans (and all other bodies) will still retain their exact orbital distances even though the bearing are randomised
(http://www.pentarch.org/steve/Screenshots/Asteroids3.PNG)
(http://www.pentarch.org/steve/Screenshots/Asteroids4.PNG)
Steve
-
looking good Steve !
When can we expect the update ??
-
When can we expect the update ??
-
Looking good. Though it might have been said already...
When can we expect the update ??
-
looking good Steve !
When can we expect the update ??
Over the Easter weekend at some point (I hope!)
Steve
-
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.
(http://www.pentarch.org/steve/Screenshots/Comets.PNG)
(http://www.pentarch.org/steve/Screenshots/Asteroids5.PNG)
Steve
-
Wow Steve, that is a ton of work. Great Job and thank you.
Adam.
-
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
-
Sweet jesus this is awesome. ;D
-
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: 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
-
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?
-
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
-
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
-
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.
-
I too would go with gravity based (instead of size) for this. But i wouldnt mind if you keep the old system.
-
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.
-
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
-
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
-
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. ^^
-
With regards to the asteroid module stuff;
Moons already track whether they're 'Terrestrial' or 'Chunk', right? Perhaps you could use that field to make the determination of whether or not a moon is mineable - if it's a captured asteroid (or dwarf planet or whatever), it would be available for asteroid mining modules. That seems to me to be a decent compromise between having to crunch the numbers to tell if a body is too large/small and only being able to mine in asteroid belts. All the player would need to do would be to scan along the Body Type line in the system display window to pick new targets.
I don't know if that would have repercussions for system generation or the like, though.
-
With regards to the asteroid module stuff;
Moons already track whether they're 'Terrestrial' or 'Chunk', right? Perhaps you could use that field to make the determination of whether or not a moon is mineable - if it's a captured asteroid (or dwarf planet or whatever), it would be available for asteroid mining modules. That seems to me to be a decent compromise between having to crunch the numbers to tell if a body is too large/small and only being able to mine in asteroid belts. All the player would need to do would be to scan along the Body Type line in the system display window to pick new targets.
I don't know if that would have repercussions for system generation or the like, though.
It isn't hard to do this, or the size or gravity, from a programming point of view. It's all about the extra micromanagement. If we used the above for example, anywhere that a player would look at mineral deposit information, they would also need to know whether the moon was a 'chunk'.
In fact, if we reduce whatever method we use to a simple "This can be mined with asteroid miners" flag (whether the underlying reason is gravity, size or body type), players would still want to see that flag on survey ship/team reports, the minerals sidebar of the system map, the Geological Survey window, individual colonies summaries and perhaps even the actual graphical system map. It would add a extra level of lookup to what is an easy lookup at the moment.
However having said all that, it just occurred to me that in the Sol system at least, because I just named all the asteroids, it will no longer be obvious from the name whether the body is an asteroid and therefore a suitable target for mining modules :). Therefore I probably do need to add a "can be mined with asteroid miners" flag. If I am doing that, I guess we can revisit the parameters from what is an acceptable target body.
Steve
-
add an "(AM)" Asteroid module tag to the bodies name, that can be toggled with a tickbox for those who dont want/need to see it, in the system map, the system generation and population screens?
-
I think I'd prefer a diameter-based or gravity-based option instead of an arbitrary limit. It really depends on what kind of description you want to apply to asteroid miner harvesting: is it because the minerals are on the surface since asteroids are chunks of unfinished planets, or because the low-gravity or small size facilitate mining on the body whereas a much larger body proves impossible.
-
However having said all that, it just occurred to me that in the Sol system at least, because I just named all the asteroids, it will no longer be obvious from the name whether the body is an asteroid and therefore a suitable target for mining modules :). Therefore I probably do need to add a "can be mined with asteroid miners" flag. If I am doing that, I guess we can revisit the parameters from what is an acceptable target body.
Unless the rule is that "anything that's not a (non-dwarf) planet is eligible". Then players only have to know the names of the 9 (or 8 ) planets. Of course this brings the Pluto issue to the foreground :)
I never use asteroid miners because a long time ago I decided the ROI wasn't worth it compared to regular mining facilities. Even if I'm wrong (e.g. engineless miners that get towed by tugs), I don't think it will be too imbalancing to expand the scope where players use them - I'd rather have this than see the display cluttered up with YAF (Yet Another Field :) ).
John
-
So long as there's an easy flag (I considered this to be designation as a chunk or what have you in the F9 menu because that's generally where I make my mining decisions from), I think the added micromanagement isn't especially trying. And as long as whatever parameter controls it allows asteroids and comets to be always mineable, the player who can't be bothered with the extra micro (but can be bothered to micro asteroid miners in the first place) won't really notice a difference.
As far as the fluff/technobabble goes, I like the simpler option of making it any body which hasn't rounded itself (which according to my quick Wiki check means it would preclude the dwarf planets). Assuming this is what a moon being a 'chunk' means, it opens up quite a few options in the solar system, and in my experience generated systems have a lot of those as well. Mechanically I prefer it because I'm concerned about the impact adding more tech lines (to determine the size/gravity that's mineable) will have on the cost/benefit ratio of asteroid miners which is already somewhat tenuous.
-
In fact, if we reduce whatever method we use to a simple "This can be mined with asteroid miners" flag (whether the underlying reason is gravity, size or body type), players would still want to see that flag on survey ship/team reports, the minerals sidebar of the system map, the Geological Survey window, individual colonies summaries and perhaps even the actual graphical system map. It would add a extra level of lookup to what is an easy lookup at the moment.
When I evaluate system bodies to mine I always use the System Generation and Display screen (F9) to find which has what minerals on it. That screen already has a body type field listed, so there is no need to add one there. But for everyone else I can see the need to have it for other screens. I personally like the choice of flagging the body type for asteroid mining. Simply because it's a non-issue for my method of decision making. In fact it makes choosing that much more simple to know the exact parameters of a asteroid mining module. I just need to look at 2 fields: the body type (Asteroid, Chunk & Comet) and the minerals it has then add a colony there. I can do all that on the System Generation & Display screen. Even better I have a rough idea of where the mining target is because this screen lists by default bodies closest to the parent star to the most distant.
-
Put a tickable box in the "find mineral resources" screen that you can select and name it "allows asteroid miners". That way I can search for specific minerals and immediately see whether I need auto-mines or not.
-
Since a game can get very large, with tens of systems, hundreds of planets and thousands of asteroids, finding what minerals you want becomes only possible using the Geological Survey Report screen. In my opinion, the solution to limit that micromanagement is to improve this screen. The System View screen (F9) is comparatively clunky with long loading times and tedious searches. So here are some suggestions.
There's a check box to limit search to asteroids only. Currently, comets aren't included, it would be useful to change that box to "whatever asteroid miners have access to", regardless of changes on that point.
And since mining ships are often very slow (or engine-less and towed at slow speeds), outsystem asteroids/comets are sometimes way too far to be accessed in a reasonable time, so a "distance from primary" criteria might be nice. This is a minor point since, currently, far asteroids are a pain to survey anyway, with the auto-survey default orders limited to 10b km.
Choosing where to search is currently a single system, or all of them. Manually choosing multiple systems could be nice, or even simply systems you control (as set in the Galaxy screen). That would give a practical use to that tag. Searching systems controlled by another race could help you determine if an invasion is worth it.
Limiting sorium search to gas giants can help finding rich deposits for harvester bases.
Also, I wouldn't go into a new tech line for asteroid modules. The module costs as much corundium as a regular mine, but can operate anywhere. If it could operate on large bodies, automines would be useless, so there needs to be a limit. Giving the ability to increase that limit means that, at game start, when the module is most useful (scarce corundium supplies), many possible deposits are inaccessible.
Hope it helps Steve.
-
Choosing where to search is currently a single system, or all of them. Manually choosing multiple systems could be nice, or even simply systems you control (as set in the Galaxy screen). That would give a practical use to that tag. Searching systems controlled by another race could help you determine if an invasion is worth it.
Another option that could help would be limit a search to a sector (same as the systems controled by a sector hq.)
Brian
-
Another update:
At the moment, the planets, moons and asteroids in the Sol system are always at the same point in their orbit at the start of every game. From v5. 70 onwards, every body in the Sol system will be assigned a random point in its orbit at the start of each new Sol-based campaign. This means every game will be unique in terms of the Sol system starting layout.
Steve
Randomly? Not computed according to the date? I'm dissapointed!
Just joking, I'm very impressed by the amount of work you spent just to name "space rock #2561" :)
* Concerning L4 and L5 bodies, two things bugged me for some time. . .
- The first one is that secondary stars (which can be considered as bigger than usual superjovians actually) lack the intra-system lagrange jump point. adding those may ease the exploration of ultra-large systems (if the primary have a superjovian around, it cut the travel distance by 2/3)
- Why is there only one lagrange intra-system jump point per body?
* Concerning the orbital asteroid miners, why not allowing them for all bodies, but with a variable yield depending of the size/gravity of the body?
(The smallest chunks being the fastest to mine - even faster than now if possible - and Earth-sized planets would be a waste of time for the mining ship)
For now, asteroids mining ships seems not very interesting compared to automated mines due to their low yield, but if they can outperform the mines on the smaller bodies, they can fit nicely in this niche.
-
Is there a possibility, in some future release, of real-life star systems included? There are quite a few, some with as much as six confirmed planets (like Kepler-11 with six gas giants inside the orbit of Mercury). While those systems would still need some randomly generated objects, I think it would be nice to have some "fixed" systems in the game other than Sol.
-
Is there a possibility, in some future release, of real-life star systems included? There are quite a few, some with as much as six confirmed planets (like Kepler-11 with six gas giants inside the orbit of Mercury). While those systems would still need some randomly generated objects, I think it would be nice to have some "fixed" systems in the game other than Sol.
Recently a a project was (crowd) funded that will search for exomoons. I predict that in 2 or years steve has to code a dozen complete starsystems :P
-
Recently a a project was (crowd) funded that will search for exomoons. I predict that in 2 or years steve has to code a dozen complete starsystems :P
"Complete" might be pushing it. We are still regularly finding sizable bodies in our own system! The prospect of colonizing known systems has a certain appeal to it. Takes the RP of the future of Earthlings to a new level if the systems we are working with are actually real bodies.
I love Cocyte's idea for asteroid miners. Instead of putting an arbitrary limit on body type or size have the miners work with a rate of diminishing return on any body. Bodies up to the size of one that starts to round off are relatively full capacity for mining and bodies of size between asteroids and moons or even dwarf planets still work but are scaled. If you wanted to add tech lines to support that there could be a place for expanding the capacity of the miners. It would preserve the usefulness of auto mines and improve the flexibility of mining ships.
Since we are pretty far off the original topic here, but in the realm of mining ships, will we ever see a nebulae miner?
-
I love Cocyte's idea for asteroid miners. Instead of putting an arbitrary limit on body type or size have the miners work with a rate of diminishing return on any body. Bodies up to the size of one that starts to round off are relatively full capacity for mining and bodies of size between asteroids and moons or even dwarf planets still work but are scaled. If you wanted to add tech lines to support that there could be a place for expanding the capacity of the miners. It would preserve the usefulness of auto mines and improve the flexibility of mining ships.
Since we are pretty far off the original topic here, but in the realm of mining ships, will we ever see a nebulae miner?
This. I like the idea of being able to have a massive orbital mining operation. Even if it IS a planet. Could be very, very cool. Orbital habitats, miners, etc, etc.
-
Never really thought about an orbital with 50(0) asteroid miners on it, or some such. I just giggled a little on the inside of the visualization of subjugating an alien home world and then following up with an orbital mining array that strips/decimates the planet and renders the surface near inhospitable in the extraction of the resources. (a little combining of this idea and one I just posted in suggestions about player activities damaging the habitability of a body)