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

[Pappystein]

7 hours ago, DECQ said:

Are you kidding? What is the decrease in the number of parts if the person interested in the engines, but it will have all of his unwanted barrels of fuel, this decrease the number of parts?

Actually it is more the point that if I want to mount say 9 RD-180s under say an 8m diameter central tank, I will have a much lower part count.   Since with SSTU we can have multiple engines in ONE part (including a dizzying number of fairings!)  True this does not greatly reduce the number of polygons but it greatly reduces the number of parts the game has to track.

[Akira_R]

@Shadowmage I have couple of hopefully small feature requests.

First would it be possible to expose a diameterIncrement variable in the part cfg for the SSTUNodeFairing module? Currently we can set the diameter increment for engine mounts, which is fantastic and I have set mine down to 0.3125, however the auto-fairings that are generated on these engines do not have as fine of an adjustment range (I am assuming this is handled by the SSTUNodeFairing module).

Second for the interstage decouplers would it be possible to add an adjustment for "extra height"? Currently we can adjust the height of the decoupler which also adjusts where the attachment node is, the extra height slider would have the same effect on the model, making the height of the shroud higher, but leave the attachment node untouched. This would be very useful for nesting upper stages or other things down into the interstage, this can be partially accomplished with the stock offset tool however the offset tool has significant limitations, specifically when you try to move the center of mass of the attached part down below where the attachment node is, the attached part gets forced off to the side and can't be moved back to center.

The change to the SSTUNodeFairing module would almost not be needed if the extra height feature could be added to the interstage decoupler as one would be able to simply disable the fairing on the engine and use the interstage decoupler as a fairing when there are odd ratios between the upper stage and lower stage diameters.

[Shadowmage]

51 minutes ago, Akira_R said:

@Shadowmage I have couple of hopefully small feature requests.

First would it be possible to expose a diameterIncrement variable in the part cfg for the SSTUNodeFairing module? Currently we can set the diameter increment for engine mounts, which is fantastic and I have set mine down to 0.3125, however the auto-fairings that are generated on these engines do not have as fine of an adjustment range (I am assuming this is handled by the SSTUNodeFairing module).

Second for the interstage decouplers would it be possible to add an adjustment for "extra height"? Currently we can adjust the height of the decoupler which also adjusts where the attachment node is, the extra height slider would have the same effect on the model, making the height of the shroud higher, but leave the attachment node untouched. This would be very useful for nesting upper stages or other things down into the interstage, this can be partially accomplished with the stock offset tool however the offset tool has significant limitations, specifically when you try to move the center of mass of the attached part down below where the attachment node is, the attached part gets forced off to the side and can't be moved back to center.

The change to the SSTUNodeFairing module would almost not be needed if the extra height feature could be added to the interstage decoupler as one would be able to simply disable the fairing on the engine and use the interstage decoupler as a fairing when there are odd ratios between the upper stage and lower stage diameters.

Increments are already adjustable through config for SSTUNodeFairing:

        /// <summary>
        /// Increment to be used when adjusting top radius
        /// </summary>
        [KSPField]
        public float topDiameterIncrement = 0.625f;

        /// <summary>
        /// Increment to be used when adjusting bottom radius
        /// </summary>
        [KSPField]
        public float bottomDiameterIncrement = 0.625f;

 

