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

[JoseEduardo]

21 minutes ago, Shadowmage said:

I probably will be going with a 'pod' design for the 1.875m, so likely either VA or a rescaled Apollo/Orion.  No, it won't have a big station butt attached to it, but it will have a special purpose built (1.875m) service module.  Will investigate station uses when I get there (though, will consider it a bit during pod design, as it might influence a few things).  It likely won't have a big reto-motor thing stuck on the front either; that is one of the bits of Gemini/etc that I dislike; so whatever  pod I do, it will -not- have that sort of setup -- it will terminate at a standard docking port, and will likely include a LAS/BPC shaped specifically for it.

that RCS/retro/antenna mast could be left to when you investigate the station parts if you add a TKS body to it 

btw, I think the VA can have a 1.25m docking port where the parachute/RCS pod base is supposed to be, not sure though as I'm not having luck on finding the dimensions of it at work...

EDIT: it wouldn't be the first time the VA pod was flown without the mast though  https://en.wikipedia.org/wiki/Kosmos_1686

Edited December 8, 2015 by JoseEduardo

[Shadowmage]

General Development Update:

• Parachute module is -working-; it animates all deploy states, transitions states, and transitions between different drag states properly.  The rest of the drag setup is config based.
  • Needs some 'tweaks', such as disabling body lift of the part when the chute is deployed, but leaving it enabled when stowed, so you can fine-tune your ballistic trajectory with the pod before deploying chutes.
  • Needs to rotate the part/part-COM properly in relation to the chute/wind/drag direction.  Currently the pod orientation does not matter once chutes are deployed, and you can freely pivot it around its COM.
    • This all might actually be fixed by adding the proper CoP and CoL offsets in the part.cfg; the config I am working with was from 0.90, so those did not exist yet.  Will know more tonight.
• RCS block models have been started.  If you have any specific block layouts you would like to see done, speak up about it today/tomorrow.
• SC-A-Command-pod model is...complete I think.  Needs a bit more 'thought' on it, and then unwrap/texture.
• SC-A-SM model is in pretty rough shape.  I'm keeping most of the old cylinder geometry (and texture if I can manage it), but will be redoing the engine mount, fill ports, and engine bell.
  • At this point I need to decide if the service module should have an integrated engine, or?  I'm thinking for these 'purpose built' service modules that integrating an engine is probably acceptable
  • Either way, integrated or not, I need to create geometry and texture for the SM engine; as it is one of the engines I have planned (AJ-10-137), I will be taking the time to do up the model fully/properly, and it will be available as a stand-alone engine (and clusters).
• SC-A-BPC - not even started, need to finish CM model
• Parachute - Generic - Model re-used from SC-B-DPM parachute cap model.  Texture re-used as well.  This model, at least, can be called 'done'.
• Docking Port model - started; well, reworked from the existing docking port to lower poly count (>4k down to <800).  Needs unwrap and texturing.  Seems likely that I'll be re-using the same (rescaled) geometry at least for 0.625 and 1.25m docking ports(including for station-core parts), so this model is on the 'needs to be finished' list.

 

 

Questions regarding Parachute Module:

What feature set should the parachute module have?  Should I merely mimic the stock options/features? (e.g. speed limits, heat limits, etc).
 

Intended feature Set:
* Min Atm pressure for semi/full deploy for both drogue and main
* Max Dynamic pressure / speed? for each chute/state -- if stat is exceeded, parachute fails
* Max temp for each, drogue/main.  Drogue can have higher max temps to allow for some higher-speed/altitude deployment.  A bit unsure how to separate the chute heat from the pod heat....
* Auto-deploy sequence - deploy drogues and the rest will be taken care of for you.

 

I am personally going for the following sequence/feature set:

Start re-entry,  continue on ballistic trajectory until re-entry heating has mostly subsided, generally around 25k. 
Hit 'Deploy Chutes' button to deploy drogue chute.  Can be deployed higher depending upon heating/dynamic pressure.  Drogue semi should merely add a bit of drag, keep speed from increasing too much, slows to ~800ms by 17k
Drogue switches from semi-full deployed at ~17k/?atm, slows to ~100ms @6k
Drogue auto-cuts and semi-deploys main chute at ~6k, slows to ~30ms @1k
Main chute full-deploys at ~1k, slows to <6ms @ Sea-level
Land...(hopefully intact)

