[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[Pigzippa47]

@Shadowmage

I recently got back into KSP and updated a few of my old mods to play in 1.3 (I'd been limping in 1.3 in the Spring and got fed up with mods being all out of date). In particular, I installed the current workaround of Infernal Robotics 2.0.12, removing Active Struts and Struts folders and adding a new IRSurfaceSampler.dll. 

KSP x32 crashes upon loading my savegame, so I haven't been using it. 

In KSP x64:

I noticed that when I added a MFT-A to my craft, it threw a "NullReferenceException: Object Reference Not set to an instance of an object" error, and the right click GUI menus on ALL parts stopped working. I read that this can by caused by corruption of KSP files, so I reinstalled the game fresh, and reinstalled the mods. Same issue. 

I have noted that I can use the right click GUIs on other parts (including other SSTU parts, such as the MFT-S) before the MFT-A is added, and can reset this issue by leaving the VAB and returning.  
It occurs in both the VAB and SPH.

The MFT-S, MFT-D, and MFT-L have no issues and function normally. 

I have not experienced this bug with any other circumstance than adding and right-clicking the SSTU MFT-A.

Thanks!

Mods Folder

KSP Log

Output Log

 

[StickyScissors]

Well, it works, but KSP's (still) poo landing gear code makes it slippy, springy and generally unstable on the surface, and it's crap phys-warp handling drops the frames to ~10 after phys-warping. 12 parts, Intel i7-7700 / GTX-1080 -.-

-

Edit: 

 

Edited September 17, 2017 by StickyScissors

[Shadowmage]

59 minutes ago, Pigzippa47 said:

@Shadowmage

I recently got back into KSP and updated a few of my old mods to play in 1.3 (I'd been limping in 1.3 in the Spring and got fed up with mods being all out of date). In particular, I installed the current workaround of Infernal Robotics 2.0.12, removing Active Struts and Struts folders and adding a new IRSurfaceSampler.dll. 

KSP x32 crashes upon loading my savegame, so I haven't been using it. 

In KSP x64:

I noticed that when I added a MFT-A to my craft, it threw a "NullReferenceException: Object Reference Not set to an instance of an object" error, and the right click GUI menus on ALL parts stopped working. I read that this can by caused by corruption of KSP files, so I reinstalled the game fresh, and reinstalled the mods. Same issue. 

I have noted that I can use the right click GUIs on other parts (including other SSTU parts, such as the MFT-S) before the MFT-A is added, and can reset this issue by leaving the VAB and returning.  
It occurs in both the VAB and SPH.

The MFT-S, MFT-D, and MFT-L have no issues and function normally. 

I have not experienced this bug with any other circumstance than adding and right-clicking the SSTU MFT-A.

Thanks!

Mods Folder

KSP Log

Output Log

 

From the KSP.log file:

[ERR 12:13:12.016] Module SSTUVolumeContainer threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at SSTUTools.SSTUModInterop.onPartKISInventoryVolumeChanged (.Part part, Single liters) [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUVolumeContainer.updateKISVolume () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUVolumeContainer.updateTankResources () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUVolumeContainer.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 

It looks like the KIS interaction code is currently broken.  Likely something has changed in KIS in the ~9mo since that code has been looked at.

Your options are to

1. Try removing KIS or,
2. Remove the SSTU-KIS integration patch (GameData/SSTU/ModIntegration/KIS/SSTU-KIS-Integration.cfg)

Either of those should stop the null-ref from occurring, which is what is causing the fuel tank code to stop working.

I would also suggest filing a bug report on the github issue tracker so that the problem can be fixed.  Include a link to the log file, and any other details you can think of that might help duplicate the problem during testing.

[Shadowmage]

19 hours ago, StickyScissors said:

Well, it works, but KSP's (still) poo landing gear code makes it slippy, springy and generally unstable on the surface, and it's crap phys-warp handling drops the frames to ~10 after phys-warping. 12 parts, Intel i7-7700 / GTX-1080 -.-

-

Edit:

 

 

Re: Landing legs -- if you know what mod those legs are from, I can add them to the list of mods/parts that need converted to use KSPWheel.  It doesn't do any of that weird crap that the stock wheels/legs do.  And yes, they do very weird crap, especially the landing legs (I've had them tip over a widely stanced perfectly vertically landed craft, sitting on one of minmus' flats).

Re: The 2n'd image -- that is a problem with Scatterrer's ocean-rendering routines.  Anytime you hyper-edit (or stock set orbit tool) yourself away from the space-center, you have to go into the scatterer menu and hit the 'rebuild ocean data' button.  Or change scenes properly.

 

General development update:

Spent most of the weekend doing heat-shield/re-entry testing.  Hours and hours and more hours of it.  And then a few more hours of it.  The good news is that I think it is nearly done.  Have a couple more parts/scenario combinations to test, but compared to the 60+ scenarios already tested, the last few should be easy (as long as no more balance changes are needed).  (yes, that is 60+ distinct setups that needed tests ran on them, each taking ~3-5 minutes, and having to redo all of them after every single minor balance change)

SC-V (VA) parts are nearly/mostly finished.  Probably could be released except for needing to finish all the heat-shield re-balance stuff first.  It works well, and the balance all sits about where I had intended it to.  VA+TKS provides ~650m/s and once decoupled the SM provides ~200m/s for de-orbit.  In its default configuration, it should be usable for Mun/Minmus return missions (with a proper upper-stage to deliver it to mun/minmus).  Drogue chutes are contained in the SM, main chutes in the VA capsule itself (SM should be jettisoned as the main chutes are deployed; SM will continue its descent with the drogues and be recoverable as well).

Late last week (friday) I was able to do a bit of work on the upper-stage SRBs.  Models are unwrapped and reduced to unique geometry, need to finish the UV layout and start working on textures.  Hope to be able to have these available within a couple of weeks, but no guarantees -- still a bit that needs to be figured out on the plugin/code end of things regarding the integrated RCS (seems to be working, but needs lots more testing).

Also spent a bit of time working on some of the mod integration patches.  Trying to get things cleaned up so that I can start up a new career game here in a few days/weeks (mostly waiting for 1.3.1 to be released).  Starting by working through MKS to remove FS and GC dependencies, and rework to use SSTU-VolumeContainer for resources and EPL for construction (and converting any usable fuel tanks to be a single-part MFT setup).  Next will be a pass over all of the SSTU parts for USI-LS balance/integration (and second balance pass for StationCore parts for mass/resources/etc).

Finally, spent a bit of time working on the conversion patches for KSPWheel -- converting all of the stock (and other mods') wheels/legs/gear to use the KSPWheel system.  So far, so good; stock is mostly done from the original testing setup work, needs to have speed/load/dust added/updated.  Put together some quick patches for the wheels for the WBI-Buffallo rover, which are working extremely well, though still need a bit of touch-up work (motor gearing/max-rpm, default steering curve setups).  Will be slowly working on finishing up the stock-conversion patches and adding patches for other mods' wheels and legs as I find time.

 

If all goes well I should have an updated release later this week / weekend that contains the heat-shield rebalance pass as well as the updated / finished SC-V parts.  Have a few other small issues/bugs on the tracker that I'll try to get fixed up for that release as well -- so if anyone has any issues to report, please do so now so that they have a chance of being fixed for the next release.

[Pappystein]

@Shadowmage

Not really an issue so REAL LOW priority.  But the DOS station parts endcaps do not have a complete set of matching "default" texture types/styles to the base body.  If this is as intended COOL.  If not I will create an issue in the Hub.   I ended up with a pretty DOS core part for my refueling station but the Top 5x Node was unable to match the central body.   It ended up looking awesome with the color adjustments you have given us but I wanted to make certain it was mentioned.

I am using 0.6.36.139

 

 

Also I am not certain if the following is an Issue with SSTU,  My MM file or Kopernicious.   I have resized your DP-1P docking port to a 0.9375m size for Various other parts (Agena or Apollo being two keys units for this.)   The Parachutes don't deploy on Granus (Galileo Solar System) until I am at 200m... That is with a deployment set to 1200m.   I have included my entire resize MM for the 0.9375m port.

Spoiler

+PART[SSTU-SC-GEN-DP-1P]:NEEDS[SSTU]:AFTER[SSTU]
{
@name = SSTU-SC-GEN-DP05P
@title = SC-GEN-DP05P
@rescaleFactor = 0.75
// @node_stack_top =    0,  0.06597, 0, 0,  1, 0, 2
// @node_stack_bottom = 0, -0.0375,    0, 0, -1, 0, 2
// @node_attach =       0, -0.0375,    0, 0, -1, 0
@manufacturer = Pafftek Enterprises in conjunction with SSTU
@description = Developed for the Agena and similarly sized craft, the DP-05P docking port fills your 0.9375m needs to perfection.
@mass = 0.0657
@cost = 980
@techRequired = heavierRocketry
}

 

 

[Shadowmage]

14 minutes ago, Pappystein said:

Not really an issue so REAL LOW priority.  But the DOS station parts endcaps do not have a complete set of matching "default" texture types/styles to the base body.

Could you be more specific on which end-caps / adapters you are referring to?   And what texture set(s) you think are missing that should be there?  (think I'm up to ~60+ adapters, and hundreds/thousands of adapter-times-texture set combos, so need to know exactly what I should be looking at)

(And if it is just that the 'defaults' aren't setup.... that is because the defaults are specified for each model, and not for each use of that model in each part; so they have a single 'default' texture set that is used regardless of what part the model is used in; some of that behavior can be overridden, but not all)

 

16 minutes ago, Pappystein said:

Also I am not certain if the following is an Issue with SSTU,  My MM file or Kopernicious.   I have resized your DP-1P docking port to a 0.9375m size for Various other parts (Agena or Apollo being two keys units for this.)   The Parachutes don't deploy on Granus (Galileo Solar System) until I am at 200m... That is with a deployment set to 1200m.   I have included my entire resize MM for the 0.9375m port.

The parachutes have a 'min atmosphere density' specification in their configs.  The atmosphere has to be at least that dense before the chutes will deploy.

What exactly is the Granus planet/moon, and how dense is its atmosphere?

From the config files for the docking ports / parachutes:

	mainMinAtm = 0.01

That line specifies that the atmosphere must be at least 0.01 (somethings) before the chute will deploy.  The value is taken from part.atmDensity, but I'm not sure what units it is in (kPa, standard atmospheres, ??).

[Pappystein]

1 minute ago, Shadowmage said:

Could you be more specific on which end-caps / adapters you are referring to?   And what texture set(s) you think are missing that should be there?  (think I'm up to ~60+ adapters, and hundreds/thousands of adapter-times-texture set combos, so need to know exactly what I should be looking at)

(And if it is just that the 'defaults' aren't setup.... that is because the defaults are specified for each model, and not for each use of that model in each part; so they have a single 'default' texture set that is used regardless of what part the model is used in; some of that behavior can be overridden, but not all)

 

 

I am loading my KSP build right now (takes 5 minutes to load with all the mods for Galileo...  But a Fun system to play in!)   I will run through.   and create a spreadsheet.

 

3 minutes ago, Shadowmage said:

What exactly is the Granus planet/moon, and how dense is its atmosphere?

 

Sorry I screwed up.. Gael is the planets name and is the Kerbin equivalent in Galileo.   I will run a couple tests with the Barometric Atmosphere sensor since I don't know where to dig it out of the myriad of CFGs for Koperenicus/Galileo.

I also Forgot to mention I am running Realchute.

Per the Sensor 100kPa at SL.  down to 45kPa at 5000m   RealChute derived parachute modules are deploying at correct altitudes (pressure 0.1 for pre-deployment and full deployment at 700m)

 

[Pappystein]

RE Textures on Station parts:  Please disregard my previous query.  I have found exactly ONE missing texture... And I don't think it was intended to be on the adapters anyway.   The ST-B texture that is on the cores of the stations does not extend to the adapters.

[Shadowmage]

1 hour ago, Pappystein said:

I also Forgot to mention I am running Realchute.

RealChute shouldn't touch the SSTU parachutes, as far as I'm aware.  Nor should it have any impact on their functionality.  FAR should also work jut fine with the chutes, just in case you are using that.

 

1 hour ago, Pappystein said:

Per the Sensor 100kPa at SL.  down to 45kPa at 5000m   RealChute derived parachute modules are deploying at correct altitudes (pressure 0.1 for pre-deployment and full deployment at 700m)

Looking through the code, the parachutes are using density to determine if it is safe to open (whereas the kPa measures air pressure).  I believe this value is specified in kg-per-cubic-meter, and I think should be roughly ~1.225kg/m3 at sea level (Earth, Kerbin, other properly setup earth-like worlds).

Hmm.. there might be something in the stock debug tools that will let you view the current air density for the vessel -- probably under the stock debug menu -> aero -> view aero debug GUI.  I'll try to take a look at this tonight to see if I can locate where that information might be found in the stock tools.

-- do the parachutes open at a higher altitude if you set the opening-altitude higher (higher than 1200) in the GUI, or are they simply limited to ~200m and below in your current setup?  Does setting the 'mainMinDensity' to a super-low value allow them to open at a higher altitude (e.g. set it to 0.00001 and see if anything changes)?

 

1 hour ago, Pappystein said:

The ST-B texture that is on the cores of the stations does not extend to the adapters.

Indeed, that is a texture set intended to be specific to the StationCore parts, hence the ST- prefix.  You should be able to get fairly equivalent texture setups on the adapters by selecting one of the non-cloth texture sets and then using the recoloring GUI to match up the colors.  I'll admit that the texture / recoloring system isn't perfect (neither in function nor in config/setup)... but it is also way more customization than you will get with most other mods.

[StickyScissors]

7 hours ago, Shadowmage said:

Re: Landing legs -- if you know what mod those legs are from, I can add them to the list of mods/parts that need converted to use KSPWheel.  It doesn't do any of that weird crap that the stock wheels/legs do.  And yes, they do very weird crap, especially the landing legs (I've had them tip over a widely stanced perfectly vertically landed craft, sitting on one of minmus' flats).

Re: The 2n'd image -- that is a problem with Scatterrer's ocean-rendering routines.  Anytime you hyper-edit (or stock set orbit tool) yourself away from the space-center, you have to go into the scatterer menu and hit the 'rebuild ocean data' button.  Or change scenes properly.

That particular mod would be KRE. Great mod but, yeah, stock wheel code: 

 

[Pappystein]

4 hours ago, Shadowmage said:

RealChute shouldn't touch the SSTU parachutes, as far as I'm aware.  Nor should it have any impact on their functionality.  FAR should also work jut fine with the chutes, just in case you are using that.

 

Looking through the code, the parachutes are using density to determine if it is safe to open (whereas the kPa measures air pressure).  I believe this value is specified in kg-per-cubic-meter, and I think should be roughly ~1.225kg/m3 at sea level (Earth, Kerbin, other properly setup earth-like worlds).

Hmm.. there might be something in the stock debug tools that will let you view the current air density for the vessel -- probably under the stock debug menu -> aero -> view aero debug GUI.  I'll try to take a look at this tonight to see if I can locate where that information might be found in the stock tools.

-- do the parachutes open at a higher altitude if you set the opening-altitude higher (higher than 1200) in the GUI, or are they simply limited to ~200m and below in your current setup?  Does setting the 'mainMinDensity' to a super-low value allow them to open at a higher altitude (e.g. set it to 0.00001 and see if anything changes)?

 

Indeed, that is a texture set intended to be specific to the StationCore parts, hence the ST- prefix.  You should be able to get fairly equivalent texture setups on the adapters by selecting one of the non-cloth texture sets and then using the recoloring GUI to match up the colors.  I'll admit that the texture / recoloring system isn't perfect (neither in function nor in config/setup)... but it is also way more customization than you will get with most other mods.

First thanks for the quick and detailed replies.

I ran 3 tests. 

Test 1) BDB Apollo Blk-IV. MM created DP-05P of 0.9375m Diameter.   Single Deploy altitude in the right click menu (more on this in a bit).....    No mater what altitude I set it to, UNLESS I click Deploy BEFORE that altitude... I get a deployment starting around 200m.  

Test 2) SC-V VA capsule on TKS.   (I needed to try this out since I haven't played with it yet.)   inbuilt Dockingports have 2x deployment altitudes showing on the SC-V and 1x on the TKS...   I discovered something... tragic here.  The Chutes deploy over about 8 seconds..... 8 x220m/s = ~4000m traveled....   

https://imgur.com/a/Se5yM

Test 3)  Final test...   BDB Apollo Blk-IV with MM created DP-05P of 0.9375m again.  This time setting deploy altitude to 5500m (Max allowed).

 

Well you can see the results in the Imgur library.  The Chute is deciding the speed is unsafe and not deploying.    Cause is not my MM file as I initially surmised but the fact that SSTU built in ports have both a Drogue and a main chute whiles the add on ports only have the mains...   Add the fact that the BDB Apollo has less intrinsic drag than the SSTU Apollo.....   Yep 100% not an issue.

So I did Test 4 before posting....   Same Atlas V launch vehicle... Launching the SC-B Apollo capsule.   Interesting... On a rocket that could only get the SSTU SC-V to 453km and the BDB Apollo to 1.1Mm....  The SC-B went past escape velocity.   Judicous use of the Hyperedit Thrust adjustment tool.... and I am ALMOST escape velocity....   Landed safely 28 days after launch.

Sorry for raising this @Shadowmage  Maybe I should play KSP more often so I can not make these....fun... mistakes.

 

NOTE:  The only reason the SSTU VA and Apollo capsules did not burn up was because of the drogue chutes....   I attached the 0.9375m docking port to both and they both crashed.  This was in my sandbox game so I just reverted

My Solution.... Add 4 Air-breaks to any capsule I am trying to land with the docking port serving as a parachute module.

 

 

 

 

Edited September 19, 2017 by Pappystein
Broken Imgur link

[Nightside]

@Shadowmage, Some Feedback on Station Core:

I have been playing a lot with the DOS parts & I would suggest 100-150% of real life mass (~17-20 tons for DOS, not sure on COS). 

Getting these beasts to orbit should not be easy I changed them in my game and it out that in a 3.2x Kerbin, the  Proton Rocket from Tantares puts a DOS module into a perfect orbit with just enough dV to circularize. 

I haven't played with them much but I would say the same about the modular satellites. They should least 1-2 tons.

thanks again !

@Pappystein, are you are landing on a different planet? You might need to use more 'chutes or deploy sooner than you would on Kerbin.

[Pappystein]

Nightshade,

It is Gael which is the home planet if you use the Galileo mod.   It is analogous to Kerbin in most respects (it is arid vs lush for example.)

 

I have not had issues with any other parachutes which is why I brought up my unfounded concern.

 

Edited September 19, 2017 by Pappystein

[Shadowmage]

New upper-stage SRB nozzles (and one lower-stage 4-nozzle) that are in the works, models courtesy of @blowfish  

These will likely become a new part, and will have slightly higher ISP than the lower-stage SRBs.  Will include the use of vertical scaling of the body segments to allow for more precise control over length (and thus thrust/burn-time).  Two of the single-nozzle variants will include RCS ports for roll control.  Bit more work to do before they'll be in-game, and of course still need textures / masks created.  Should at least have prototypes available for the next release, possibly textures.

 

1 hour ago, Pappystein said:

Well you can see the results in the Imgur library.  The Chute is deciding the speed is unsafe and not deploying.    Cause is not my MM file as I initially surmised but the fact that SSTU built in ports have both a Drogue and a main chute whiles the add on ports only have the mains...   Add the fact that the BDB Apollo has less intrinsic drag than the SSTU Apollo.....   Yep 100% not an issue.

There are three settings that control when a chute is safe to deploy or not --

• Has to be below a certain dynamic pressure (so it doesn't get shredded by aero forces, this is mostly governed by speed)
• Has to be above a specific air density (so there is enough air to spool it out and deploy it, this is determined by altitude)
• Has to be below a certain temperature (so it doesn't burn up, this is a combination of speed/density)

I should also add that all of those settings can be tweaked in the config for the parachute module, and separately for the main and drogue chutes.

Additionally, and this is the really neat thing about the module, you can add a drogue parachute to those parts simply through config edits/additions.  No need for modeling, animations, etc...  If that is something you are interested in learning more about, let me know and I can work on putting together some examples for you.  You can actually use the module to add parachutes to -any- part through config edits/patches.  Fun stuff...  (also supports alternate models and textures)

Yes, the chutes take a bit of time to deploy (also configurable); this is to limit instantaneous g-forces from deployment or transition from semi-deployed to full-deployed.  They move from packed towards semi-deployed at the specified 'deploy alt' in the GUI, over the config-specified number of seconds.  At 75% of the target altitude, they will start moving to the full-deployed state over the config-specified time.

 

2 hours ago, StickyScissors said:

That particular mod would be KRE. Great mod but, yeah, stock wheel code

Good to know, have added it to the list of mods to make wheel/leg patches for   (which you will be able to find through KerbalFoundries in the near future)

[Mike`]

- i should refresh the page before replying to an outdated post :s

Edited September 19, 2017 by Mike`

[Serkanamore]

Hey,

I love your mod but I have one idea/suggestion. In my opinion the option to make the tanks lightwight is kind of op, because you you always could get lots more Delta V by just pressing a button.

Of course it's just useful in the first stage and in a upperstage with fuel which doesn't boil off. To bring realism the tank could be made out of carbon fiber? Than the fuel tank would be more expensive (20% more?)

Thank you!

[Shadowmage]

14 minutes ago, Serkanamore said:

Hey,

I love your mod but I have one idea/suggestion. In my opinion the option to make the tanks lightwight is kind of op, because you you always could get lots more Delta V by just pressing a button.

Of course it's just useful in the first stage and in a upperstage with fuel which doesn't boil off. To bring realism the tank could be made out of carbon fiber? Than the fuel tank would be more expensive (20% more?)

Thank you!

You bring up good points regarding the tank cost -- currently I adjust heat tolerance(lower), impact tolerance (lower), and boiloff (higher) for the 'lightweight' tanks, but they should probably come with an increase in cost as well.  They are also intended to be unlocked through something in the tech-tree, so that you have to pay to 'research' them before they can be used (not yet implemented, but should be relatively soon).

[Shadowmage]

Hmm...  (Yes, that is an SRB)

[tater]

LOL

[StarStreak2109]

3 hours ago, Shadowmage said:

Hmm...  (Yes, that is an SRB)

Looks like a PAM.

[Shadowmage]

19 hours ago, StarStreak2109 said:

Looks like a PAM.

Pretty much

 

Few more random upper-stage SRB samples from testing today (nozzle textures unfinished, but probably won't have much more added either):

 

[StarStreak2109]

4 hours ago, Shadowmage said:

Pretty much

 

Few more random upper-stage SRB samples from testing today (nozzle textures unfinished, but probably won't have much more added either):

 

Just what the doctor ordered! One small request: can you make it so that the lower stage SRBs can be stacked? Right now, it is only possible to use one SRB as first stage, but not as second (eg like in a Vega rocket). Thanks.

[Shadowmage]

6 hours ago, StarStreak2109 said:

Just what the doctor ordered! One small request: can you make it so that the lower stage SRBs can be stacked? Right now, it is only possible to use one SRB as first stage, but not as second (eg like in a Vega rocket). Thanks.

Noted -- all of these new nozzles will have lower attach nodes (and also fairings...).  Will also consider adding them to the existing lower-stage nozzles; no real reason not to have them.  As a bonus, a few adapters that previously lacked attach nodes will now have them as well (some of the domes and nosecones).

[StarStreak2109]

Great, looking forward to building solid fuel launchers.

[Pappystein]

14 hours ago, StarStreak2109 said:

Just what the doctor ordered! One small request: can you make it so that the lower stage SRBs can be stacked? Right now, it is only possible to use one SRB as first stage, but not as second (eg like in a Vega rocket). Thanks.

Err... Um Vega was to fly with a JPL 6K Hypergolic upper stage and an ATLAS-E lower stage... Where for are you finding Solid rockets    Seriously why do countries re-use other countries rocket names?!

 

Whats next, the replacement for SLS in 2055 is Soyuz? 

 

Ok ON Topic now.  Shadowmage those SRB upper stages are awesome.  Are they going to have any way to cut thrust?   In real life Man rated SRMs have an explosive charge that shatters the upper portion of the rocket to neutralize thrust and almost immediately blow out the explosive fire within the SRM.   The ALMOST part is why Saturn IN16 (between 2 and 7 UA-1205/1206/1207s under a Saturn IVB upper stage,) was a non starter.    I BELIEVE that Upper stages have a similar device built into them (else precise orbital positioning would not be possible due to any fluctuation in lower portions of the flight.

 

http://www.astronautix.com/s/saturnint-16.html 

On 9/18/2017 at 10:34 PM, Shadowmage said:

 -- those parts simply through config edits/additions.  No need for modeling, animations, etc...  If that is something you are interested in learning more about, let me know and I can work on putting together some examples for you.  You can actually use the module to add parachutes to -any- part through config edits/patches.  Fun stuff...  (also supports alternate models and textures)

Yes, the chutes take a bit of time to deploy (also configurable); this is to limit instantaneous g-forces from deployment or transition from semi-deployed to full-deployed.  They move from packed towards semi-deployed at the specified 'deploy alt' in the GUI, over the config-specified number of seconds.  At 75% of the target altitude, they will start moving to the full-deployed state over the config-specified time.

 

Is it more involved than just cutting and pasting the Drogue chute data and tweaking it to my particular MM files?  Either way I am sure such a document would be useful to myself or others.  I really love the DP-1P family of ports but I have objects of other sizes so the ability to make my own ports to work the way I want is very VERY nice!

 

Thanks

In

Advance (TIA!)

Edited September 21, 2017 by Pappystein
Never finished my first actual question :)