Project Orbiter Galaxy

[jedidia]

Why recursing thru docked tree won't work?

It would work, of course, I simply didn't think it neccessary. If the feature is called for, I'm sure I can implement it with some more work.

I assume that, since it wasn't mentioned, there are no problems with attached vessels?

Not implemented yet, but will be of course. If noone would have said anything, it'd probably have been the same as with dockings, but if some people think the feature of vessels attached to vessels attached to vessels attached to vessels aso. is critical, I'm sure I can make it work. At least up to a certain "generation" (c'mon, only japanese put that much boxes into a box :lol

I rebuilt the thing with Universal Cargo Deck anyway

Thanks for reminding me to test the cargo deck. I would have forgotten about that one...

---------- Post added 08-28-10 at 08:37 AM ---------- Previous post was 08-27-10 at 08:06 PM ----------

Success. An ISS docked with two Mirs, which in turn had some deltagliders and shuttle A docked to them, just made a trip to Tau Ceti. So you may now dock up to a 1000 vessels together in whichever configuration (I can up the number if some sick mind thinks he needs more).

Now I'll have to do the same for attachements, which is a completely different kind of animal (I think), but we'll get there.

---------- Post added at 10:39 AM ---------- Previous post was at 08:37 AM ----------

Attachements weren't so different as I expected, so implementing them went pretty fast. It all works now: Docked together vessels with all their attachements and the attachements of those make the switch (i.e. Universal Cargo Deck compatible). The only thing you can't do is initiate the switch while the focus is on a child attachement (doesn't matter which docked ship you're focusing though, since docking connections have no hierarchy), and I'd dare to say that there'll bet a crash if anyone ever manages to dock ships in a loop, but other than that it's running quite stable (there's the odd crash on exit, not sure yer what those are about...).

There was nothing to do for UCGO, since they work without attachement management, everything is written down in the vessel block directly and therefore gets transferred without any trouble whatsoever.

There's a few things left: Asteroid belts don't get exportet yet, the rotation of the ship isn't aligned correctly with the target ecliptic after the switch, I have to find a way of calculating a sensible atmosphere altitude limit, and there's a few issues with the textures. But I'm getting there, can't quite believe it myself yet...

I'm gonna get myself the long shot now and have some fun!

 

[Izack]

Success. An ISS docked with two Mirs, which in turn had some deltagliders and shuttle A docked to them, just made a trip to Tau Ceti.

That is one of the most awesome things I have ever heard.

 

[jedidia]

Yay, testing two addons at once. That's a view on the inner system of Tau Ceti. A bit crowded, but no, there's no coliding orbits as it might seem on the pic, one planet has a bit a higher inclination than usuall. Overall it looks very nice.

You can see me here on the final aproach to Tau Ceti f. The trajectory comes from "above" the ecliptic, because Tau Cetis ecliptic is almost aligned with the galactic plane and standing underneath the sol system. The re-orientation of the vector to the new ecliptic frame seems to work quite nicely, allthough I can't get the nose to face the right direction yet, no Idea why. They're using one and the same rotation matrix...
And the Navigator, well... that one's going to be so cool, navigation will never be the same again! Allthough there's no automatisation yet, It's really great to plan a course with it. And you're actually seeing what you're doing for a change!

 

[jedidia]

While Orbiter Galaxy becomes more and more playable, I get to play with it more and more... which means I notice shortcommings that I wouldn't have expected, so I'm implementing a little unplaned feature every now and then. Today, for example, I reworked the output methods for the systems in a way that lets the user define how many systems he wants to keep on the hard drive before the systems and their textures get deleted again. Before this, there were always a maximum of two systems resident: the one you are in and the one you targeted. The new system should speed things up greatly for "planet hoppers" that visit the same few systems a few times, and also helps creating a buffer that takes crashes something of their edge. If there was a crash with the old system, in 99% of the time you couldn't reload the old scenario, nor could you start the new one with the new system.

 

[Moach]

man, this is great news!

so awesome that not only you're getting dynamic systems, the navigator also works in them :woohoo:


this project(s) rock!

---------- Post added 09-01-10 at 12:35 PM ---------- Previous post was 08-31-10 at 04:58 PM ----------

O-M-G!!!!!! :hail:

just now it hit me what this project is about! you're effecivelly making Orbiter and Spaceway one and the same :woohoo:


how come i didn't hear of spaceway earlier?? what an awesome thing! it's like Spore but with brains, and without evil EA :tiphat: - hear THAT, Will Wright?! here's what you get when you fail to deliver! :lol:


