Project Multistage2015 - Development Thread

[4throck]

It's live.

Could it be because I'm starting the scenario with the second stage active?

 

[fred18]

It's live.

Could it be because I'm starting the scenario with the second stage active?

One reason that comes to my mind is that maybe the fact that the payload is attached to the stage as a child doesn't fit well with something attached to it.

I have to look through the docs of Orbiter to see if this is mentioned somewhere (or if by chance martins sees this he could quickly help), but it seems to me that if two vessels are attached and then a third vessel docks to the child vessel of the first pair, the status update doesn't work perfectly.

If that is the case any workaround won't be easy at all... :hmm: Could you convert the docking port of the Orion into a child attachment point, maybe creating a chain of attachments will work better than docking it.

 

[4throck]

The Orion is launched on the Ares I so it really needs to dock...

If you could have a docking port on the multistage vessel, that would do.
That's how I did it with Velcro:

After the TLI maneuver, you undock Orion from the stage, and then detached Altair.
The jettison speed of Altair would immediately dock it to Orion

_______

Tried adding a docking port to Multistage by editing stage.cfg (and Multistage2015.cfg) and it seems to work. I can control the stack from any vessel.
But for the user it's not a great solution having to edit "system" files.

 

[Face]

One reason that comes to my mind is that maybe the fact that the payload is attached to the stage as a child doesn't fit well with something attached to it.

Martin wrote about the limitations of the attachment system in the documentation /orbitersdk/doc/API_Reference.pdf p.9 (20/672). There is no hint on docking ports not working on child attachments, though. Perhaps it is a side-effect of the second point in that enumeration that talks about simplified physics engine.

That chapter still talks about docking ports not working on the ground, BTW. Therefore it could be that it needs some update. :shrug:

 

[fred18]

Tried adding a docking port to Multistage by editing stage.cfg (and Multistage2015.cfg) and it seems to work. I can control the stack from any vessel.
But for the user it's not a great solution having to edit "system" files.

It should be only in the Multistage2015.cfg.

I suggest to create a dedicated cfg file, something like Ares_MS2015.cfg, which has inside it

ClassName = Multistage2015
Module = Multistage2015

///DOCKING SPECS HERE BELOW
XXX

and in the launch scenario file you'll change the default scheme of your vessel from something like:

Ares:Multistage2015

to something like:

Ares:Ares_MS2015

so the docking port remains something about the ARES and is not going into all the Multistage vessels you have. Also for redistirbution this is surely a preferred scheme.

 

[jacquesmomo]

Tried adding a docking port to Multistage by editing stage.cfg (and Multistage2015.cfg) and it seems to work. I can control the stack from any vessel..

I think it's not a good idea ...:facepalm:

As explained by Fred18, it is better to add a cfg file.

I did this for several rockets provided with my Kourou-CSG-base add-on.

You need 2 files : 1 cfg file and 1 ini file.

Exemple:
I put in the folder ...\Config\Kourou_Rockets\Soyuz these files :
- soyuz.cfg
- soyuz.ini
- soyuz_guidance.txt (this file is optional)

here is the soyuz.cfg file :

 [COLOR=red]ClassName = Soyuz
Module = multistage2015
[/COLOR]Size = 2
 
 ; === Attachment specs === 
BEGIN_ATTACHMENT
P 0  0  -13.8  0  0 -1  0 -1  0  SZ
 END_ATTACHMENT
 
 ; === Docking ports ===
[COLOR=red]BEGIN_DOCKLIST
0 0 16.0865   0 0 1    0 1 0    587
0 0 7.65   0 0 -1    0 1 0    588
END_DOCKLIST
[/COLOR]

As you can see I added an attachment point and 2 docking points .
The Soyuz.ini file is a multistage2015 configuration file.

And for your scenario, the file is like this :

 BEGIN_SHIPS
[COLOR=red]Soyuz:Kourou_Rockets\Soyuz\Soyuz
[/COLOR] STATUS Landed Earth
  POS -52.7473238 5.2317856
  HEADING 210.50
  ATTACHED 1:0,MS_LaunchPad_Soyuz
  AFCMODE 7
  FUEL 1
  [COLOR=red]CONFIG_FILE Config\Kourou_Rockets\Soyuz\Soyuz.ini
[/COLOR] GUIDANCE_FILE Config\Kourou_Rockets\Soyuz\soyuz_guidance.txt  [COLOR="Green"](optionnel)[/COLOR]
  CONFIGURATION 0
  RAMP
  PEG_PITCH_LIMIT 65.000
END

In this system, Orbiter will first read the file \Config\Kourou_Rockets\Soyuz\Soyuz.cfg
then the file Config\Kourou_Rockets\Soyuz\Soyuz.ini

And it works fine !!!

Thanks one more time to Fred18 and his work !!! :thumbup:

 

[4throck]

Yep, that's it. Thanks for the detailed help!

 

[gattispilot]

So for the SLS we had to edit an cfg. We added an attachment point for the SLS to be carried on our crawler.

ClassName=EmptyModule
Module=EmptyModule
BEGIN_ATTACHMENT
P 0  0  57   0  0 -1  0 1  0  PAD
END_ATTACHMENT

Not sure another way around it?

 

[Buck Rogers]

I'm getting a CTD when using the command line "Explode()", O2016, inline gfx, WinXp. Has this been tested/checked in O2016, or is this possibly an OS issue? Gattispilot asked something similar here: https://www.orbiter-forum.com/showthread.php?t=39207 but didn't receive a definitive answer. Having a lot of fun with MS, had forgotten how cool it is, especially the new features.

 

[boogabooga]

@Buck Rogers
All I can say is to look here where that was discussed:
https://www.orbiter-forum.com/showthread.php?p=542593&postcount=510

Do you have that texture?

 

[Buck Rogers]

Thanks Boogabooga, missed that, have followed the thread but it's got pretty long.
I wasn't getting any errors in the log like that, actually nothing relevant at all. I added the Jarvis textures just to check, but to no avail, I'm still getting a CTD- memory crash!?

Can anyone confirm that this feature works in Orbiter 2016?- just so I know which tree I'm barking up.

 

[1987VCRProductions]

I've noticed a bug in Multistage2015 for Orbiter 2010 where there's an issue with doing the ejection burn using TransX. I've not tested this with Orbiter 2016. The following screenshots are of an escape trajectory from Earth to Venus using both Multistage2015 and Vinka's old Multistage2.

When the escape burn is done with the module set to Multistage2015, there's a slight offset that gets more noticeable when the delta V requirement is higher:

When I switch the module back to Multistage2 temporarily and attempt the same burn again, the escape trajectory is more accurate:

This offset is more noticeable in high escape velocities such as the Voyagers where it's so great that there isn't enough fuel left for a trim burn before spacecraft separation.

---------- Post added at 11:25 PM ---------- Previous post was at 11:22 PM ----------

In the case of Voyager 1 and 2, I make a save-state just before the ejection burn and temporarily switch the module back to Multistage2.

 

[boogabooga]

"When the escape burn is done"

Manual or are you using the auto-burn?

 

[1987VCRProductions]

There is no auto-burn with TransX (as far as I can tell) I do the burn when the time to burn counter reaches 0 and burn until the Delta V is at zero. I did use the auto-center feature for both burns, but manually tracking the green X gets a similar result as well. Both screenshots are of the same burn but using Multistage2015 for one and Multistage2 for the other. This is an issue with Multistage2015 as Multistage2, Spacecraft3, and Velcro Rockets don't have this problem with TransX.

---------- Post added at 05:07 AM ---------- Previous post was at 05:04 AM ----------

The issue is more notable when the Delta V requirements are larger, with Multistage2 coming very close if not nailing it and Multistage2015 being way off.

---------- Post added at 05:25 AM ---------- Previous post was at 05:07 AM ----------

I'll try to give a high Delta V example in an attempt to better illustrate what I'm talking about.

---------- Post added at 06:58 AM ---------- Previous post was at 05:25 AM ----------

I did an example with Voyager-1, here's the post-burn trajectory using Multistage2015:

Here's the post-burn trajectory using the old Multistage2:

Making these examples, I discovered the reason for the difference in trajectories. There's a discrepancy in the time to burn countdown when loading the save file using Multistage2015 vs. Multistage2.

This is an example of the time to burn using MS2015:

And here is the same but with MS2:

---------- Post added at 07:01 AM ---------- Previous post was at 06:58 AM ----------

In short, TransX anticipates a longer burn time with Multistage2015 so it moves the burn timer to have the burn occur earlier than it needs to. I don't know why that is though.

 

[boogabooga]

Do you have burn time MFD?

See if there is a difference in what it says between the two versions.

 

[fred18]

are you using a live payload in ms2015?

 

[1987VCRProductions]

I wasn't using a live payload with that particular add-on but it makes no difference whether the payload is live or not.

---------- Post added at 07:40 AM ---------- Previous post was at 07:39 AM ----------

I've never used Burn Time MFD before but I will check it out the next chance I get.

 

[1987VCRProductions]

I tried it again using Burn Time MFD alongside TransX and the results were a little bit better but not quite.

There is a difference in the ignition times which gave me some hope:

But the result was still an offset (not as bad as before but still off):

In this instance I was using a live payload but as I pointed out earlier that makes no difference. MS2015 seems to confuse TransX in a way that you only see with more complexly coded rocket stages that require some process to ignite the engines other than just pressing the + key and locking it down with CTRL.

 

[boogabooga]

No.
What I meant was, ignore TransX for a minute,

Set up a future burn with just BurnTime MFD with a mutistage2015 vehicle. Pause. Take a screenshot. Save and then reload the scenario but substituting in the old multistage2 module and see if all the BurnTimeMFD numbers are the same.

I'm trying to figure out if it is just a TransX issue, or a more fundamental difference between the multistage modules. BurnTimeMFD might tell you.

 

[1987VCRProductions]

Ah, sorry for the misunderstanding. This is Burn Time MFD with a Pioneer 11 escape burn loaded into it. There's no difference in times between MS2015 and MS2: