Idea Kerbal Style Vehicle Assembly for Orbiter

[Royalkin]

Hello fellow Orbinauts,

I've been playing Orbiter for a couple years now, and recently picked up Kerbal Space Program. I love both for different reasons, Orbiter for it's realism and exacting physics, and KSP for it's Rocket Building Feature

Is there no addon, or future addon that would provide this feature to Orbiter, or is the idea even possible?

BTW, I did try to search for an existing thread, but found none with my specific question answered. Which is odd, being that I figured the idea would have been a frequented topic.

Anyway, thanks in advance. :tiphat:

 

[N_Molson]

You should try Velcro Rockets, which, while not as user-friendly as KSP, of course, allows you to make your own launchers from various stages, and even easily make your own custom stages with new or existing meshes.

I've been thinking about it too. Some things are possible and other aren't because of different game engines (Orbiter has its very own, KSP uses Unity).

What would be doable is :

- Create a 3D VAB interface.
- Create various parts : engines, tanks, fairings, etc... with properties like mass, thrust, resistance to dynamic pressure or vertical velocity impacts...
- Create an interface (even text-based) that would allow to stick some parts together using some kind of "logical tree" to define which parts are compatible.
- Create a more evolved assembly interface using the 2D panel or 3D virtual cockpit features, with parts preview (scaled down simplified models ?)
- Let the possiblity for the user to add parts via .cfg files (very much like Velcro Rockets).

What would not be possible :

- Make a "point-and-click" interface as flexible as in KSP.
- Simulate the physical interaction between parts. Well, in the absolute, you probably could, but it would be a coder hell.
- Simulate collisions between parts.
- From the two previous points, your launcher would never suffer structural failures caused by improper building.

Now of course, something simple like defining some parts as Vessels would probably be doable. Like :

Engines : SSME, RS-68, F-1, RD-107, RD-170, OMS pod (parallel), RSRM (parallel or inline as 1st stage), etc...
Tanks : Short/Medium/Long, 4/6/8 meters of diameter, LOX/LH2, Kero/LOX, Hydrazine...
Fairings & Interstages : Short/Medium/Long, 4/6/8 meters of diameter, adapters to switch from a diameter to another...

Then you code "rules" in the "Vessel-parts" to define compatibilities : "SSME class" can be attached to "all LOX/LH2 classes" but "not Kero/Lox or Hydrazine classes". Same idea for the adapters/fairings/tanks...

:2cents:

 

[PeterRoss]

What about IMS?

 

[Royalkin]

Thanks for the suggestions guys, I will check in to them.

 

[4throck]

The simplest solution for Orbiter would be to create a velcro / multistage scenery generator.
It could even be 2D. Simply provide an image for each stage, load the actual parameters and display the components with their relationships.

Sure, no explosions or pieces falling off at launch, but a simple step in the right direction.

A second version could add some system simulation just like IMS and perhaps handle temperatures and aerodynamics. The would certainly make some combinations "blow" :lol:


But IMS is the way to go right now. You have to setup your craft in orbit, but it's possible to place it on a pad and launch it.

 

[PeterRoss]

But IMS is the way to go right now. You have to setup your craft in orbit, but it's possible to place it on a pad and launch it.

I prefer launching module stacks or individual modules to orbit and then assemble them there using tugs and RMS. Time-consuming though, it's a great experiense.
As for assembling it prior launch to orbit - it's basically the same thing you're doing in KSP except that there's an open space around you instead of VAB with little green men running around.

 

[N_Molson]

Notice that next version of Orbiter will allow to dock vessels on the ground. It should be possible to assemble stuff easily using the scenario editor, and will definitively help a lot. One of the best features is that Orbiter determines automatically the CoM/CoG of a docked assembly, taking into account the mass and size of each component. :yes:

 

[BruceJohnJennerLawso]

Notice that next version of Orbiter will allow to dock vessels on the ground. It should be possible to assemble stuff easily using the scenario editor, and will definitively help a lot. One of the best features is that Orbiter determines automatically the CoM/CoG of a docked assembly, taking into account the mass and size of each component. :yes:

True, although control will still be quite difficult all the same.

I would love to experiment on something like this, but my time for such things is constricted to nil right now. I do have a vaguely similar project on my computer called VirtualVab. No guarantees of any kind, but it might eventually evolve into what you're thinking someday.

 

[AlfalfaQc]

I would really love something like that, even if it's not exactly like KSP (drag and drop), it would help a lot. It is the only thing missing really IMO in Orbiter. I tried using Velcro, but it can become complicated sometimes. A simple "ship builder" would be pretty neat.

 

[4throck]

Simple is the key here. Something that provides some GUI in creating a velcro config would be nice.
The same approach could be used to create a docked vessels scenario, that you could then use with IMS.
All you need is to output some a simple text files.

On my end, I know this can be done with Javascript and be browser based.
Anyway, it will be a team effort to get the relevant physical parameters of each rocket into XML or a database, along with an image of each, etc, etc.
You will need those for any decent GUI (even if only text / simple graphics), and it's a big job for a single person.
Orbiter doesn't care about geometry, but it does care about where the docking ports are, so that's really the only graphical information you really need. For the rest a generic top / side view of the assembled meshes would do. Can be done with saved images of each one, no need for fancy 3D engines.

_____________

IMS is the way to go. I successfully built a large self launchable/landable space station that was fun to operate. It's solar powered, so I had to deploy the panels and change the batteries on ground. Then the panels were retracted for launch, with the vessel using just batteries until out of the atmosphere. That is quite fun to operate indeed!

 

[Loru]

