Project Orbiter Galaxy

Extrasolar visions puts class II at 150-350 K and class III at 350-900 K.
Thanks, then the data on Wikipedia is probably wrong. That would solve that problem.

@Linguofreak: I'm afraid I have to disapoint you, other than Gas Giants, the gas mass is so low that it comes out of stargen as zero for other planets (probably because Stargen handles it in solar masses), so I think that won't help you much to get to the density problem. I also put in the core radius, but that's about all the additional information I can get out of the generator at this time.
However, I looked up the density of the rocky planets in our solar system, and it seems that composition indeed seems to play a significant role. So the only way to fix the density in the generator will be to model a more detailed geological composition, which is planed, but I'd like to wait with that until version 0.6 is out.

I also took the opportunity to look at the Gas Dwarfs. The code currently classifies a gas dwarf if it has a mass lower than 10 earth masses and more than 5% of its total mass is in gas. So the very low density Gas dwarf you observed must have quite a small core. It seems still justified to classify them as gas dwarfs, but you tell me if you think I should set the ratio higher.

---------- Post added at 02:21 PM ---------- Previous post was at 11:46 AM ----------

No crashes anymore when reloading the Galaxy Map in Orbiter. The problem was once more due to undefined behaviour.

On we go to put a simple MFD in, and then I'll see how well the system switching works! :)
 
Last edited:
how much does it matter for the density wheather the core is liquid or not?

Shouldn't matter too much. I'm not familiar with the behavior of iron at thousands of K and hundreds of gigapascals, but liquid/solid transitions in general don't tend to make a whole lot of difference (you see differences between substances, with normal ice being *less* dense than water, as opposed to other substances being more dense when solid, and also differences between different parts of the same substance's phase diagram, with the properties of high-pressure water ice being very different from "normal" ice.

In any case, the difference in density between solid and liquid iron would be dwarfed by the difference between rock and iron.

From what I've seen so far, yes, but I'll take another look at how water and ice are actually calculated. I'll pass you a patch with an updated planet display as soon as possible.
Edit: confirmed, no "trinitarian" composition. The water covering seems to be estimated from the volatile gas inventory and temperature. Haven't quite understood it yet, but ices definitaly don't have an influence on the density calculation.

I had the same thoughts, actually. I think the program currently has only "accreted" atmospheres, not self-generated. I'm not quite certain about this, but I haven't seen anything indicating otherwise so far. There is also the question of how old the system is. The program calculates the decay of Helium and Hydrogen.

At the temperatures in question, it shouldn't matter.

There is a flag for "resonant spin locked", but I think that's meaning that the planet rotation is locked in a ratio to its orbit,

Yes, it does, such as Mercury's 3:2 spin lock with its orbit or the Moon's 1:1

Keep in mind that spin-locks have can influence on orbital parameters, and vice versa. Mercury's spin lock and the eccentricity of its orbit are related, and the Moon is slowly backing away from Earth as a result of its lock.

Also, for close orbits around stars/planets, a non-1:1 spin lock can create quite a bit of tidal heating (or a 1:1 spin lock combined with an orbital resonance with another moon/planet, such as Io and its 1:2:4 resonance with Ganymede and Europa). This is primarily a concern for moons, but will also be important for planets of red dwarves.

and not the relationships of the orbits of two planets. Might be tough to implement...

Well, it's pretty closely tied with the problem of migration, and the solutions to the two problems will probably go hand in hand. A very rough algorithm would be:

Figure out the planets that have more than a certain amount of gravitational influence on a given planet. (In terms of mass and similarity of orbital elements).

Give a random "kick" to the orbital elements based on the existing elements.

After repeated iterations, some situation should result that results in the "kick" becoming less and less: Either: A) The planet migrating to another part of the system. B) The planet leaving the system, colliding with another body, or diving into the sun. Or, C) The planet's orbital parameters settling into a stable resonance (the combination of certain period resonances like 2:3 or 3:2 with certain inclinations and eccentricities, such that the planets never come near each other, and such that imperfections in the resonance (say 201:300) tend to lead to the orbit being pushed back in the direction of a perfect resonance, rather than away from it (back to 2:3 instead of to 202:300)).

You'll need a fairly full set of orbital parameters to make this work.

That wouldn't be a problem. In fact, my code currently deletes moons above a certain mass on purpose, because I thought them too unrealistic. I can remove that and see what comes out.
Edit: I pushed the mass limit up to one earth mass,

I wouldn't put explicit limits on mass (for one thing, a reasonable upper mass limit for an Earth-sized world's moon will be different than for a 10-Jupiter mass planet). Rather than a hard limit, your algorithm should have a given probability of outputting various masses, and that should go to zero for absurdly high masses.

