Project Multistage2015 - Development Thread

[4throck]

now, if you are on a vessel which is not a ms2015 you can open the ms2015 mfd, click on the SEL button, type in the name of a ms2015 currently in the scenario and follow it, command it etc from remote.

:tiphat:

That's great ! Tested it and it works perfectly :thumbup:

 

[fred18]

We have growing particles!!!

here below some play with the numbers:

Users will have the possibility to choose the growing factors which are 2: growthrate change and size change. This because some users may prefer one or the other or a combination of the two. in some pictures you can see the particles that seems almost a big drop, this because I did that test with a remarkable size rate change and with a negative growthrate change.

if no numbers are set in the ini file (particles section) no growing effect will be shown.

Details and formulas will be explained in the documentation, but since it's working I wanted to share the preview.

by default the effect will be off, and needs to be activated with a line in the scenario file.

Now I'll see if I can make the MFD status persistant and that will be all for this release, nothing I can do more I think

 

[boogabooga]

Is it possible to change the color of the particles too?

 

[romanasul]

fred18, I seem to be experiencing a problem with the new multistage. I'm using scorpius's PTK spacecraft addon and Orbiter keeps crashing during load. I loaded the original multistage2 and it doesn't crash so Multistage2015 seems to be the problem. I'm not sure what's causing it, there's no indication in the log file.

---------- Post added at 12:17 AM ---------- Previous post was at 12:06 AM ----------

I solved the problem, it seems the particle stream effect 'smoke' is causing the problem.

---------- Post added at 01:36 AM ---------- Previous post was at 12:17 AM ----------

I also seem to be getting some very unusual issues.

 

[fred18]

Is it possible to change the color of the particles too?

Nope, but I also would not recommend it: particle color is governed by the particle's texture. In order to use a texture it must be "registered" and registering a texture once a second in the simulation (that's the rate of particle updating) could be a performance killer. Also you will need to prepare a set of textures with the color slightly changed one from each other.

fred18, I seem to be experiencing a problem with the new multistage. I'm using scorpius's PTK spacecraft addon and Orbiter keeps crashing during load. I loaded the original multistage2 and it doesn't crash so Multistage2015 seems to be the problem. I'm not sure what's causing it, there's no indication in the log file.

---------- Post added at 12:17 AM ---------- Previous post was at 12:06 AM ----------

I solved the problem, it seems the particle stream effect 'smoke' is causing the problem.

---------- Post added at 01:36 AM ---------- Previous post was at 12:17 AM ----------

I also seem to be getting some very unusual issues.

ok I'll check this. Relevant to the particles causing crash I think that the problem is that I didn't put a default texture to be used, so if in the particle definition there is no texture line the simulation crashes. I'll put a default value to avoid this kind of issue. I had it in my mind but I forgot to do it.

About visuals I confirm to have the problem too but it's easy to solve in the immediate while I see if there is a consistent solution for the future:

in the config file the line

off=(0,0,22.15) ;off=(0,0,17.1)

generates confusion because the module can load multiple payload meshes with multiple playload offsets separated by semicolumn and in this ini file there are two valid offsets but only one mesh defined. In this case the second offset must be ignored. If you take out the second part it will work:

off=(0,0,22.15)

I'll work on the module to avoid this anyway and to use just one offset if only one mesh is defined

 

[crisbeta]

I have a problem with Jarvis-H (look at total payload mass). I attached a print-screen. First I thought that is from my installation. I had overwrite with an older ms2015 (from around 6-Oct) and I haven't had any more problems. I also don't remember to have this issue with the previous release.

 

[boogabooga]

About visuals I confirm to have the problem too but it's easy to solve in the immediate while I see if there is a consistent solution for the future:

in the config file the line

off=(0,0,22.15) ;off=(0,0,17.1)

generates confusion because the module can load multiple payload meshes with multiple playload offsets separated by semicolumn and in this ini file there are two valid offsets but only one mesh defined. In this case the second offset must be ignored. If you take out the second part it will work:

off=(0,0,22.15)

I'll work on the module to avoid this anyway and to use just one offset if only one mesh is defined

