Project Multistage2015 - Development Thread

[fred18]

?? Hi!
What do you mean? this doesnt work. i just did a complete orbiter reinstall 2 weeks ago.
basically nothing apart from ravenstar works from the popular addons in O2016.

i mean the inculded 3 test scenarios work, but nohing else, it constantly appchrashes when i try to run any addon that is dependent on it for example MS2015 titans or Soyuz...

rockets blow up, or disappear in mid air, and stages appear in weird configurations, etc...

what do you use that works with this?
thx. :tiphat:

Can we have more details on that? the version of the linked is made expressly for the official release of Orbiter2016 (Note: not the Beta, the official one). Nobody ever complained about it, so your must be a particular case. Can you take me a specific example with log file and everything so I can investigate and try to be of assistance?

 

[4throck]

"i mean the inculded 3 test scenarios work"

Your problem might be with Orbiter itself.
Orbiter must work 100% before you can add any addons.

Tell us exactly what scenarios work or not.

 

[fred18]

I have a question for the forum... I had a small exchange with Uwrumpe some days ago about the architecture of Multistage and I gave it some thougths, but I have a doubt and I was wondering what you guys think about it:

let's say that I move on and switch the architecture of Multistage from the unique vessel which spawns the used stages to a new concept made of separate vessels attached one to the other (I said attached, because docked is possible but I found the docking available commands too general to manage such a complicated situation like Multistage module is).

It will mean then that the core vessel should be the last stage of my multistage rocket, which is intuitive, since I would need it to manage everything that goes on before.

So I thought of an architecture where the last stage is the core stage, and it creates all the other stages, it attaches them to it and among themselves, and creates the rocket. that's easy.

Now when I want to use it I would focus on the last/core stage and "drive" the rocket from there, right? BUT if I do it this way and I don't let the rocket drive itself automatically, when I will press the + button the engines of the core stage will fire instead of the ones of the first stage. Same story for the attitude control and everything.

There could be a way of intercepting all the important keys and send the commands to the appropriate stage, but that would be very heavy to build and would exclude for example the usage of joystics and other similar devices.

What do you guys think about this kind of topic? how do you see it? hearing the point of views of many users of the addon may enlight me on some solution about this.

Thanks guys, and cheers

Fred

EDIT: I just realized that since there could only be attachments, the only way to make the rocket actually fly is if the core stage itself is the thruster... so the issue above is solved automatically. The biggest issue that I see is that I don't know if the juice is worth the squeeze to make such a complex new architecture like this if in the end the change is almost only cosmetic

 

[IronRain]

I have a question for the forum... I had a small exchange with Uwrumpe some days ago about the architecture of Multistage and I gave it some thougths, but I have a doubt and I was wondering what you guys think about it:

let's say that I move on and switch the architecture of Multistage from the unique vessel which spawns the used stages to a new concept made of separate vessels attached one to the other (I said attached, because docked is possible but I found the docking available commands too general to manage such a complicated situation like Multistage module is).

It will mean then that the core vessel should be the last stage of my multistage rocket, which is intuitive, since I would need it to manage everything that goes on before.

So I thought of an architecture where the last stage is the core stage, and it creates all the other stages, it attaches them to it and among themselves, and creates the rocket. that's easy.

Now when I want to use it I would focus on the last/core stage and "drive" the rocket from there, right? BUT if I do it this way and I don't let the rocket drive itself automatically, when I will press the + button the engines of the core stage will fire instead of the ones of the first stage. Same story for the attitude control and everything.

There could be a way of intercepting all the important keys and send the commands to the appropriate stage, but that would be very heavy to build and would exclude for example the usage of joystics and other similar devices.

What do you guys think about this kind of topic? how do you see it? hearing the point of views of many users of the addon may enlight me on some solution about this.

Thanks guys, and cheers

Fred

EDIT: I just realized that since there could only be attachments, the only way to make the rocket actually fly is if the core stage itself is the thruster... so the issue above is solved automatically. The biggest issue that I see is that I don't know if the juice is worth the squeeze to make such a complex new architecture like this if in the end the change is almost only cosmetic

I'm not entirely sure I'm useful in this discussion, mostly because I lack Orbiter development (C++, to be more specific) knowledge.

However, I'd like to say that I think the developer tool in MS2015 is one of the most useful things in Orbiter. It made creating missions so much easier and faster. It gives me a bit a KSP feeling (I'm not a KSP guy, but this is a good thing).

Personally, I think that calling it something like "developer tool" (I'm not sure what it's exactly called anymore :facepalm really undermines it's functions, since it's essentially a rocket builder. Since this is about the future I just want to raise this as something that might be taken into consideration as well.

The biggest issue that I see is that I don't know if the juice is worth the squeeze to make such a complex new architecture like this if in the end the change is almost only cosmetic

Cosmetic changes are not bad, it's a matter how much time you'd like to spend on it
In other projects, I've experienced that these kind of changes might be really useful later on.

Just my :2cents:

 

[4throck]

"The last stage is the core stage, and it creates all the other stages, it attaches them to it and among themselves, and creates the rocket. "
Good in theory, not in practice.

You can't take an existing vessel (lets say DG) and make it your core vessel, unless you recode it!

I think that a better payload / rocket interaction could be achieved by introducing a "control stage" (logical only, no mesh).
The placement of the stage on the stack could be used to indicate where the rocket ends, and the payload vessel starts.
That stage would be configured to intercept/sends vessel commands (like J for jetisson...), automatically select vessels, etc.
I think such a system could handle most situations.


Practical example:

» Your vessel caries a satellite to deploy at 150km.
» The vessel has key commands for opening the cargo doors (ALT+D) and then releasing the satellite (ALT+J).
» You attach your vessel as live paypload to the multistage rocket.
» Multistage launch with a desired 300km x 300km orbit. So you need to release the satellites while the autopilot is running.
» Multistage "control stage" sends the intended key presses to the payload vessel at the right altitudes.


A simple syntax could be:

[ControlStage]
Logic = AtAltitude (150000, "ALT+D", "TargetVessel")
Logic = AtAltitude (151000, "ALT+J", "TargetVessel")

(TargetVessel could be omitted, defaulting to whatever is defined on the stack after the "control stage")

 

[fred18]

However, I'd like to say that I think the developer tool in MS2015 is one of the most useful things in Orbiter. It made creating missions so much easier and faster. It gives me a bit a KSP feeling (I'm not a KSP guy, but this is a good thing).

