Project Multistage2015 - Development Thread

[boogabooga]

Anyway it seems to me that this:

I know you worked very hard on this, but I would rather go back to just editing the config directly:

1) The interface is huge (40-50% of the screen), and the window can't be shrunk or minimized. This really defeats the whole purpose for me. If I can't see my changes, what is the point?

2) Everytime I update the vessel, it gets flung off at hypersonic velocity.

is no longer valid

About that...

1) I still wouldn't complain if the DMD interface was a bit smaller. But it's workable as is.

2) I've only been testing in Orbiter 2016, but I'm not getting flung at hypersonic velocity.

Which reminds me, do you plan to retrofit Multistage2015 for Orbiter 2010 with DMD mode and the various bugfixes that came about since you posted to Orbiter Hanger?

Regarding crisbeta's issues..

I would recommend that the gravity turn portion of the "orbit" function be available as a separate function of its own. As in, it would do the gravity turn but not execute the PEG algorithm and instead wait for Vinka-style Pitch commands.

Reason is that it is that you almost always want the smooth and efficient gravity turn, but that is very hard to execute with the Vinka-style pitch program. You don't always want PEG, at least right away.

So in crisbeta's case, you would have the built in gravity turn up to PEG altitude, then execute Pitch commands to get through singularity, then execute orbit command on the other side to finish. The separate gravTurn function would also provide the flexibility of allowing the gravity turn with non-standard trajectories such as suborbital or constant pitch orbital insertions.

 

[Longjap]

@Longjap: sorry it isn't explained well enough, I'll make ti more clear in the next version of the docs.
you have to be more clear because I can't understand what you mean exactly.

Sorry for my English. No problem, I hadn't thought about reading Vinka's manual clearly. Maybe a line in your manual reminding to read the multistage2 manual about specific inputs would suffice to help others like me. The fairing issue I had was because I didn't name the mesh properly with a root name. Like your example fairing_1.msh and fairing_2.msh makes the name in the dialog: SLS\fairing and N=2. Not SLS\fairing_1 and N=2. I got it working now after reading Vinka's docs.

The problem with the payload being rotated 90 degrees when released is because the payload vessel itself is a forward facing vessel. I have no problem with other vessels. I'm trying to add the MDV/MAV as a payload to the SLS which works fine at most but I don't know how to release/jettison it in a way so it holds the attitude like it was attached to the upper stage so the hover engines are facing downward towards 2nd stage. Now it gets rotated facing forward instantly at the moment of release/jettison (hover engines facing Earth). But I think that's not related to your add-on.

I'm now almost done creating a crewed SLS block II with EUS upper stage borrowed from SLS beta from Gattispilot and the Orion MPCV by francisdrake and the rest from your SLS gift added in Multistage2015. I'm working on a orange texture for the stages and would love the boosters to have the nice decals shown in artist renderings but have to learn for that. If you want to use the textures in multistage2015 when I'm done I'll be glad to share.

Take care IRL.

PS. Does anybody know if there are any known complete specs for the enhanced EUS stage so I can fill in the blanks? Wiki only gives you so much.

 

[fred18]

I think that in the far future will be useful the following guidance functions:
- disable(yaw|attitude) (already exists Disable(pitch|Roll|Jettison))
- enable(attitude|pitch|yaw|roll|jettison)

Workaround that worked automatically:
- use old vinka's guidance style implemented very well in Multistage2015
- when the north to south change is finished, check the MET and add a margin error. Start using "orbit" autopilot for the final part of the orbit insertion.

Thank you for your input, I'll go through the heading equation again to see if I can find a way to make it continuos instead of having a singularity!

There is an issue in the documentation about the number of parameters of the roll guidance function. I mention than the functions works as expected in vinka's multistage style.

From Multistage2015 documentation


From vinka's multistage documentation

oops, I'll correct it! Thanks!!

Which reminds me, do you plan to retrofit Multistage2015 for Orbiter 2010 with DMD mode and the various bugfixes that came about since you posted to Orbiter Hanger?

Actually I was not, but it shouldn't be too long to copy paste the code frome the 2016 module to the old 2010, there is no too much difference. Priority is for the 2016 version, then I'll go through the old one.

I would recommend that the gravity turn portion of the "orbit" function be available as a separate function of its own. As in, it would do the gravity turn but not execute the PEG algorithm and instead wait for Vinka-style Pitch commands.

Reason is that it is that you almost always want the smooth and efficient gravity turn, but that is very hard to execute with the Vinka-style pitch program. You don't always want PEG, at least right away.

So in crisbeta's case, you would have the built in gravity turn up to PEG altitude, then execute Pitch commands to get through singularity, then execute orbit command on the other side to finish. The separate gravTurn function would also provide the flexibility of allowing the gravity turn with non-standard trajectories such as suborbital or constant pitch orbital insertions.

That is possible, I can make a separate call, heading shall be indicated then, would it be better to have in the call to indicate the heading or the target inclination? If the launch is suborbital maybe the heading? And would it be preferrable to have a time reference or a altitude reference? let's see what's best

I think that moving also the altitude step of the orbit program can be a trick for having just the grav turn: if you move the third (IIRC) altitude step very high the peg will never be triggered.

The fairing issue I had was because I didn't name the mesh properly with a root name. Like your example fairing_1.msh and fairing_2.msh makes the name in the dialog: SLS\fairing and N=2. Not SLS\fairing_1 and N=2. I got it working now after reading Vinka's docs.

I know, since naming it automatically is a bit problematic I'll add a note in the dialog window as a reminder

The problem with the payload being rotated 90 degrees when released is because the payload vessel itself is a forward facing vessel. I have no problem with other vessels. I'm trying to add the MDV/MAV as a payload to the SLS which works fine at most but I don't know how to release/jettison it in a way so it holds the attitude like it was attached to the upper stage so the hover engines are facing downward towards 2nd stage. Now it gets rotated facing forward instantly at the moment of release/jettison (hover engines facing Earth). But I think that's not related to your add-on.

I don't know if I understood correctly, but the idea that comes to me is to try to make the payload as "live", then rotating it as you prefer.

I'm now almost done creating a crewed SLS block II with EUS upper stage borrowed from SLS beta from Gattispilot and the Orion MPCV by francisdrake and the rest from your SLS gift added in Multistage2015. I'm working on a orange texture for the stages and would love the boosters to have the nice decals shown in artist renderings but have to learn for that. If you want to use the textures in multistage2015 when I'm done I'll be glad to share.

Can't wait!



Before this modifications which I think are marginal (grav turn call in guidance, recheck of the heading equations to see if it's possible to make it continuos etc) I am planning to post here a pre release candidate, I'm writing a small doc with everything that changed or that has been introduced.

 

[boogabooga]

I think that moving also the altitude step of the orbit program can be a trick for having just the grav turn: if you move the third (IIRC) altitude step very high the peg will never be triggered.

What happens when the "Orbit" function and the "Pitch" function conflict with each other? Which has priority?

 

[fred18]

I was wondering the same and was checking exactly that part of code. Actually they are not meant to be used at the same time, so there is no priority set among them... I think they'll conflict and you'll have the thrusters fighting against each other, but it's necessary to test it because i really don't know.

EDIT:
maybe you should delete the orbit call manually from the mfd when you want to switch to vinka's pitch, but of course that's not a "proper way" to do it.

---------- Post added at 18:05 ---------- Previous post was at 17:48 ----------

UPDATE:
here's the first pre release.
What is still missing:
- Full documentation update, only a small update doc is provided
- Test scenarios for SLS, hangar, crawler etc
- Tutorial scenarios (work in progress)

I'm also working on the topics raised in the previous posts, but in the meantime let's send this public so if anything is wrong I can correct it.

Same link, reposted here for conveniency:
http://www.intech-srl.eu/MS2015WIP.zip

 

[crisbeta]

An old request become reality
isp_sl = reference isp value
pressure_sl = reference pressure value

Also I will enjoy:
XX=explode()

I will start testing the new version.

Thank you :tiphat:

 

[boogabooga]

Which reminds me, do you plan to retrofit Multistage2015 for Orbiter 2010 with DMD mode and the various bugfixes that came about since you posted to Orbiter Hanger?

Actually I was not, but it shouldn't be too long to copy paste the code frome the 2016 module to the old 2010, there is no too much difference. Priority is for the 2016 version, then I'll go through the old one.

I would suggest that you at least bring the Multistage 2015 for Orbiter 2010 up to the 2015 11 03 standard on the "official" Orbiter Hangar d/l:

http://www.orbiter-forum.com/showthread.php?p=518995&postcount=28

The version on Orbiter Hangar now (2015 10 27) still has the bugs in the particle stream definitions.

 

[Interceptor]

Hey fred18,I am just wondering if it's possible to use just the crawler,or just the hangar,like for instance if you wanted to crawl the rocket to a different hangar than the one you included,or if you wanted to use a different crawler,but use your hangar?

 

[crisbeta]

I tested all new features from the document, except "FX_LAUNCH". It works as expected; no issues so far (just a small freeze and go on CAMERA, but no big deal).

For "FX_LAUNCH" I let boogabooga. His knowledge at this are far better than mine

I think would be useful for realism in config file a tag with isp_rcs as optional (I think now is isp*10) or isp_linear just for linear thruster.

 

[boogabooga]

Seems to be some textures missing:

--------------------------- WARNING: --------------------------
>>> Texture not found: Jarvis\Explosivebolt.dds
Skipping.
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 1040]
---------------------------------------------------------------
--------------------------- WARNING: --------------------------
>>> Texture not found: Jarvis\explosion.dds
Skipping.
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 1040]
---------------------------------------------------------------
000507.849: About To Explode

CTD on triggering explode()

However, e notation seems to be working well.

Edit:
I grabbed the missing textures from the Jarvis add-on and the explosion effect works well.

Edit again:

Okay, bug report. Tested with my SLS launch scenario. Seems if you trigger explode() while the vehicle is still landed, the explosion happens back on the numbered hover pads instead of where the rocket was actually located.

Admittedly, I wouldn't have tried this if it weren't for this month's earlier unpleasantness. :shifty:

More bug reports:
Putting CAMERA in the scn file causes CTD upon scenario loading for me.

Updating the vessel from DMD mode while in the hangar causes CTD.

Another edit:
I'm starting to suspect that you are making a critical assumption somewhere with all your new goodies that the rocket has
STATUS Landed Earth
BASE Cape Canaveral:1

In general, things seem to be working well when this is the case, but going haywire when it is not...

More specifically, "RAMP" and "CAMERA" seem to hate to be together if status is not BASE Cape Canaveral:1

 

[fred18]

Seems to be some textures missing:

--------------------------- WARNING: --------------------------
>>> Texture not found: Jarvis\Explosivebolt.dds
Skipping.
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 1040]
---------------------------------------------------------------
--------------------------- WARNING: --------------------------
>>> Texture not found: Jarvis\explosion.dds
Skipping.
>>> [TextureManager::AcquireTexture | .\Texture.cpp | 1040]
---------------------------------------------------------------
000507.849: About To Explode

CTD on triggering explode()

you're right here, I forgot to modify the exploding function from the jarvis one, thanks.

Okay, bug report. Tested with my SLS launch scenario. Seems if you trigger explode() while the vehicle is still landed, the explosion happens back on the numbered hover pads instead of where the rocket was actually located.

Ok, actually exploding on the pad was never meant to happen because the failures are set to happen during flight, but it could be a good point to add, I'll modify this to have a proper explosion also if still on the pad.

More bug reports:
Putting CAMERA in the scn file causes CTD upon scenario loading for me.

I'm starting to suspect that you are making a critical assumption somewhere with all your new goodies that the rocket has
STATUS Landed Earth
BASE Cape Canaveral:1

In general, things seem to be working well when this is the case, but going haywire when it is not...

More specifically, "RAMP" and "CAMERA" seem to hate to be together if status is not BASE Cape Canaveral:1

Well i'm actually not using BASE Cape Canaveral:1 at all, as a matter of fact I didn't provide any scenario. The scenario I use most frequently for testing uses this:

  STATUS Landed Earth
  POS -80.6208600 28.6271940

maybe defining the pad instead of a position on earth gives issues? if you use a latitude longitude position does it work?

Updating the vessel from DMD mode while in the hangar causes CTD.

This never happens to me and I did it 100.000 times :huh:
Logfile pls?

Hey fred18,I am just wondering if it's possible to use just the crawler,or just the hangar,like for instance if you wanted to crawl the rocket to a different hangar than the one you included,or if you wanted to use a different crawler,but use your hangar?

you can use just the crawler or just the hangar. It should be tested a bit to see if everything works somehow in that case.

 

[boogabooga]

Ok, actually exploding on the pad was never meant to happen...

Tell that to SpaceX. :shifty:

EVERYONE is going to want to blow it up on the pad now. Or is it just me? :lol:

The scenario I use most frequently for testing uses this:

Please post your test scenario and I will try to figure out what I am doing differently. I already posted my test scenario.

 

[Longjap]

Hi Fred,
It's a work of art! Thanks much for the update! I too have some problems updating the vessel through the DMD mode. CTD's when updating in hangar. I'm not sure why. Camera isn't working for me either. Hangar and crawler work perfectly.

Anyway I did some work on the block IB Orion SLS this weekend.

Almost done texturing.

 

[fred18]

Wow looks great!

Update, same link
- I found the issue with the DMD updating while in Hangar Mode, it seems to work now.
- I updated the "boom" vessel so now it works with its own texture without reference to the jarvis.
- The following are my test scenarios. Regarding the camera vessel I have issues only if I reload a saved scenario with the camera vessel as focus, else it works. I'll dig to find out why this happens.
- Still working on having a pad blow up and the rest of the topics


General Test + Camera:

BEGIN_DESC
This is a Test Scenario for the Multistage2015 Module. 

It uses a model I realized for the SLS Heavy Lift configuration.

Have Fun!

Fred
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51985.6206116061
END_ENVIRONMENT

BEGIN_FOCUS
  Ship SLS
END_FOCUS

BEGIN_CAMERA
  TARGET SLS
  MODE Extern
  POS 2.89 0.74 -110.96
  TRACKMODE TargetRelative
  FOV 70.00
END_CAMERA

BEGIN_STATIONS
END_STATIONS

BEGIN_SHIPS
SLS:Multistage2015
  STATUS Landed Earth
  POS -80.6208600 28.6271940
  HEADING 0.00
  FUEL 1.000
  CONFIG_FILE Config\Multistage2015\SLS.ini
  GUIDANCE_FILE Config\Multistage2015\Guidance\SLS_57302.65_GNC.txt
  TELEMETRY_FILE Config\Multistage2015\Telemetry\SLS_57310.61_TLM.txt
  CONFIGURATION 0
  COMPLEX
  CAMERA
END

General test + Hangar:

BEGIN_DESC
This is a Test Scenario for the Multistage2015 Module. 

It uses a model I realized for the SLS Heavy Lift configuration.

Have Fun!

Fred
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51985.6206116061
END_ENVIRONMENT

BEGIN_FOCUS
  Ship SLS
END_FOCUS

BEGIN_CAMERA
  TARGET SLS
  MODE Extern
  POS 2.89 0.74 -110.96
  TRACKMODE TargetRelative
  FOV 70.00
END_CAMERA

BEGIN_STATIONS
END_STATIONS

BEGIN_SHIPS
SLS:Multistage2015
  STATUS Landed Earth
  POS -80.6538600 28.5897940
  HEADING 336.00
  FUEL 1.000
  CONFIG_FILE Config\Multistage2015\SLS.ini
  GUIDANCE_FILE Config\Multistage2015\Guidance\SLS_57302.65_GNC.txt
  TELEMETRY_FILE Config\Multistage2015\Telemetry\SLS_57310.61_TLM.txt
  CONFIGURATION 0
  COMPLEX
  HANGAR
  CRAWLER
END

 

[boogabooga]

Can the camera and the hangar/crawler exist together?

 

[fred18]

There is no "wanted" reason not to have them together. If it doesn't work i'll check why.

 

[boogabooga]

Bug report:

It seems that DMD mode is writing the Booster angle to the ini file in radians instead of degrees.

I haven't checked every angle, so in general be careful about radian/degree conversions.

 

[fred18]

Bug report:

It seems that DMD mode is writing the Booster angle to the ini file in radians instead of degrees.

I haven't checked every angle, so in general be careful about radian/degree conversions.

I'll check immediately, that's crucial for sure.

How about the scenarios? is it going any better?

EDIT:
I confirm the bug, and it's already solved, you'll have it solved in the next update. In the meantime I think it's safe if I check all the angles definition as per your suggestion. They are a lot and some of them are used in radians, some other in degrees, so I'll check them all in these days

---------- Post added at 18:16 ---------- Previous post was at 00:38 ----------

Hi guys,
let's make a small list of points to be closed or already closed

in my list I have:
1) CTD on updating when in Hangar - SOLVED
2) Camera issues - Maybe I solved some or all of them, in the next release we'll check
3) Check all the angles between reading and writing from and to the ini file - ongoing
4) Add a GravTurn Call to the guidance program - to be started, should not be too difficult
5) Try to solve the orbit guidance program issue when the velocity passes from northward to southward or the opposite - Not easy at all. there are work arounds but i'll try to solve this anyway if I can.
6) having a pad blow up - Should be solved, public in the next update
7) scenarios with pad issues - still to be checked, I don't know if there is an issue or not.

Once that is finished to me there is only
- documentation full update
- a couple of test scenery to setup

Anything else from you?
Cheers!
Fred

 

[Marg]

Hi, have been testing this amazing addon as well... I remember my old addon Columbia's "STS-5" way to launch pad some 10 years ago (still on Orbithangar) using pylon...
1) I just thought about launch effects... " space shuttle" has two sources of steam/smoke clouds, when orbiter starts engines - 6 secs before liftoff - in the front direction, and 1 sec before liftoff - from SRB's - in the opposite deflecting direction. Maybe some option with "time shift" is possible?
2) MS_CAMERA exhibits Orbiter graphic client's problem - heavy flickering (z-buffer fight?), when zoomed in from a distance... not a multistage problem though...

P.S. Also (but it also is not a direct multistage problem) I still think how to improve these launch smoke clouds, because they have blurry edges when grown up (because of "growth factor")... in real life they have sharper edges. One solution would be - not make this "growing up", but then they stay low above the ground, no high "clouds".
Another - another texture "contrailxx.dds" with very sharp edges, and after defining in pstream2, so when even after "growing up" it still has sharp edges?

P.S. 2 - I noticed that after ~1 min after launch, clipping effect happens, ground is clipped - black (if <300 m above) , also launch smoke's underground part becomes visible as well. That is when I do not follow rocket in Orbiter's ground camera mode, but look at launch pad.

 

[crisbeta]

in my list I have:
1) CTD on updating when in Hangar - SOLVED
2) Camera issues - Maybe I solved some or all of them, in the next release we'll check
3) Check all the angles between reading and writing from and to the ini file - ongoing
4) Add a GravTurn Call to the guidance program - to be started, should not be too difficult
5) Try to solve the orbit guidance program issue when the velocity passes from northward to southward or the opposite - Not easy at all. there are work arounds but i'll try to solve this anyway if I can.
6) having a pad blow up - Should be solved, public in the next update
7) scenarios with pad issues - still to be checked, I don't know if there is an issue or not.

I think point 5 should be skiped for the moment. You are probably very close to release and trying to fix point 5 could lead you to unexpected guidance errors.