(Speeds are... guessed... will require a bit of tweaking to get the re-entry profile down properly)

 

 

18 minutes ago, lynwoodm said:

The pod you are referring to is for the a series cm/sm part catalog? Or a different pod from this series?

-Which- Pod?  Heh, we are talking about at least 3 different ones at the moment.

 

SC-A-CM = 2.5m pod = posted pics yesterday, is the focus of this weeks/next updates development, will be available in a few weeks.

SC-C-CM = 1.875m pod = talking about it a bit, trying to find something to base it on.

SC-D-CM = 1.25m pod 'plan' - not even to the concept stage yet.

SC-B-CM = 3.75m 'Orion' pod = available in the existing mod, will be reworked in the next few weeks.

[VenomousRequiem]

20 hours ago, RedParadize said:

Ejection seat would be hilarious. I wonder if anyone ever tried do a mod about that.

There is totally a mod wit that. I believe it includes a part that EVAs a Kerbal on the "Abort" action group.

[davidy12]

Will it eventually in the distant future have an IVA? 

[ComatoseJedi]

1 hour ago, Shadowmage said:

38 minutes ago, davidy12 said:

Will it eventually in the distant future have an IVA? 

I am pretty sure that IVA's are going to be re-done, as stated in the goals of this project. But, as I look at it, the IVA's are functional at best, and the orion pod in this series is probably has the best IVA out there. I can use the current IVA's for just about what I need to get done, but with parts, I always keep it in chase mode to see what's going on. Just be patient with Shadowmage, he's doing awesome work with the time he's put into this project. If I had any knowledge of how to do what he can do, I'd already be putting in to help him as much as possible to roll things out to get this awesome mod released, keeping it up to date and adding new features. 

On an interesting side note on the Orion pod: You can put this pod -inside- the top of any 3.75 meter hab module and now you have an extended command module. Which now I'm in a interplanetary mood, I like this very much!

 

Edited December 8, 2015 by lynwoodm
added pictures

[riocrokite]

hey ShadowMage,

since you're on the topic of parachutes and my inline ballutes mod that relies on both stock parachute module and realchutes (especially when someone is using FAR aero) I guess I can throw an idea

For me the biggest hurdle now is lack of variable parachute drag depending on mach number that would differentiate different types of chutes:

I guess it concerns mainly drogue chutes and ballutes since normal parachutes operate at speeds below 1 mach where drag coeff is const;

This feature is absent both in stock and FAR-RealChute(lite) modules.

What might interest you is that RealChute sets parachute temperature independently from skin/internal temperature. Also it has multiple parachutes options-in-one parachute part so you can go with 1 part which contains both drogue and main parachute.

[RedParadize]

on the same topic:

https://www.nasa.gov/mission_pages/tdm/ldsd/overview.html

[Shadowmage]

The parachute module that I've developed can support -both- mains and drogues in a single part, -and- properly support -multiple canopies- for each (drogue/main) with independent tracking and spacing (so no clipping).  For example, the SC-A-CM will have two drogue chutes, and 3 main chutes, all part of the same part, with drogues and mains capable of being deployed independently.  Will try and make a video-clip of it tonight if I can find the time.  It is quite something watching the caps all flip around and re-align themselves

Yes, I was investigating how to handle allowing a drogue to be usable in the upper atmosphere while not overpowered lower down -- mostly for drogues.  Right now, if you make it useful higher up it is like flying through soup lower down.  If you tune it for lower-altitude performance, it is useless at higher attitudes.  I might end up trying to find out how to do variable drag based on atm density or something (or rather, inverse density); so the drogues actually become -less- effective in thicker atmosphere. - Edit: Or, as you hint, making it speed/density based -- more drag at higher speeds?

Thankfully most of that stuff is all fine-tuning balancing and does not effect the core functioning of the module (deploying chutes, swapping drag cubes).