and habitable moons seem to have become fairly common around Gas Giants around F-stars that have left main sequence (For having them in Main Sequence stars, I'd have to put in orbital migration first, I'm afraid). However, they're all showing up around Sudarsky III giants, looks like something with the temperature classification isn't quite alright...

and yet another Edit: I took the temperatures for the classifications from Wikipedia, which sets a Sudarsky II at somewhere around or below 250 K. That's about 40 K too low for a habitable planet, so they show up around the colder Sudarsky III in the generator. Should I just put up the classification of a Sudarsky II to 300 to 320 K?

Well, something that has to be kept in mind here is that the temperature of a planet is not necessarily the temperature of its moons. (Though the 250K in Wikipedia appears to be a typo, because the Wikipedia article leaves a 100K gap between the top of Sudarsky II and the bottom of Sudarsky III (which it gives as 350K))

The big question I have WRT the Sudarsky classification is where they're measuring from.

Are they measuring the temperature of the re-emitted black-body radiation?

The layer where light is absorbed/reflected (IE, the cloud deck)?

Are they measuring the temperature at one bar atmospheric pressure?

They certainly *aren't* measuring the temperature at the solid surface, but for a terrestrial planet, or a moon of one of these gas giants, this would be the temperature one would be most likely to measure.

And on Earth or Venus, all three temperatures are different. Venus, being more reflective than Earth (like a Sudarsky II would be), is actually *colder* in re-emitted blackbody (I believe both are below freezing). Both planets are warmer at the 1 bar line than their blackbody temperature (because the average height at which radiation is emitted, reflected, and absorbed is higher than the 1 bar line, and also because the average absorption/reflection height is lower than the emission height. This is what the greenhouse effect is), and both planets actually have quite similar temperatures around the one bar line.

So even though we've established that the Wikipedia article is in error, the fact that the temperature at the cloud deck (or wherever they're measuring from) of a Sudarsky II is around 250 K does not preclude the temperature at the surface of a less beclouded and more begreenhoused moon being above 273K.

---------- Post added at 20:44 ---------- Previous post was at 20:11 ----------

I also took the opportunity to look at the Gas Dwarfs. The code currently classifies a gas dwarf if it has a mass lower than 10 earth masses and more than 5% of its total mass is in gas. So the very low density Gas dwarf you observed must have quite a small core. It seems still justified to classify them as gas dwarfs, but you tell me if you think I should set the ratio higher.

Actually, the super-low-density planets I observed were rocky worlds in hot orbits.

The gas dwarves I'd been talking about just had insanely low amounts of gas. I'll try looking through the compositions on the Gas dwarves once there's a patch up with gas/rock ratios in it (The latest patch I see in the release thread is 0.52 with the keyboard fix, or am I looking in the wrong place?).
 
first of, here's your patch. As I said in the previous post, I doubt it's going to help you much, because gas mass for non-giants is always zero. Appart from that, the table now shows the core radius, and if the planet has a greenhouse effect:

http://xcc.rpgee.com/orbitermods/jed...y-Patch053.rar

Also fixes the negative mass in kg, which was caused by the function responsible of cutting the decimal points. Seems it can't handle scientific notation...

After repeated iterations, some situation should result that results in the "kick" becoming less and less

I hope it won't need too many iterations, the speed-penalty could be significant.

The big question I have WRT the Sudarsky classification is where they're measuring from.

I was asking myself the same question. I'm just using the estimated temperature from stargen, which is more or less derived from the energy the sunlight has at that distance and the planetary albedo. However, with pushing the limit for Sudarsky II up to 350 K, I will have the Sudarsky II's in the habitable zone (not yet updated in the patch, I'm afraid, but the only thing it really changes is the displayed thumbnail), so I guess I'm not too far off. Not far enough for anyone to notice, anyways :lol:
 
first of, here's your patch. As I said in the previous post, I doubt it's going to help you much, because gas mass for non-giants is always zero.

Well, I was looking for it as a general tool, not just for one specific issue. I'm also trying to figure out if the density figures for gas giants are to my liking, and to do so, I've got to have some idea how much of them is core and how much is atmosphere.

Also, as far as gas dwarves go, I'd like to see the ratio/percentage/fraction/whatever that's being fed into the "determine if it's a gas dwarf" function. The gas dwarves I'd been looking at indeed do show up with zero gas mass (as opposed to most gas dwarves which list a gas mass), and they have surface pressures listed (which most gas dwarves/giants don't), and said pressures are far too low to account for 5% of the mass of the planet. It appears that something is telling the generator that they have 5% gas when they have pretty much none at all.

Appart from that, the table now shows the core radius, and if the planet has a greenhouse effect:

Well, pretty much anything with an atmosphere (especially if it includes clouds or anything that is opaque to any frequency) will have a greenhouse effect. The real question is how much, and what the sign is.

http://xcc.rpgee.com/orbitermods/jed...y-Patch053.rar