I think that what is happening here is that the original author of the .ini file was using ";" as a comment operator to comment out an alternate offset. That's not really supported for multistage ini files. It usually seems to work, but not in this case. I wonder how this the original multistage2 was handling this issue?

I have a problem with Jarvis-H (look at total payload mass). I attached a print-screen. First I thought that is from my installation. I had overwrite with an older ms2015 (from around 6-Oct) and I haven't had any more problems. I also don't remember to have this issue with the previous release.

Can you post the ini file for the vessel?

 

[Loru]

can you put negative values on "particle size change" parameters to get them shrinking over time?

 

[DaveS]

can you put negative values on "particle size change" parameters to get them shrinking over time?

Shrinking them? Why would you want to do that? The plume expansion is anchored in solid well understood physics. As the atmospheric pressure decreases the plume expands as there's less force acting on it which makes it balloon and grow in size.

 

[fred18]

I have a problem with Jarvis-H (look at total payload mass). I attached a print-screen. First I thought that is from my installation. I had overwrite with an older ms2015 (from around 6-Oct) and I haven't had any more problems. I also don't remember to have this issue with the previous release.

I can't reproduce the bug. If you download and reinstall the latest version of ms2015 does this keep happening? which scenario of jarvis H are you flying and as boogabooga correctly asked, can you post the ini file? is it a real number (vehicle too heavy to lift off) or is it just a representation number on the instrument?

I think that what is happening here is that the original author of the .ini file was using ";" as a comment operator to comment out an alternate offset. That's not really supported for multistage ini files. It usually seems to work, but not in this case. I wonder how this the original multistage2 was handling this issue?

Correct, that's exactly the point. About Ms2 we'll never know, the way I solved it: if it is defined just one payload mesh stop reading its offset at the first ")" and it works, so also this kind of mistakes won't cause more issues.

can you put negative values on "particle size change" parameters to get them shrinking over time?

Yes absolutely, this picture was obtained with growing size positive, growthrate factor negative, to have the "drop shape" effect

also position of the emitted particle is updated, since when it becomes large if the emitting point is not update it will "swallow" half of the rocket. So emitting position is updated to keep the particle "tangent" to the engine.


I was about to post the updated module with the effect, but I noticed that if there are more engines the growing particle effect is too much a perfomance killer (with the sls which has 5 engines I have a drop of about 100 fps...)

So I will add a feature to the ini file to optionally "pack" the particles of the engines of a stage into a single particle effect, and I think this will be a great deal for graphic perfomances.

 

[Loru]

Shrinking them? Why would you want to do that? The plume expansion is anchored in solid well understood physics. As the atmospheric pressure decreases the plume expands as there's less force acting on it which makes it balloon and grow in size.

For example to use particle system to render interior of the flame

 

[DaveS]

For example to use particle system to render interior of the flame

That just isn't true to physics. Plumes grow in a vacuum, they don't shrink. For a plume to shrink you would need to increasing pressure beyond the nozzle which means an increase in ambient pressure. This is something that just about everyone misses despite being an very easy to understand effect. What your screenshot shows entirely fiction, there's not an ounce of science in it as far the plumes are concerned.

 

[fred18]

I agree that since pressure is decreasing flames and particles emitted shall increase in volumes.

the formula calculating the growth for both size and growthrate is

[math] GrowthRate_{CurrentAltitude}=GrowthRate_{SeaLevel}+FactorRate*log_{10}\left ( \frac{Pressure_{SeaLevel}}{Pressure_{CurrentAltitude}} \right ) [/math][math] Size_{CurrentAltitude}=Size_{SeaLevel}+FactorSize*log_{10}\left ( \frac{Pressure_{SeaLevel}}{Pressure_{CurrentAltitude}} \right ) [/math]
where users inputs the RateFactor and the SizeFactor


I just left the option of a "minus" effect open to the addon developers. As showed above for examples increasing size but decreasing growthrate can create a drop-shape that I think can mantain realism. It will be on the addon developer shoulders anyway to put plug in the proper numbers.

 

[crisbeta]