if you need anything, programming-wise or art-related (sounds, graphics, 3d) - i'm hereby reporting for duty!

 

[jedidia]

:lol: You grok somewhat slowly, my friend... although the statement

just now it hit me what this project is about! you're effecivelly making Orbiter and Spaceway one and the same

Is not quite accurate. The only thing this has currently to do with spaceways is the texture generator. Mostly for the two reason because there's nothing else around that's really usable (and the spaceway textures are quite nice and are getting better as I write), and that Artlav has a big interest in Orbiter and is able to assist me without me having to explain much.

However, appart from textures, Orbiter Galaxy and Spaceway have not a lot in common (yet). Spaceway is a kind of next generation Noctis that focuses on producing an unlimited(!) virtual Universe (you can even switch galaxies!), while Orbiter Galaxy's focus is more on accuracy: More accurate planetary properties, more believable systems (at least I hope in the end, there's still a lot of work to do) and most of all, existing stars and the ability to add custom systems as they are mapped out in real life. It also focuses on giving the player a fast and efficient overview over where what is. While Spaceway is in essence a universe generator, Orbiter Galaxy is in essence a map. So while Orbiter Galaxy allows you to plan stuff, exploring is much more involved, fun and carefree in Spaceway.

Also, There is no way for me to ever reach the graphical proficiency of spaceway. I currently can produce the same textures (thanks to Artlav), which takes a whole lot of pre-calculation time before you can switch from one system to the other, and I don't have any terrain whatsoever. The only possibility of ever changing that is if Artlav puts the WHOLE procedural graphics system into OGLA, a thing he might or might not like to undertake at any unsepcified time in the future.

So no, I'm afraid this won't be as nice looking as spaceways. The bright side is, you can use all of Orbiters add-ons to do exciting stuff like building your own base on a planet at the end of the galaxy and stuff like that.

i'm hereby reporting for duty!

Thanks! It looks like I'm fine for now, but the point where I'm going to put generated Starports into Orbiter Galaxy is a faint speck growing slowly brighter on the horizon. When I reach that stage, I'll need building meshes. The more the merrier. From current tech realistic to futuristic-insane architecture, buildings for every conceivable purpouse. I want to make this thing as flexible as possible, so If some people want a realistic colony they fly to at relativistic speeds, or people want to fly their star trek vessels with warp drive to futuristic cities, they shall get it. So, if you'd crunch out some kind of building mesh every once in a while, I'd be happy to accept it into my yet unexisting collection

 

[DarkEnergy]

This project has been getting better and better. I can't wait to explore other new places in Orbiter and set up colonies. Thanks for the hard work you're putting in it! :thumbup: I can tell it will be great.

I don't know if this has been discussed and there are a lot of pages to look through, but will this be seamless like Spaceway? Or will it need a loading screen? Either way is fine, I'm just out of the loop. :lol:

 

[jedidia]

will this be seamless like Spaceway

No, as far as I know that's not possible with the current orbiter architecture. It might be possible to hack something together if we'd find a way to load textures on runtime, but I'd rather wait until Martin puts an architecture for interstelar travel into the core.

 

[Artlav]

which takes a whole lot of pre-calculation time before you can switch from one system to the other

Don't be pessimistic yet, i have an idea.

Please check this thread:
http://www.orbiter-forum.com/showthread.php?t=17927

 

[cinder1992]

No, as far as I know that's not possible with the current orbiter architecture. It might be possible to hack something together if we'd find a way to load textures on runtime, but I'd rather wait until Martin puts an architecture for interstelar travel into the core.

if you'r lucky, he might use yours! :lol:

 

[jedidia]

if you'r lucky, he might use yours!

Well, it's not really an architecture, and it uses its own graphics engine, so I don't think the chances of that happening are too high. besides that I'm a pretty novice coder without any education on conventions and proper coding structure, so putting that piece of spaghetti into the probably very professionally written Orbiter core would be kind of defilation :lol:

