Project Orbiter Galaxy

[Frogisis]

Let me say this whole thing looks absolutely amazing and I wish I had the time to contribute... Stupid real life, not being in space.

I might be in the minority in that I really want to do my interstellar flying at sublight. I'll just say my ship is run by an AI to whom spending a thousand years in transit isn't that huge a deal. I really like the McGuffin drive, though, and the focus on making the galaxy an exciting and dramatic place to explore, but I'm not sure I understand what the Vector MFD is capable of in terms of navigation, as well.

It would be great if there were some provision for using up fuel in transit to decelerate so that you've got the right amount of propellant remaining when you arrive at your target system, depending on the variables you entered for how fast you wanted to get there.

Maybe the loading screen between systems could be a separate little window running in front of the Orbiter loading screen, counting up the years in transit, and the fuel remaining, and showing a little icon moving between two stars... I don't want to pile work on you unduly, I'm just brainstorming...

As for the planet texture loading, what about generating and releasing libraries of pre-rendered textures to fill the gaps? Maybe before you load a system you could pick which planets you wanted to generate, if any, and the others would be picked from "Orbiter Galaxy PlanetPack 5" or whatever.
Maybe you could run the texture generator overnight on your own machine, too, and have the unique systems you want for a flight the next day waiting in the right folder.

 

[DarkEnergy]

I might be in the minority in that I really want to do my interstellar flying at sublight.

