Project Multistage2015 - Development Thread

[Michael_Chr]

Two things that I have noticed additionally working with MS2015(applies to 2010P1).
If you open the MS2015 MFD in a DX9 EXT MFD, selects any other mode than FST (the default I guess) then... As MFD window is resized it reverts back to FST mode as it updates (whereas it should retain the previously selected mode I think).
The other is a bit more complex but relates to the orbit call in the guidance file.
I have included the scn, ini and gnc file below for retesting and perhaps confirmation of observation. I have replaced my mesh and exhaust tex files with either the MS2015 default SLS or orbiter default files so it looks weird but is OK for testing this.
Using these files as setup starting the AP will initiate launch after 15 secs. What happens is that the Orbit AP will initially roll the vessel to one side for 90 deg. (MET 0:05 to MET 0:12 approx) after which it will reverse the roll going back through the original orientation for a 180 deg roll to the final Launch roll orientation. If you look at the HDG value the AP rolls to 90 deg HDG (which corresponds to a 29 deg incl at Cape C) but in a heads-up attitude after which it rolls through 180 deg to heads a heads-down (as I have specified upside down in the GNC file) but largely maintaining the HDG due to the fact that it pitches ever so slightly back over zenith.
In general the Orbit call is a bit twitchy in the beginning which however can be dealt with - but I just wanted to point your attention to this and since it is repeatable maybe it can be addressed. (I have actually used roll and pitch MS2015 AP commands on other designs and once stable values has been achieved then letting the orbit AP take over).
On a sidebar I can mention that I discovered if I - after launch - activate developer mode - have it reread the ini - and then reset the vehicle to same position and orientation as previously...the AP will actually roll the correct way from the beginning.
Zip file with a scen, ini and txt (GNC) is attached
Best regards
Michael

 

[Michael_Chr]

Hi again Fred
Another issue I have come across is mass update from additionally attached vessels. I’m working with a constellation type project in which a spacecraft has to perform EOR and dock with a final upper stage of a MS2015 vessel where after the MS2015 vessel shall perform a TLI burn. Since defining dockports with a MS vessel is not possible the “live payload” option it is a real nice addition in that you can attach (I’m using attachment manager for this) an already orbiting vessel to a MS2015 “live” payload and then hurl the entire stack away using the MS2015 vessel. All this is fine and already doable as it is. However the MS2015 doesn’t recognize that an additional vessel has been attached with respect to payload. Is it possible to have MS2015 register additional vessel attachment after launch? I’m guessing that this might be tricky if not impossible so I was reverting to a “workaround”. I would add an additional live payload (In this case a payload adapter but could also be a hidden mesh/ballast etc.) – however defined with fuel tank with a mass resembling the added mass of additional attached vessels. So when the attachment was done you could load up the fuelmass (using scenedit) thereby simulating the additional mass of a newly attached vehicle to a MS2015 payload stack. So…I did this but then I discovered that the mass of a payload in MS2015 is only updated on scenario entry and not dynamically in the scenario. Again this would in normal circumstances seem logical (Why would you refuel after liftoff??) but in this context (using the fuel added to have MS2015 “sense” the added mass of an additionally attached vehicle) it did not work so well. The workaround is to exit the scenario and then reenter allowing MS2015 to update the entire payload mass.
In conclusion:

• Is it possible to dynamically update the mass of the “live” payload stack of a MS2015 vessel in case of attachment updates…and/or
• Have MS2015 to dynamically update payload mass (in case a live payload id re/defueled).

I hope that you understand all this and I’m sorry for the long winded explanation but I felt I needed to explain the rationale behind this request in order for you to do the possible modifications to MS2015.
Best regards (and merry Xmas )
Michael

 

[Marg]

I am also thinking about all this... I just began to simulate Space Shuttle, and began to think how to attach payloads in payload bay. Currently shuttle itself is a payload and only after separation from ET it turns to STSxx.ini vehicle.
And all satellites inside are "spawning" at the same time as payloads of the STSxx vehicle itself. Actually not bad, but is there a better way? I haven't tried "live" payload yet...