Also fixes the negative mass in kg, which was caused by the function responsible of cutting the decimal points. Seems it can't handle scientific notation...



I hope it won't need too many iterations, the speed-penalty could be significant.

Yeah, it could. I also see potential for time requirements in O(n^2) where n is the number of planets in a system.

Some help could probably be gotten from asking around (I'm on a mailing list where we might be able to get a few suggestions, http://games.groups.yahoo.com/group/sfconsim-l)

But figuring out a way of dealing with gravitational interactions, resonances, etc, however imperfect, would kill several birds with one stone: It would provide a basis for migration, it would help with the modeling of multiple star systems (though Orbiter can't quite handle that, the program could be useful for other things as well), it would introduce "interesting" features that are seen in the Solar system, and would also help deal with the maddening lack of asteroid belts. (Basicallly, the asteroid belt didn't form a planet because Jupiter swept most of the material in it inwards towards the inner planets, or outwards towards the other Jovians and interstellar space, leaving only a smattering in the belt itself. The Kuiper belt is associated with Neptune, although in a rather different fashion).
 
It appears that something is telling the generator that they have 5% gas when they have pretty much none at all.
It's a bit weird, because something like that should be rather easy to find... but I'll fix it, don't worry.

Well, pretty much anything with an atmosphere (especially if it includes clouds or anything that is opaque to any frequency) will have a greenhouse effect. The real question is how much, and what the sign is.
sorry, I meant "runaway greenhouse effect". I guess I worded that wrong in the display too.

But figuring out a way of dealing with gravitational interactions, resonances, etc, however imperfect, would kill several birds with one stone: It would provide a basis for migration, it would help with the modeling of multiple star systems (though Orbiter can't quite handle that, the program could be useful for other things as well), it would introduce "interesting" features that are seen in the Solar system, and would also help deal with the maddening lack of asteroid belts.
Yes, I see. Once version 0.6 is out I'll have my work cut out for me... again! :lol:

Some help could probably be gotten from asking around (I'm on a mailing list where we might be able to get a few suggestions

I'll be glad for any help I can get. I'm afraid I'm in over my head, considering that my math doesn't go beyond trigonometry...
 
It's a bit weird, because something like that should be rather easy to find... but I'll fix it, don't worry.

sorry, I meant "runaway greenhouse effect". I guess I worded that wrong in the display too.

Yeah, but just whether the greenhouse effect is "runaway" or not is a bit subjective, and also only gives one bit of information. If the code is actually calculating how much it is, it would be nice to see a number.

Yes, I see. Once version 0.6 is out I'll have my work cut out for me... again! :lol:

I try...

I'll be glad for any help I can get. I'm afraid I'm in over my head, considering that my math doesn't go beyond trigonometry...

Yeah. Mine fades out somewhere around pre-cal/calculus.

At some point when I have a bit more free time, I've got a catologue based on HYG (Hab-HYG, to be exact), that I had been proofreading and adding star masses to myself before I got bogged down by schoolwork / sidetracked by other interests.

It might be a bit more reliable, at least near Sol (It goes out to 50 ly, plus a few stars I've added by hand beyond that), than the raw data, and has masses for the known stars involved. It also has multiple identifiers for each star, which is a major plus both for proofreading and searching (you would not believe how difficult it can be to find a star (or data about it) if you only have one identifier for it. It's good to have several catalogue numbers, the Bayer-Flamsteed designation if the star in question has one (Alpha Centauri, Epsilon Eridani, etc.), plus any proper name it has (Rigel, Betelgeuse, Keid, Rigil Kentaurus, Sol).

The cons are that it would require a change in either the format of the file itself, or Orbiter galaxy, or, likely, both, to be useful to you, that it only goes to 50 ly, and that it is structured for a program of mine that is meant to create an FTL map, and needs to know if a system is single or multiple, and if multiple, whether it contains close-binary components, so it's got certain dummy entries I've used to deal with that, and lots of un-merged multiple stars, while Orbiter Galaxy only wants the primary star in each system. Also, while we seem (if I've read the data files right. I'm not entirely sure which field is which, but I've found numbers that seem to match between mine and yours) to be using the same coordinate system, mine has only tenth-parsec precision, whereas yours, if I'm looking at the right field, is precise to six decimal places.
 
Yeah, but just whether the greenhouse effect is "runaway" or not is a bit subjective, and also only gives one bit of information. If the code is actually calculating how much it is, it would be nice to see a number.

That information is lost during the generation, since the variables get overwritten at every iteration. If after a certain number of iterations the temperature is sitll rising, it's designated "runaway greenhouse effect", if I read the code correctly. To output the numbers in the display, I'd have to log them during creation.

It might be a bit more reliable, at least near Sol (It goes out to 50 ly, plus a few stars I've added by hand beyond that), than the raw data, and has masses for the known stars involved.

Sounds like it could be usefull!

It also has multiple identifiers for each star, which is a major plus both for proofreading and searching (you would not believe how difficult it can be to find a star (or data about it) if you only have one identifier for it. It's good to have several catalogue numbers, the Bayer-Flamsteed designation if the star in question has one (Alpha Centauri, Epsilon Eridani, etc.), plus any proper name it has (Rigel, Betelgeuse, Keid, Rigil Kentaurus, Sol).

The HYG database has several identifiers, but I kept only one when recompiling the catalogue for Orbiter Galaxy. Majorly to make it smaller (reducing memory usage and loading time). As far as the HYG-library is concerned, I can modify the program to store more information and reparse the library relatively easily.

The cons are that it would require a change in either the format of the file itself, or Orbiter galaxy, or, likely, both

That would hardly be a problem, as long as it's in csv or something similiar. write a reader, write a writer that throws out all information I don't need and rearranges what's left, that's it.
 
That information is lost during the generation, since the variables get overwritten at every iteration. If after a certain number of iterations the temperature is sitll rising, it's designated "runaway greenhouse effect", if I read the code correctly. To output the numbers in the display, I'd have to log them during creation.

I believe greenhouse effect is numerically quantifiable at any given time. The reason you'd want to iterate is that warming can trigger the release of more greenhouse gasses (The oceans boiling off, to give an extreme example). So you could just give the greenhouse warming figure for the last iteration.
 
yes, that should be possible. I'll have to introduce another member to the planet struct from StarGen, but it's not the first one, and certainly won't be the last.

I'll be gone now until wednessday. Last developement notice is the successfull exporting of a system without textures and without atmospheres, and a scenario to launch it, and the basic connections between the Map and the MFD are established. The first experimental jump through hyperspace is getting close!
 
yes, that should be possible. I'll have to introduce another member to the planet struct from StarGen, but it's not the first one, and certainly won't be the last.

I'll be gone now until wednessday. Last developement notice is the successfull exporting of a system without textures and without atmospheres, and a scenario to launch it, and the basic connections between the Map and the MFD are established. The first experimental jump through hyperspace is getting close!

Ooh. Maybe my FTL-map creator would come in handy for creating a stargate/wormhole type network. Of course, the player would probably want some means of getting to an arbitrary system at will, but some "canonical" way of getting between systems might add some flavor. (Or maybe I'm just trying to mooch off your hard work because my FTL-map generator was me starting a similar project on the end that I knew how to do).

EDIT: BTW, I noticed that star densities between the spiral arms are pretty much zero. This isn't the case in real life. In real life the spiral arms are where all the hot (O/B), massive, young (as in "still young enough to be alive at that mass", so a few million years or less) stars are. The distribution of middle-aged stars is fairly even throughout the disk.
 
Last edited:
EDIT: BTW, I noticed that star densities between the spiral arms are pretty much zero. This isn't the case in real life. In real life the spiral arms are where all the hot (O/B), massive, young (as in "still young enough to be alive at that mass", so a few million years or less) stars are. The distribution of middle-aged stars is fairly even throughout the disk.
Interesting, I'm hearing about that for the first time. Will be difficult to implement, because the program doesn't know where a spiral arm is and where not, it just checks the brightness of the pixel on the grayscale image in the background and uses it as a basis for calculating the density (which is, I must say, totally unacurate... I had to go with values that make sense in the program and the engine, since the density would get much too high if I took realistic values).

I could boost up the density for the lower density regions (allthough I'll have to search for a new function), but I can't give them other populations. I guess I could throw an alpha-chanel into the image so the program would know what's a spiral arm and what isn't, but the drop-off might get a bit rapid then...
Then again, solving this problem might be a good way to get my missing blue giants into the disc (of which there is a serious lack once you get into purely generated regions).

Ooh. Maybe my FTL-map creator would come in handy for creating a stargate/wormhole type network. Of course, the player would probably want some means of getting to an arbitrary system at will, but some "canonical" way of getting between systems might add some flavor. (Or maybe I'm just trying to mooch off your hard work because my FTL-map generator was me starting a similar project on the end that I knew how to do).
Actually I have a "canonical" way planed. In general, there will be several ways to get around. First is a "magical teleportation device" that just gets you to any system you want, majorly for debugging purposes and for people that just want to look around. Then of course a direct flight method, that enables you to fly freeform between two stars (as long as they're not too far apart. Too large distances make orbiter crash, but I have yet to establish the stable distance limit). This would also be compatible with all warp-drive mfd's.

The "canonical" way I have in mind is called the McGuffin drive, named so because that describes best what it is: A drive whoms properties were chosen by what I would want the galaxy to look like. It's a kind of "open a wormhole"-drive, just that the efficiency of the drives drops off with the steepness of the gravitational well. It can form wormholes from very steep gravity wells to very steep gravity wells over almost any distance (making black holes natural jumppoints to cover vast distances), while it gets terribly inefficient and needs a lot more jumps to get, for example, from one G-star to the next.
It solves several problems I wanted to have solved in "my" FTL-drive. a) it doesn't give the player an uber-powerfull engine to get around in the systems (which would kind of defy the purpose of orbiter) b) it allows getting from one end to the galaxy to the other relatively fast, enabling potential alien races to meet early in their history, while still making it hard to reach other regions, resulting in potential "wild-west badlands" c) providing strategically crucial points, meeting places and trade centers d) still giving the player lots of room for the decision about which route to choose and where to go and d) introducing a rare unobtainium resource to drive the whole thing.

I decided against a "Starlane" network for two reasons: a) it feels too limiting, reducing the complexity of possible navigational decisions, and b) is a nightmare to code in a procedural galaxy.

And feel free to mooch a bit more, your input is highly apreciated ;)
 
Last edited:
Hi there,

I'm a bit of a noob with Orbiter, totally self taught. I've long lamented not being able to travel to Alpha Centauri buy just pointing in the general direction and firing up the ol warp drive or FTL capacitors. This project sounds absolutely amazing!!!

I don't have a programming back ground or much in the way of software needed for add-on development. I just like tinkering with configs and kit-bashing meshes and textures for my own use of couse.

HOWEVER, if you guys need any help in the way of researching stars and confirmed extra solar planets etc... or typing out config files for star systems and planets etc I'm pretty free this summer and would just love to help out in whatever capacity I can.

Let me know if this sounds practical, if not then best of luck and I'll wait eagerly along with the rest of the Orbiter community.

Cheers!
 
Speaking exo-planets i have three systems i would like to make compatible with this when it's complete. My Gliese 581 optimized and the HD 28185 system and my next project the Upsilon Andromedae system (not started).
 
Last edited:
Interesting, I'm hearing about that for the first time. Will be difficult to implement, because the program doesn't know where a spiral arm is and where not, it just checks the brightness of the pixel on the grayscale image in the background and uses it as a basis for calculating the density (which is, I must say, totally unacurate... I had to go with values that make sense in the program and the engine, since the density would get much too high if I took realistic values).

I could boost up the density for the lower density regions (allthough I'll have to search for a new function), but I can't give them other populations. I guess I could throw an alpha-chanel into the image so the program would know what's a spiral arm and what isn't, but the drop-off might get a bit rapid then...
Then again, solving this problem might be a good way to get my missing blue giants into the disc (of which there is a serious lack once you get into purely generated regions).

I (being the feature-greedy user and not the poor guy who has to implement it all :P) might use two or three separate images: One for stellar density, and then one or two for stellar age and star formation related parameters.

The "canonical" way I have in mind is called the McGuffin drive, named so because that describes best what it is: A drive whoms properties were chosen by what I would want the galaxy to look like. It's a kind of "open a wormhole"-drive, just that the efficiency of the drives drops off with the steepness of the gravitational well.

It's better, for the sake of having a well defined entrance point to a system (which is important for the sake of both "choke points", preventing in system jumps, and probably ease-of-implementation in orbiter), to have your drive use existing connections rather than "creating a wormhole" or "jumping into hyperspace".

It can form wormholes from very steep gravity wells to very steep gravity wells over almost any distance (making black holes natural jumppoints to cover vast distances), while it gets terribly inefficient and needs a lot more jumps to get, for example, from one G-star to the next.

Interesting. In some ways similar to my own. But when you say steepness, do you maybe mean depth? "Depth" is how much kinetic energy you'd get per kilogram by falling from infinity to a given point in an object's gravity well, and is the escape velocity squared. The depth of Earth's gravity well at the surface is (11 km/s)^2, or about 121000 joules / kg. "Steepness" is the amount of gravitational force you have at a given point. E.g. The "steepness" of Earth's gravity well at the surface is 9.81 m/s^2, or 9.81 (J/kg)/m (one gee).

Large black holes (such as those in galactic nuclei) are very deep (a black hole, by definition, has a depth at the event horizon of infinity), but not necessarily very steep (the more massive, the shallower), with the most massive known black hole having a horizon gravity of "only" 86 g's, comparable to the surface gravity of objects at the brown dwarf / red dwarf boundary, which have a tenth of a solar mass (80 jupiter masses) and a radius about equal to Jupiter. Compared to planets and more massive (solar mass and above) main sequence stars (and even moreso compared to giants), it's quite steep, but compared to any stellar remnant, it's downright shallow (white dwarves for example have the mass of the sun with a radius comparable to that of Earth, and get smaller with added mass, neutron stars have several solar masses and a radius comparable to my morning drive to school back home (20 km)).

If you make it steepness based, red/brown dwarves will actually be a *better* jumping off point than anything short of a stellar remnant, and even planets like Earth will outdo giant stars.

Also, "steepness" and "depth" are properties of points of space, not stars themselves, so you still might see interesting effects, even with a depth based system (for example, depth will increase in general towards the galactic center, since the galaxy has its own gravity well, though you may choose not to model this).

It solves several problems I wanted to have solved in "my" FTL-drive. a) it doesn't give the player an uber-powerfull engine to get around in the systems (which would kind of defy the purpose of orbiter)

It could still potentially happen. For instance, if your drive allows you to jump to any point whose "depth" or "steepness" is within 1% of the point you're at, it could allow a jump from any point around Earth to a "shell" around Earth consisting of all points with approximately the depth/steepness at that point, plus similar shells around the sun and every other body in the solar system, as well as the galactic center, with the same depth/steepness. (Of course, if you want, you can simply make the behavior of the drive not totally consistent to forbid this).

b) it allows getting from one end to the galaxy to the other relatively fast, enabling potential alien races to meet early in their history, while still making it hard to reach other regions, resulting in potential "wild-west badlands" c) providing strategically crucial points, meeting places and trade centers d) still giving the player lots of room for the decision about which route to choose and where to go and d) introducing a rare unobtainium resource to drive the whole thing.

I decided against a "Starlane" network for two reasons: a) it feels too limiting, reducing the complexity of possible navigational decisions, and b) is a nightmare to code in a procedural galaxy.

Well, that's not exactly what my starmap generator does. I have an algorithm for deciding whether a link exists based on the masses of two stars and the distance between them. (Basically, given the masses of the stars, I put each into a mass class, and do a table lookup based on the mass class for a pair. The table lookup gives a distance, and if the separation between the two stars is within 15% or so of that distance, a link exists). It's a bit more complex than that, in that there's handling for close binaries and stars on a mass-class borderline, but it gives you the general idea.

So the algorithm itself is somewhat similar to what you have, and depends only on the tables (which at the moment have five mass classes and cover masses between 0.06 and 4-point-something solar masses) and stellar properties that are already being generated procedurally. Given a star and a list of nearby stars and their locations and masses, the algorithm can generate a list of valid targets. My mapping program is simply for the convenience of the user in finding multi-jump paths. At first I was calculating links between stars with the algorithm and editing them into two separate file formats with two separate programs by hand. That got old fast, so I wrote* a python script to read in a CSV file with stellar data, calculate the links for me, and spit out the results in the two file formats I'm using.

There are a few rough spots, such as that I know the algorithm I want, and that I want the connections to take the form of naturally occuring wormholes/jump points (for the reasons I listed towards the top of the post), but I don't know the best algorithm to determine where in the system they should appear in a way that makes sense and is appropriate "plot wise" in all systems. (For example, if they always appear at 0.5 AU from the star, then they'll be inside your larger giants. If they always appear 30 AU from the star, they'll take a long time or a really spunky drive to reach. There are potential problems with binaries with separation on the order of the usual star <-> jump point distance).

*Actually, the guy who runs the Atomic Rockets site had the sources to a C program on another section of his site that applied another algorithm and outputted one of the file formats I wanted. He's on sfconsim-l, so, not being familiar with C and encountering barriers (compile errors, I think), I posted a message to the list saying "I'm trying to modify this and having trouble". After trying to help me for a bit, he said "screw it, the code is too old and creaky" and rewrote the thing in Python. I then modified it to implement my algorithm and ouput another file format.

And feel free to mooch a bit more, your input is highly apreciated ;)