The only bad side about this parachute module?  The setup is so different from stock/real-chute that there is -no way- you would be able to convert between the two (they are both animation based, mine is...transform and config based).  Honestly, that was the whole point of the module; to break away from the stock animation-based setup, and to allow the parachute setup to be defined completely through config -- so I can change the animation/settings/etc without having to touch the model, or the mess that is Unity.

Edited December 8, 2015 by Shadowmage

[RedParadize]

Wow, that sound awesome! Will we be eable to test it on the next release? If yes, you are a boss! (if not, you are still a boss)

[Shadowmage]

2 hours ago, RedParadize said:

Wow, that sound awesome! Will we be eable to test it on the next release? If yes, you are a boss! (if not, you are still a boss)

I'm not going to delude myself by saying that it will all be done (CM/SM/RCS/Docking Port/AJ-10-137), but at least the CM should be in and usable for this weekends 'dev' release.  May not have textures on the docking port, SM and stuff will likely not be done (need to make both RCS and engine models first) - but the CM itself should be in and usable in its two forms (one with heatshield+parachutes, one without).  Working on unwrapping and AO bake right now, and will likely do at least some of the texture work today.  When I set the 'goal' for this release, I didn't realize how many -new- models I would have to create, so it will likely only be partially completed for this weekend -- as such, it will have only a 'dev-preview' release (intended only for preview purposes), rather than a normal pre-release (which would be for testing/bughunting).

In short - Some of it should be available, and at least the CM should be usable (but probably not finished).

 

Edit:

SC-A-CM - Finished Geometry (unwrapped, AO done, texture shown is pure AO bake)

Edited December 8, 2015 by Shadowmage

[blowfish]

Did you say that pod is 2.5m?  The docking port looks smaller than I would expect, but maybe it's just the perspective.

[Shadowmage]

6 minutes ago, blowfish said:

Did you say that pod is 2.5m?  The docking port looks smaller than I would expect, but maybe it's just the perspective.

2.5m pod, 0.625m docking port - nothing bigger will fit on the Apollo-styled pod.

[Jimbodiah]

Wow....  Nice work Mage!

Would love to see the chute in action!

[Shadowmage]

Single-part craft.  Still have not coded the 'parachute cap removal' bit, but that is relatively easy compared to what is already done.

Transition from drogues fully deployed to mains semi-deployed (need to clean up the initial rotation of them when deployed, but that is a config-side fix, may re-upload video if I feel like taking the time)

 

Transition from mains-semi to mains-full:

 

Still a bit of code cleanup and config work to do, but they are quite functional, and seem to play nicely with everything on the part so far.

 

 

 

 

 

 

 

[VenomousRequiem]

Shouldn't the drouge parachutes be much smaller and more of a gray-ish colour? Apologies if you're getting to that and/or stated that somewhere I just skimmed over it...

[Shadowmage]

A:  Its a preview/test of the plugins ability to... function, and not a preview of CM (it merely happens to be the only part that has the plugin on it currently).  Note the title of the video.

B:  Both parachute model and (retracted/semi/full) scale are set through the config file, so you can edit them to your liking (and the # of them, and their positions and orientations... its all config, all the way)

C:  I only have a single parachute model, and will likely be leaving it that way for the near future.  Simple enough to swap the model in the config if/when another model is available.

D:  Really?  Parachute colors?  Does it matter?  I'm going to make them fluorescent purple and green if it suits me. (That is mostly to reiterate:  I'm not aiming for historical replicas... if that is what you are after, you will -hate- the texture the CM is going to have).

 

 

Edited December 9, 2015 by Shadowmage

[Shadowmage]

21 hours ago, riocrokite said:

hey ShadowMage,

since you're on the topic of parachutes and my inline ballutes mod that relies on both stock parachute module and realchutes (especially when someone is using FAR aero) I guess I can throw an idea

For me the biggest hurdle now is lack of variable parachute drag depending on mach number that would differentiate different types of chutes:

I guess it concerns mainly drogue chutes and ballutes since normal parachutes operate at speeds below 1 mach where drag coeff is const;

This feature is absent both in stock and FAR-RealChute(lite) modules.