I have tried it now. Right on the launch pad I can "take control" of live STS shuttle - open PB doors, also payloads (defined in its ini file) are in! Great!
I only think - is it possible to attach something to this LIVE shuttle? I took spotlight by BrianJ and pressing "V" entered " STS-27 0" - and spotlight attached to shuttle!
But it would be good to make it possible to attach via scenario file. Line "ATTACHED 0:0,STS-27" does not work, because officially there is no vessel STS-27 (in scenario)...

P.S It is the third edit to this message - I tried and it works pretty well. There is vessel in scenario, so it's OK. I just looked at "current state" after attaching spotlight.
Example was obvious. I attached satellite as well and it worked! Multistage continues to amaze me, so many things which I thought are not possible, actually are possible!

 

[fred18]

Hi guys,

first of all thank you for your interventions and sorry if I am not present as I was some months ago but I spent days and nights over MS2015 for months and in the last period real life has took the lead over my time! But even if I had to slow down, I am not stopping and I'll keep following up on your points!

Two things that I have noticed additionally working with MS2015(applies to 2010P1).
If you open the MS2015 MFD in a DX9 EXT MFD, selects any other mode than FST (the default I guess) then... As MFD window is resized it reverts back to FST mode as it updates (whereas it should retain the previously selected mode I think).
The other is a bit more complex but relates to the orbit call in the guidance file.
I have included the scn, ini and gnc file below for retesting and perhaps confirmation of observation. I have replaced my mesh and exhaust tex files with either the MS2015 default SLS or orbiter default files so it looks weird but is OK for testing this.
Using these files as setup starting the AP will initiate launch after 15 secs. What happens is that the Orbit AP will initially roll the vessel to one side for 90 deg. (MET 0:05 to MET 0:12 approx) after which it will reverse the roll going back through the original orientation for a 180 deg roll to the final Launch roll orientation. If you look at the HDG value the AP rolls to 90 deg HDG (which corresponds to a 29 deg incl at Cape C) but in a heads-up attitude after which it rolls through 180 deg to heads a heads-down (as I have specified upside down in the GNC file) but largely maintaining the HDG due to the fact that it pitches ever so slightly back over zenith.
In general the Orbit call is a bit twitchy in the beginning which however can be dealt with - but I just wanted to point your attention to this and since it is repeatable maybe it can be addressed. (I have actually used roll and pitch MS2015 AP commands on other designs and once stable values has been achieved then letting the orbit AP take over).
On a sidebar I can mention that I discovered if I - after launch - activate developer mode - have it reread the ini - and then reset the vehicle to same position and orientation as previously...the AP will actually roll the correct way from the beginning.
Zip file with a scen, ini and txt (GNC) is attached
Best regards
Michael

Ok then. Relevant to the first point there's not much I can do. It seems that window resizing will reset the MFD and I was not able to make the MFD status persistent without incurring in major issues with more than one vessel inside a scenario. So that's a compromise that for the time being we have to live with.
Relevant to the roll issue I know what do you mean and I will check if there is a way to avoid it but I remember to have checked something like that already and with small angles or small angular accelerations that kind of behaviour is difficult to avoid.

Hi again Fred
Another issue I have come across is mass update from additionally attached vessels. I’m working with a constellation type project in which a spacecraft has to perform EOR and dock with a final upper stage of a MS2015 vessel where after the MS2015 vessel shall perform a TLI burn. Since defining dockports with a MS vessel is not possible the “live payload” option it is a real nice addition in that you can attach (I’m using attachment manager for this) an already orbiting vessel to a MS2015 “live” payload and then hurl the entire stack away using the MS2015 vessel. All this is fine and already doable as it is. However the MS2015 doesn’t recognize that an additional vessel has been attached with respect to payload. Is it possible to have MS2015 register additional vessel attachment after launch? I’m guessing that this might be tricky if not impossible so I was reverting to a “workaround”. I would add an additional live payload (In this case a payload adapter but could also be a hidden mesh/ballast etc.) – however defined with fuel tank with a mass resembling the added mass of additional attached vessels. So when the attachment was done you could load up the fuelmass (using scenedit) thereby simulating the additional mass of a newly attached vehicle to a MS2015 payload stack. So…I did this but then I discovered that the mass of a payload in MS2015 is only updated on scenario entry and not dynamically in the scenario. Again this would in normal circumstances seem logical (Why would you refuel after liftoff??) but in this context (using the fuel added to have MS2015 “sense” the added mass of an additionally attached vehicle) it did not work so well. The workaround is to exit the scenario and then reenter allowing MS2015 to update the entire payload mass.
In conclusion:

• Is it possible to dynamically update the mass of the “live” payload stack of a MS2015 vessel in case of attachment updates…and/or
• Have MS2015 to dynamically update payload mass (in case a live payload id re/defueled).

I hope that you understand all this and I’m sorry for the long winded explanation but I felt I needed to explain the rationale behind this request in order for you to do the possible modifications to MS2015.
Best regards (and merry Xmas )
Michael

Ok, I lost you at some point but I think that I got your issue.
1) not at the moment. I'll check the code but I am very scared of touching something fundamental as payload weight which at the moment works fine. Point is: in orbiter attachments do not add any mass, so to update the mass dinamically it means to change the empty mass of the vehicle at each frame, which scares me quite a lot.
2) beyond what said above, I was thinking about a tricky workaround of a ghost payload with negative mass. I haven't tried it yet, but if positive mass is added, negative mass is substracted, what about playing with a payload sequence with ghost payloads with negative mass to obtain the refueling procedure correct? It's just an idea, I don't know if it might work!

I am also thinking about all this... I just began to simulate Space Shuttle, and began to think how to attach payloads in payload bay. Currently shuttle itself is a payload and only after separation from ET it turns to STSxx.ini vehicle.
And all satellites inside are "spawning" at the same time as payloads of the STSxx vehicle itself. Actually not bad, but is there a better way? I haven't tried "live" payload yet...

I have tried it now. Right on the launch pad I can "take control" of live STS shuttle - open PB doors, also payloads (defined in its ini file) are in! Great!
I only think - is it possible to attach something to this LIVE shuttle? I took spotlight by BrianJ and pressing "V" entered " STS-27 0" - and spotlight attached to shuttle!
But it would be good to make it possible to attach via scenario file. Line "ATTACHED 0:0,STS-27" does not work, because officially there is no vessel STS-27 (in scenario)...

P.S It is the third edit to this message - I tried and it works pretty well. There is vessel in scenario, so it's OK. I just looked at "current state" after attaching spotlight.
Example was obvious. I attached satellite as well and it worked! Multistage continues to amaze me, so many things which I thought are not possible, actually are possible!

thank you very much buddy! :tiphat:

PS: remember to read the manual guys, sometimes it's useful :thumbup: :

What if I have a live payload and I need
to add specific parameters for it in the
scenario file?
In this case simply load the scenario with the live
payload as it is. Once loaded close the simulation and
get the CurrentState.scn file. It will contain the
launcher and the payload attached to it, so you can
modify directly the payload sections a you wish,
rename the CurrentState.scn to whatever you please
and launch it again to enjoy the ride!

 

[Michael_Chr]

Hi Fred

2) beyond what said above, I was thinking about a tricky workaround of a ghost payload with negative mass. I haven't tried it yet, but if positive mass is added, negative mass is substracted, what about playing with a payload sequence with ghost payloads with negative mass to obtain the refueling procedure correct? It's just an idea, I don't know if it might work!

Did a quick test of this...and it works perfectly. Edited an MS2015 ini to amend a "dead" ghost payload (live=0) with a null mesh and some negative mass as the first payload in a payload stack. At scenario entry the negative payload mass is indeed subtracted from overall vehicle mass. After orbiti nsert I then jettisoned this ghost payload and it seems that when jettisoning a negative mass the overall mass of the payload increases. This is verified dynamically by:

• MS2015MFD - PLD display
• MS2015 HUD - "Total payload weight" statement
• Burntime MFD - (dV decreased after Ghost payload jettison)
• Scenedit - Vehicle propellant display

MS2015MFD - FST display "total payload mass" did not update at jettison. I had trouble reopening the scenario (Causes a CTD - I will investigate into that and report back).
So all in all the idea of having a ghost payload with a negative mass does the job and seen from my perspective I'm very happy with this solution (as opposed to recoding and thereby possibly introducing new errors etc - not to to mention the associated workload).

With regards to the other issues I brought up...
MFD resizing... Understand that multiple MS2015 vessels requires an MFD "refresh" at certain times. If that is the penalty of having MFD support multiple vessels is a small price to pay (if it can be considered a problem at all )
Roll issue... just wanted to point your attention to it. Its not a big issue...I deal with it using various combinations of Attitude, Roll and Pitch command which you can issue "on top" of a previously given orbit statement until I get the trajectory I want. I have a sensation that you had already thought about this since its possible to give a command and once this is executed the AP will revert to the original orbit command...Nice work
Update mass on additional in orbit attachment... Again... Not an issue at all and you already provided an exellent workaround.

The work effort that you have put into this is by all standards monumental. I can only guess at how many nights you have been coding and testing so please don't feel sorry for any perceived "lack of presence"...Its Xmas and you need your holiday as well as the rest of us. Sometimes when you have been hard at a project for so long time as you have some "fatigue" will set in. Then...Take a break from the project and perhaps get back later . It is only a hobby after all.
Best regards
Michael

Ps. would it be an idea to include some of these "finer points" in the manual? I would gladly offer to write it up so you can cut'n paste it in!

 

[thammond]

I am thinking of using Multistage 2015 for making my first addon and have some basic questions about it and want some feedback on basic planning before I start anything.

I am planning on making the historical Juno I/Explorer 1 rocket/satellite.

Since the 4th stage of the rocket is built integral with the Explorer 1 satellite, my thought would be that I would not have a payload section defined. Just 4 stages. Is there any potential issues with doing it that way that I have not thought about?

I'm a bit confused about the height and diameter parameters in the Stages section. Namely what are they for or what do they do, and are they tied into the mesh somehow? Do the meshes need to match size wise with these parameters?

The next question is about mesh offsets. I don't understand what the offset does or what its for. I have not yet made my first mesh and maybe once I do that will all make sense. But I am asking here so that I don't get end up with completed meshes and find out I have to redo them because I did not plan correctly ahead.

And the 3rd question is about Expbolts. Are they functional as in stages would not separate if the Expolts have not actuated. Or is that more of eye candy type of thing.

I guess that is it for now, I'm sure I will have some more questions as I go forward.

 

[K_Jameson]

I am planning on making the historical Juno I/Explorer 1 rocket/satellite.

It was already done:
[ame="http://www.orbithangar.com/searchid.php?ID=3235"]http://www.orbithangar.com/searchid.php?ID=3235[/ame]

 

[fred18]

I am thinking of using Multistage 2015 for making my first addon and have some basic questions about it and want some feedback on basic planning before I start anything.

sure! I'll try to be quick and effective!

Since the 4th stage of the rocket is built integral with the Explorer 1 satellite, my thought would be that I would not have a payload section defined. Just 4 stages. Is there any potential issues with doing it that way that I have not thought about?

Payload section is a mandatory one, which means that if there is no payloads the module won't work. But there is always a workaround: in case you want no payloads, put a ghost payload there like an empty mesh with 0 kg of weight

I'm a bit confused about the height and diameter parameters in the Stages section. Namely what are they for or what do they do, and are they tied into the mesh somehow? Do the meshes need to match size wise with these parameters?

those parameters are used for just 2 things:
- inertia tensor : it defines how the rocket "resist" to rotation input
- cross sections: they define the rocket atmospheric drag

there is no link at all with the meshes, that's why user has to put it directly. If you are designing your rocket just put the correct values and you will obtain a simulation that could be as realistic as possible during the atmospheric phase of the flight.

The next question is about mesh offsets. I don't understand what the offset does or what its for. I have not yet made my first mesh and maybe once I do that will all make sense. But I am asking here so that I don't get end up with completed meshes and find out I have to redo them because I did not plan correctly ahead.

I think that you'll learn it immediatly when you'll start to develop but to let you jump on the learning curve I'll try to say it as clear as I can here:
simply each stage will have its own mesh and you have to tell to the module where to put each stage in the rocket. Think that you have the rocket set of coordinates which starts at 0,0,0 which will be its center of gravity. Where do I want to put the mesh of the first stage? 5 meters below the COG, then its offset will be (0,0,-5). And the second? 6 meters above the COG and its offsets will be (0,0,6). Then of course you will have to set the numbers so the stages "touch" themselves and match perfectly at the conjuction point. It's very useful to pick meshes coordinates from 3d drawing, there is a tutorial on this in the multistage2 tutorial on OH.

And the 3rd question is about Expbolts. Are they functional as in stages would not separate if the Expolts have not actuated. Or is that more of eye candy type of thing.

