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

[vossiewulf]

FYI, unless I'm missing something, and I often am, neither the Variant nor Scale buttons on the DP-0 do anything.

[Shadowmage]

1 hour ago, vossiewulf said:

In short if I had an expanding heat shield part, it would be my default heat shield particularly if it came with all of SSTU's other useful configuration options

Lets figure it out then

Certainly I can SSTU-ify a part, if we can come up with a functional model.

30 minutes ago, vossiewulf said:

FYI, unless I'm missing something, and I often am, neither the Variant nor Scale buttons on the DP-0 do anything.

Try radially/surface attaching it to the side of a round tank, where it is not sitting flush.

The variant is a 'backplate' or tube structure -- so you don't need extra parts just for a flush mounting.  The 'scale' applies only to the backplate.

[vossiewulf]

1 hour ago, Shadowmage said:

Lets figure it out then

Certainly I can SSTU-ify a part, if we can come up with a functional model.

Great! As mentioned, I think now it could be done relatively simply by using rectangular petals with a tongue (as in tongue and groove) that, once the petals are folded down, extends out of one side of each petal and into a groove on the next petal. Or they extend from both sides to meet each other. Some greeble and it looks like a fancy part that took years to design. For visual interest and a little more aerobraking you could fiddle around with the outside edge of the petals, adding a slight point to each one so the heat shield edge isn't perfectly round. Thinking about it a bit, I think it should expand maybe 20% of the stack core diameter, but petal length (and therefore expansion ratio) would be very nice as a dynamic parameter.

Will definitely fill a glaring parts gap if you can make this work

 

[Shadowmage]

4 minutes ago, vossiewulf said:

Great! As mentioned, I think now it could be done relatively simply by using rectangular petals with a tongue (as in tongue and groove) that, once the petals are folded down, extends out of one side of each petal and into a groove on the next petal.

Hmm... I have an idea    Will try and mock it up when next I have some modeling time.  Should be relatively simple, if I grasp what you are getting at regarding overall concept (probably not, but gotta start somewhere).

[vossiewulf]

Here's how reentry goes riding in on the engines

 

 

[Starwaster]

@vossiewulf Even without the Deadly Reentry icon in your tray, there's just something about a spacecraft bathed in the reddish orange glow of reentry that brings a smile to my face first thing in the morning with a cup of coffee in my hand!

JNSQ Kerbin reentries are on average going to be a bit ... toastier than over stock Kerbin btw.

[Shadowmage]

@vossiewulf

Here is the concept that I quickly mocked up for a stowable heat shield.  Three 'layers' of 'leaves' which fold down.  The outermost layer is a simple hinge, while the inner layers would require a hinge+strut.

stowed:

deploying:

deployed:

 

I guess I'm curious if this is the same kind of part you had envisioned?  (mostly I'm wondering how something like this would help with your situation; how would you mount a heat-shield below the engines without it interfering with their normal operation?)

[Starwaster]

16 minutes ago, Shadowmage said:

I guess I'm curious if this is the same kind of part you had envisioned?  (mostly I'm wondering how something like this would help with your situation; how would you mount a heat-shield below the engines without it interfering with their normal operation?)

Shielded covers or doors 

[danshu15]

ah something similar to this mod

 

what I tried to do for stage recovery was hide a heatshield internally, so it has 100% ablator remaining to trick stage recovery into working - recovery failed and I didn't actually get a message from stage recovery at all. Ship just poofed lol

[Shadowmage]

2 minutes ago, danshu15 said:

ah something similar to this mod

LoL, apparently yeah, quite similar in regards to deployment mechanism.  Apparently I'm not the first to think up that kind of setup

1 hour ago, Starwaster said:

Shielded covers or doors 

Yeah... not doable in a 'generic stowable heat-shield' type part.  That would require per-engine heat-shield models... that also somehow adjusted to the users selected cluster layout and all of the procedural settings available there.

Although, if I were to actually engineer such a design, that is likely how I would do it.  There would be a standard heat-shield with holes in it for each engines exhaust, and engines would have small'ish cover-plates that moved into position during heat-shield deployment that filled in the holes in the heat shield.

[vossiewulf]

2 hours ago, Shadowmage said:

I guess I'm curious if this is the same kind of part you had envisioned?  (mostly I'm wondering how something like this would help with your situation; how would you mount a heat-shield below the engines without it interfering with their normal operation?)

Yes, similar, although I was thinking one layer of petals that were narrower, and when then fold down they then get wider to fill the gaps. Yours is just another way to do it, but same concept. If you make it a stack decoupler also, that would be perfect. Thanks very much for taking a cut at it

You don't mount the heat shield on the bottom, you mount it at the top, and the booster section goes in head first. Which is why the extra diameter is particularly important, it's required to keep the hot plasma from getting anywhere near the skin of the tank. Try to do that with a stack-sized heat shield, and the whole thing blows up. Besides the shield, each would get its own probe core and reaction wheels, and parachutes of course.

[Shadowmage]

Just now, vossiewulf said:

You don't mount the heat shield on the bottom, you mount it at the top, and the booster section goes in head first.

Ahh, yep, that makes sense, and would be usable with a part like this.

I'll toy around with the concept a bit more in-depth now that I've confirmed we're thinking of the same thing.  The bashup earlier for the examples was very crude and not intended for further development, just showing the concept.  Unless you wanted to take a crack at the modeling?

Fair warning -- even if I start work on this now, it will likely be a few weeks before it will be available and usable.  Few other WIP projects consuming large portions of my time that I want to wrap up or get to the next phase (fixes for TU, finishing KF texture conversions + balance, custom TU patch set for stock), and then would need to take the time to actually develop this new part (or part(s) most likely).  Likely only take ~1 week for this part once it gets to the top of the queue, perhaps a bit more depending on the complexity of the models and if any variants are created.  Texturing should be simple enough / fast enough, and of course we can add recoloring if desired.  Might require some minor additions to the plugin code to facilitate interaction of the heat-shield module with an animation module (e.g. heat shield code only active while deployed), but that should only be a few minor edits.

[vossiewulf]

40 minutes ago, Shadowmage said:

I'll toy around with the concept a bit more in-depth now that I've confirmed we're thinking of the same thing.  The bashup earlier for the examples was very crude and not intended for further development, just showing the concept.  Unless you wanted to take a crack at the modeling?

If I can stop building giant space stations everywhere for five minutes, yes I could open MAX and take a cut. And of course you have existing priorities, I'm just happy it's maybe in the queue somewhere, so no rush.

Seriously, I think I'm losing control of these, the one I'm building now has a crew of 209, with USI/LS supplies for almost two years and hab time of almost 1yr/crew. And one gig EC solar without any of the 8 reactors running. I had to design a 7.5m orbital bus that will carry around 50 to make crew transfer even vaguely possible.

Anyway, toward SSTU's stated primary goal, the heat shield should have a probe core, and doing so makes it literally a one-stop shop for all your heat shield needs, from bringing down giant booster sections safely to protecting all your surface-attached hardware on pod reentries. With, of course, the drawback that with its own probe core, internal mechanism, and bigger size compared to other stack size-specific heat shields, it should be somewhat heavier, deeper, and the petals will take up some surface attach real estate. No such thing as a free lunch.

I'm not suggesting adding parachutes as they'd only be applicable to booster recoveries and there is too wide a range of required parachute power to practically fit them also within the heat shield.

But you could also move another step towards SSTU's goal by SSTUifying a couple parachute parts, one stack and one radial mounted. They'd be selectable for drogue/landing, single/triple, canopy size, and number of canopy units, and support a wide range of canopy sizes with the largest being insanely big. You could add diameter increases and other option additions to the tech tree like you do with tanks/probe cores.

The first three params would affect the mass/size of each parachute unit. The last parameter would instance any number of units, like you do with some of the tanks where you can instance 1/2/3 round tanks. When set to say four parachute units, the multiple instances would look like four separate radial parachutes, but actually be just one part. And I'm sure you'd insist on doing something groovy like having a choice to instance them vertically or horizontally or curved to follow a stack circumference, etc.

If you could do that, two parachute parts total would be all anyone ever needed to handle everything from teeny probe recovery to battleship-sized booster recovery.

 

[Shadowmage]

3 hours ago, vossiewulf said:

the heat shield should have a probe core

I can't agree with the general use-case of that.  90% of the time I want a heat-shield, I already have a probe core.  You could easily patch it in yourself though, if desired, or patch yourself a second version with probe core.

Edit:  It could include decouplers for both ends, with optional staging, and optional jettison-able shroud/fairing surrounding the stowed petals.  Can't think of too many other features I would want in a heat-shield of this design.

3 hours ago, vossiewulf said:

With, of course, the drawback that with its own probe core, internal mechanism, and bigger size compared to other stack size-specific heat shields, it should be somewhat heavier, deeper, and the petals will take up some surface attach real estate. No such thing as a free lunch.

Pretty much all of that, yes.

3 hours ago, vossiewulf said:

But you could also move another step towards SSTU's goal by SSTUifying a couple parachute parts, one stack and one radial mounted. They'd be selectable for drogue/landing, single/triple, canopy size, and number of canopy units, and support a wide range of canopy sizes with the largest being insanely big. You could add diameter increases and other option additions to the tech tree like you do with tanks/probe cores.

Funny you mention that, as the module was written with a good deal of that functionality in mind.  All of the parachutes are already positioned and scaled by the plugin code, so it really just needs some minor adaptation to include scaling of a base model, and all the fiddly UI bits for scaling and parameter setup, and their backend code.

