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

[tater]

Older version of SSTU:

I've been using 365 (3.2X planet size, 6.4X distances, stock parts).

Coming in from 6.4 distance Minmus, I could a couple versions ago directly reenter with ablation set to ~650, I explode even from LKO at 450 in that version. This is the SC-A CM. The SC-C, OTOH (I tested last night) I upped the max to 325 I think, and it started overheating with ablator still left. I have hyper edit installed for testing stuff, I'd be happy to post some 3.2X kerbin reentry stuff for you, if you like, though with the ablator settings you have (balanced for stock) none will survive munar reentry as you have them...

I suppose I could test with the ablator set to 500, 550, 600, 650 etc, and let you know what happens.

If you have some 3.2X testing (kerbin atmosphere ends at ~81km in this), let me know if I can help. I can make a copy of KSP with sigma and try a different scale if that would help you as well. Let me know.

Edited March 11, 2016 by tater

[tater]

WOW, OK, I forgot that I was messing not with the latest test build, my bad. Now on the latest build.

Made a copy of my 365 with nothing but KJR and SSTU (latest from github), KER, etc (I had SMURFF before as well which I dumped).

SC-A from bare LKO (82km) with periapsis set to 20km blows up at 62 km with ablation set to 450

Set to 600, the pod makes it to almost 58km.

Set to 750, it makes it to 55km.

So yeah, upping ablation short of changing it to a few thousand isn't going to help any more, it needs a new solution for scaled systems.

 

Edited March 11, 2016 by tater

[blowfish]

@tater You're going to have the same problem for stock parts.  Just reduce re-entry heating in the difficulty settings.  It's much simpler than trying to change the settings on many parts.

[tater]

4 minutes ago, blowfish said:

@tater You're going to have the same problem for stock parts.  Just reduce re-entry heating in the difficulty settings.  It's much simpler than trying to change the settings on many parts.

I had been using stock parts with SMURFF, and had no difficulty with default reentry heat as the stock 2.5m heat shield has 800 ablation (overkill). In previous SSTU versions, all I needed was slightly higher ablator values. Setting reentry heat lower globally means that the stock shields are even more grossly overpowered. I want entry parameters to matter, ideally.

Edited March 11, 2016 by tater

[Shadowmage]

5 minutes ago, tater said:

WOW, OK, I forgot that I was messing not with the latest test build, my bad. Now on the latest build.

Made a copy of my 365 with nothing but KJR and SSTU (latest from github), KER, etc (I had SMURFF before as well which I dumped).

SC-A from bare LKO (82km) with periapsis set to 20km blows up at 62 km with ablation set to 450

Set to 600, the pod makes it to almost 58km.

Set to 750, it makes it to 55km.

So yeah, upping ablation short of changing it to a few thousand isn't going to help any more, it needs a new solution for scaled systems.

 

 

Aye, you need to rescale the ablationEfficiency value and the heatCurve floatCurve in the SSTUHeatShield module.