Well, as far as we know, you are in the majority. Unless someone discovers a work around to the relativistic speed limit, we will all be going sub-lightspeed... The difference is that time will move much quicker for you than the people that are not in your spaceship (of course Orbiter doesn't simulate that yet, but you know, if you wanna stay realistic).

 

[Frogisis]

Well, as far as we know, you are in the majority. Unless someone discovers a work around to the relativistic speed limit, we will all be going sub-lightspeed... The difference is that time will move much quicker for you than the people that are not in your spaceship (of course Orbiter doesn't simulate that yet, but you know, if you wanna stay realistic).

Well, yeah, I just meant in the sim. Personally I doubt FTL is possible, at least the way it's often imagined.
But in Orbiter we can be magic if we want to; I just don't want to rely on it.

 

[DarkEnergy]

Being magic in Orbiter sure is fun. Until you get careless. :lol:

In Orbiter Galaxy I'll probably go sub-light too and once I arrive at the other system, figure out the time dilation (using "1 / sqrt(1 - v^2 / c^2)") and adjust the date to the proper relativistic time.

 

[Moach]

Well, yeah, I just meant in the sim. Personally I doubt FTL is possible, at least the way it's often imagined.
But in Orbiter we can be magic if we want to; I just don't want to rely on it.

well, as far as my understating of relativity goes, FTL travel is impossible by definition... however, that doesn't mean you can't travel the length of a lightyear in less than "one year" - remember, it's ALL RELATIVE, including time itself :thumbup:

wait, what??

it's quite a large concept to get in your head (that's why we call Einstein a genious) - the thing is, you'll always perceive the "speed of light" as the same speed, relative to you

this is regardless of how fast you're going, because as it turns out, you might as well be stopped - the thing is: THERE'S NO SUCH THING AS BEING "STOPPED"...
there is no absolute state of rest, so if there's no zero, how could there be an "upper speed limit"?

there couldn't...
...and you know what? - there really isn't :blink:


there's no cosmic speed limit - what happens is that while you speed towards it, you'll notice that it "speeds up with you"... at the same time, for someone back at wherever you departed from - it also remains unchanged

how's that possible?

well, TIME itself "bends" in order to maintain the "upper limit" unchanged... so while you accelerate, your very perception of "speed" is altered in such proportion, that the speeed of light, as well as all other laws of physics remain constant :tiphat:


cool, huh?

 

[T.Neo]

There are possible methods of FTL, but they're highly hypothetical if anything. Of course we can magic anything into Orbiter that we want, based on these concepts or totally fictional, like a hyperdrive or magic portals that can be generated from a wristwatch.

Of course though, I agree... I would very much like to navigate the playing field "naturally", either with some form of sublight propulsion or some FTL-gizmo (Orbiter is, afterall, newtonian and doesn't limit velocity to C). At 0.92 c, travels up to 10 light years become feasible... and although we don't have relativistic effects in Orbiter, we do have time accel... :hmm:

 

[Moach]

hmm... how's this for a slogan?

"Orbiter Galaxy! -- relativistic effects disregarded for YOUR convenience!" :lol:


i've concluded that it really doesn't matter if relativistic effects are simulated in Orbiter or not... you're switching from a system to another, this will cause the sim to reload, and in doing that, the time-lapse can be safely compensated (if desirable)

as long as you have nothing to compare against, there are no relativistic effects - remember, it's ALL relative

yet i reckon this WOULD matter when flying inside a system.... time would move faster as you travel near S/L... hence, planets would be found at different positions....


simulating this can be very tricky... i believe it could not be done by simply using the default time warp feature alone.... your ship would have to be "unwarped" in inverse proportion for it to work properly


perhaps it could be implemented by an addon... has it not already? what's that "relativistic warp mfd" about, anyways?

 

[Frogisis]

Even without directly simulating relativistic effects, you could create a workaround that would at least bring them into the mind of the player...
I'm not sure how big an effort this would be to program, but during the reload between systems, it would be neat if you could get a window displaying the relativistic effects you'd be experiencing, at least as just hard data like how long the trip would seem to you vs. those back home. Maybe even a scalable sprite of a starbow, too, in a little box in the corner or even as the background... I dunno.

So while the next system is loading underneath in Orbiter, you'd see a splash screen saying something like:
"CRUISE PHASE---*DECELERATING*
Sol to Procyon
Current Speed: 0.32c (96,000km/s)
Max Speed: 0.7c
ELAPSED TIME---
Shipboard: 3yr 6mo 12dy
Base: 17yr 11mo 4dy

Remaining Propellant: 21%

Sol -----------------------+>----Procyon"

Then that business closes and voilà, there you are in your newly-loaded star system, ready to explore. The appropriate Lorentz equations aren't that complicated, and you could even assume half the trip is accelerating and half is decelerating to keep it simple, but I'm not sure how much of a chore it would be to create an MFD (Vector MFD?) that would let you plug in the flight profile you wanted, calculating for the capabilities of the ship you're flying, and then export it to this little loading window, close Orbiter and run the window, and then change the scenario that's loaded so you have the right amount of propellant left and the date is correct, etc... It might not be worth the distraction from the actual meat of the project.

 

[Moach]

yeah, but it can be tricky to account for that... have you ever read about the "twin paradox"?
it's not a proper paradox, really... but it seems like it would be one at first glance -

briefly explained (to be taken with a grain of salt, too):

two twin brothers are enrolled in a space program - one will leave earth and travel at almost the speed of light, the other will stay back and wait...
but, remembering that there's no such thing as an absolute frame of reference, once the ship departs, each brother sees the other one "moving away"...

so how come once the astronaut brother returns, he is the one who has aged less?

at that moment, it would seem like we have a paradox in hands... but turns out it can be explained...

although both brothers see the other one as being in relative motion, their overall situation is NOT really symmetric... the brother in the ship has undergone a reference frame change, while he accelerated outwards and when he turned back around....


and right there, the logic of why that makes him the one who experienced less "time" continues to puzzle me a bit - can anyone clarify?

 

[jedidia]

great discussion here while I'm away :thumbup:

To address some points:

I'm not sure I understand what the Vector MFD is capable of in terms of navigation, as well.

It's not capable of much, but it should be enough: It points the direction the star lies from your current position. Given that if you go sublight, you're still dealing with velocities that don't care much about gravity influences (at least not of planets. And simulating gravitational attaction of other stars along your way, oh my, there's a can of worms I'm not going to open), the direction to point your nose and start the thrusters should be enough. You're not going to slingshot around jupiter to get to Alpha Centauri or stuff like that anyways.

As for calculating stuff while you're underway, here's what it currently looks like: You can define a "switch distance", i.e. the switch will happen as soon as you reach this distance from your current star. If you set that distance to 0, the switch will happen when you're in the middle, i.e. you'll travel half the way in the reference of your current system, and half the way in the reference of your target system. in this case, you'll have realistic fuel consumption and realistic concumption of supplies by UMMUs. If you set the switch distance to earlier, you'll skip the way in between. There will be a calculation for fuel consumption, but I'm not sure if it will make it into version 0.6. Also, there will be a problem with stacks. If you intend to use another vessel for the breaking maneuver than you used for the acceleration, I can't foresee it. The same goes of course if you want to drop stages along the way. So that method won't be perfect by far, if you want to have it realistic you'll have to make the flight half/half and wait a while... Also, getting to your target too late will probably lead to the known bumping up and down effects on planetary surfaces, although I could prevent that by adjusting the epoch in the cfg-files of the exported planets (although the player would have to specify some kind of eta for that, since the system gets exported right after targetting it (i.e. at the beginning of the voyage).

I'm sound enough at special relativity to put in a lorentz compensation for the time passed, I think, although the only thing that would change is your arrival date, and the compensation would only be for the distance skiped in the switch (I guess I'd have to work with two different time frames, one of your ship for fuel consumption, and one for earth to keep the calendar at the right date, then display the time actually passed on the ship in transit, or there wouldn't be any sense to it). On the other hand, most people are probably spending most of their time with acelerating and decelerating, which means special relativity doesn't apply anyways, and general relativity is waaaay over my head. But, as mentioned, MAYBE the fuel consumption will make it into version 0.6, everything else (like splashscreens and relativistic stuff) will certainly have to wait until later. Let's not forgett that this will be an early Alpha release...

and right there, the logic of why that makes him the one who experienced less "time" continues to puzzle me a bit - can anyone clarify?

In short, and technically not quite correct terms, because he moved faster. Or, because time moved slower for him. Or, because he had less way to cover (lorentz contraction). You may choose any of the three, they're all correct in a way, and all wrong in a way. Probably the fact that time moved slower for him because in his frame of reference light moved faster would be the most precise short formulation, but a pretty confusing one too. Everything else needs a bit more time to explain (and I keep forgetting the precise explanation because its so darn counterintuitive and have to refresh the topic every time I think about it :lol

 

[Linguofreak]

and right there, the logic of why that makes him the one who experienced less "time" continues to puzzle me a bit - can anyone clarify?

What it comes down to is that for three dimensional Euclidean space you have a quantity called "distance" between two points, determined by the Pythagorean theorem:

d^2 = x^2 + y^2 + z^2.

(You often see the two dimensional version of this given as "a^2 = b^2 + c^2" in geometry classes)

A straight line in Euclidean space is the shortest distance between two points. For four dimensional Minkowsky spacetime, however, you have a quantity called the "spacetime interval" between two points (often called "events", since one of our coordinates is time), which is determined by a variation on the Pythagorean theorem:

s^2 = t^2 - x^2 - y^2 - z^2

where s is the spacetime interval and t is time.

By this equation, when s^2 is positive between two events you have a "timelike" separation (that is, there exists a slower-than-light reference frame in which the only difference between the coordinates of the two events is their t coordinate, so they can be described as the same place at two different times in that reference frame, and s is the length of time between the two in that reference frame).

When s^2 is negative (s is imaginary), the separation is "spacelike", and you can't get from one event to the other slower than light. However, there exists a slower-than-light reference frame in which the difference in the t-coordinates of the events is zero, and the only difference in coordinates is in the x, y, and z coordinates. In this reference frame, the events can be described as two different places at the same time, and the absolute value of s is the distance between the two points in that reference frame. When s^2 is 0, the two events are at a "light-like" separation, which means that, by travelling at exactly the speed of light, you could get from one to the other. In all reference frames, t^2 = x^2 + y^2 + z^2 (ie, the time between the events is equal to the distance when the separation is lightlike (distance divided by the speed of light, if you aren't using a system of measurements where c = 1)).

Basically, what it comes down two is that because t has the opposite sign from x, y, and z, a straight line in spacetime is the *longest* route between two events (approximately. I can think of some ways you might get a longer route, but none of them would be physically possible to follow with a spacecraft). Acceleration is simply a curved path through spacetime, so an unaccelerated path is the longest route between two events in spacetime, which, for two events at a timelike separation, means that an unaccelerated path takes the longest.

 

[jedidia]

Very good! I like the new custom system feature!

However I got a bunch of crashing and CTD's.

Please try to reproduce the crashes on a clean install. I can't do anything by just knowing that there's a crash.

Also, when i set a system as my target the Orbiter Galaxy window doesn't minimize, so the textures don't generate.

This is *very* weird. Anyone else having the same problem? I need to know how it fares on other machines, since on mine it's no problem...
Are you exporting from the standalone .exe or from the orbiter plugin? the standalone will not minimize, it will just freeze until export is finished. Export might take a while, but it should be working.

This is apparent when a few Orbiter scenario loads later, I find myself in the Rigel Kentaurus B system, but no textures are visible.

What do you mean "a few scenarios later"? You don't just end up in another system unless you travel there.
If you travel there before texture export has finished, it is logical that there are no textures.

Either way, I love the addition of custom systems. I'll get right to adding a ton of known Exoplanet systems!

Please do that! the more system support the framework, the merrier! :thumbup:

I'll finally go to sleep now (darn, it's half past two in the morning over here!) I guess I'll have my work cut out for me over the weekend, but I'll need a bit more precise reports than provided here if I am to fix anything.

 

