Project Orbiter Galaxy

[Linguofreak]

ah, now I get it!

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!).

Well, at present, my mapping algorithm doesn't go any further than ~26 ly + 15% (about 30 ly), so all stars reachable within one jump from the current star should fit within the current sector and its surroundings. If a higher-mass mass class is added to the table, links between two stars of that class would have distances that could potentially be problematic, but that would only be for massive stars, of which there are a limited number.

 

[jedidia]

I just noticed that the orbits of my moons are rubish. Most of them seem to be INSIDE the fricking planets (noticed that as I had no moons showing up in orbiter). Something with my Roche limit can't be right at all...
Edit: false alarm. Merely a conversion error in the display. So I still don't know why orbiter doesn't show my moons...

but that would only be for massive stars, of which there are a limited number.

which is exactly the problem, because they're very hard to find, but are incredibly usefull for covering long distances. Then again, it gives the player something to explore...

One question I still have: Do your ships need time to pass through the wormholes? the trouble with single jumppoints in a system is that, if there's no time needed to pass through them, you get around the galaxy way too fast, since you just come out of a jumppoint and enter it again, using no time at all until you are at the destination system. This means that there are almost no "remote" systems where crime and high adventure can flourish.

 

[Linguofreak]

I just noticed that the orbits of my moons are rubish. Most of them seem to be INSIDE the fricking planets (noticed that as I had no moons showing up in orbiter). Something with my Roche limit can't be right at all...

Edit: false alarm. Merely a conversion error in the display. So I still don't know why orbiter doesn't show my moons...

False alarm aside, you do have to implement a direct collision check and not just a Roche limit. For satellites more than ~ twice the density of their primary, the limit will be inside the primary.

which is exactly the problem, because they're very hard to find, but are incredibly usefull for covering long distances. Then again, it gives the player something to explore...

Could one perhaps keep a catalog of massive stars out to a bit more distance than unmassive ones? The rarer a star type is, the further out you can keep them in memory without the machine choking.

One question I still have: Do your ships need time to pass through the wormholes? the trouble with single jumppoints in a system is that, if there's no time needed to pass through them, you get around the galaxy way too fast, since you just come out of a jumppoint and enter it again, using no time at all until you are at the destination system. This means that there are almost no "remote" systems where crime and high adventure can flourish.

As I said, I've got the mechanics of how to determine if a link exists between to stars figured out, but not the in-system properties of the links.