What has stopped me is that it is really only useful in a stack-mount setup for part-count reduction, and I rarely use stack-mounted parachutes.  There is no way to reduce part count for radially attached parachutes =\  (I guess you could provide larger ones through scaling, reducing duplicate-part-spam a bit for larger designs).

Perhaps something to think on and further develop.

Edited July 24, 2019 by Shadowmage

[vossiewulf]

1 hour ago, Shadowmage said:

There is no way to reduce part count for radially attached parachutes =\  (I guess you could provide larger ones through scaling, reducing duplicate-part-spam a bit for larger designs).

Not understanding this. I'm going to put one radial-mounted parachute, one part. Instead, I place one part but it appears (and functionally there is) four radial parachutes in a vertical line or horizontally or in a square shape. Still one part, but now I get the same visual and functional result as I would have if I'd put four separate parts on.

For bigger vehicles I frequently find myself doing exactly that, putting on 20 parachutes in five rows of four parachutes. Instead, you could reduce that to four parts total. As I said, last param would be number of (in this case) radial parachute units you want to place, in our example you set it to five, go to the rocket, set radial symmetry to four, place your part and the end result looks like you placed 20 separate parachutes with one click. It would sure reduce the parts count on my rockets, being someone who tries to recover most everything.

And usually when I do this, I don't mind the size of the parachute part, as I move them just under the skin of the vehicle. I say to myself that a booster designed to be recovered wouldn't have parachutes bolted on all over, they'd be incorporated into the tank top or base, and the important thing is I'm carrying the extra mass. It would be perfect if the tank got a little longer as a result. 

Well, that's something else you could do also. Add parachute recovery capability to the Magic Fuel Tank - have a button for "include 5m/s parachutes" or something like that, and then calculate the number and size needed based on the player's volume setting, then increase the mass appropriately and the length somewhat to account for the space needed for the chutes. Include the normal chute settings on the tank's context menu, and then you have to have the right number and size and type of parachutes to come out of the base of the stack at the right time. If you did that, including an option to have drogue chutes as well as landing chutes would help, plus an option to have the parachutes come out of the top or base of the stack, both can be needed.

Well. except you'd have to make wild guesses as to the stage mass, unless you performed the configuration of the number of chutes needed at runtime after accessing the stage dry mass. But not sure KSP allows modification of basic parameters like that after leaving the VAB.

 

Edited July 24, 2019 by vossiewulf

[Shadowmage]

10 hours ago, vossiewulf said:

Not understanding this.

Best explained through images I think.

When you place a part as you suggest, faking cloning of radial parts, you have one real part (in red), and some clones (in blue), around a cylinder (wireframe).  KSP sees these as one part (the white disc) for drag purposes, and has one joint (on the red node).  So far, so good.

Now, lets add some aero force and see what happens.  Add a few kN of drag to each of the parachutes at their attach position, and the parts will end up looking like this:

Okay, so the 'fake' parachutes all get pushed out of position due to KSP's joint mechanics.  Perhaps not the end of the world for most parts to be offset a little bit? 

Except for KSPs 'drag cubes'.  Now the drag-cube system sees an inclined plate intersecting the part, which it dutifully calculates drag for in its inclined angle, and you might as well have put a wing or control surface there for all it cares.  The result is that now you have some odd drag going on throwing your rocket all over the place. 

This happens even during ascent with the parachutes stowed, simply by the nature of the 'one attach joint, on the side of the part' and the 'disc' created by the drag cube system.  Drag pushes on disc, disc rotates around its attach joint (red node), and inclines the other direction; the result is you again have an inclined plane intersecting your rocket, throwing good aero design out the window.

 

I know.  I've done this for parts in the past.  There is a reason I'm not doing it now

In order for it to work you would need to somehow offset the part-joint into the center of the parent part.  Which is not directly supported by KSP, and would require someone with knowledge of KSPs internals and their use of joints in order to fix.

[vossiewulf]

Sigh. I swear that somewhere in the universe is a guy whose only job is to make interesting things arbitrarily difficult. I really want to kick that guy's ass.

[Shadowmage]

7 minutes ago, vossiewulf said:

Sigh. I swear that somewhere in the universe is a guy whose only job is to make interesting things arbitrarily difficult. I really want to kick that guy's ass.

Most of the time that guy is me.  Today though... someone at SQUAD can have the finger pointed at them

[vossiewulf]

What's up here? I set it to 6.25 (and clicked a couple more times trying to make it bigger) and then was just clicking around through the fuel and variant options, and it collapsed into a singularity. With the standard tank variant, it's about as long as it is wide.

[vossiewulf]

9 hours ago, Shadowmage said:

Okay, so the 'fake' parachutes all get pushed out of position due to KSP's joint mechanics.  Perhaps not the end of the world for most parts to be offset a little bit? 

One thing though, I actually wasn't suggesting placing the fake clones radially as that would be hard to do, but rather placing them all at the click spot, like you'd placed four radial parachutes right next to each other, and if you wanted to clone that around a stack, you'd allow the game to do that. Therefore all of the fakes should provide at most a very small moment arm, and if you place them vertically one below the other, there'd be no torque. Or has the jerk who complicates things figured out a way to screw that up too?

[Shadowmage]

23 minutes ago, vossiewulf said:

Or has the jerk who complicates things figured out a way to screw that up too? 

Again, drag cubes and joint-mechanics would be wonky.  Similar to the oddities seen with the RBDC part in this use case, so perhaps not entirely unworkable.  That part has a bit of character at times, but works well for the most part.  Hmm... see below

25 minutes ago, vossiewulf said:

but rather placing them all at the click spot, like you'd placed four radial parachutes right next to each other

I think more easily accomplished by just scaling a single central 'base' model, and adjusting the # of parachute caps it spawns would accomplish the same effect, with less hacking-around-ksp-code altogether.  Perhaps allow for a 'modular' type model setup, and switch between longer and longer models as the # of caps increase (for either vertical or horizontal orientations), as well as providing a general 'model scale' option, and separate main/drogue chute configuration capabilities.

That ^^ I could see doing at some point.  Useful for part-reduction; configurable; mostly works fine with KSP 'physics'.

[Shadowmage]

2 hours ago, vossiewulf said:

What's up here? I set it to 6.25 (and clicked a couple more times trying to make it bigger) and then was just clicking around through the fuel and variant options, and it collapsed into a singularity. With the standard tank variant, it's about as long as it is wide.

You clicked the 'variant' slider onto 'sphere'.

Fallout of the dynamic model system, and the desire to allow for single-sphere fuel tanks.  Try clicking the 'core' option to the right one time, to select the sphere-1 core, and then selecting the sphere upper and lower options.

The default is a '0-length' core (undesired as a default, but also unconfigurable), which is present so that you can use a sphere top-cap, and a sphere bottom-cap, and end up with just a single sphere fuel tank, without providing it as an entirely separate part.

Ideally I would have the ability to define the 'default adapters' when changing between variants... but I built a bit too much auto-generated dynamic configuration into the system, and haven't found the 'gentle' way to coerce it allow specifying that without breaking other things.

[vossiewulf]

2 minutes ago, Shadowmage said:

I think more easily accomplished by just scaling a single central 'base' model, and adjusting the # of parachute caps it spawns would accomplish the same effect, with less hacking-around-ksp-code altogether.  Perhaps allow for a 'modular' type model setup, and switch between longer and longer models as the # of caps increase (for either vertical or horizontal orientations), as well as providing a general 'model scale' option, and separate main/drogue chute configuration capabilities.

That ^^ I could see doing at some point.  Useful for part-reduction; configurable; mostly works fine with KSP 'physics'

Yeah, that's certainly fine also, I suggested spawning whole units as I thought that would be easier. But if you had a model with compartments for each canopy unit, you just make the overall model shape longer/wider by the number of compartments, and you could make the number of canopies it represents easy to see by drawing the compartment hatches on the front or with other markings to divide up the rendered model into units.

So a stack version would be easy, but you could make it even more useful if, when specifying the number of canopy units, it gave you the option to make the parachute container longer or increase its diameter. Both would be useful.

So that's all figured out now  Hopefully they will go on the roadmap somewhere also.

[vossiewulf]

Just now, Shadowmage said:

You clicked the 'variant' slider onto 'sphere'.

Fallout of the dynamic model system, and the desire to allow for single-sphere fuel tanks.  Try clicking the 'core' option to the right one time, to select the sphere-1 core, and then selecting the sphere upper and lower options.

The default is a '0-length' core (undesired as a default, but also unconfigurable), which is present so that you can use a sphere top-cap, and a sphere bottom-cap, and end up with just a single sphere fuel tank, without providing it as an entirely separate part.

Ideally I would have the ability to define the 'default adapters' when changing between variants... but I built a bit too much auto-generated dynamic configuration into the system, and haven't found the 'gentle' way to coerce it allow specifying that without breaking other things.

Ah, thanks. I thought I had clicked around and it was staying small, which is why I asked. I will go try again.

[Starwaster]

2 hours ago, vossiewulf said:

What's up here? I set it to 6.25 (and clicked a couple more times trying to make it bigger) and then was just clicking around through the fuel and variant options, and it collapsed into a singularity. With the standard tank variant, it's about as long as it is wide.

It's possible to put a round dome type on that (I think I used the top slider) and get yourself a flying saucery looking thing. Not sure how useful that is but it looked neat.