[Izack]

Bugs...bugs...

The Galaxy Map window won't display anything unless I jiggle it around a bit, and then doesn't accept any mouse or key commands. I clicked on Orbiter's window and pressed some buttons as per instructions.

Beyond that...well, there's really nothing for me to test if I can't go anywhere.

Nevertheless, congratulations on your release! It must feel good to finally have a usable (questionable, but not trying to burst any bubbles) product out.

 

[IgnoreThisBarrel]

I got a bunch of crashing and CTD's when pressing the JMP button after selecting a system. When I set a system as my target the Orbiter Galaxy window doesn't minimize, so the textures don't generate (?). This is apparent when a few Orbiter scenario loads later, I find myself in the Rigel Kentaurus B system, but no textures are visible. Instead I just see some black spheres, and other spheres which are illuminated but have no texture.

EDIT: Oops, i found you had already addressed my issues. Anyway, I'm posting them here with slightly better grammar.

Edit2: Also, this is when I'm using the plugin. The standalone works great as usual.

 

[jedidia]

The Galaxy Map window won't display anything unless I jiggle it around a bit, and then doesn't accept any mouse or key commands. I clicked on Orbiter's window and pressed some buttons as per instructions.

The mouse *might* in rare cases be unresponsive, which can usually be fixed by closing the map and opening it again. It should work most of the time, really...
The fix posted works only for keyboard commands, and you have to press a KEY to resolve it, not a mousebutton.

If the problem persists, I need some more information: OS, Orbiter version, that kind of stuff.

Beyond that...well, there's really nothing for me to test if I can't go anywhere.

You can still try the standalone .exe file. But if I remember correctly, you were having difficulties with the las release too?

Also, this is when I'm using the plugin. The standalone works great as usual.

Ok. Since you found yourself in the system "some scenarios later" (did that happen accidentaly? if so, 0_0!), it clearly shows that the cfg export works. that means your window at least flickered when targeted. But only the first time around! once it's in the cache, it won't be exportet until it gets thrown out again (which depends on how high you set the cache size in the cfg). That would mean that something with the texture export goes wrong... try to set your texture export method to CPU (0) in the cfg and see if the problem persists (target another system, or remove that one from the cache. make sure the number on top of the cache file shows the correct number of systems after you edited it).
It is still strange, since your settings seem to work fine in the standalone...

I got a bunch of crashing and CTD's when pressing the JMP button after selecting a system.

What vessel were you using? Did you change your Orbiter Restart options to "respawn orbiter process"?

Also, is there anyone who downloaded it where it works without any of these troubles? that would be kind of important to hear...

---------- Post added at 10:44 AM ---------- Previous post was at 10:36 AM ----------

Ooops, I just found a slight problem. Has nothing to do with the above, but I can tell you that currently your old textures aren't going to be deleted!! The texture log is saved in a wrong directory, a fragment left over before the cache was introduced. Seems like now I'm spawning peoples harddisk with textures! Damit, that's exactly that stuff that SHOULDN'T happen!

