Project Multistage2015 - Development Thread

[Interceptor]

NO rotation of payload,no translation speed,and I didn't jettison payload in atmosphere,infact the same scenario works perfectly if I didn't add the live payload option.I am using the scenario I showed in an earlier post,and when the Resolve shuttle jettisons it's ET thats when the problem occurs the ET tank just un attaches,and floats through the Resolve shuttle.Thanks

 

[Urwumpe]

-rename multistage2.dll to multistage2backup.dll
-create a copy of Multistage2015.dll
-rename the copy to multistage2.dll

Can't you just edit multistage2.cfg to refer to Multistage2015 as module?

 

[fred18]

Can't you just edit multistage2.cfg to refer to Multistage2015 as module?

That was my original idea but doesn't work: many addon developers have created their own cfg files, also for multistage2 vessels. Sometimes they added attachment points, some times they just created the cfg file referring to the multistage2 module (I have no idea of why, but I found a lot of them) so the only way to get all of them is to rename the dll file.

---------- Post added at 12:31 ---------- Previous post was at 12:24 ----------

NO rotation of payload,no translation speed,and I didn't jettison payload in atmosphere,infact the same scenario works perfectly if I didn't add the live payload option.I am using the scenario I showed in an earlier post,and when the Resolve shuttle jettisons it's ET thats when the problem occurs the ET tank just un attaches,and floats through the Resolve shuttle.Thanks

All right, thanks! :tiphat:

This is an issue that I found that can happen to side mounted payloads.

if you put the translation speed (item "speed=(xx,yy,zz)") with all the speeds to 0, when you jettison the payload it will remain there and you will be able to move away with the RCS of the payload.

This happens because live payloads are attached to the vehicle through attachment. The Detach function allows only to specify the value of the speed of detachment but the direction can be only the attachment direction.

So I am thinking to manually set the status of the detached payloads adding the proper separation speed and rotation speed. The issue is also that I'm not finding in the orbiter api a function like "setVesselStatus" or something, I'll have a deeper look.

---------- Post added at 13:36 ---------- Previous post was at 12:31 ----------

All right I found it and found the way! (clbkSetStatus is my friend..)

you really pushed me a bit to the limit of this because I thought that small thing of detaching was not a big deal, but luckily I got the idea on how to solve it, and now should work exactly as normal separation does! :thumbup: let me know

Same link to update, give it a check.

I post it down here anyway just for ease of download.

 

[Interceptor]

OK other than that I am really enjoying your Multistage2015,thanks again.

---------- Post added at 07:08 AM ---------- Previous post was at 06:37 AM ----------

That was my original idea but doesn't work: many addon developers have created their own cfg files, also for multistage2 vessels. Sometimes they added attachment points, some times they just created the cfg file referring to the multistage2 module (I have no idea of why, but I found a lot of them) so the only way to get all of them is to rename the dll file.

---------- Post added at 12:31 ---------- Previous post was at 12:24 ----------



All right, thanks! :tiphat:

This is an issue that I found that can happen to side mounted payloads.

if you put the translation speed (item "speed=(xx,yy,zz)") with all the speeds to 0, when you jettison the payload it will remain there and you will be able to move away with the RCS of the payload.

This happens because live payloads are attached to the vehicle through attachment. The Detach function allows only to specify the value of the speed of detachment but the direction can be only the attachment direction.

So I am thinking to manually set the status of the detached payloads adding the proper separation speed and rotation speed. The issue is also that I'm not finding in the orbiter api a function like "setVesselStatus" or something, I'll have a deeper look.

---------- Post added at 13:36 ---------- Previous post was at 12:31 ----------

All right I found it and found the way! (clbkSetStatus is my friend..)

you really pushed me a bit to the limit of this because I thought that small thing of detaching was not a big deal, but luckily I got the idea on how to solve it, and now should work exactly as normal separation does! :thumbup: let me know

Same link to update, give it a check.

I post it down here anyway just for ease of download.

Great news Fred18,the ET seperated downward perfectly,may I ask one small request,and I will get off your back? can you somehow get the Camera shake addon to work in a Live payload VC,it just adds so much more emersion,but for some reason it won't with multistage2015,but if you can't don't worry about it.Thanks:thumbup:OH one more thing is it possible to add more than one Mach effect?I would like to put several around the boosters.

 

[fred18]

OH one more thing is it possible to add more than one Mach effect?I would like to put several around the boosters.

You're right here, didn't think about it. I'll add the feature.

Relevant to CamShake I never used it. I'll see how it works and let you know :thumbup:

---------- Post added at 17:25 ---------- Previous post was at 14:20 ----------

Ok interceptor, link updated.

You may now implement up to 10 mach effects, see documentation to understand how.

Relevant to CamShake I think I can't do anything to make it work actually.

I hope to have fulfilled all your requests

The only further modification that I'm thinking about is to move the button that toggle the autopilot from the GNC screen to the Control Screen and to implement the opportunity to load guidance file directly from the MFD, like the Telemetry.

Actually the AP button is more useful in the GNC screen because you input commands and you can execute them immediatly. I don't know, I'll think about it and I'll write the full documentation during the next days.

 

[Interceptor]

Ok Fred18,I appreciate it that you looked into camshake for me,and thanks for the extra Mach effects.:thumbup:

 

[boogabooga]

Public service announcement:

It pays to play with the GravTurnPitch parameter. In the default SLS test scenario, try a value of 85.5. This value produces a noticeably more efficient trajectory.

Edit:
Bug report-

The engines restart themselves even if autopilot is OFF a few seconds after a scenario is restarted with the stage already in orbit.

 

[fred18]

Thanks! I'm happy to hear this, it means that you're getting familiar with the module

Can I ask you which absides and inclination you're pointing? The optimal grav turn pitch parameters changes in function of the absides. The calculated one is fixed anyway and can be used as reference.

Relevant to engine restart at the moment is part of the full rocket flying process, not linked to the autopilot, but i think you're right! I'll link the auto engine ignition to the autopilot. Can't remember how vinka ms2 used to work, but i'll simply link this to the autopilot and it should work fine!

 

[boogabooga]

The grav turn pitch parameter was the only thing I changed, so still 180 x 220 or whatever it was.

 

[4throck]

Just to say that I'm testing it with Little Joe and it's running smoothly.
The launch angle is really welcome I have the NASA report with all the data from the flights so I'll try to see if it matches with our Orbiter simulations.

On Orbiter Beta the launch angle gives strange results and you start underground. I guess that the touchdown points are different. :hmm:

 

[fred18]

Just to say that I'm testing it with Little Joe and it's running smoothly.
The launch angle is really welcome I have the NASA report with all the data from the flights so I'll try to see if it matches with our Orbiter simulations.

On Orbiter Beta the launch angle gives strange results and you start underground. I guess that the touchdown points are different. :hmm:

Happy to hear that!! :thumbup:

Yep: touchdown points change completely in the orbiter beta, I still haven't studied how. Once I finished this, I'll prepare a version also for the beta.

---------- Post added at 20:51 ---------- Previous post was at 14:55 ----------

NEW UPDATE

Change Log:
- Fixed bug of automatic restarting stages on scenario startup
- Fixed bug of multiple roll programs (noticed that some addons have more than one). Note: if the first roll program is deleted via the MFD, the second will not work anyway
- Wrote the full set of documentation!

LINK FOR DOWNLOAD (always the same)

 

[boogabooga]

Not saying that you need a code change, but advice to users wanting to set their own grav turn pitch parameter:

I think what you want to have happen is to avoid a pitch discontinuity between the gravity turn and the PEG. That is, if the PEG wants an attitude of say 35 degrees to start with, try to get the gravity turn to end (altitude 35 km) when the pitch is 35 degrees. Make sense?

Also, some launch vehicles stagger or delay the jettison of the spent solid boosters. Would it be possible to add a user-specified delay parameter between the booster burn-out and booster separation? Or is it there and I missed it?

 

[fred18]

From the new documentation file

BUT the computational evaluation of gravity turn is good but not perfect. It cannot know if for example engines are being throttled down for maxQ reasons, and each step is so dependent on the other that even if the results are quite good they cannot be taken as gold, also because actually the best conditions at which the rocket is left at PEG takeover depends also on the final orbit we want to achieve: for a low orbit of 160x160 km we will want to be almost horizontal for maximum tangential acceleration. For an high orbit of 300x300 km we will want to be still pointing up and gaining some more vertical speed to get to 300km. Therefore the value computational calculated usually works, but is a "suggested" value, that can be optimized by the user. In the orbit call of the guidance program users can set this at their pleasure, in order to find the optimal value. I've made hundreds of tests about this, but since all the rockets are different and the firing sequences are different it cannot be made completely closed to the user inputs, and by specifying which is the "suggested" value the user can have an idea of which value shall be used for that particular orbit. If the user does not input anything the guidance computer will use the suggested value.

Also, some launch vehicles stagger or delay the jettison of the spent solid boosters. Would it be possible to add a user-specified delay parameter between the booster burn-out and booster separation? Or is it there and I missed it?

A way is to do disable(jettison) and then jettison() whenever you want. Or to play with Curve values so the booster thrust will get to 0 just before fuel finishes, then booster will not be automatically jettisoned but there will be the need of a Jettison() call

 

[boogabooga]

The quote in the first box is not mutually exclusive with what I said.

 

[fred18]

Yep sorry, I was a bit in hurry. What you pointed makes perfectly sense, but it is very difficult to achieve precisely, that's why i call it a "suggested value". Anyway, since i feel that the biggest part of the job is over, and that also the documentation is almost there, I'll spend some time to try to refine the computational gravity turn evaluation system. It's very complicated actually (see the relevant doc in the documentation) but i'll try!

 

[boogabooga]

You don't have to do anything, really. I was just pointing out for people that wanted to set their own value.

Edit Bug Report:

After finishing SLS orbital insertion and restarting scenario, second stage respawns with interstage skirt attached again. Also, the restartable engine flag doesn't seem to be respected anymore.

 

[fred18]

Edit Bug Report:

After finishing SLS orbital insertion and restarting scenario, second stage respawns with interstage skirt attached again. Also, the restartable engine flag doesn't seem to be respected anymore.

:facepalm:

I have to be careful, if i correct one thing too rapidly i can mess up something else. Save and restoring is very difficult for this kind of vehicle. I'll check tomorrow about this! Thanks for your support!

 

[boogabooga]

Sorry for this, but....

How exactly are you handling "diameter" and "height" for a stage? I get what that is physically supposed to be. But, what are the consequences of changing the values in the module?

I tried to scale a large rocket into a tiny one, but the actual mesh in the simulation is just as large as before.

 

[fred18]

That's ok. Those parameters are used to:
1) calculate the cross sections for atmospheric drag
2) calculate the overall size of the vehicle
3) calculate the Principal Moments of Inertia
4) set default values for engine rendering if nothing is specified by user

For 1 and 3 a total cylindrical volume is calculated, then an equivalent diameter of the whole stack is determined and the cross sections are those of the equivalent cylinder, plus the boosters cross sections,since usually boosters are laterally attached. PMIs are those of the equivalent cylinder.

2 is the total height of the stack (recalculated for each stage, this is new compared to Vinka, that's why at staging you see the outside visual zooming)

4 is simply that if user does not set any value for engines, engine position will be (0,0,-0.5*height) and engine diameter will be 0.5 of stage diameter

So nothing related to visuals or meshes

 

[boogabooga]

Since you know the engine diameter, I think that a good goal for multistage2015 would be to model nozzle over-expansion (i.e. thrust increase with altitude). I can help you with the math.