What might interest you is that RealChute sets parachute temperature independently from skin/internal temperature. Also it has multiple parachutes options-in-one parachute part so you can go with 1 part which contains both drogue and main parachute.

 

Have been giving a bit of thought to this (variable drag), and I'm pretty certain I can implement something that would simulate it to some degree.  Shouldn't be too hard to add some mach-speed curve-based manipulation of the drag cubes into place.

Might have to get together with you on IRC/Steam-chat/etc to go over some details regarding what you would like to see out of the system, as I am certainly no expert on supersonic flow or drag caclulations, but I think it could benefit from a better high-speed parachute handling setup.

 

 

And, on the related subject of re-entry / heating -- Working on laying out the groundwork for a custom ablator/heat-shield module to be used by the upcoming capsules.  As apparently the stock module has some issues with integrated parts, this will be a full-custom setup - and probably much more feature filled than the stock one.

Requirements:

• heatShieldVector - Heat-shield 'shielded' direction vector to determine if heatshield is facing the airstream and should ablate/protect.  The more it is facing the air-stream, the more effective it is.  (will have a slight 'grace' area where you can be slightly off-vector without too much bad effect).  This means the heat shield will only protect a part if oriented properly  -- no more heat shields losing their ablator during launch.
• minEffectiveDot - minimum dot product between wind and heat-shield direction where heat shield will still be effective (dot product is basically the angle between two vectors, expressed as a range of 1 to -1)
• maxEffectiveDot - the dot product at which the heat shield is most effective (at higher dot products than this, it will be 100% effective; it is this that provides some small off-perfect 'grace' area).
• ablationStartTemp - temperature at which ablation will start; below this temp and the heatshield is just dead weight
• ablationMaxTemp - temperature at which ablation peaks -- beyond this temperature effective ablation rate will peak at 100% of maximal.
• Node/occlusion checking - even if facing the airstream, if the specified attach node has a part attached the shield will be considered 'occluded' and not function.  Can be used to 'stack' heat-shields for sequential use.  Undecided if this will use drag-cube occlusion checks such as the stock heatshield, or if it will be purely node based.
• ablation heat reduction is based on the material used for ablation -- using specific heat capacity/density of the material.

Would-be-nice:

• Allow for other types of heat-shield -- passive thermal soak, ejectable, active thermal soak, others?
• Allow for variance in the ablator material? (e.g. in-editor switching)  More dense = higher start temp, but more effective (use for super-high-speed re-entries, such as direct-return-from other planets)
• For non-ablating types of heat-shield, allow variance in shield materials; higher density = more soak potential, ??

Any ideas/input on that list of requirements?  Will be needing to get this module finished up for the command pods as well; the stock heat-shield module just doesn't cut it for integrated parts (and the config values make zero sense / difficult to tweak properly).

 

 

[VenomousRequiem]

I'll hate the CM texture? What's it going to be? Neon green?

You do you, yo. It's your mod.

[Shadowmage]

29 minutes ago, VenomousRequiem said:

I'll hate the CM texture? What's it going to be? Neon green?

You do you, yo. It's your mod.

Hehe... I can just see it now... a bright neon-green CM wreathed in plasma, hurtling towards Kerbin @ mach 8.  Would look like a christmas-tree on fire

Nah, will be a white base texture, with silver accents.  Probably similar to the Skylab CMs that were flown; so I guess there is -some- historical basis for it.  Not going to be silver though (and even after 1.1, still might not be silver unless I can find a way with Blender to fix the normals and have proper undistorted shading).

[ComatoseJedi]

17 minutes ago, Shadowmage said:

Hehe... I can just see it now... a bright neon-green CM wreathed in plasma, hurtling towards Kerbin @ mach 8.  Would look like a christmas-tree on fire

Nah, will be a white base texture, with silver accents.  Probably similar to the Skylab CMs that were flown; so I guess there is -some- historical basis for it.  Not going to be silver though (and even after 1.1, still might not be silver unless I can find a way with Blender to fix the normals and have proper undistorted shading).