Alternatively, in the next release (tonight/tomorrow) there is a slightly simplified scale method using 'ablationMult' and 'fluxMult' parameters in the module.  It should be simple to patch these two values to increase the heat-shield stats for other system scales.  No clue exactly what values would be needed, but should be doable with a simple short patch (should even be able to do a blanket patch to all parts using SSTUHeatShield with the same scale values... if I've done the rest properly).

[Shadowmage]

2 minutes ago, tater said:

I had been using stock parts with SMURFF, and had no difficulty with default reentry heat as the stock 2.5m heat shield has 800 ablation (overkill). In previous SSTU versions, all I needed was slightly higher ablator values. Setting reentry heat lower globally means that the stock shields are even more grossly overpowered. I want entry parameters to matter, ideally.

Indeed -- I want re-entry parameters to matter as well -- which is why I've gone with a careful balance for the intended use on the pods.  They require specific re-entry corridors, or you'll have problems.

If all you have to do for -any- atmospheric heating is slap a generic heat-shield on it... why not just up the part masses and turn off heating entirely?  The end result would be the same.

This is partially caused by stock, only having a single type of heat shield for each size; generic by nature.  Their solution literally is 'just slap a generic heat shield on it'... which to me has never made much sense (it is just extra part count with no function at that point; might as well just add the mass and turn heating off).

It is precisely that which I'm trying to avoid.  This will matter even more if/when I add the modular-heat shield module to the pods (a heavy heat-shield has more dry-mass than a light one, so choosing the proper one for your mission can result in a more efficient rocket/design).

[tater]

This is again 365 (no SMURFF) with The SC-A-CMX with a stock 2.5 heat shield on the bottom reenters fine from bare LKO with 140 ablator left. 

From the Mun (~5800 m/s) it (SC-A-CMX with a STOCK heat shield) actually survives with 464 remaining (same periapsis, but it doesn't dwell as long in the atmosphere, hence not as extreme, in stock it's all about dwell time).

The SC-A-CM as is, with ablation set to 675 reenters from the Mun just fine. The pod overheats to near destruction with hundreds of ablation left, and ends up safe with 99 ablator left.

So right now, current build, upping ablator totally works. I was only seeing the problem with an incredibly shallow entry (82,000m circular to a 20,000m periapsis). A steeper entry might well work fine from LKO. (my testing was to set bare LKO in hyper edit, then reenter using the RCS to move periapsis. I did the same from munar orbit distance).

Edited March 11, 2016 by tater

[Shadowmage]

12 minutes ago, tater said:

This is again 365 (no SMURFF) with The SC-A-CMX with a stock 2.5 heat shield on the bottom reenters fine from bare LKO with 140 ablator left. 

From the Mun (~5800 m/s) it (SC-A-CMX with a STOCK heat shield) actually survives with 464 remaining (same periapsis, but it doesn't dwell as long in the atmosphere, hence not as extreme, in stock it's all about dwell time).

The SC-A-CM as is, with ablation set to 675 reenters from the Mun just fine. The pod overheats to near destruction with hundreds of ablation left, and ends up safe with 99 ablator left.

So right now, current build, upping ablator totally works. I was only seeing the problem with an incredibly shallow entry (82,000m circular to a 20,000m periapsis). A steeper entry might well work fine from LKO. (my testing was to set bare LKO in hyper edit, then reenter using the RCS to move periapsis. I did the same from munar orbit distance).

Apparently I need to fine tune it a bit more then; -- it shouldn't just 'nearly overheat', but 'overheat and explode terrifically!' when subject to that kind of heat load.  So... don't expect that to continue working (upping ablator amount).  (edit: yes, if the heat load is too great it should explode with tons of ablator left -- amount of ablator is -not- the sole determining factor in heat-shield performance; it shouldn't even be a factor aside from length of ability to dwell at a certain heat-load)

Use the two parameters that I've stated numerous times (ablationEfficiency and heatCurve).

 

Edit:  https://en.wikipedia.org/wiki/Atmospheric_entry#Entry_vehicle_design_considerations

Stock accounts for only the 'heat load' part of re-entry heating (their heat shields appear to be indestructible from instant-heat-flux, and infinitely just use more ablator when subject to more heat).  I am however accounting for both peak heat flux, and duration heat load in the design of my heat-shields.

Edited March 11, 2016 by Shadowmage

[tater]

Yeah, I figured since I already had the patch to up the maxablator to 750 for the SC-A-CM, I might as well test it for you. I tried a steep reentry with your SC-A-CM as-is (450), and it made it to 34km (82km circular start, braked to a -600,000 km periapsis).

I can mess with the other values as suggested, clearly, but then the stock heat shields will be unaffected. If you add a procedural shield, then that will be fine, as I can build Duna or Eve lander shields using that (vs sticking a stock one on and knowing it is magically bulletproof).

Edited March 11, 2016 by tater

[tater]

Question about the tanks. In sandbox they work fine, but in career testing (Engineering Tech Tree) they are not able to change diameter to 3.75m even though I have unlocked a couple of those stock tanks.

Presumably it will end up like PP where the tank sizes are tied to the tree.

[Shadowmage]

4 minutes ago, tater said:

Question about the tanks. In sandbox they work fine, but in career testing (Engineering Tech Tree) they are not able to change diameter to 3.75m even though I have unlocked a couple of those stock tanks.

Presumably it will end up like PP where the tank sizes are tied to the tree.

Well.. that means the tech limits are working   Perhaps not setup properly/fully configured, but at least working.

LargeVolumeContainment is needed to unlock 3.75m diam for all custom/procedural parts.  Alternatively 'veryHeavyRocketry' should give you the unlock for up to 10m.

Will be adding a second/third/fourth alternate node to unlock 3.75m while I'm doing the career balance pass (during 1.1 update). 2.5m already has alternate nodes; will likely also add the full 10m unlock to one or two more end-tree nodes.

[tater]

Gotcha, and again, I'm using ETT, so I was surprised it worked at all

[RedParadize]

About the bug I listed before, it seem that the last version works just fine. So thanks for that, (unless the problem was on my end, sorry if it was)

About scale 6.4x and heat: I can go with reducing heat ingame. At this point its not realy a issue since I don't use that much stuff that is not SSTU for re-entry.
 

Edit: oh and the "engine spacing" bar jump from -0.2 to -0.6. No -0.55 -0.50 etc.

Edit2:  model = SSTU/Assets/SC-GEN-LG-B  missing from FSX.
 

Thanks for all that great stuff!

 

Edited March 12, 2016 by RedParadize

[Shadowmage]

3 hours ago, RedParadize said:

About the bug I listed before, it seem that the last version works just fine. So thanks for that, (unless the problem was on my end, sorry if it was)

About scale 6.4x and heat: I can go with reducing heat ingame. At this point its not realy a issue since I don't use that much stuff that is not SSTU for re-entry.
 

Edit: oh and the "engine spacing" bar jump from -0.2 to -0.6. No -0.55 -0.50 etc.

Edit2:  model = SSTU/Assets/SC-GEN-LG-B  missing from FSX.
 

Thanks for all that great stuff!

 

Engine mass - noted and fixed;

FSX missing landing-gear model - noted and fixed.

Engine-spacing - noted and... not sure what is going on with that one, but I'll look into it   (https://github.com/shadowmage45/SSTULabs/issues/259)

 

Should have a reasonable method to do heat-rescaling with the next release;  might also have a resizable/modular heat-shield part.  It is...working... but needs a lot of testing and tuning / balancing to get it all working properly with the rescaling and multiple types.

[RedParadize]

2 hours ago, Shadowmage said:

Engine mass - noted and fixed;

FSX missing landing-gear model - noted and fixed.

Engine-spacing - noted and... not sure what is going on with that one, but I'll look into it   (https://github.com/shadowmage45/SSTULabs/issues/259)

 

Should have a reasonable method to do heat-rescaling with the next release;  might also have a resizable/modular heat-shield part.  It is...working... but needs a lot of testing and tuning / balancing to get it all working properly with the rescaling and multiple types.

Thanks you allot! If you want me to test the rescaling, I am up for it. I am using the 64x, But I will have to double check if I didn't tweak it.

Reading what I previously posted, I fear that the "Thanks for all that great stuff! " right after the bug list could be misinterpreted as sarcastic. It was not. Just to clarify...  And I should stop editing my post. I erased the engine mass issue from the last one. 

Edited March 12, 2016 by RedParadize

[Jimbodiah]

Would it be possible to have some make-shift clusters for the Merlin and H1? I kind of miss using them.  Also the, AJ10-190 does not have clustering, don't know if this was intentional?

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.29-pre12

Lots more fixes, updates, and balancing.

Will likely have another release tomorrow with the ModularHeatShield part in it... if I can get the scaling cleaned up

[Sudragon]

Part Suggestion: Scaleable in-line SAS ring. 

[Jimbodiah]

Euhm, use stock parts with tweak scale?

But I'm guessing this will be the modular SM that Mage was planning on?

Edited March 13, 2016 by Jimbodiah

[drtedastro]

@Shadowmage: Wow, I have been away for awhile and have just downloaded and started working with your latest version on github.

Very, very nice.  I have been working with these from the start and you are doing a great job.  Really nice mod.

Always looking forward to seeing what you come up with / do next.

I should be able to get back into more testing now.

Wheeeeeeeee.

Cheers.

 

Also, if anyone has ANY craft files for this, I would appreciate being able to use those as a starting point.  This mod has grown so much, so fast that I am afraid that I am basically lost with all of the changes and permutations.

Thanks again, cheers.

 

Edited March 13, 2016 by drtedastro
Need info

[ComatoseJedi]

I -think- I'm looking at a bug with the Shuttle's IVA placement where it places the cockpit in the rear of the cargo bay -again-. While it starts out normally in place, when you start switching views from IVA to the outside and back, it resets the placement. Now, before I go any further with this and fully test this out, I am using the ASET MK3 cockpit in place of the shuttle IVA that comes with the mod. Reason being, I am testing out the Canadarm mod VIA RPM computer screen cameras. The ASET MK3 IVA has large screens to facilitate full use of the camera's view and only accommodates 6 kerbals. I'm not sure if the number of occupants and/or IVA selection has anything to do with this, but this is what I use when I use so an STS.  

I'm not sure if this has a lot to do with it, but in my *flawed* logic, it shouldn't matter what you put in that slot for the IVA, the model node is there to accept the IVA coding that points it to the interior space designated in the config files. I am wondering if me changing the IVA model to another one has anything to do with this? I will continue to test with both IVAs to see if I get the same results. If the problem persists, I'll submit a full ticket on Git with pics/logs. 

[Shadowmage]

On Saturday, March 12, 2016 at 5:46 PM, Sudragon said:

Part Suggestion: Scaleable in-line SAS ring. 

See the comments on the Github ticket;  in short:  not likely.

 

On Saturday, March 12, 2016 at 6:15 PM, Jimbodiah said:

Euhm, use stock parts with tweak scale?

But I'm guessing this will be the modular SM that Mage was planning on?

If at all, yes, they would be as part of the service modules.  Magic-ship-turning-rings they will not be.

 

18 hours ago, drtedastro said:

@Shadowmage: Wow, I have been away for awhile and have just downloaded and started working with your latest version on github.

Very, very nice.  I have been working with these from the start and you are doing a great job.  Really nice mod.

Always looking forward to seeing what you come up with / do next.

I should be able to get back into more testing now.

Wheeeeeeeee.

Cheers.

 

Also, if anyone has ANY craft files for this, I would appreciate being able to use those as a starting point.  This mod has grown so much, so fast that I am afraid that I am basically lost with all of the changes and permutations.

Thanks again, cheers.

 

Thanks   Yep, mod is constantly changing/growing/evolving.  Getting a few things to a good state though, so some areas should start settling down soon

Craft files -- likely not until after 1.1. is release and the mod fully updated; still far too much stuff in flux and changing / not finished / not finalized.  And of course, little/nothing has had balancing done yet, which will be needed before any craft files can be made or released.

 

11 hours ago, ComatoseJedi said:

I -think- I'm looking at a bug with the Shuttle's IVA placement where it places the cockpit in the rear of the cargo bay -again-. While it starts out normally in place, when you start switching views from IVA to the outside and back, it resets the placement. Now, before I go any further with this and fully test this out, I am using the ASET MK3 cockpit in place of the shuttle IVA that comes with the mod. Reason being, I am testing out the Canadarm mod VIA RPM computer screen cameras. The ASET MK3 IVA has large screens to facilitate full use of the camera's view and only accommodates 6 kerbals. I'm not sure if the number of occupants and/or IVA selection has anything to do with this, but this is what I use when I use so an STS.  

I'm not sure if this has a lot to do with it, but in my *flawed* logic, it shouldn't matter what you put in that slot for the IVA, the model node is there to accept the IVA coding that points it to the interior space designated in the config files. I am wondering if me changing the IVA model to another one has anything to do with this? I will continue to test with both IVAs to see if I get the same results. If the problem persists, I'll submit a full ticket on Git with pics/logs. 

If you are using a different IVA.cfg file you will need to patch/update its position (e.g. if you patched the SC-E-FS to use a the ASET iva).  If you are just patching the main model in the SC-E-IVA to use a different model, you will also need to patch it to update its position.

In short - the method I used to 'fix' the stock IVA is not very well supported, and is going to require custom hand-work in order to get other IVAs setup for it.  Your assumption is incorrect -- the positions of the parts within the IVA are defined in the iva config and -not- in the part config (and it is the positions in the iva config I had to patch).  So, if you put a different IVA in place for the part.cfg, you will -also- need to update the positions of the models (and props) -in- that IVA .cfg file.

 

 

 

Got the modular heat-shield part mostly working yesterday.  At least it functions the same for a given type of shield regardless of the size.  So a 'light' 1.25m performs the same as a 'light' 10m -- they will experience the same heat load, same external heat, same relative flux input/output, and burn through their ablator at the same (relative) rate (both will run out simultaneously).

Currently have defined the following types (each with their own mass, resource amount, and heat-peak curves):

Light - intended for LKO (~350km) re-entries.  Not needed for many parts/craft, and mostly only necessary for protecting sensitive bits (science stuff).

Medium - intended for Mum/Minmus/Duna return.  Should be capable of direct-to-ground capture when returning from any of those bodies.

Heavy - intended for return from further origins, or aerobraking through Jool.  Tested for a 10.75km/s pass through Jool @ 170km periapsis, resulting in capture (highly eliptical) with ~50% ablator remaining, plenty for a second/third less-energetic pass.

Extra-Heavy - same heat-load capability as Heavy, but double the amount of ablator; should be used for multiple passes through Jool/Laythe, or when a single heat shield needs to perform both Jool capture and Kerbin return aerobraking passes.

Have not yet tested any of them at Eve, but I would expect the Heavy/Extra-Heavy varieties to be needed. 

I lowered the max-part temp on them, and cut the heat-curve down to maintain them at a lower temp.  This results in much more logical setup for the part... where they -will- explode if they run out of ablator.

Also have them set up in a very easily scalable manner -- simply patch two values in the part config to rescale them all for a different heat load (solar system rescales or stock-heating increase).  Still unsure what scale values would be needed as I don't use system-rescale mods... but the code-side support is there for it.

 

During all of that investigation (staring at re-entries for the past two days...), I also ran across the reasoning for the pod-integrated heat shields' odd performance, and have a few ideas on how to clean those up as well (higher area and skin thermal mass than they should have).

 

Still needs at least a few more days worth of testing and balance; though I'll consider packing them up tonight and letting some of you guys do that testing

 

[Jimbodiah]

Cool!!!!

[Shadowmage]

Laid-out and unwrapped the H-1 this morning (and AO bake):

Edit: Updated image with first-pass texturing (diff/norm/spec; no noise, and barely any detail work so far)

Reference for coloring:

 

With luck I'll get it about half-textured today, and get a preliminary export of it tonight with the basic texturing.

Edit:  Probably won't get too much more done on the texture today, but at least it will have a basic tex for exporting the model / setting it all up in KSP.  Will keep poking at the texture throughout the week, possibly starting on the RD-0110 geometry later on in the week.

 

On Friday, March 11, 2016 at 9:02 AM, Jimbodiah said:

Would it be possible to have some make-shift clusters for the Merlin and H1? I kind of miss using them.  Also the, AJ10-190 does not have clustering, don't know if this was intentional?

I won't be making cluster configs for the WIP engines until the final geometry is done -- far too much time investment to setup the spacing when it would just need to be redone for the new geometry (not to mention breaking all the craft using those parts due to the geometry/size changes).

Edit:  AJ10-190 -- will look into some cluster configs for it.  Who knows, maybe someone wants to cluster them up for a lander or something?  Heh

Edited March 14, 2016 by Shadowmage

[Shadowmage]

And, on a future-looking note:

Just about time to start deciding what external mods will be the defaults as far as resource and production-chain compatibility goes.  This will not really matter for a simple stock+SSTU install (as stock doesn't have any production chains aside from Ore->ISRU->Stock Fuels), however it will be quite important for interaction with MKS / Life-Support / EPL.  This will also determine what resource-switch options are present for the default setups for the various (not-yet-available) shipping-container styled MFTs (and the lander-core cargo containers).  Yes, the reason they only hold Ore right now is because that is the only stock non-fuel resource.  No other resources = no other resource switch options.

Been quite awhile since I've played around with any of them, but last I did, there was pretty much two very different setups as far as resources were concerned -- the EPL production chain, and the MKS production chain.  Apparently there is now a third option...some warehouse/workshop mod? (OKE or something?.... yah, I'm a bit out of touch with the current state of affairs for much of this stuff)

I'm personally leaning towards the MKS resource chain, as that opens up easy integration with the MKS/OKS habitation and life-support system (at least on a plugin/module basis, even if I may design custom parts for many uses); while still maintaining a working interface with EPL (as MKS changes around the recipes/etc).

I don't want to turn this into a discussion on which is better/more realistic/easier/harder/whatever -- merely inquiring about preferences?

Whichever direction I take won't be the end-of the road -- as usual my plugins and parts should be easily patchable/adaptable to whichever system the end-user wants to use (though may require some effort on their end to accomplish).