Interstage Decoupler extra height -- no, sorry.  It would take substantial amounts of code changes in order to add that in, and it would be far less precise than the stock offset tool.  The stock offset tool should be sufficient for this, is exactly what it is intended for.  If it is having problems, try holding SHIFT while using it (that should disable the limits and snapping stuff -- if that doesn't work, regenerate your KSP settings/config files, as legacy settings from pre 1.2.x prevent it from working).  I'm willing to consider looking into it if it can be proved that there is a good reason why the stock offset tool does not work.

[Akira_R]

1 hour ago, Shadowmage said:

Increments are already adjustable through config for SSTUNodeFairing:

        /// <summary>
        /// Increment to be used when adjusting top radius
        /// </summary>
        [KSPField]
        public float topDiameterIncrement = 0.625f;

        /// <summary>
        /// Increment to be used when adjusting bottom radius
        /// </summary>
        [KSPField]
        public float bottomDiameterIncrement = 0.625f;

 

Interstage Decoupler extra height -- no, sorry.  It would take substantial amounts of code changes in order to add that in, and it would be far less precise than the stock offset tool.  The stock offset tool should be sufficient for this, is exactly what it is intended for.  If it is having problems, try holding SHIFT while using it (that should disable the limits and snapping stuff -- if that doesn't work, regenerate your KSP settings/config files, as legacy settings from pre 1.2.x prevent it from working).  I'm willing to consider looking into it if it can be proved that there is a good reason why the stock offset tool does not work.

Where can I find the config for SSTUNodeFairing? Clearly I'm blind or something because I can't find a .cfg or .xml file for that 

I wasn't aware of holding down SHIFT, I will give that a try, it's a fresh 1.2.2 install so there shouldn't be any legacy settings in there but if I'm still experiencing problems with it I will try deleting the settings file, thank you.

 

EDIT: Oooohhhh derp, took a look at the source and realize now that I need to add the topDiameterIncrement and bottomDiameterIncrement nodes to the part cfgs, thank you Shadowmage

Edited February 26, 2017 by Akira_R

[StickyScissors]

There seems to be an issue with engine clusters and Stage Recovery TWR calculations. 

I am currently working on a recoverable rocket with 8 first stage engines, which should be plenty of thrust to bring the stage down safely. However, SR is calculating that the thrust of the 8-engine cluster is...less than the thrust of just one engine. However, using 1 engine in 8x symmetry, SR gets the calculation right and recovers the stage.

[pilot009]

Great mod, I love it! Thanks!

Sorry if I missed it somewhere but I looked around a lot... 

I cannot configure options for ladder, solar panels, etc on the lander tanks. 

On KSP 1.2.2 64 bit, latest SSTU release.

Cheers

UPDATE: Found the answer finally, maybe revise the mod description and take out that feature? Thanks again for the great mod

Edited February 26, 2017 by pilot009
Found answer

[Shadowmage]

16 hours ago, StickyScissors said:

There seems to be an issue with engine clusters and Stage Recovery TWR calculations. 

I am currently working on a recoverable rocket with 8 first stage engines, which should be plenty of thrust to bring the stage down safely. However, SR is calculating that the thrust of the 8-engine cluster is...less than the thrust of just one engine. However, using 1 engine in 8x symmetry, SR gets the calculation right and recovers the stage.

Nothing that I can do to fix that one, you'll need to file a bug with SR.  The problem is that he is using the thrust values from the protomodule and/or prefab module, neither of which will be correct in the case of SSTU engine clusters.  The only way he will get the actual thrust from those engines will be get the thrust values from the live engine modules while the vessel is active, and cache those for later use.

https://github.com/magico13/StageRecovery/blob/master/StageRecovery/RecoveryItem.cs#L245-L254
https://github.com/magico13/StageRecovery/blob/master/StageRecovery/RecoveryItem.cs#L278-L287

I would wager that there are problems with that code with RO / RealFuels / ModuleEngineConfigs / TweakScale setups as well..  Really, anything that manipulates engine thrust at runtime will cause that method to fail.

Sadly, I'm not sure if there is any other way around it.  At the point where SR does its recovery there is no means available to fully load the entire vessel, and it is only when the entire thing is fully loaded that the engine modules will have their proper thrust.

 

13 hours ago, pilot009 said:

Great mod, I love it! Thanks!

Sorry if I missed it somewhere but I looked around a lot... 

I cannot configure options for ladder, solar panels, etc on the lander tanks. 

On KSP 1.2.2 64 bit, latest SSTU release.

Cheers

UPDATE: Found the answer finally, maybe revise the mod description and take out that feature? Thanks again for the great mod

Noted, and updated.  Sadly yeah, that stuff was broken and removed in the 1.05->1.1.x updates (when all of the wheels broke).

Hoping to start working on a refresh of those parts and the entire LanderCore system before too long.

[StickyScissors]

7 hours ago, Shadowmage said:

Nothing that I can do to fix that one, you'll need to file a bug with SR.  The problem is that he is using the thrust values from the protomodule and/or prefab module, neither of which will be correct in the case of SSTU engine clusters.  The only way he will get the actual thrust from those engines will be get the thrust values from the live engine modules while the vessel is active, and cache those for later use.

-

Hoping to start working on a refresh of those parts and the entire LanderCore system before too long.

I figured that was an SR issue. This whole reuse thing is turning out to be more trouble than it's worth, especially with already cheap launches.

Also, glad to see that the lander parts are gonna get a refresh. Hopefully the wheel magic you and others have been working on will make it less of a headache

-

Edit: Holy krap, now i'm remembering why i pretty much quit KSP. The stock legs/wheels are atrocious. If i even -think- about touching down on a planet, let alone coming in too fast and exploding, my game hemorrhages NRE's like nobody's business. I sure hope you can get it right, because Squad sure as hell hasn't.

Edited February 27, 2017 by StickyScissors

[MaxZhao]

Been looking at Github issues and I saw that FAR compatibility issue was fixed, if so the description should be updated?

 

By the way it makes me want to cry to see mod developers caring about people who play KSP with potatoes like I do, thanks so much for the mod!

[Shadowmage]

On 2/26/2017 at 1:05 PM, StickyScissors said:

Also, glad to see that the lander parts are gonna get a refresh. Hopefully the wheel magic you and others have been working on will make it less of a headache

 

Yeah, still a little ways out (month or two before I can start working on it), but it is the next planned 'big thing' to do. 

Probably safe to start the discussions and planning on it.  Going to be two main lines of 'landers'.  Vertical (the stuff that is available now, with some minor reworking), and Horizontal (all new stuff).

The first is the classic vertical lander setup, much as is available now.  Will include the current LC pods (perhaps updated a bit), and a new set of octagonal MFT fuel tanks.  The new tanks will -not- include solar, rtg, legs, etc; the old system for those was a giant collection of hacks, and I have no desire to go down that road again.  Instead I am working on a system of 'pre-built' leg sets that will ship with KF.  The new tanks will likely also be less of a 'bare tank' look and more of an enclosed fuel tank segment; makes it far easier to allow for the length/model adjustments used by the MFT module (still undecided on this, might be able to get bare tanks working).  When the tanks are created I'll also work on creating some octagonal mounts and adapters for them.  One final bit that I'm going to investigate is allowing for standard rigid/animated landing leg setups to be included in the tanks (probably as one of the adapter/end-cap types); these legs, if included, would feature no suspension functions and would be driven to deployment by a standard animation  (WIP support for this kind of a setups is in place for the cargo-bay modules, can likely back-port it to be usable on the MFT modules -- which would also allow for MFT nosecones/adapters that had built in service bays and the like, and possibly other uses not yet considered).

 

The second line of lander parts will be designed for horizontal lander creation.  It will likely be a bit of a mashup between several existing reference designs, and my old SC-C design:

Horizontal lander, with either squashed octagonal or hexagonal main form factor.  Will include segments with built in legs and/or engines/rcs, cargo bay segments, frame-bays, fuel segments, etc.  These parts will likely not include any form of scaling/MFT support, and will be less of a generically usable system.  Still a bit undecided on these -- would like for them to have a wider range of compatibility with other mods, but I'm unaware of any other mods using similar form-factors for fuselage parts.

 

Edited February 27, 2017 by Shadowmage

[rasta013]

There are some wide bodies in B9 and some slightly less wide from OPT Spaceplanes.  Also, Nertea's Mark IV Spaceplane is a design for carrying 3.75m parts.  These are really the only wide body form factors I can think of from other mods...

[RedParadize]

Hi @Shadowmage

I took a long brake from KSP, glad to see your stuff is still improving! KSPWheel is awesome btw, thanks allot.  I was wondering, would it allow a singlepart rover? I am still thinking about the fold-able Munar rover... Anyways, wrong tread.

 

The horizontal lander stuff will be quite challenging to mod I think. I personalty find the NASA design flawed, and it was meant to address challenge that we do not necessarily have in KSP.  Here is my analysis for whats worth. I had a hard time keeping it structured enough to be readable, sorry about my bad english.

 

I believe the lifting aeroshell is the main reason behind NASA design. Mars lack of a real atmosphere kinda prevent semi ballistic decent, not without massive assisted breaking. Slower and controlled decent using lifting surface like the space shuttle do is desirable. Note that SpaceX opted for that too except that do not discard the aeroshell. But I just can't see how they will flip mid-flight something that huge, but that's for another tread... I think that a lifting aeroshell l would be desirable KSP as well. But not for the same reason, the extra mass of the structure and overall package does not justify the fuel saving as most KSP part can go trough Duna entry un-shielded, but there is Laythe... and Eve.

NASA design seem suited to at least some horizontal flight capacity before and after aeroshell separation. So accurate landing should be quite easy. In KSP, it might be even more useful as it is kinda hard to land at a specific location. But to be realistic, the frame would have to be quite heavy to support all that horizontal charge. That's my main critic of NASA design, that and the fact it can only be single use and exclusively a lander. But in KSP it may or may not be a issue and may or may not be used that way.

Another point that undoubtedly influenced NASA is the necessity of unloading allot of equipment. Unloading stuff from a traditional rocket can't be done without some kind of tower. The horizontal frame make it easy, specially for rover. (BTW, SpaceX deceptively left that part out of their presentation) This feature translate really well in KSP. I imagine people might also use it to airlift rover and stuff when traveling long distance. Balancing mass will be quite hard with engines spread like that. There is TCA for that I guess but that's a external dependency. Oh, in NASA design, the horizontal frame is also serve as lunch pad for the ascent vehicle. Not as complicated in KSP, but for destination like Laythe or eve it might be something to think about. 

About the Ascent vehicle, I am highly doubtful that NASA would have reused landing engines as shown on these image. Not after being bombarded by rock during landing and exposed to environment for six month. In KSP its obviously not a problem. The thing to keep in mind is that player may or may not want to do that. And here I will point back at Laythe and Eve, the frame will need to be highly customizable to be able to carry large enough accent vehicle to these destination.

 

Depending on the level of customization, I can see these horizontal lander used for anything from miniature probe to massive Eve lander. I am just a peasant when it come to modding, but it sound kinda hard to mod. I should not worry, to this day SSTU delivered way more than what I expected...

If you have some doubt, I think a alternative design like the Mars Excurtion Module would be quite nice too and would blend well with the rest of SSTU.

 

Just my 2 cents

[Shadowmage]

21 hours ago, MaxZhao said:

Been looking at Github issues and I saw that FAR compatibility issue was fixed, if so the description should be updated?

 

By the way it makes me want to cry to see mod developers caring about people who play KSP with potatoes like I do, thanks so much for the mod!

SSTU + FAR is not 100% compatible -- there are still some voxelization issues on some parts, notably anything with fairings always voxelizes the fairings, even when they are disabled.  Probably a few other problems that I've not seen; though as I don't use FAR, and nobody has submitted any bug-tickets on them, I have no idea what they could be.

 

 

13 hours ago, RedParadize said:

I was wondering, would it allow a singlepart rover? I am still thinking about the fold-able Munar rover...

Yes, absolutely.  Was one of the base design goals for the system - to allow pre-rigged and welded multi-wheel setups.  If you can rig it and animate it, KSPWheels can put wheels on it.

13 hours ago, RedParadize said:

The horizontal lander stuff will be quite challenging to mod I think.

Oh, yeah.  Been down that road once already, and had something...mostly usable  (the old SC-C freighter parts).  The real challenges come in making it broadly compatible with other parts / form-factors.

13 hours ago, RedParadize said:

I believe the lifting aeroshell is the main reason behind NASA design.

Yeah, I've been thinking on that a bit as well.  Not quite sure how I would handle it, if at all.  As you say, they are not really needed for Duna in the stock system.  Could have some use for Eve/Laythe/Kerbin -- the problem is that stock occlusion code is not well suited to non cylindrical setups (there would be no simple way to shield the lander from the airstream properly with half of a fairing)

13 hours ago, RedParadize said:

That's my main critic of NASA design, that and the fact it can only be single use and exclusively a lander.

Why would it be used exclusively as a lander?  My old SC-C parts worked very well for orbital freighters -- just don't put landing legs or landing engines on it.

13 hours ago, RedParadize said:

Another point that undoubtedly influenced NASA is the necessity of unloading allot of equipment.

Yep, this is the main reasoning behind the horizontal lander designs in KSP -- ease of loading/unloading equipment, rovers, base-modules, etc.  Pretty easy to drop things off if they are belly-slung; nearly impossible from a traditional rocket stack. 

Balancing -- tools exist in stock (and mods) to enable load-balancing on horizontal setups -- careful initial craft design combined with thrust limiting (either manual or mod-provided).  I've done lots of horizontal lander designs for landing base components and rovers, many very off-balance, and have never needed anything beyond thrust-limiters and a bit of gimbal range (and/or reaction wheel authority).

 

13 hours ago, RedParadize said:

And here I will point back at Laythe and Eve, the frame will need to be highly customizable to be able to carry large enough accent vehicle to these destination.

Nothing says these would have to be used to carry ascent vehicles -- could just as easily be a disposable cargo lander, airdroping/eggdropping base components or rovers, or even used as some sort of rover themselves.  And nothing is going to be big enough to carry an Eve ascent vehicle, so I'm not too worried about that.  Either way, a frame is just a frame -- what people choose to stuff in it is their own choice.

 

13 hours ago, RedParadize said:

If you have some doubt, I think a alternative design like the Mars Excurtion Module would be quite nice too and would blend well with the rest of SSTU.

Those kind of designs (MEM) are already easily doable with existing parts (the SC-B-CMX or SC-C-CMX work very well as an ascent vehicle; I'll be using one in my career game in the very near future, will post pics when I get that far).  The entire point of these new parts was to enable new design themes that aren't doable with the existing parts -- horizontal landers being the biggest of those.

Anyhow, good to see you around again, and thanks for the info and feedback -- gives me a few things to think on.

[tater]

I too am looking forward to horizontal landing options. I've actually had a lot of difficulty making such designs work in my experiments to date, so any improvement would be awesome.

The 2 top images with MAVs inside would be interesting as models for a way to land something like the inflatables you already have, but designed to be on their sides? I posted some images of a Bigelow concept up the thread, and I could see those landers somehow being the framework.

[Rock3tman_]

4 hours ago, tater said:

I too am looking forward to horizontal landing options. I've actually had a lot of difficulty making such designs work in my experiments to date, so any improvement would be awesome.

The 2 top images with MAVs inside would be interesting as models for a way to land something like the inflatables you already have, but designed to be on their sides? I posted some images of a Bigelow concept up the thread, and I could see those landers somehow being the framework.

I second this. I have wanted to do a Constellation Mars mission forever, but my designs are all complete crap.

[DocRockwell]

Using this mod for the first time, it's a really cool concept and the parts look great!

I'm trying to make a Soyuz/R7 ship but I can't get the diameter of the fuel tank and the RD108 engine to match (see pic). Having a similar issue at the top end too, I selected the Soyuz nose for the top of this fuel tank, but its diameter doesn't match the 3rd stage.

Are there any working ship config files so I can see how others have used the features of this mod to recreate ships? The repository linked in the OP is no more.

Cheers.

 

[Pappystein]

1 minute ago, DocRockwell said:

Using this mod for the first time, it's a really cool concept and the parts look great!

I'm trying to make a Soyuz/R7 ship but I can't get the diameter of the fuel tank and the RD108 engine to match (see pic). Having a similar issue at the top end too, I selected the Soyuz nose for the top of this fuel tank, but its diameter doesn't match the 3rd stage.

Are there any working ship config files so I can see how others have used the features of this mod to recreate ships? The repository linked in the OP is no more.

Cheers.

 

 

I have never built an R-7 Analog with this mod so I don't know if this will help but the Size of the tank is completely variable.  Try dragging the slider to match the engine at the bottom.  Then check if the top matches the 3rd stage.

 

[DocRockwell]

5 minutes ago, Pappystein said:

I have never built an R-7 Analog with this mod so I don't know if this will help but the Size of the tank is completely variable.  Try dragging the slider to match the engine at the bottom.  Then check if the top matches the 3rd stage.

 

Thanks, that did the trick! I didn't know you could drag the slider for fine scale adjustments, I've just been using the buttons. 

[RedParadize]

 

6 hours ago, Shadowmage said:

Why would it be used exclusively as a lander?  My old SC-C parts worked very well for orbital freighters -- just don't put landing legs or landing engines on it.

Just to clarify, that was a critic of real world NASA design, not what you will come up with in KSP universe. I just find Nasa design quite un-efficient and over-engineered. I believe their "newer" ,glorified moon lander design is much better. But that is already covered by SSTU.

Quote

Those kind of designs (MEM) are already easily doable with existing parts (the SC-B-CMX or SC-C-CMX work very well as an ascent vehicle; I'll be using one in my career game in the very near future, will post pics when I get that far).  The entire point of these new parts was to enable new design themes that aren't doable with the existing parts -- horizontal landers being the biggest of those

I agree, but there is two part that would be desirable for a fully SSTU MEM. Jetisonable conformal radial tanks and a holed heatsheild for the decent engine, but there is way around that.

 

I am curious about how you plan to do the aeroshell, Will it be similar to your fairing module or a separated part with adjustable Length, width and height? Either way that sound be really complicated.

And since I slipped on the complicated side, what would be really cool is if a fixed aeroshell version would be possible, with bay doors, trap for legs and hole for engine, it would be like designing your own space shuttle. Obviously, that would be really complicated on a modular/customization standpoint, it would require some kind of boolean subtraction and allot of black magic. Boolean are quite unstable in maya, can't imagine that being possible in unity. 

[Pappystein]

@Shadowmage,  Didn't think I should quote the whole exchange visa-v the Horizontal lander.

1) AWESOME idea to have such a lander (or I guess re-launch being the better description.)

2) I am a huge proponent of lifting bodies and horizontal or angled (not vertical) launch of rockets.   Others mentioned the OPT, B9, and "MkIV" form factors.   To me, all of them get too big too quick IMHO.  Might I suggest if you don't like any of the existing form factors, something that is low and wide similar (but not the same) as the smaller Mk-II fuselage structures.   Something that instead of carrying BIG tanks can carry a bunch of smaller tank sized things in cargo?  

I would LOVE to be able to carry two DOS style station parts up side by side

 

 

     

 

[DocRockwell]

The thrust on the Soyuz service modules is kind of low. It's set to 1.225 kN, whereas this source (http://www.astronautix.com/s/soyuz.html) puts their thrust at 3.92 kN.

[tater]

 

I could have made that art with SSTU screenshots  

[Shadowmage]

16 hours ago, DocRockwell said:

The thrust on the Soyuz service modules is kind of low. It's set to 1.225 kN, whereas this source (http://www.astronautix.com/s/soyuz.html) puts their thrust at 3.92 kN.

I don't remember the exact source that I got the thrust from, but generally I use RealWorldThrust*0.64*0.64 (scaled for nozzle area).  So for 3.92kN, that would be ~1.6kN scaled.  Seems likely that the source I based those parts from had something like ~3kN listed as the base thrust (3*0.64*0.64 = 1.2288).

At some point in the future I intend to revisit and revise all of the ShipCore service-modules to increase their thrust for *sigh* gameplay balance reasons.

[Shadowmage]

19 hours ago, RedParadize said:

I am curious about how you plan to do the aeroshell, Will it be similar to your fairing module or a separated part with adjustable Length, width and height? Either way that sound be really complicated.

Honestly, I don't have any real plans for aeroshells.  They are just not something that KSP can handle very well / at all, at least with any sort of accuracy or reliability.  Partially due to the aero model, and partially due to the 'collection of parts' model.

The problems are:

1.)  Each individual part would need its own custom piece of the aero-shell -- e.g. so that engine-enabled parts have holes for the engines.  Possibly workable, but there would be only a single aero-shell configuration (size, length, whatever) available per part, limiting its general use.  Cannot be done procedurally due to the complexity needed to create procedural meshes (theoretically possible, but I'm not going to do it).
2.)  There is no simple way to link all of those partial aero-shells from the various pieces together (without massive plugin-side-hacking, which would probably cause larger problems in the long run).
3.)  KSP does not support partial part occlusion -- either the entire part is shielded from the airstream, or none of it is.  So your aeroshell would shield the entire part, in which case engines/legs/etc would be unusable.
4.)  If the aeroshell was a separate part(s), there would be no way to configure it for the specific craft design (e.g. holes for engines).

Even if 1 & 2 were to be solved, #3 is still a huge problem that renders them mostly useless.  #3 wouldn't be a problem in FAR, but as I don't use FAR, that is of no help to me.  #4 only applies to aeroshells-as-separate-parts, but is the entirety of why they are not viable. 

Edit:  I'm still going to give them a bit more thought to see if I can come up with a viable method to do both the modeling on them, and how to make them functional in KSP... but I wouldn't get your hopes up.

Edited March 1, 2017 by Shadowmage

[RedParadize]

@Shadowmage

I got a idea that might interest you. kinda of a "divide and conquer" type of solution. I will stay a bit longer at work and do a mockup because I am surely not doing this in paint. I will be happy if it inspire you one way or another.

Edit: I have something that allow 2axis shape change only trough joint scaling, it work in maya at least. I believe it should be transferable to Unity, as for KSP I dont know... I should have something presentable tomorrow, will see.

Edited March 3, 2017 by RedParadize