Thank you.
 
Last edited:
HOWEVER, if you guys need any help in the way of researching stars and confirmed extra solar planets etc... or typing out config files for star systems and planets etc I'm pretty free this summer and would just love to help out in whatever capacity I can.
That won't be neccessary, since I'll leave implementation of custom systems up to third party developers anyway. The only real system that will be integrated from the start is sol, all other planetary systems will be generated. However, you can already start to build your systems if you like, since the next version will certainly support the implementation of custom systems, and I'm sure a lot of users will apreciate if people make actual systems with known Exoplanets.


Speaking exo-planets i have three systems i would like to make compatible with this when it's complete. My Gliese 581 optimized and the HD 28185 system and my next project the Upsilon Andromedae system

I saw your HD 28185 system, and it's visualy quite impressive! don't worry, you'll be able to put it in with a minimum of work. As it looks currently, only one additional config should be neccessary to implement an orbiter system into the generator.


I (being the feature-greedy user and not the poor guy who has to implement it all :P) might use two or three separate images: One for stellar density, and then one or two for stellar age and star formation related parameters.
I could deliver support for that, but I'll need help to create the images, since I'm not really a good astronomer. So if you could produce the grayscale images, it would be a breeze to put them in. They should be in the same size as the current greyscale image.
Currently the age composition is handled in three cathegories: core, thin disc and thick disc, the thin disc having an age-drop-of towards the rim (you can look up and modify all age parameters in MilkyWay.cfg, except the thick disc, which has its age hardwired to a relation to the core).