I would prefer to have zero transit time "jumpoints" rather than wormholes (it's easier to Macguffin how we might have missed one or more of those, which could be invisible, in the Solar System, rather than one or more wormholes, which actually have a spatial structure to it and would likely be visually and gravitationally noticeable).

Still, a jump-point need not be a "jump in, immediately jump to the next system" thing if, for instance, each link has its own jump point. If that be the case, it might be "Jump into Delta Trianguli from Capella, spend two weeks travelling 0.5 AU (even moving that fast requires a fairly spunky drive) to the Upsilon Andromedae Jump point, jump out". Even with a single jump point, there are things that could make trips take a bit longer, especially for the fuel-concious, such as ships having random velocities or displacements relative to the point on coming out and having to re-synch before making the next jump.

Even then, I'm not sure being able to make jumps in quick succession hinders adventure and high crime. It would probably help "civilization" extend out further, but would make it harder for the authorities to chase adventurers and high criminals. "By the time we even knew the crime had occurred, the perpetrator had already left the system. By now he could be ten jumps away, and there are 400 stars within that distance".

 

[jedidia]

False alarm aside, you do have to implement a direct collision check and not just a Roche limit. For satellites more than ~ twice the density of their primary, the limit will be inside the primary.

oh, ok, will do. Anyways, moons working in Orbiter now. I wasn't too exact with the naming...

Could one perhaps keep a catalog of massive stars out to a bit more distance than unmassive ones? The rarer a star type is, the further out you can keep them in memory without the machine choking.

Is of course possible, I even had something like this in mind, allthough for a follow-up project to orbiter galaxy (yeah, I didn't tackle this project with just a galaxy generator in mind, but I had to see how it works out. Any further progress is still a faaar way off). Plus, the player can easily create his own database with the hotspots system.

Still, a jump-point need not be a "jump in, immediately jump to the next system" thing if, for instance, each link has its own jump point.

practically impossible to do, since the program has no idea how many links actually exist...

such as ships having random velocities or displacements relative to the point on coming out and having to re-synch before making the next jump.

This sounds like a nice idea. pitty my stars aren't moving, but a galactic perturbation model would have been a bit overkill for this project :lol:

"By the time we even knew the crime had occurred, the perpetrator had already left the system. By now he could be ten jumps away, and there are 400 stars within that distance".

Yes, but there's not much "at the end of the world"-systems where rarely anyone comes because its hard to get to. And I really like that "Firefly" feeling.
Then again, such regions might still be possible on moons around the outer planets of a system, since the journey there could take longer than to a nearby star, and there might also be systems that have the jump point at inconvieniant places. The more I think about this thing, the more I like it. So, let's try to find a solution for the jump point placement problem.

---------- Post added at 07:33 PM ---------- Previous post was at 07:09 PM ----------

ha... I just noticed for the first time that Msss simulates keycombinations to close orbiter and load it with the new scenario. I always thought there was an actual call in the Orbiter API that allows reloading a scenario without closing Orbiter first. That's kind of a bummer, because it means that Orbiter Galaxy will have trouble with OGLA, which needs Orbiter to shut down COMPLETELY before rebooting it. It can still be used together, but people using OGLA will have to shut down and reload manually. A bit annoying, this...

 

[hribek]

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

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.

Yeah, but I just think it counts as a cheat with our current knowledge of physics. Unless there's some special circumstances I don't know about.

I've been wondering if perhaps a ship with fusion powerplant and with whatever the predicted roof of VASIMR specific impulse is could do the 1G thingy.

 

[Linguofreak]

Is of course possible, I even had something like this in mind, allthough for a follow-up project to orbiter galaxy (yeah, I didn't tackle this project with just a galaxy generator in mind, but I had to see how it works out. Any further progress is still a faaar way off). Plus, the player can easily create his own database with the hotspots system.



practically impossible to do, since the program has no idea how many links actually exist...

Why not just group the in-memory stars by mass class, then search through each list for stars at the right distance for the pairing of the mass class for that list and the mass class of the current system? Then, if a certain mass class, in combination with that of the current star, has a distance associated with it such that part of its "valid jump shell" spills over into other sectors, generate those (or parts of them, if you can. Can you start generating a star, test its mass, and abort and generate the next one if it's not in a certain range without affecting the calculations for downstream stars?), pick out the stars of proper mass class, and test them for distance to the current star.

Yes, but there's not much "at the end of the world"-systems where rarely anyone comes because its hard to get to. And I really like that "Firefly" feeling.
Then again, such regions might still be possible on moons around the outer planets of a system, since the journey there could take longer than to a nearby star, and there might also be systems that have the jump point at inconvieniant places. The more I think about this thing, the more I like it. So, let's try to find a solution for the jump point placement problem.

Well, assuming no aliens in the galaxy and that you're early in human expansion, you'll have enough places that are "at the end of the world" not because nobody *can* reach them, but because there are only so many scoutships. You also have the potential for "islands" of interconnected stars that have no connection with the rest of the galaxy, or "semi islands" where the only connection is through a far or mid spaced binary system. (One star in the binary has a connection to the island, the other to the rest of the galaxy).

Also, you could have jumps require some sort of heavy, expensive, infrastructure that either has to be in place on both sides of the link, or else lugged along by utility vessels with an exploration convoy or millitary fleet.

Another idea, though I'm not sure how implementable it would be, is to let the user define their own link determination equations.

 

[jedidia]

I've been wondering if perhaps a ship with fusion powerplant and with whatever the predicted roof of VASIMR specific impulse is could do the 1G thingy.

No chance. a VASIMR doesn't have the power, and to get a fusion drive up to that power you will need a magical way to conjoure away the waste heat, done so by Niven and Pournelle in "the mote in gods eye", where they of course have an FTL drive too. It's still considered hard sceince fiction, because they bothered about the implications of a magical way to get rid of heat, which changed pretty much their whole universe. The effect of an FTL drive can be limited easily, the effect of an effective way to cheat thermodynamics are severe, so I'd rather stick with the first

@Linguofreak: sorry, it's late, and the browser just ate the second half of my post. I'll reply you tomorrow.

---------- Post added 07-02-10 at 06:13 AM ---------- Previous post was 07-01-10 at 09:26 PM ----------

Why not just group the in-memory stars by mass class, then search through each list for stars at the right distance for the pairing of the mass class for that list and the mass class of the current system?

I'd still have to iterate through all of them, but that isn't really the problem. The trouble are the stars not currently in memory.

Can you start generating a star, test its mass, and abort and generate the next one if it's not in a certain range without affecting the calculations for downstream stars?

generating only parts of the cube isn't possible, since the generator has no idea what a star will look like before he starts generating it.

canceling the generation of a star after mass and coordinates have been established isn't possible currently either, but the adjustments in the code to enable it would be minor. There's still the problem that the stars falling into the right mass class have to be walked through their whole evolution, because their mass can change if they left the main sequence. Plus, we're operating in three-dimensional space here, so the number of cubes to be checked rise in cube with the diameter of the sphere. Well, not quite, because we have to check a sphere and not a cube. Say a jump from the highest mass class to the highest mass class can take you 200 lightyears, that's probably up to 1000 cubes to partly generate (educated guess). The processor load would be awfully big, I'm afraid.

Well, assuming no aliens in the galaxy and that you're early in human expansion

That's two assumptions I'm not making, at least not for my long-term plans

Also, you could have jumps require some sort of heavy, expensive, infrastructure that either has to be in place on both sides of the link, or else lugged along by utility vessels with an exploration convoy or millitary fleet.

Nah, that slows down expansion too much. We'll have a whole galaxy at our disposal, it would be a pitty to use only a small sphere. That's why I thought the McGuffin drive a handy concept, because it allows relatively easy access across the galaxy while still leaving plenty of room besides that (allthough I haven't solved the zero-transition problem either, yet.)

Another idea, though I'm not sure how implementable it would be, is to let the user define their own link determination equations.

That would kind of defy the purpose of a canonical way to get around. The implementation wouldn't be too hard, but the users would have to write up their own tables (which they will be able to do anyways, if they really want to).

 

[Linguofreak]

I'd still have to iterate through all of them, but that isn't really the problem. The trouble are the stars not currently in memory.

I had that feeling.

generating only parts of the cube isn't possible, since the generator has no idea what a star will look like before he starts generating it.

But you still don't need to fully generate every star in the cube.

canceling the generation of a star after mass and coordinates have been established isn't possible currently either, but the adjustments in the code to enable it would be minor. There's still the problem that the stars falling into the right mass class have to be walked through their whole evolution, because their mass can change if they left the main sequence.

Ooh. I'd forgotten that little detail.

Well, stars at or above the right mass class would have to be walked through their entire evolution, since a higher star could lose mass into the right mass class.

In any case, stars in the catalog could certainly be searched, though that would apply only near Sol.

Plus, we're operating in three-dimensional space here, so the number of cubes to be checked rise in cube with the diameter of the sphere.

For any given mass class it will (I think) only rise with the square of the diameter as long as 30% of the base distance for a jump between that mass class and the current star is less than the width of a cube (as long as our shell is thinner than 1 cube, we're only dealing with a surface area, not a volume). That will take us out to ~ 100 ly before things start getting cubic, unless I'm overlooking something. Then again, the shells are fairly thick. Maybe higher mass classes ought to have thinner shells (percentage wise, perhaps even absolutely)

Still, even quadratic can be messy.

Well, not quite, because we have to check a sphere and not a cube. Say a jump from the highest mass class to the highest mass class can take you 200 lightyears, that's probably up to 1000 cubes to partly generate (educated guess). The processor load would be awfully big, I'm afraid.



That's two assumptions I'm not making, at least not for my long-term plans

Of course, with other civilizations being out there, and travel being too fast, why aren't they here yet.

Nah, that slows down expansion too much. We'll have a whole galaxy at our disposal, it would be a pitty to use only a small sphere. That's why I thought the McGuffin drive a handy concept, because it allows relatively easy access across the galaxy while still leaving plenty of room besides that (allthough I haven't solved the zero-transition problem either, yet.)

Yeah, and it strikes me that the "have to check a huge volume for valid jumps" problem almost strikes the McGuffin drive worse than it does mine. (I hope I don't come across as tooting my own horn too much... If so, feel free to do this).

That would kind of defy the purpose of a canonical way to get around. The implementation wouldn't be too hard, but the users would have to write up their own tables (which they will be able to do anyways, if they really want to).

Well, you can still have canonical tables and also have a way of editing them.

 

[jedidia]

Of course, with other civilizations being out there, and travel being too fast, why aren't they here yet.

yes, yes, the Fermi-paradoxon. I like to solve it with pointing out that life is very unlikely to arise on a pre-generation 3 Star, and that we therewith could as well belong to the "first ones". Besides that, charting every bloody star in the galaxy might mathemathicaly not take that long, but it practically it still needs a sponsored commitement over millenias. Assume they found some other races first, got held up with a little war and have to resolve some domestic problems like a revolution or a civil war or stockmarket crash every few centuries (if they're anything like humans, that seems quite probable), I wouldn't count on it that they would have spent the resources to chart all the great balls of fire out here.

Well, stars at or above the right mass class would have to be walked through their entire evolution, since a higher star could lose mass into the right mass class.

I didn't even think of that. Unless we establish that the jumppoints form somewhere aound the ignition of a star and remain stable even when the star loses mass, until they get blown away by a supernova, or somesuch...

In any case, stars in the catalog could certainly be searched, though that would apply only near Sol.

yeah, but that would be kind of an unsatisfying solution...

For any given mass class it will (I think) only rise with the square of the diameter as long as 30% of the base distance for a jump between that mass class and the current star is less than the width of a cube (as long as our shell is thinner than 1 cube, we're only dealing with a surface area, not a volume)

not quite. Since any given mass-class to any given mass-class has a different distance, I think you'd have only insignificant breaks in between those distances. At least methinks, I haven't seen the table.

(I hope I don't come across as tooting my own horn too much... If so, feel free to do this).

:rofl:

Since with the MacGuffin you'd only be interested in a few very effective Jumppoints as a kind of "Highway through the Galaxy" (hrmph. Let's hope they don't have to build a bypass somewhere around here) and the rest would be more or less local navigation, it would be a lot easier creating a log file. Like, the explorers log every black hole they find, then the only problem is to find an efficient way from your current star to the next black hole, which will most probably lie somewhere along a straight line between your position and said ho', err, hole.
Basically it's just finding a star with better properties for a jump that lies somewhere on the line between you and the target. Since you don't have to pay attention to the distance so much, it would be a lot easier. Sure, it would still be quite a task of finding the most efficient way, but it would be much easier finding a moderately efficient way.

Well, you can still have canonical tables and also have a way of editing them.

certainly. It would be a concious effort PREVENTING them from doing it, actually.

---------- Post added at 04:23 PM ---------- Previous post was at 03:13 PM ----------

This is major Tom to ground control, reporting first succesfull jump. Allthough ground control won't get that message for about 50 years... :hello:

shifting priority to implementation of custom systems now.

 

[Linguofreak]

yes, yes, the Fermi-paradoxon. I like to solve it with pointing out that life is very unlikely to arise on a pre-generation 3 Star, and that we therewith could as well belong to the "first ones".

Actually, confusingly, the third generation is called "Population I" and the first is called "Population III", so at first I read that as "Pre-population 3".

That said: The sun is not among the oldest of population I stars, and even if it were, there's still probably at least half a billion years of leeway on when intelligent life could show up. That gives quite enough time for any aliens to have overrun the galaxy by now, unless there were either other barriers to them doing so (such as no FTL, which is quite likely), or they did, but then went extinct to a "man", or they never existed in the first place.

Of course, if, like me, you assume divine interference in the history of the universe, all bets are off. You could have a thousand civilizations all timed to burst onto the galactic scene at once. (Though I tend to operate on the assumption of a humans-only universe).

Besides that, charting every bloody star in the galaxy might mathemathicaly not take that long, but it practically it still needs a sponsored commitement over millenias. Assume they found some other races first, got held up with a little war and have to resolve some domestic problems like a revolution or a civil war or stockmarket crash every few centuries (if they're anything like humans, that seems quite probable), I wouldn't count on it that they would have spent the resources to chart all the great balls of fire out here.

You're talking hundreds of millions to billions of years available.

Only ~1.5% of the age of the sun, or ~0.5% of the age of the universe is needed to stand between us and whoever showed up first for them to have burst onto the galactic scene in the mid-Cretaceous. At 5.5% of the age of the Sun, or 2% of the age of the universe, they'd date back to the Permian-Triassic boundary, and the Sun (as well as their home star) would have completed a galactic orbit since they showed up.

I didn't even think of that. Unless we establish that the jumppoints form somewhere aound the ignition of a star and remain stable even when the star loses mass, until they get blown away by a supernova, or somesuch...

Well, I'd been operating under the assumption that the jump points have shorter lives than the stars: given that my scheme is distance based and stars move (IRL, not of course in your map or in mine, that would be too much hassle to implement).

not quite. Since any given mass-class to any given mass-class has a different distance, I think you'd have only insignificant breaks in between those distances. At least methinks, I haven't seen the table.

Granted. There's actually some degree of overlap (for example, the longest ranged jump for a mass class is always to a star of the same mass class, mismatched classes gives a shorter range).

Here's the table of mass classes.

If we're going to add mass classes as the high mass end, I should probably flip the numbers around and make red-dwarves 0, and A stars 5.

Mass            Mass class        (Very) Approximate spectral class
0.04-0.26     5                        Low M
0.24-0.61	    4                        High M
0.59-0.93	    3                        K
0.91-1.23	    2                        G
1.21-1.73     1                        F
1.71-4.32	    0                        A

And here's the table of distances:

	0	1	2	3	4	5
0	26.5000	13.9130	9.2401	7.0091	5.2030	3.7487
1		16.0000	10.6261	8.0605	5.9834	4.3110
2			12.2200	9.2696	6.8809	4.9577
3				10.6600	7.9130	5.7013
4					9.1000	6.5565
5						7.5400

:rofl:

Since with the MacGuffin you'd only be interested in a few very effective Jumppoints as a kind of "Highway through the Galaxy" (hrmph. Let's hope they don't have to build a bypass somewhere around here) and the rest would be more or less local navigation, it would be a lot easier creating a log file. Like, the explorers log every black hole they find, then the only problem is to find an efficient way from your current star to the next black hole, which will most probably lie somewhere along a straight line between your position and said ho', err, hole.

Oh no... not that again...

Basically it's just finding a star with better properties for a jump that lies somewhere on the line between you and the target. Since you don't have to pay attention to the distance so much, it would be a lot easier. Sure, it would still be quite a task of finding the most efficient way, but it would be much easier finding a moderately efficient way.

certainly. It would be a concious effort PREVENTING them from doing it, actually.

---------- Post added at 21:36 ---------- Previous post was at 21:26 ----------

This is major Tom to ground control, reporting first succesfull jump. Allthough ground control won't get that message for about 50 years... :hello:

They will if he hand-delivers it.

Any chance of a patch for us to play with?

 

[jedidia]

That said: The sun is not among the oldest of population I stars, and even if it were, there's still probably at least half a billion years of leeway on when intelligent life could show up.

Yes, I know my explanation isn't exactly water-proof, but considering the exeptional conditions that life can arise and all the things that can go wrong during evolution or during the civilatory stages of a race, I wouldn't expect very much races to make it to interstellar travel. It's all a bit McGuffin, of course, but the most probable explanation is simply that there is no breaking the lightbarrier, which is a poor foundation for a science fiction game that takes the galaxy as its playground...

Of course, if, like me, you assume divine interference in the history of the universe, all bets are off. You could have a thousand civilizations all timed to burst onto the galactic scene at once. (Though I tend to operate on the assumption of a humans-only universe).

I assume divine interference in the RL creation of the universe, yes. However, modeling it would be a somewhat philosophical task... :lol:

I have no Idea about the humans only universe, however. It would be theologicaly most convieniant, but it wouldn't be the first time that God surprises me... Anyways, in a science fiction scenario, I like my Aliens...

Well, I'd been operating under the assumption that the jump points have shorter lives than the stars: given that my scheme is distance based and stars move (IRL, not of course in your map or in mine, that would be too much hassle to implement).

true, true. Do you have any "theories" on the formations of these jumppoints, that could help us solve the positioning problem within the system?

Here's the table of mass classes.

thanks. As I see it, the mass classes would probably encompass a bigger and bigger mass interval the higher the mass gets, right?

Ok, after a bit of further thinking on the problems, Here's what I think could be a sensible way to remedy the problem with the jump points:

The program has no way of knowing what links actually exist, except for those in the current cubes, everything else would be too much number crunching.

The generator will mark every star that is connected to the current star, so the player can manually scroll through the cubes and see if he finds a connection he likes. He can designate a linked star as a waypoint, whereupon all links will be displayed respective to that star, so he can plan a route of several jumps.
Additionaly, a search function can be provided that searches for a jump link at a player defined distance in a general player defined direction. I'm afraid that's the best I can do without waiting for the next generation of processors, but maybe you have some ingenious Idea how to further streamline the process without eating up too many cicles.

They will if he hand-delivers it.

Unfortunately, since custom systems aren't supported yet, a jump back to Sol was not possible...

Any chance of a patch for us to play with?

Since this is now fully orbiter integrated, a patch won't do, it'd need pretty much a whole new version. But since there are no textures, no atmospheres and no custom systems yet (i.e. no return to Sol, at least not the Sol we know) it wouldn't make much sense to release one yet.

By the way, just to check the needs: Would it be greatly apreciated if the next version, allthough capable of running completely inside Orbiter, would still come with an .exe file that allows to use it as a stand-alone?

 

[Linguofreak]

true, true. Do you have any "theories" on the formations of these jumppoints, that could help us solve the positioning problem within the system?

Not really. I just know that they have to be invisible, or nearly so, (Sol has three, and we want them in the inner system, so they fail the believability test if they're something we would have seen), so it's hard to figure out how to justify basing their positions on stellar luminosity, which would otherwise be quite convenient, and my first instinct. Invisibility does help solve the "multiple points, but not all enumerated" problem.

They should orbit the star, rather than staying still (otherwise you'd have all sorts of difficulties).

thanks. As I see it, the mass classes would probably encompass a bigger and bigger mass interval the higher the mass gets, right?

Well, I pretty much pulled the mass ranges out of thin air. They probably would be bigger absolute-mass-wise, but I'm not sure they'd be much bigger percentage-wise. Basically "Whatever works". The most massive mass class ended up being so big because I was getting tired that day, and also knew that the "Where do we put the jump points" problem would get worse at higher mass classes, so I made it one class rather than two, and stopped building the table with that class.

Ok, after a bit of further thinking on the problems, Here's what I think could be a sensible way to remedy the problem with the jump points:

The program has no way of knowing what links actually exist, except for those in the current cubes, everything else would be too much number crunching.

The generator will mark every star that is connected to the current star, so the player can manually scroll through the cubes and see if he finds a connection he likes. He can designate a linked star as a waypoint, whereupon all links will be displayed respective to that star, so he can plan a route of several jumps.
Additionaly, a search function can be provided that searches for a jump link at a player defined distance in a general player defined direction. I'm afraid that's the best I can do without waiting for the next generation of processors, but maybe you have some ingenious Idea how to further streamline the process without eating up too many cicles.

Sounds good enough for starters, at the very least.

Unfortunately, since custom systems aren't supported yet, a jump back to Sol was not possible...

Oh, a jump back to Sol is possible, but I guess ground control won't be there to receive the message after all.

Since this is now fully orbiter integrated, a patch won't do, it'd need pretty much a whole new version. But since there are no textures, no atmospheres and no custom systems yet (i.e. no return to Sol, at least not the Sol we know) it wouldn't make much sense to release one yet.

By the way, just to check the needs: Would it be greatly apreciated if the next version, allthough capable of running completely inside Orbiter, would still come with an .exe file that allows to use it as a stand-alone?

Yes please.

 

[jedidia]

Implementation of custom systems is comming along, but it's an awfull lot of boring legwork... :goodnight:

They should orbit the star, rather than staying still (otherwise you'd have all sorts of difficulties).

In any case. I would put the jumppoints into Orbiter as vessels, which means that we we can add and remove them at runtime. Which in turn implies that we CAN have different jumppoints for every link, because we only have to have the targetted jumplink in the system, which will be procedurally added when the link was targeted in the galaxy map (also improves oversight. I like it. I really start to like it.)

Well, I pretty much pulled the mass ranges out of thin air. They probably would be bigger absolute-mass-wise, but I'm not sure they'd be much bigger percentage-wise. Basically "Whatever works". The most massive mass class ended up being so big because I was getting tired that day, and also knew that the "Where do we put the jump points" problem would get worse at higher mass classes, so I made it one class rather than two, and stopped building the table with that class.

It might be a good time to pick it up again, then

Oh, a jump back to Sol is possible, but I guess ground control won't be there to receive the message after all.

yap. That would be kind of an alternate universe sol. Since Altair was the destination of the jump, I guess major Tom by now got eaten by his own dark desires somewhere near the fourth planet while listening to old Blind Guardian songs...

Yes please.

ok.

 

[Linguofreak]

It might be a good time to pick it up again, then

What kind of distance would you like to be coverable in a single jump?

 

[T.Neo]

A ship with constant 1G acceleration can reach half the speed of light in about 174 days.

The question is not the acceleration... but where the fuel and power for getting that acceleration (and more importantly the Dv) are going to come from.

And then debris mitigation, and then dealing with the problems that the drive system presents... etc etc.

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.

You can avoid the problem of destroying the engine by using a magnetic nozzle. Admittedly it probably is something that would need a great deal of R&D, but it's far closer to reality than FTL.

Yeah, but I just think it counts as a cheat with our current knowledge of physics. Unless there's some special circumstances I don't know about.

There are several concepts ([ame="http://en.wikipedia.org/wiki/Wormhole"]wormholes[/ame], [ame="http://en.wikipedia.org/wiki/Alcubierre_drive"]Alcubierre drives[/ame] and [ame="http://en.wikipedia.org/wiki/Krasnikov_tube"]Krasnikov tubes[/ame], for example) that allow apparent FTL within the current knowledge of physics, but they are highly speculative if anything.

"Jump Points" could be simulated as wormholes, but doing so realistically would open up an entire can of worms.

 

[Linguofreak]

You can avoid the problem of destroying the engine by using a magnetic nozzle. Admittedly it probably is something that would need a great deal of R&D, but it's far closer to reality than FTL.

Yes and no. 1 gee for a few hours is the upper limit of believability for any kind of drive with an onboard power source and propellant supply. Beyond that you're talking a drive that puts out more energy than the current generating capacity of all of human civilization at this point in history that has to somehow fit on a ~5000 ton ship. For offboard power generation or propellant supply, it's not quite so bad, but it still starts to add up.

On sfconsim-l, even the halfways believable drives are known as MFT's, "Magical Fusion Torches". Beyond that, you need just as much fairy dust and chanting in Welsh as for FTL.

 

[T.Neo]

Beyond that you're talking a drive that puts out more energy than the current generating capacity of all of human civilization at this point in history that has to somehow fit on a ~5000 ton ship. For offboard power generation or propellant supply, it's not quite so bad, but it still starts to add up.

The problem is that if you want to attain high (ie relativistic) velocities, you're going to have to expend enormous amounts of energy regardless.

"high performance" drive concepts usually use nuclear fission or fusion, or remotely, antimatter. Admittedly remote power generation is attractive in that you don't have to lug the powerplant along with you, but it doesn't mean the problem of power generation goes away.

Even modern chemical launchers store a large amount of energy...

 

[jedidia]

What kind of distance would you like to be coverable in a single jump?

hmmm, tough question. I'd say somewhere between 200 and 300 lightyears would be good for a longest range, maybe less, but not more, but that's pure gut feeling.

You can avoid the problem of destroying the engine by using a magnetic nozzle.

That's just the problem, you can't. Unless your magnetic nozzle can take care of the whole luminosity of the reaction (i.e. deflect light at 100% efficiency over the WHOLE spectrum), the waste heat is still too high. A deflection of 100% over the whole spectrum is exactly what the langston-field from pournelle does, so it also gets used as a shield. And for many other things.
If you have a magnetic nozzle that can work at 90% efficiency, (and that's VERY optimistic), the remaining 10 percent are still too much heat. You can further optimise it with some incredibly durable alloy you use to build the core, and by increasing the core radius, but if you do the math you still get rather sobering results for the performance/weight ratio.
I designed a ship once, it was around a 1000 tons empty mass, 300 tons of propellant, and with a fusion engine that had a magnetic nozzle operating at 80% efficiency (i.e. 20% waste heat), and the durability of the core was at the theoretical maximum.
I ended up with a fusion engine with a core radius of 10 meters (!), operating at an ISP of 100'000 m/s and having a rather lame thrust of 55'000 Newtons. Nothing that could get you anywhere near one G acceleration for any extended period of time (of course, on the paper, you can change thrust for ISP as long as the energy output stays the same, but I rather wanted the delta-V than the thrust, so I left it at those values).

"Jump Points" could be simulated as wormholes, but doing so realistically would open up an entire can of worms.

That's why we hex up a new physical phenomenon. Every SF-author does it to a certain extent (even Clarke and Heinlein), so I feel in rather good company. Don't worry, the Jumpdrive will be only an option in Orbiter Galaxy, and you'll be able to deactivate it and have all the realism you want. But I need some form of FTL drive for my future plans, and I'm willing to make that sacrifice to keep everything else stimulating and challenging. For example, I could hex up a drive that runs on fairy dust, but then getting around between the planets would get lame. I want drives to stay limited, so the player still needs those navigational skills, otherwise I could just go and play FFED3D (which is excellent, but I miss the spaceFLIGHT aspect).

 

[T.Neo]

That's just the problem, you can't.

Fair enough, but it's still an engineering challenge, albeit a difficult one, and nowhere near arranging stellar masses of as-of-yet wholly hypothetical matter in terms of implausibility.

I'd be willing to bet that if the arrangement of the engine components was engineered correctly, they could escape a large portion of the waste heat. And there are systems like Orion, which apparently dealt with their waste heat just fine...

 

[jedidia]

well, a way to deflect 100% em-radiation isn't exactly an engineering problem, it's just as impossible as FTL. Dealing with the waste heat might be considered an engineering challenge, but the prospects of solving it are rather bleak. Besides that, we don't even know for sure yet if a self sustaining fusion reaction by artificial means is possible at all, allthough it seems only an engineering problem to make it work.

I'd be willing to bet that if the arrangement of the engine components was engineered correctly, they could escape a large portion of the waste heat

It's a spherical or torroidal core, and the heat from the reaction will spread spherically. I don't see how the core walling could be arranged in a maner to collect less heat. Allthough I'm not an engineer, granted.

And there are systems like Orion, which apparently dealt with their waste heat just fine...

Only for very short pulses, after which it has the opportunity to cool down again until the next. It's quite a different problem.

Anyways, basic architecture for custom systems is implemented. I'm currently writing up a config file with the parameters for the solar system, it's quite some work. If the authors of custom systems want all the data displayed in the system overview of the galaxy map, they'll have a tough job...