OHM Multistage2015 - for Orbiter 2010P1

OrbitHangar

Addon Comments
Joined
Apr 9, 2008
Messages
3,832
Reaction score
13
Points
0

Author: fred18

Multistage2015 is the renewed Multistage module.

Inspired by the module made by Vinka, Multistage2015 allows to develop multistage launchers even for those who are not willing or capable to code, or for those who simply wants to exploits all the built in features of this module.

New Features:

- Orbit autopilot!!! - A complete autopilot that take the vehicle from the ground and release it in orbit with extremely high precision, based on the PEG Algorithm
- A lot of new guidance calls available!
- A lot of new configuration file calls available!
- A custom made MFD which allows to monitor and to interact with the launcher, even from remote!
- Possibility of "live" and rotated payloads! - finally no more dead meshes!
- Growing particles effect! - to boost the realism of the launch simulation
- A Developer Mode option which allows to reload the vessel from the configuration file within the simulation! no more closing and reopening to see a change!
- Complete retrocompatibility with Vinka Module, all old addons will still work, but all the new systems can be exploited now!

- Hangar, Camera and Crawler vessels are included for added fun!

This version is for Orbiter 2010P1

Please read the manual since a lot of information is included in it.

A hypotetical SLS Heavy Lifter is included in the package as example

Biggest Thank goes to Dr Martin Schweiger, for the rest of the credits and thanks check documentation.

Development Thread: h ttp://www.orbiter-forum.com/showthread.php?t=35845

Have fun up there!

Fred18

 

Update 07/10/2016: added the SLS meshes and textures to the package that were missing in the first release

Update 07/10/2016 (2) : stage.cfg was missing

 

Update 07/10/2017: playsound command in guidance file is now supported and independent from Orbiter Sound. added stage.dll that was missing, added notes in the docs.

Update 06/26/2017: Changed logic and application for Hangar and Crawler, no dirty hacks anymore. Fixed bug for ignite_delay=0. Fixed Camera bug. SLS.ini now fixed as per boogabooga file.



DOWNLOAD
 

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
There is no more "well it's just multistage for now..." by add-on developers that don't know how to program. Multistage2015 is competitive with almost every dll launcher that I have seen.
 

romanasul

Member
Joined
May 5, 2012
Messages
301
Reaction score
0
Points
16
Location
Toronto
There is no more "well it's just multistage for now..." by add-on developers that don't know how to program. Multistage2015 is competitive with almost every dll launcher that I have seen.

Yes, it's amazing what fred18 has achieved here. The only dll launcher that I can say is superior to this is the Jarvis.
 

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
Yes, it's amazing what fred18 has achieved here. The only dll launcher that I can say is superior to this is the Jarvis.

I don't think that that is a coincidence! :lol:

Perhaps the only need for dll is for something very specialized- like Falcon 9 landing on a barge (which we have) or something. Also, some architectures (cross feeding, etc.) may still be handed better in Velcro or dll.

The only downside is that there is no longer motivation to encourage Orbinauts to learn to program, which is otherwise a good skill to have.
 
Last edited:

fred18

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,667
Reaction score
106
Points
78
Thanks guys, I'm very happy this is appreciated, I dedicated a huge amount of time to it and I was hoping to meet the needings of the orbinauts! :thankyou:

The only downside is that there is no longer motivation to encourage Orbinauts to learn to program, which is otherwise a good skill to have.

well yes and no. The launcher still is just the launcher and payloads are still there to be coded. And I think that the launcher holds in itself some barriers that are too descouraging for those who want to start coding. For example the management of a vehicle that changes its physical parameters so much due to staging and the mathematical mess off the complete multistage PEG guidance (consider that I started to study an implementation of it when I was doing the ELIS launcher, almost three years ago).

Now you have this in this module an not only, you have the code available.

On the otherside I think that the possibility of using such autopilot can really boost the addon developers number.

And with a launcher ready maybe people will be willing to start to develop new probes and addons! I don't know, we'll see :crystalball: :lol:
 

K_Jameson

Active member
Joined
Dec 30, 2009
Messages
1,076
Reaction score
18
Points
38
Yes, it's amazing what fred18 has achieved here. The only dll launcher that I can say is superior to this is the Jarvis.


Actually, in my understanding, MS2015 is even superior to it in some ways, for example the PEG guidance.

Anyway... for me the approach mentioned by Fred is clever. For example, if in the past in FOI we had to develop complete dll rockets, surely Antares or Eridanus would not have seen the light in the current form, and perhaps other funny initiatives as Orbiter Live Missions would have less space, because time is not infinite; relying on an inventory of always ready multistage2 launchers, at the cost of some compromises we could focus on other projects that needed more extensive efforts.
 
Last edited:

fred18

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,667
Reaction score
106
Points
78
Actually, in my understanding, MS2015 is even superior to it in some ways, for example the PEG guidance.

I would say that Jarvis dll was the basis to create this: PEG was already working ok with Jarvis but here it is a lot evolved. Basically the Jarvis dll was my Gemini program and this is my Apollo program :lol:

Also I think that the MFD here is a lot helpful.

The only things that I think Jarvis is still better are the specific functions and effects. For examples jarvis ramps are commanded directly by jarvis computer, producing a very nice and realistic procedure and I think that abort sequences of jarvis are one of its nicest feature, but these features are almost impossible to reproduce in a general module because they are too specific to be generalized.
 

Michael_Chr

New member
Joined
Jul 16, 2013
Messages
153
Reaction score
0
Points
0
Location
Virklund
Thanks a lot for your effort Fred... As already stipulated this will be one of the "must have" addons in the future. That we have people like you in the community is very promising for the future.
 

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
Bug report: I do not believe that reloading ini in "developer mode" is properly checking the two new growing particle factors.
 

fred18

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,667
Reaction score
106
Points
78
Bug report: I do not believe that reloading ini in "developer mode" is properly checking the two new growing particle factors.

Developer Mode is still not totally perfect, I added it at the last second so please forgive any inaccuracy. I found a bug myself in it: at the moment if you change rotation of payload probably it will CTD, but I already solved it, it will be updated when I'll publish also the orbiter beta version.

I cannot imagine any particular reason why change in particles growing factors is not reloaded properly, I'll check.

Just in case, try to reload twice.

EDIT:

oh yes, I see it. It's one of the few parameters based on dynamic allocation so it doesn't get updated in reload. I'll see if I can fix it.
 
Last edited:

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
I think beta testing is my new favorite thing to do. :cheers:
 

fred18

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,667
Reaction score
106
Points
78
It was recognized in documentation :cheers:
 

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
I think perhaps you need to explain the new growing particles a bit better. I am a bit confused. :shrug:

My "understanding" upon reading the documentation was that GrowFactor_size would affect Srcsize and GrowFactor_rate would affect Growthrate to each have an altitude dependence. As in, at say 50km altitude the particle stream would look as if you had simply used the modified Srcsize and Growthrate all along.

That doesn't seem to be what is happening at all. The growing particles seem to be a new effect altogether, is that correct? I can almost see the "original" particle stream inside the "growing" particle stream. Growthrate does not seem to affect the "growing" stream, but the "original" stream instead. However, Srcrate has a huge impact on the "growing" stream. I'm really confused. :shrug:
 

PhantomCruiser

Wanderer
Moderator
Tutorial Publisher
Joined
Jan 23, 2009
Messages
5,607
Reaction score
170
Points
153
Location
Cleveland
Holy cow!

Fred18, that's some great work. I played around with an earlier release, taking a look at your SLS gives me a ton of things I'd like to implement in my own projects and I can't wait until work settles out and I can get busy on them.

Thanks so much for taking the time for this. It looks live I've got some config files to write. :thumbup:
 

fred18

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,667
Reaction score
106
Points
78
I think that you are getting disoriented by the mixed effect of multiple factor. Let me try to explain clearly.

first of all:

My "understanding" upon reading the documentation was that GrowFactor_size would affect Srcsize and GrowFactor_rate would affect Growthrate to each have an altitude dependence. As in, at say 50km altitude the particle stream would look as if you had simply used the modified Srcsize and Growthrate all along.

First part is correct, the rest I don't know if it's exact, I'm not sure if I got correctly what I highlighted. The dependence is on the pressure, by the published formulas which of course means an altitude dependence for both factor.

The particle stream works in this way(not considering now atmo and level mapping) : at each instant the engine emits particles as per specification given. The particles emitted have a size of srcsize, a number of srcrate per second of this single particles are emitted, they stay in the simulation for the lifetime defined before dissolving. While staying in the simulation (the cloud that you see behind the vehicle) they grow in size by growthrate meters/sec.

The growing particle effect allows to change in time, depending on outside pressure, two of this parameters: size of emitted particle and growthrate of the emitted particle.

So at 50 km you will see behind the rocket the particles already emitted by the engines while flying to that altitude and you will emit the particles that will have the size and growthrate applying in that moment.

To give an idea the effect is stopped when outside pressure reaches the level of 10e-5 Pa. On earth at sea level pressure is 101400 Pascal, so the formula gives at maximum a variation of 10*factor for each from original value at sealevel.

Now let's take a look at the relevant parameters for this scope which are of course:
- srcsize = size of the single particle emitted
- growthrate = measure of how the single particle emitted grows in size while rendered (it is how, once emitted the smoke grows while still "alive", before dissolve itself)

so a single particle is emitted with size = srcsize and after a while, while flying in the atmosphere it would have grown proportional to growthrate right? this is how it already works in orbiter.

If you increase the size of the particle, even if you don't touch the growthrate, you will have the feeling that also growthrate is increasing, because a bigger particle that grows with the same growthrate of the smalle particle will end up being bigger at the end: it simply started from a bigger value, grew the same amount and logically ended to a bigger value.

This is why you have the feeling of growthrate changing even if it's not.

If you instead increase just the growthrate the particles will be emitted at the same size at every altitude but they will grow much faster. This leaves the way to have a bigger cloud without having to extend the particle lifetime (which is also really performance consuming).

to see what I'm trying to explain, try this in the example of the SLS with growing particles:
Code:
[PARTICLESTREAM_3]
NAME=growingcont
SRCSIZE=4
SRCRATE=5
V0=150
SRCSPREAD=0
LIFETIME=8
[B]GROWTHRATE=0[/B]
ATMSLOWDOWN=0.3
LTYPE=EMISSIVE
LEVELMAP=LVL_PSQRT
LMIN=0
LMAX=1
ATMSMAP=ATM_PLOG
AMIN=1e-6
AMAX=1
TEX= contrail1
GROWFACTOR_RATE=0
GROWFACTOR_SIZE=6

you'll see regular tube of particles just growing in diameter as per altitude increase.

then if you want to see the growthrate factor working try this

Code:
[PARTICLESTREAM_3]
NAME=growingcont
SRCSIZE=4
SRCRATE=5
V0=150
SRCSPREAD=0
LIFETIME=8
GROWTHRATE=4
ATMSLOWDOWN=0.3
LTYPE=EMISSIVE
LEVELMAP=LVL_PSQRT
LMIN=0
LMAX=1
ATMSMAP=ATM_PLOG
AMIN=1e-6
AMAX=1
TEX= contrail1
GROWFACTOR_RATE=6
GROWFACTOR_SIZE=0

Last thing: the feeling you have to see the old particle stream inside the new one is just because the texture is much denser at the center, but it's only one particle that is emitted (or 2 if 2 of them are defined).

The effects simply recalculate the parameters and once per second delete the old particle and add the new with the updated specifications.

I'm not sure if I was clear, it's not totally easy to explain just with words, drawings would have helped a lot!

Let me know if it was understandable and anyway don't hesitate to ask ;)

---------- Post added at 01:41 ---------- Previous post was at 01:23 ----------

Just to add what might be clearer to you:

It seems to me that you think of particle streams paramters as the parameters of the cloud of smoke behind the rocket, that is not true or at least not accurate.

the particle stream parameters are the paramaters of the single particle of smoke emitted by the engines, the cloud of smoke is the result of the sum of all this particles which stay in the simulation for their "lifetime".
 
Last edited:

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
Could the use of ";" as comment out in particle stream section confuse things?
 
Top