Personally, I think that calling it something like "developer tool" (I'm not sure what it's exactly called anymore :facepalm really undermines it's functions, since it's essentially a rocket builder. Since this is about the future I just want to raise this as something that might be taken into consideration as well.

That is a very interesting feedback: the Developer tool is something that was really "costly" in terms of time necessary to make it and is also a bit of a stopper some time because it is strongly tied in the code of MS and if I want to change something in the code I don't want to face issues in the tool... So my idea is to make this tool separate, so you have the rocket module which goes one way and the developer plugin which goes in parallel but with its own code.

Relevant to KSP, the tool started because I thought about doing something like this: having a Database of stages which you load from the tool and you assembly on the rocket. I never played KSP but I know it works more or less like this. I will keep a thought on that.

Cosmetic changes are not bad, it's a matter how much time you'd like to spend on it
In other projects, I've experienced that these kind of changes might be really useful later on.

That's very true: in order to change something "cosmetic" then you find yourself on the path of some serious overall improvement.

Thanks!!

I think that a better payload / rocket interaction could be achieved by introducing a "control stage" (logical only, no mesh).
The placement of the stage on the stack could be used to indicate where the rocket ends, and the payload vessel starts.
That stage would be configured to intercept/sends vessel commands (like J for jetisson...), automatically select vessels, etc.
I think such a system could handle most situations.

That could be a way too, by extend it could even be a plugin and not a vessel which controls everything... Another thing to think about! :tiphat:

 

[boogabooga]

I'm not sure that I follow your plan, but I wan to add one point regarding multiple attached vessel stacks: JUst make sure that the vessel that ends up in orit is the one that starts outon the pad.

IIRC, in old Velcro rockets, you launched from the bottom stage focus and ended up in the upper stage focus. This made it difficult for intrplanetary missions because it reset all the MFDs, and you had replan your IMFDs, etc.

 

[Donamy]

We need another remote vessel control that accepts key inputs, works with SC3 and works in Orbiter 2016.

 

[fred18]

I'm not sure that I follow your plan, but I wan to add one point regarding multiple attached vessel stacks: JUst make sure that the vessel that ends up in orit is the one that starts outon the pad.

IIRC, in old Velcro rockets, you launched from the bottom stage focus and ended up in the upper stage focus. This made it difficult for intrplanetary missions because it reset all the MFDs, and you had replan your IMFDs, etc.

That's another important point, that will stand for having the last stage as the core stage that drives all the package.

 

[4throck]

A "vesselcontrol.dll" would be nice and could be used standalone (without multistage) if needed.

It could run on top of existing vessels and add the landing point equation for instant 2016 compatibility.
That alone would make the effort worth your time.... :tiphat:

The basic functionality would be:
- define a set of vessel parameters for launch, another set after jettison;
- support 2016 only parameters to make older payload vessels compatible;
- intercept or send key presses;
- handle vessel focus, attachment or docking during / after jettison
- work standalone from multistage, adding functionality to existing vessels

 

[fred18]

A "vesselcontrol.dll" would be nice and could be used standalone (without multistage) if needed.

It could run on top of existing vessels and add the landing point equation for instant 2016 compatibility.
That alone would make the effort worth your time.... :tiphat:

The basic functionality would be:
- define a set of vessel parameters for launch, another set after jettison;
- support 2016 only parameters to make older payload vessels compatible;
- intercept or send key presses;
- handle vessel focus, attachment or docking during / after jettison
- work standalone from multistage, adding functionality to existing vessels

I think that could be interesting but it would be beyond the scope of what I am looking for here.

Recapping: the point is the actual multistage structure (the unique vessel which spawns the various stages) works fine, BUT I always had the doubt if it would be nicer to have a more realistic multistage structure with each stage a single vessel that it just separates on the flight.

Recently in a discussion Urwumpe (which is a very knowledgeable user here) pointed out the same and stated that it would be much nicer to basically be able to choose payloads and maybe stages architecture on the go (if I got it right).

While this is theoretically almost possible with the current Developer Mode Dialog of MS2015, it tickled my fantasy again of making the multistage module flying an actually multistage vessel, composed by various vessels, as said before.

Now the process I am in the middle of is:

• physics in Orbirer is currently properly computed with docking and it is not with attachments.
• to do it properly docking should be used (now that it is possible in Orbiter 2016).
• the docking APIs provided with orbitersdk are poorer comparing to the attachment APIs. I could elaborate this a bit more and try to recreate the same commands of attachments, but it is not immediate since docking is thought for something different.
• using docking will probably mean to generate wrong atmospherical drag foces, due to the fact that the orbiter core would probably not consider that the stages are one on the tail of the other
• therefore maybe attachments are better. They are also much more versatile. But then there will be the need of updating the whole set of physics of the rocket at each staging event, exactly like the current system.
• so in the end I keep the doubt if it's worth the effort...
• the only proper way I see to do it IMHO is to just use the last stage as core. An independent plugin can be used for general management, maybe to make it usable more like KSP (even though I never played KSP).
• the developer mode dialog shall be untied from the multistage code and walk with its own code (but that is another story).

And that's it, there I am with my doubts about this...

 

[DaveS]

the only proper way I see to do it IMHO is to just use the last stage as core.

This is how it's done on real LVs, the actual flight computer(s) are located on the last common stage. For Delta IV, this is the DCSS and for Atlas V, it's on the Centaur. The lower stages only react to commands sent from the upper stage.


The Saturn V/1B flight computer, called the Launch Vehicle Digital Computer (LVDC), was located inside the Instrument Unit (IU) ring that sat on top of the S-IVB stage. This was true even for the Saturn V that launched Skylab as Skylab was just a modified S-IVB stage.

 

[4throck]

On multistage the user defines each stage parameters, including the position of the meshes.
With vessels, the parameters will already be there, they come from the vessel's .dll
If you use docking, vessels limit you to the existing docking ports.

So you'll need to overwrite all of that to make it work for the end user.
And then you will end up with my broader scope suggestion :thumbup:
What you are thinking is MultiVessel, not Multistage :hmm:

 

[martins]

... (I said attached, because docked is possible but I found the docking available commands too general to manage such a complicated situation like Multistage module is).

Could you expand a bit on what you mean by "too general"? If there are specific interface functions missing in the API you would need to implement your module, I'd be happy to consider adding them. In general, I'd like to encourage using the docking, rather than attachment mechanim, since it takes into account the modified physics of the assembly (mass, PMI, angular moments, merged touchdown hulls, etc.) Attachments don't do any of this, so the addon developer would have to implement those things manually. Attachments were really only meant for sticking small bits onto the main vessel that wouldn't change the vessel behaviour significantly.

 

[Urwumpe]

Recently in a discussion Urwumpe (which is a very knowledgeable user here) pointed out the same and stated that it would be much nicer to basically be able to choose payloads and maybe stages architecture on the go (if I got it right).

Nonono... just payload (and maybe upper stage) would be enough. Do you remember Kulchs Payload Manager SDK? Something like that would be sweet. :thumbup:

http://www.kulch.spb.ru/Eng/PM_project.html

Sadly, it is a bit outdated now.

---------- Post added at 16:22 ---------- Previous post was at 16:21 ----------

This is how it's done on real LVs, the actual flight computer(s) are located on the last common stage. For Delta IV, this is the DCSS and for Atlas V, it's on the Centaur. The lower stages only react to commands sent from the upper stage.

Not always, you can also have hybrid solutions there - for example a launch vehicle guidance for the first two stages and a guidance for upper stage and payload by the payload guidance computer.

 

[fred18]

Could you expand a bit on what you mean by "too general"? If there are specific interface functions missing in the API you would need to implement your module, I'd be happy to consider adding them. In general, I'd like to encourage using the docking, rather than attachment mechanim, since it takes into account the modified physics of the assembly (mass, PMI, angular moments, merged touchdown hulls, etc.) Attachments don't do any of this, so the addon developer would have to implement those things manually. Attachments were really only meant for sticking small bits onto the main vessel that wouldn't change the vessel behaviour significantly.

Sure, the main issue is that the AttachChild/DetachChild commands of the Vessel class uses the attachmenthandles to attach the vessels, while the Dock/UnDock command of the vessel class uses docking port numbers instead.
And there is no API to go from Handle to Port number (only the other way around). Considering that everytime there is a deletion of a docking port all the numbers after it make a step back, when there are a lot of docking ports it soon becomes quite a mess to keep trace of the correct port to use.
Even if I don't delete the docking ports and just undock the stages, I can pick the correct port only if I have kept a very linear trace of docking creations.

Now, it just came to my mind that a possible solution could be to make a small function which recursively checks through all the ports available if the dockhandle that I am looking for is equal to the dockhandle of any of the ports and in that case returns the port number and then basically create some MyOapiDockFunction and MyOapiUnDockFunciton which use that system.

pseudocode:

int MyVessel::GetDockingPort(DOCKHANDLE hDock){
 for(UINT i=0;i<DockCount();i++){
    if(GetDockHandle(i)==hDock) return i;
 }
return -1;
}

int MyVessel::OtherVesselGetDockingPort(OBJHANDLE h_OtherVessel, DOCKHANDLE hDock){
VESSEL *otherVessel;
otherVessel=oapiGetVesselInterface(h_OtherVessel);
  for(UINT i=0; i<otherVessel->DockCount();i++){
    if(otherVessel->GetDockHandle(i)==hDock) return i;
  }
return -1;
}


int VESSEL::MyOapiDock(OBJHANDLE target, DOCKHANDLE myDock, DOCKHANDLE tgtDock, UINT mode){
return  Dock(target,GetDockingPort(myDock),otherVesselGetDockingPort(target,tgtDock,mode);
}

plus all the safety checks to be included.

The other difference is that moving an attachment point is easy and works, while moving docking port is difficult. So if I want to "move" stages or payloads to fine tune the setup of my rocket I can't do it.

---------- Post added at 17:45 ---------- Previous post was at 16:40 ----------

Nonono... just payload (and maybe upper stage) would be enough. Do you remember Kulchs Payload Manager SDK? Something like that would be sweet. :thumbup:

http://www.kulch.spb.ru/Eng/PM_project.html

Sadly, it is a bit outdated now.

That is already basically possible. not super quickly as it was with Kulch's addon, but neither this far.

And payloads can be live as well, so not spawned. Relevant to live payload it is possible to make the shuttle by placing the orbiter as payload, making the rest as multistage jump in the VC of the orbiter and command the sequence from there. Same for capsules above any other rocket of course.

 

[Urwumpe]

So in theory - spawning a MS2015 vessel during runtime is possible?

 

[fred18]

So in theory - spawning a MS2015 vessel during runtime is possible?

I never tried from 0 with the scenario editor actually... but if you start your scenario with just a monostage basic vessel with just the most basic definitions needed then you can change everything, add stages, boosters, payloads, place them in correct place, test the rocket and then reset it to the ramp,... you can also edit the ini file and then reload the rocket during runtime (which gives the idea that you can do anything you want).

For making it spawnable from 0 with the scenario editor it would be just a matter of creating a series of initialization definitions for vessels loaded without any ini file

 

[Linguofreak]

Sure, the main issue is that the AttachChild/DetachChild commands of the Vessel class uses the attachmenthandles to attach the vessels, while the Dock/UnDock command of the vessel class uses docking port numbers instead.
And there is no API to go from Handle to Port number (only the other way around). Considering that everytime there is a deletion of a docking port all the numbers after it make a step back, when there are a lot of docking ports it soon becomes quite a mess to keep trace of the correct port to use.
Even if I don't delete the docking ports and just undock the stages, I can pick the correct port only if I have kept a very linear trace of docking creations.

Maybe a "stage attachment" type of connection is needed, which behaves exactly like a docking port, but has its own port numbers and deletes automatically if not attached to something (either at scenario start, as with a core with optional boosters that aren't attached, or if detached in flight, as with a staging sequence)?

 

[Urwumpe]

For making it spawnable from 0 with the scenario editor it would be just a matter of creating a series of initialization definitions for vessels loaded without any ini file

Yes, about that. Practically, I just want to be able to build a space station and spawn a rocket to launch the modules. Of course, an assembly building would look better, but its not needed for the "game".