Just and only Eye-Candy

I guess that is it for now, I'm sure I will have some more questions as I go forward.

Hope that helped, ask questions as much as you want, I'm here :thumbup:

Good luck!

 

[thammond]

K Jameson: Thanks for the info. I have tried that one and for some reason the autopilot spins the rocket in one big loop before the autopilot settles down. I then tried to fly it manually, but couldn't get it to jettison the 1st stage.

I found another version of it made for 2005 Orbiter. The autopilot works on that one, but the ending orbit is significantly lower than the historical one.

Fred18: That is very helpful info. So if I understand your offset examples correctly, the parameter for the MISC section would be COG=5 (assuming launching from the ground) and the length of the 1st stage would be 11 m?

The payload mesh would still need to "attach" offset to the tip (nose) of the 4th stage then, but could be any convenient size shape for the mesh just define it to have 0.0 size and mass?

 

[fred18]

So if I understand your offset examples correctly, the parameter for the MISC section would be COG=5 (assuming launching from the ground) and the length of the 1st stage would be 11 m?

Actually not exactly: in my example I put the mesh of the first stage 5 meters below the COG of the whole rocket, so it means that I put the center of the mesh (the origin of the coordinates in the mesh file) 5 meters below the center of the coordinates of the whole rocket. I don't know how big the mesh is and where would be its contact with ground.
Now you have to think this as a pure graphic point, meshes are basically eyecandies in orbiter, so nothing related to actual physical behaviour. And everything is relative here: it depends on where in relation to the center of the graphics in the graphic program you saved your meshes. If you create for example a whole rocket and save all meshes at their places (so shifted from the origin) then the offsets will be all 0, but you will have the center of gravity of the rocket that will not change during flight and you will experience some strange effects (like rotating around a point outside of the aircraft). IIRC the Jaxa rocket from donamy was done like this if you want to try it to see what I mean. I think a graphical example would help but I cannot draw now. I'll see if i can come up with a drawing explaining this.

The payload mesh would still need to "attach" offset to the tip (nose) of the 4th stage then, but could be any convenient size shape for the mesh just define it to have 0.0 size and mass?

as said above mesh is just an eyecandy, so you can have a mesh big as a planet with 0 size and mass, they are not related. The ideal is a complete empty mesh, like a line, or a sigle point, or a microscopic shape. I use the following sometimes, but it can be a lot simplified, i'm just lazy to create another since this one is already invisible. And it's not necessary to put it on the nose, since it will be not visible, just put it at 0,0,0

MSHX1
GROUPS 1
MATERIAL 1
TEXTURE 0
GEOM 24 8	; mesh83 material23 0
0.000000 0.000000 -0.010000 0.577350 -0.577350 -0.577350
0.000000 0.000000 0.010000 0.577350 -0.577350 0.577350
0.000000 0.000000 -0.010000 -0.577350 -0.577350 -0.577350
0.000000 0.000000 -0.010000 -0.577350 0.577350 -0.577350
0.000000 0.000000 -0.010000 0.577350 0.577350 -0.577350
0.000000 0.000000 0.010000 -0.577350 -0.577350 0.577350
0.000000 0.000000 0.010000 -0.577350 0.577350 0.577350
0.000000 0.000000 0.010000 0.577350 0.577350 0.577350
0.010000 0.000000 0.000000 0.577350 -0.577350 -0.577350
0.000000 -0.010000 0.000000 0.577350 -0.577350 -0.577350
0.000000 -0.010000 0.000000 -0.577350 -0.577350 -0.577350
-0.010000 0.000000 0.000000 -0.577350 -0.577350 -0.577350
-0.010000 0.000000 0.000000 -0.577350 0.577350 -0.577350
0.000000 0.010000 0.000000 -0.577350 0.577350 -0.577350
0.000000 0.010000 0.000000 0.577350 0.577350 -0.577350
0.010000 0.000000 0.000000 0.577350 0.577350 -0.577350
0.010000 0.000000 0.000000 0.577350 -0.577350 0.577350
0.000000 -0.010000 0.000000 0.577350 -0.577350 0.577350
0.000000 -0.010000 0.000000 -0.577350 -0.577350 0.577350
-0.010000 0.000000 0.000000 -0.577350 -0.577350 0.577350
-0.010000 0.000000 0.000000 -0.577350 0.577350 0.577350
0.000000 0.010000 0.000000 -0.577350 0.577350 0.577350
0.000000 0.010000 0.000000 0.577350 0.577350 0.577350
0.010000 0.000000 0.000000 0.577350 0.577350 0.577350
8 9 0
10 11 2
12 13 3
14 15 4
16 1 17
18 5 19
20 6 21
22 7 23
MATERIALS 1
material23
MATERIAL material23
0.878 0.878 0.878 0.000
0.878 0.878 0.878 0.000
1.000 1.000 1.000 0.000
0 0 0 1
TEXTURES 1
0

 