I can't reproduce the bug. If you download and reinstall the latest version of ms2015 does this keep happening? which scenario of jarvis H are you flying and as boogabooga correctly asked, can you post the ini file? is it a real number (vehicle too heavy to lift off) or is it just a representation number on the instrument?

I reinstalled a clean Orbiter and now it's ok. Sorry for the false alarm

 

[Loru]

That just isn't true to physics. Plumes grow in a vacuum, they don't shrink. For a plume to shrink you would need to increasing pressure beyond the nozzle which means an increase in ambient pressure. This is something that just about everyone misses despite being an very easy to understand effect. What your screenshot shows entirely fiction, there's not an ounce of science in it as far the plumes are concerned.

Technically you are correct however note that flame (I'm not talking about smoke plume) is not uniform. While hot gases expand, they tend to loose "glow" faster on the outside of the flame then inside giving appearence of reduced diameter futher from the nozzle.

I just left the option of a "minus" effect open to the addon developers. As showed above for examples increasing size but decreasing growthrate can create a drop-shape that I think can mantain realism. It will be on the addon developer shoulders anyway to put plug in the proper numbers.

Thanks

 

[fred18]

Hello,

a small update: I found out that the drop in the frame rate during the particle growing effect was present mainly because there was a glitch in the code and "old" particles were not deleted, therefore there was an additional particle stream every second and the simulation was going crazy.

Now that is fixed, but I anwyay implemented the option to package the particles of a multiple engine stage into a single stream.

the call is a simple line in the .ini file:

particles_packed_to_engine=xx

where xx is the number of the engine.

Since there maybe cases of asymmetrical distribution without a center engine users can set the very same parameter but negative. For example

particles_packed_to_engine=-2

this would link the particle stream to engine n.2 but it will show them from the center point of the engine positions.

Edit:

please note that particle packaging was impossible for boosters: each booster group can have more boosters, and each of them can have more engines. Complication was rising too fast, that will be maybe implemented in the future, but not for now.



I'll update docs and examples and put everything online soon, and that will be all!

---------- Post added at 20:13 ---------- Previous post was at 17:17 ----------

Download link updated with the above changes + some minor fixes here and there and an example of the growing particles + documentation update.

DOWNLOAD LINK

if no one shows up saying that this thing isn't working at all this file is going straight to OrbitHangar tomorrow :yes:

I'll then update the beta version so everything will be on the line



---------- Post added 27th Oct 2015 at 18:14 ---------- Previous post was 26th Oct 2015 at 20:13 ----------

finally!

official Release!!!!

it will surely have some hidden bug, but now it's official!

source code is included but be aware that I'm not professional programmer so be careful of what you "learn" from my code since it could be a terrible mistake!

at the very last second I added a new functionality that I saw in Generic Vessel and I think it's extremely useful:
you can switch to a "developer mode" who will allow to reload the vehicle from the ini file, so you will be able to see live all the changes you make to the ini!

link to OH!

[ame="http://www.orbithangar.com/searchid.php?ID=6838"]http://www.orbithangar.com/searchid.php?ID=6838[/ame]

in the next days I'll update and upload to OH also the version for the Beta

 

[boogabooga]

How hard would it be to allow the definition of linear thrusters?

 

[fred18]

easy without exhausts, but which rocket has linear thrusters (apart from main engines)?

 

[boogabooga]

Why, the Atlas V Centaur of course!

Seriously, they are good to have for BEO missions when you want to trim your departure burn after IMFD has finished. I do that all the time.

Plus, I suspect that they are required to get Pursuit MFD to work properly. (A very useful tool IMHO)

Neither multistage2 nor multistage2015 works with Pursuit MFD. But I don't think that any spacecraft without linear RCS works with Pursuit MFD (I am in the process of confirming this).

There is also Attitude MFD. Mutistage2 works well with Attitude MFD. Multistage2015 kind of works, but it is only using a small fraction of the available RCS force for some reason.

 

[fred18]

eheh ok, I will update this. I'll put a command in the [stage_x] section called "linear_thrust" if not defined no linear RCS will be present. ISP will be huge, no fuel will be used. I think that's acceptable.
if so, I'll do this for the release of the version for orbiter beta.
I won't code the exhaust position though. It would add too much complexity to the config file.