---------- Post added at 12:26 PM ---------- Previous post was at 10:44 AM ----------

Patch is up!

Will not help any of the above issues, but will prevent your HardDrive from getting filled up with unused texture files. Once more, sorry for the potential harmfullness of the initial release. That really shouldn't have happened!

 

[dumbo2007]

ok I am able to complete the quick start part of the manual in my machine....Pentium dual core , Intel GMA onboard gfx - 4500M. The OG window opens from the MFD when I press Map and I followed the instructions to successfully activate the keyboard. I chose a new system and the window minimized to generate the new textures. However it stayed minimized for a long time, so I decide to maximize it :lol: to see what was up. At that point the graphics inside was flickering - I had the planet details displayed in the GUI in it. So I assumed it was done exporting and I closed it, targeted my vessel to the star using tgt and dir buttons and maneuvering thrusters of the stock dg, and pressed jmp. Orbiter exited and restarted - I saw a new scenario !OGSwitch in the launchpad. And voila!!..i was in a new system. But the alien star appeared to be quite far away and there were no planets close by - but I was in a new system - I ll post a more thorough report later...your work rocks man :thumbup: !!

---------

- Can you put in a progress bar in the MFD or somewhere..so we know how much time is left before exports are done...or simply to intimate the user of definite progress during texture export

- Also ...I guess there will be a way to position the vessel in orbit around the targeted planet after the scenario restart instead of somewhere out in the oort clouds

 

[jedidia]

Sounds like everything pretty much works as perceived, that's very reassuring. Which also means that the lockup after export isn't native to my machine but happens on other systems too. We suspect that it's related to the GPU texture export. By the way, could you post your shader.log (should be in your Orbiter root directory)? Although it would really amaze me if that gpu of yours would be compatible.

Since it took a long time for the textures to export (and considering your GPU), I must assume that the generator fell back on CPU generation, but I'd like to verify that by taking a look at the shader log. If this is the case, you can change the generation method to CPU in your OGalaxy.cfg, that will prevent further lockups after export.

- Can you put in a progress bar in the MFD or somewhere..so we know how much time is left before exports are done...or simply to intimate the user of definite progress during texture export

Is planed, Artlav even gracefully provided me with a callback function that can be used to do just that, but I'll have to restructure the code somewhat in order to able to access the window handle from it. Would have taken too long a time to do before the release, and you'll probably have to wait some time until I get around doing that, sorry.

- Also ...I guess there will be a way to position the vessel in orbit around the targeted planet after the scenario restart instead of somewhere out in the oort clouds

You should enter the targeted system at the same position relative to the star as you had to the sun (although not with the same trajectory). A canonical way for FTL travel is planed for the next major release (0.7) which will probably take another year or so of developement, but for now this is all you'll get. It's more for debuging purposes than anything else. If you want to get anywhere very quickly, I'd suggest using a Warpdrive or Jumpdrive MFD. The new star apearing far away can also be due to it being much smaller than the sun. You can read your distance to the source in the MFD to get a rough estimate of where you are, or you can use videnie or the orbiter navigator.

Thanks for the report, it's good to hear that it works. I guess the high download rate and rather marginal feedback here suggests that it is working for most people. I'd like to take a deeper look at the problems of IgnoreThisBarrel and Izack, though...

 

[dumbo2007]

Yes I understand....ok here is the shader.log file

 

[jedidia]

This is interesting... it doesn't say anything about the shaders being compiled, but maybe it doesn't if they are all compatible, but I would be quite amazed if that were the case for an onboard GPU. Artlav will have to take a short look at this...

 

[Fizyk]

I tried it, but I encountered a problem. The Galaxy Map doesn't refresh itself, unless I move the dialog at least partially outside the screen. The image refreshes then, but obviously this makes it impossible to choose a star, because I have to be moving the dialog in order to see what I'm doing.

Also, that's only in Orbiter - if I launch the standalone exe, the map works perfectly.

In case you need this, I'm on a computer with AMD Turion 2x2.2 GHz, 4 GB RAM, ATI Mobility Radeon HD 3650 (yeah, I'm on a laptop) and Vista Home Premium.