It's better, for the sake of having a well defined entrance point to a system (which is important for the sake of both "choke points", preventing in system jumps, and probably ease-of-implementation in orbiter), to have your drive use existing connections rather than "creating a wormhole" or "jumping into hyperspace".
The entrance point with this system would be "as close to the star as you can get without getting your ship melted". Some supermassive gas-giants might serve as jump-points, but as terribly innefficient ones.

But when you say steepness, do you maybe mean depth?
No, I mean how "steep" (for lack of a better word, the term is purely fictional) the well is at the point the ship currently is.

It's a simple M/R ratio, with M being the mass of the object, and R being the distance of the ship to that object. Under these conditions, the "steepness" of the well at the surface of the earth is 9.4e20 (with distance in km and mass in kg), while the "steepness" of the suns gravity well at one AU distance is already 1.33e22. I have not yet made up an algorithm to calculate the actual efficiency of the drive considering source steepness, target steepness and distance, but let's say for a jump from a sun-like star to another over a distance of ten lightyears it should be neccessary to get somewhere between the orbit of mercury and venus, and to emerge somewhere at the same distance from the target star.

red/brown dwarves will actually be a *better* jumping off point than anything short of a stellar remnant
In that I have no doubt, but I don't see a big problem with it. I haven't done the math for very massive stars yet, they might be tough to reach because they're so darn hot, on the other hand their mass would allow to form a jumppoint relatively far out. I won't know until I calculated it all through.