On another note, I put asteroid belts in. The user can set in the config file a minimum and a maximum number of asteroids per belt, so everyone can have his taste (It's getting confusing enough already in the navigator with 5 of them, so watch out!)

My Bus will be leaving in 6 hours, then I'll be on the road for the better part of september. I'll probably be able to visit the forum, but I don't know how much coding I'll get done. Still, even if I can't code a single line, beginning of November still looks good. There's almost nothing left to fix, and nothing to add for that version anymore, only some optimisations to take care of, and a new parser for the custom system files, so 3rd party developers don't have to annoy themselfes with the peculiar format I was using so far :lol:

Don't be pessimistic yet, i have an idea.

sounds like an awesome plan. Didn't work yet with my graphics card (see thread), but that would definitaly be pretty coooooool!

 

[Moach]

well, he doesn't have to build the entire thing into Orbiter, really... as long as some key features are exposed, the generator should integrate seamlessly even as an addon :hmm:

has this been discussed directly with Martin?

 

[jedidia]

as long as some key features are exposed, the generator should integrate seamlessly even as an addon

Well, OGLA is an addon of sorts...

besides that, I think we're talking about two different things currently: one is the procedural generator, which could work in OGLA or as an advanced Orulex, but there's a whole lot of trouble with that. Not impossible, but would need a lot of effort from Artlav, which is entirely his to spend or not to spend. I'm glad for what I have already (and spaceway seems to be REALLY busy these days )

The other is making transition from system to system seamless, which is a feature that would definitaley have to be put into the core. If possible in combination with a completely dynamic system architecture, but Martin just got a patch on the market, and he said interstelar travel is something he might think about for a next version, so we'll have to wait for that a bit. Until then, it's splash-screen.

 

[Moach]

seamless system-to-system transitions would seem more important than it may really be...

think about it... the nearest system with planets is a couple of hundred lightyears away... travelling there in an acceptable sim-time (i can't really afford to spend a hundred years sitting on my PC, as much as i'd enjoy that, i got other stuff to do :lol would require lots of time accel...

and thinking about it, FSX would go "loading screen" every time after you return from >4x time warp - no-one seems to bother much with it....

so a loading screen is fine, i guess... as long as it's quick and doesn't break immersion by showing the desktop and all :hmm:


either way - this is gonna rock absolute! :thumbup:


cheers!

 

[DarkEnergy]

so a loading screen is fine, i guess... as long as it's quick and doesn't break immersion by showing the desktop and all

Perhaps, an animation of moving stars in the load screen to preserve the immersion? :lol:

But more seriously, a loading screen is fine. I'm more interested in exploring the actual planets, and even if it were possible, 100000x time warp is hardly enough.

 

[jinglesassy]

A loading screens fine with me too. But if we have to go seamless better add in 100,000,000,000x time warp

 

[jedidia]

as long as it's quick and doesn't break immersion by showing the desktop and all

Well, that's a little problem there... It's basically orbiter shutting down and starting up again, and with Orbiter set to respawn process it's too fast to see the desktop... in theory. In praxis, it can happen that the Orbiter window doesn't get the focus correctly, in which case you'll have to switch back to the task manually. Shouldn't happen in fullscreen mode, though.

Perhaps, an animation of moving stars in the load screen to preserve the immersion?

It's the standard Orbiter splash screen you'll see. Because Orbiter is shutting down and starting up with the new scenario on its own. That's the only hack that would allow the switch at all. How long the splash screen is there depends entirely on how fast your machine is and how large your textures are.

I'm more interested in exploring the actual planets, and even if it were possible, 100000x time warp is hardly enough.

Which reminds me, I have to put in a configurable switch distance. Currently it will only switch at half way there, which is great for warp drives, but not really for anything else.. Although people will have to accept some backdraws for this: I can propagate time, but that won't change anything for the fuel left in the ship, or the UMMU oxygen suplies (then again, I could probably do something about the fuel issue... will have to see. Can't guarantee that it will make it into 0.6, but that one will need some patches anyways until it runs for everyone).

 

[Face]

Well, that's a little problem there... It's basically orbiter shutting down and starting up again, and with Orbiter set to respawn process it's too fast to see the desktop... in theory. In praxis, it can happen that the Orbiter window doesn't get the focus correctly, in which case you'll have to switch back to the task manually. Shouldn't happen in fullscreen mode, though.

Didn't MSSSMFD have a kind of transition-screen? I guess it was done by starting an external program on shut-down of Orbiter. That program displayed a splash screen and started Orbiter again with the appropriate scenario. Maybe something like this is possible.

In addition, you can patch the splash-screen of Orbiter, too. You could e.g. save a picture of the current camera-view prior to shut-down to a file. Then, after Orbiter starts again and your module gets loaded, you could load that file and patch it into the splash-screen memory. This would cause Orbiter to show the last camera-view statically while loading. After simulation start, just re-patch the splash-screen to what it was before.

cheers,
Face

 

[jedidia]

Didn't MSSSMFD have a kind of transition-screen?

I never noticed one...

hen, after Orbiter starts again and your module gets loaded, you could load that file and patch it into the splash-screen memory.

that sounds like a neat idea. I'll look into it for a next version.

 

[ond1]

Maybe he went to use the module teleportation gates, as interesting.