There will be a show dedicated to your "silver" looking parts. It'll be called "Pimp my CM". It's just me, but I love that shiny/chrome look on ships. Makes me feel like I'm going somewhere, in style. But, as Venom said, it's your baby. I'll be happy with whatever you come up with. 

[riocrokite]

hey ShadowMage,

Thx for your reply and interest:) you're doing excellent stuff with the plugin, however lately I don't have much time to test your things/ develop my own stuff - until end of year I'll be practically out of loop.

Thinking of your parachute module and atmosphere stuff - this isn't my favorite area of interest and with (hidden) atmosphere changes from version to version of KSP and lots of testing involved to tweak values I guess I won't be changing existing setup soon

I usually hang out on #kspmodders and #kspofficial irc channels so feel free to ping me when you're there

Thinking about heatshields what I really lack now is inflatable / animated heat shield that is mounted between tank and engine and protects engine from airstream when it's closed. Plugin-wise I guess shield shouldn't work and should be vulnerable to intense heat when it's open and function as normal heat shield when it's closed. Visual example:

In other words animated heat shield / ballute module would allow to have simpler construction with engine at the back that can be shielded from airstream when entering atmosphere backwards.Otherwise you would need to drop / hide main engines so they wouldn't burn up when entering from high interplanetary speeds. Some concepts even have secondary ? engines for altitude control during reentry / multiple aerobraking passes:

 

 

Also - from more real life designs - inflatable ballutes/heatshields designs like those could work nicely:

 

I often write ballute/heatshield in one sentence since both concepts are very often mentioned together:) In KSP this is also the case as soon as someone moves into Kerbol resize mods like kscale2 / 64k where orbital/transfer speeds are much greater than in stock.

edit: example stats for ballute/heatshield operation:

http://slideplayer.com/slide/2869340/

 

Edited December 9, 2015 by riocrokite

[Shadowmage]

1 hour ago, lynwoodm said:

There will be a show dedicated to your "silver" looking parts. It'll be called "Pimp my CM". It's just me, but I love that shiny/chrome look on ships. Makes me feel like I'm going somewhere, in style. But, as Venom said, it's your baby. I'll be happy with whatever you come up with. 

Hehe

I'll likely be redoing a -ton- of texture work when 1.1 comes out.  The increase in the options granted by the new 'standard' shader is.... insane.  Probably should put on a 'Pimp my Part' type weekly series as I'm reworking the parts (only half kidding :))

On that note, I -think- I just found how to 'fix' the messed up normals/shading for basic cylinders and conical parts, though it currently requires splitting the 'fixed' parts into a separate mesh object (less than ideal from a performance standpoint; might be able to fix/work around it, if I can find a way to persist the adjusted normals during mesh joins and export/etc).  Hmm.. it seems like it accepts re-joining, as long as I don't try and alter the mesh after the fact.

This is actually quite excellent news for me, as I've been trying to find a way to 'fix' the shading on low-poly meshes for quite some time, and it has nearly caused me to quit modeling more than once (why model if even when done 'properly' it still comes out looking like mud?).  So... yah... good stuff.  Will see about applying this to the CMs as I rework them, in prep of the upcoming Unity shader improvements (one less thing I'll have to rework when 1.1 comes out).

 

Edit:

Bad normals (note the shading on the airlock hatch, has some strange vertical banding to it)

 

 

Fixed normals (not perfectly smooth shading on the hatch.... finally!!  (ignore the missing panel below the hatch, I was verifying that the normals work even with pieces cut out, which normally messes with them terribly.)

 

 

Edited December 9, 2015 by Shadowmage

[JoseEduardo]

quick question, to go along with the new Apollo CM, would it be possible to when you re-work the landers have an third model LEM-alike? you know, for 0.625m docking ports

[ComatoseJedi]

Wouldn't these be killer things to do to a CM? Granted, it's not factory standard, but awesome sauce is awesome sauce. 

[Jimbodiah]

Nice white is fine, but I do love the FASA apollo CM/LEM though with the shiny texture and detailing. I just uninstalled them as I was getting tons of errors with that mod (15-20 lines per second). Too bad it's so buggy, I really loved a lot of his parts like the capsules and the launch clamps (hint, hint).