Well, that's not exactly what my starmap generator does. I have an algorithm for deciding whether a link exists based on the masses of two stars and the distance between them. (Basically, given the masses of the stars, I put each into a mass class, and do a table lookup based on the mass class for a pair. The table lookup gives a distance, and if the separation between the two stars is within 15% or so of that distance, a link exists). It's a bit more complex than that, in that there's handling for close binaries and stars on a mass-class borderline, but it gives you the general idea.
In other words, the Stargates would allow you to jump from a star with a certain mass to another star of similiar mass. That could lead to some confusing detours around the galaxy when you have to jump to a star that is significantly lower or higher mass than your current star :lol:

But I agree that this kind of system wouldn't be too hard to implement, since it doesn't have to establish logical links between all the stars of the galaxy (which isn't so tough when you have your whole galaxy in memory, but is absolutely frickin hell in a procedural system). It could still get very laboursome to find the right stars to make your jumps, though.

As for exit points, you can always do it good old Frontier style and set them in the middle between the star and the outermost planet.
 
Last edited:
I don't think that faster-than-light speed stuff is needed. A ship with constant 1G acceleration can reach half the speed of light in about 174 days. So that solves artificial gravity issues before you start seeing relativistic effects. Turn on the gravity wheel, and you can get anywhere within 10-20 light years within a reasonable time frame of 20-30 years (plus another half a year to slow down)

That would be temporary until Orbiter supports relativistic effects, when travelling faster than 0.5c would maintain realism. This would mean that Oriter Galaxy would stay in the realm of hard science fiction. Because, let's admit it, faster-than-light drives are like flying carpets in fairy tales.
 
This would mean that Oriter Galaxy would stay in the realm of hard science fiction.

FTL is allowed in hard SF as a plot device, and there's only few authors who don't use it.

Because, let's admit it, faster-than-light drives are like flying carpets in fairy tales.

Yes, I admitt it. But so are drives that can accelerate a mass of a thousand tons at 1 G for several hours (left alone days, weeks, months). I'd rather throw a magical FTL drive into my SF-scenario that allows getting from one star to another without further implications, and leave the actual drive alone, because a powerfull drive will change the whole scenario significantly in many other ways.

Besides that, you don't HAVE to use an FTL drive. It's merely one more option.
 
I could deliver support for that, but I'll need help to create the images, since I'm not really a good astronomer. So if you could produce the grayscale images, it would be a breeze to put them in. They should be in the same size as the current greyscale image.
Currently the age composition is handled in three cathegories: core, thin disc and thick disc, the thin disc having an age-drop-of towards the rim (you can look up and modify all age parameters in MilkyWay.cfg, except the thick disc, which has its age hardwired to a relation to the core).

I'm afraid the "drawing the images" part might be a bit beyond my skill level. Once things are a bit less hectic I might ask around.

The entrance point with this system would be "as close to the star as you can get without getting your ship melted". Some supermassive gas-giants might serve as jump-points, but as terribly innefficient ones.

This sounds like, at the cost of efficiency, one could arbitrarily pick a jump point short of "as close as you can can get", which is bad as far as preventing "jump in, release tons of ordinance, jump out before anybody can react" raids, and other such stuff.

No, I mean how "steep" (for lack of a better word, the term is purely fictional) the well is at the point the ship currently is.

It's a simple M/R ratio, with M being the mass of the object, and R being the distance of the ship to that object. Under these conditions, the "steepness" of the well at the surface of the earth is 9.4e20 (with distance in km and mass in kg), while the "steepness" of the suns gravity well at one AU distance is already 1.33e22.

The thing is, when you factor the 2 times the gravitational constant in there, it becomes exactly the equation for "depth". Depth (or, to use the technical term "gravitational potential energy") is (2*G *m) / r, and escape velocity is the square root of depth. Take your steepness for Earth, multiply by 2G, and take the square root. Look familiar? (Actually, for certain reasons, you generally have a minus sign in there on the potential energy, so it's -(2*G*m)/r, but the magnitude is still the same).

In other words, the Stargates would allow you to jump from a star with a certain mass to another star of similiar mass. That could lead to some confusing detours around the galaxy when you have to jump to a star that is significantly lower or higher mass than your current star :lol:

Not really. You take the two masses, and assign each to a "class". You then use one class for the X lookup in a table and the other for the Y lookup. That gives you a *distance* that has to be within fifteen percent. You can have a link between any two stars of any mass (or, at least, any mass that gets assigned a mass class) if the distance is right. But the distance can be neither too small nor too large. For example, you can jump between two Sirius-sized stars 25 ly apart, but not 10 or 50. You can jump between two Sol-sized stars 12 ly apart, but not 5 or 20. You can jump between a Sirius sized star and a Sol-sized star if the distance is approximately 10 ly, between two low-mass red dwarves (or high mass brown dwarves) if the distance is approximately 7 ly, and between a Sirius-sized star and a red/brown dwarf if the distance is about 4 ly.

But I agree that this kind of system wouldn't be too hard to implement, since it doesn't have to establish logical links between all the stars of the galaxy (which isn't so tough when you have your whole galaxy in memory, but is absolutely frickin hell in a procedural system). It could still get very laboursome to find the right stars to make your jumps, though.

Thus the mapmaker, to help.

As for exit points, you can always do it good old Frontier style and set them in the middle between the star and the outermost planet.

Problem is that the outermost planet here is ~30 AU out, which requires magical drives to get between Earth and the jump point (at 15 AU) within a reasonable amount of time. Also, as our poor Pluto found out, there's the question of "what actually *is* a planet?"
 
I'm afraid the "drawing the images" part might be a bit beyond my skill level. Once things are a bit less hectic I might ask around.
Well, you could of course use the already existing image as a template to go from. Otherwise, I'm sure I will find the time to do it once version 0.6 is out, but I'll be very glad for some data!

This sounds like, at the cost of efficiency, one could arbitrarily pick a jump point short of "as close as you can can get", which is bad as far as preventing "jump in, release tons of ordinance, jump out before anybody can react" raids, and other such stuff.
This would be the case if the efficiency dropoff would be linear, which it won't be. As I said, I haven't yet made up a function for the efficiency, but beyond a certain depth the decay will be similiarly drastic as the increase of energy of a particle as it aproaches the speed of light.

The thing is, when you factor the 2 times the gravitational constant in there, it becomes exactly the equation for "depth".
Oh. I'm learning something new every day :)

Not really. You take the two masses, and assign each to a "class". You then use one class for the X lookup in a table and the other for the Y lookup. That gives you a *distance* that has to be within fifteen percent.
ah, now I get it!

Thus the mapmaker, to help.
Yes, I see. It could be used in combination with the generator, so the user could plot a map for a region he's currently traveling. Or it might be displayed in the map directly, although I could imagine that leading to some confusion. Especially since the computer doesn't know all stars the current star can link to when they're too far away (read: not in memory!). But it would still be possible to mark all stars that can be reached from the current star when they are generated, and with the ability to set waypoints plotting a course over several jumps should be sufficiently comfortable, at least over short distances. If you have to search half the galaxy for a star with the right mass at the right distance, it could still get very annoying.

Problem is that the outermost planet here is ~30 AU out, which requires magical drives to get between Earth and the jump point (at 15 AU) within a reasonable amount of time. Also, as our poor Pluto found out, there's the question of "what actually *is* a planet?"
Well, I would just let the astronomers quarell on about the definition and consider anything a planet that is a planet in the context of my generator :lol:.
15 AU's still a bit far, though, I'd have to agree with that.
 
Last edited:
Because, let's admit it, faster-than-light drives are like flying carpets in fairy tales.
Not nessisarily. If you have the right tecnolegy you can move faster than light with a worm hole or a powerfule warp drive (space can move faster than light). But yes if you are speaking relative to our current technolegey, it is impossible and i don't think we'll be getting faster than light anytime soon.
 
Last edited:
Back
Top