That's totally doable. Woo482 implemented that in limited fasion in Themis-A configurator utility:

 

[N_Molson]

Do you think he would have the kindness to share the code ?

 

[Napalm42]

I think the Delta IV rockets somewhere on OH have this functionality too.

EDIT: But yeah, IMS is your friend. I've been gaining experience with it assembling stations in LEO and HLO, and possibly will eventually build out into interplanetary station-craft once I can figure what works and what doesn't completely.

 

[Loru]

Well - this configurator is specially designed for Themis (already known dimensions of rocket etc) However you won't know it if you don't ask him.

 

[4throck]

That configurator is what I was trying to explain. The group effort I mentioned would be get the images and dimensions for the several components.

 

[jedidia]

The group effort I mentioned would be get the images and dimensions for the several components.

Just write a .msh and .cfg importer and plug it into an open 3d engine like for example irrlicht, and you have a universal solution. Point-and-click interface is a bit more work, but not very difficult to do in that environment. It could even be adapted to run in a seperate thread on runtime, Orbiter Galaxy style.

You can use this for creating just a docked vessel assembly and then load it into orbiter (also doable in runtime), or it would even be possible (since IMS is basically open source) to run the whole thing and load the finalised vessel into orbiter. This would be a lot of work, though, since you'd basically have to generate all the information IMS generates with the help of the orbiter instance of the vessel by yourself.

 

[BruceJohnJennerLawso]

Just write a .msh and .cfg importer and plug it into an open 3d engine like for example irrlicht, and you have a universal solution. Point-and-click interface is a bit more work, but not very difficult to do in that environment. It could even be adapted to run in a seperate thread on runtime, Orbiter Galaxy style.

You can use this for creating just a docked vessel assembly and then load it into orbiter (also doable in runtime), or it would even be possible (since IMS is basically open source) to run the whole thing and load the finalised vessel into orbiter. This would be a lot of work, though, since you'd basically have to generate all the information IMS generates with the help of the orbiter instance of the vessel by yourself.

Two parts to that problem:

How hard is it to import msh into other graphics environments? (ie, what idiosyncrasies does the format have given that its Orbiter specific?)

Is Irrlicht the best option for a project like this? I know you are a fan of it based on using it for OrbiterGalaxy, but are there any other candidates that might be equal or better for the task?


To elaborate a bit more on what I said earlier, VirtualVAB is basically just a command line program that generates source code based on a users input. (say, like asking the program to add a thruster at given coordinates, of a given engine type, etc...), add a docking port at given coordinates, with or without an airlock, add a cockpit switch at given coordinates that controls some given parameter, etc. Mostly a development tool for those that already know how to code & have a compiler set up.

The jump to a real user-friendly vessel creator like Orbiter Shipyards would certainly be fairly large, but not too difficult provided I can actually spare the time. (which wont happen until summer 2014, as far as I can imagine). The somewhat bigger question would be direct compilation, which I might be able to query Artlav about, so that users get a ready to go DLL at the end, instead of source code to compile.

Its all a very long ways off though...

 

[jedidia]

How hard is it to import msh into other graphics environments? (ie, what idiosyncrasies does the format have given that its Orbiter specific?)

Nothing. Meshes are always the same, it's only a question of what the engine receiving them can handle. The mesh notiation is particular in that it is non-standard, orbiter only, but since it's text based a parser really isn't hard to write. As long as your chosen engine supports all of orbiters DX features you're good to go (and let's face it, any engine worth the name has the full set of D3D9 functionality nowadays).
Of course' if you want to be able to see the animations in the editor it's a bit more work...

Is Irrlicht the best option for a project like this? I know you are a fan of it based on using it for OrbiterGalaxy, but are there any other candidates that might be equal or better for the task?

I'm not a "fan" of irrlicht per se, I just simply didn't need anything else so far. That said, there are a few features that make it hard to beat for small-scale tasks like this:
Multi-platform,
Multi-interface (want to switch from directX to openGL? sure, change one flag, there you go)
Easy to include
Relatively easy to use
A solid GUI (and believe me, you waste tons of time on making a well-functional GUI architecture if it doesn't come with the package!)
Open Source (if you really need a feature it doesn't have, you can write it yourself)
No known problems with certain GPUs (unlike Microsofts abysmal XNA framework)
And, for this particular purpose, has proven itself to multithread with orbiter, with the only known issues being no fullscreen and a keyboard initialisation problem that needs you to press a key outside the window before the irrlicht window receives them, which could probably be solved with a bit more motivation.

To elaborate a bit more on what I said earlier, VirtualVAB is basically just a command line program that generates source code based on a users input. (say, like asking the program to add a thruster at given coordinates, of a given engine type, etc...)

Sure. Problem is, IMS doesn't work that way. You'll have to at least make a config parser to figure out where the modules fit together anyways.

I was majorly talking about a possible interface for IMS, really, so the points don't really have apply to virtualVAB.

 

[jedidia]

You know, the more I think about this the more I think it might actually be worth a shot...

I'll need a fairly powerful editor for IMS2 anyways, and being completely unmotivated to write one was kind of a hold-up. But this way it could actually proove a bit more interesting than just endless GUI definitions. I could also start fairly small, something like an "Orbiter docking stack wizzard", that would work for basically any orbiter vessels (as long as they have their docking ports defined in a cfg), so including the old IMS. Nothing fancy, just a GUI that allows you to put vessels together by click and drag, and then click a spawn button and the docked vessels are spawned in orbiter.

From there I could work my way into the IMS2 interface for an actual shipyard editor for IMS2... it all sounds pretty convienient, really.