[Marg]

After some multistage experiments (in Orbiter BETA), I would like only have 2 aspects\features to be implemented in the future - pad deflection smoke definitions and (less important) - to switch texture of External Tank\stage1 (I am concentrated to Space Shuttle again) to show charred effects after SRB separation.

 

[fred18]

After some multistage experiments (in Orbiter BETA), I would like only have 2 aspects\features to be implemented in the future - pad deflection smoke definitions and (less important) - to switch texture of External Tank\stage1 (I am concentrated to Space Shuttle again) to show charred effects after SRB separation.

Relevant to the pad, for the future in my mind there is something like a "pad.dll" module to deliver in a multistage way, but it was too hard work for this release. I'll mark it for the future. I think that you can play a bit with the vent effects for this anyway, am I right?

For the texture change I gave it a thought already, it seemed to me a bit too complicated to do (something like implementing 10 lines of .ini file for just one effect), but I'll review this.

In the meantime this week I'll start again to work on this to complete everything is pending and have a stable and long lasting release. I talked with Vinka and he shared with me the code of the original multistage, asking for some implementations he would like to have. He said that for now he won't keep on developing MS since this one is ok! So I want to have a stable and long lasting release for this.

you'll hear from me soon

 

[boogabooga]

Please don't forget the translational thrusters.

 

[fred18]

Please don't forget the translational thrusters.

they are there already, aren't they? maybe there are just the z axis and not all of them, is it?

 

[boogabooga]

Which patch added them? I'm not using the GUI developer mode version but one before.

 

[fred18]

Which patch added them? I'm not using the GUI developer mode version but one before.

I think that your patch already have the z axis (the other axis are not implemented at all). Try to put "linearthrust = XXX" in the stage section, it should work.

I was tired when I published everything and I missed something here and there sorry, there was too much work at that time. Now that the dust has settled a bit I can finish all the points and update the documentation with everything that is missing.

 

[boogabooga]

You are right, and it is all three axis, not just Z!

This is really important, because Attitude MFD and Pursuit MFD seem to need translational thrusters defined in order to work properly.

Even a small linearthrust value (1000 N) vastly improves the attitude control capability.

Perhaps you just need to update the documentation so that this does not get lost as an Easter egg.

 

[Marg]

"I think that you can play a bit with the vent effects for this anyway, am I right?" - I really played a bit and they work really well (I easily set direction etc.) , but problem that there is not start time for them, only finishing time. (time_fin_n)... if something like "time_start_n" could be introduced...

 

[fred18]

"I think that you can play a bit with the vent effects for this anyway, am I right?" - I really played a bit and they work really well (I easily set direction etc.) , but problem that there is not start time for them, only finishing time. (time_fin_n)... if something like "time_start_n" could be introduced...

Right! Good point! I'll see if it is possible to add it as an optional parameter.

Another way could be to have ghost boosters (not ghost busters )

 

[Michael_Chr]

"I think that you can play a bit with the vent effects for this anyway, am I right?" - I really played a bit and they work really well (I easily set direction etc.) , but problem that there is not start time for them, only finishing time. (time_fin_n)... if something like "time_start_n" could be introduced...

Try and have a look at the venerable Quasar and perhaps even Jarvis addons from FOI. I know that the Quasar launchpads (there are two) has some nifty effects and maybe also Jarvis (I havent used this one that much).

And good news about Multistage from Vinka with relation to having the MS2015 as the new baseline for multistage. It would be a shame if these two (MS "classic" and MS2015 forked away from each other - So congrats Fred...Your'e IT (when it comes to MS in the future) :tiphat: :thumbup: