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

[Shadowmage]

4 minutes ago, RedParadize said:

@Shadowmage Oh... That's fantastic! Thank you so much!  I might have a idea to make it behave with stock aero, I imagine the drag cube is calculated around part colider? If yes, it probably only see the base, so increasing the angularDrag and maximum_drag might do it. If not, I will try make a part with the heat shield included, that or a base plate. Since I now I feel guilty of wasting your time, let me do these test myself to redeem myself!

I think the drag/CoP situation is caused by a few things. 

• The drag cubes are updated to represent the deployed state; the 'drag' value in the debug menus will confirm it (cannot confirm if it is -correct-, only that it changes).  Drag cubes calculate from visible meshes (as well as colliders? might only be visible meshes....).
• The CoM of the petal-adapter itself does not change as the panels are deployed
• The CoP/CoL is located at the CoM regardless of deployment (really not even sure how I would calculate this, and I would -think- that the drag-cube would be responsible for the CoP calculation)
• Calculating proper CoM and/or CoP positions could possibly be done.  CoM I'm fairly certain I can figure out, CoP... no clue where to even begin on that one.  Possibly just setting it to the CoM would be sufficient.

Not really sure how to solve it, or even if it should be solved.  Use of the petal adapter as airbrakes is really...so far from a standard use case as to probably not warrant consideration; it was never intended to be deployed while moving through atmosphere, let alone used as a drag system.  I just couldn't resist when I saw how they deployed... it seemed like the perfect airdrop system.

Don't feel bad though; working on these has been on the todo list for at least a few weeks now, but just now getting around to it as most of the PBR-related chaos has died down a bit.

The real painful bit in all of this is there are some.... issues... with some collider generation code that went uncaught until now.  The actual work needed for the petal-adapter retract function is nearly done (small bit of UI/consistency cleanup), but the collider problems still have a ways to go.  It requires digging into my procedural mesh generation code, which isn't so much a mess as it is some sort of arcane scripting; it works, and it is very well organized, but it always takes me a week to wrap my head around it all before I can make much progress with it.  (There is a reason I don't do much procedural mesh stuff...)

[RedParadize]

@Shadowmage Personally, I do not mind much if can't be used as a airbrake or if does not have effect once deployed. Sure, it would be fun, but as long as it's not too unstable when closed its fine.

Another option, if you have a taste for deceptive humor, would be to write "warranty void if deployed while moving" and make the panel jettison when under too much pressure. No one read the small character... 

[Norcalplanner]

@Shadowmage It may be unrealistic, but it works.  I've used the shielded docking ports in the deployed position as an airbrake for quite some time, opening and closing sometimes as needed to adjust the range during a reentry.  Here's a picture of a craft using the technique:

 

 

[tater]

Presumably those are some sort of regolith bags on top. Possibly a model swap (use this type with a standard base, and buried habs require that there be a special "dozer" landed.

[RedParadize]

@tater Yeah, bags make sense. There is no wind on the moon, but there is on Mars. The model I am working on have a metallic textile covering the top, I used that to hide the junction with the real ground surface on one side. The other side have its ground junction hided by a large deck, that also make sense as dust is bad for airlocks. I suspect that any medium to large scale installation will not come in "IKEA" kit but  will be made using generic material. So I tried to give hab entrance a little makeshift taste. I think I went to far in that direction.

Edited November 28, 2017 by RedParadize

[tater]

There are 3d printing ideas to stabilize dust as well.

[Shadowmage]

12 hours ago, tater said:

Will this at least be possibly useful to you later? Ie: to make similar parts for different uses you might imagine?

Sadly, not really.  The petal-adapter code is specific to only those two parts, and was only ever intended to have very specific and basic functionality.  I can't see any uses for it elsewhere.  The 'cargo bay' parts will all be using pre-compiled models and animations.

 

I did finally track down that collider generation issue last night.  After that was fixed up most other bits seemed to be cooperating acceptably.  Still have a couple minor UI/usability problems to clean up, but I would anticipate that I can have it cleaned back up later this evening.

Also realized why it wasn't working as an airbrake -- because it was 'stack-occluded' (all of its stack nodes were occupied), which causes KSPs drag simulation to apply only very minor 'skin drag'.  The exposed stuff from inside the fairing was producing far more drag than the giant seemingly-made-for-drag deployed fairing.  Not sure there is much/anything I can do about that, nor do I think I'm going to spend much time on it.  The part -works- for its intended function (and many un-intended ones)... not going to hurt my feelings if it can't be used for absolutely everything.

 

@tater -- Yes, regolith covered bases are completely doable, probably 90% like you would be desiring/expecting.  Including 'growing' of the regolith over the top of the parts, and proper collisions for your mound of dirt.  Land your base, break out the bulldozer (abstracted a bit, of course), and watch the dirt pile up.  A simple subdivided planar mesh could be easily deformed to form the regolith pile; the texture could be borrowed from the surrounding terrain (either use the same material, or literally 'project' the terrain texture onto the regolith mesh seamlessly).  The 'base' part could be examined for its bounds/render extents to determine how much to deform the regolith mesh, and where to keep it open for the 'door'.

However it is not something that I'm going to have time to work on, certainly not anytime soon.  Unless someone else offers to pick up modeling/texturing work for SSTU, my time is pretty much spoken for at least for the next year (and probably 2-3 with all of the random requests I deal with).

[RedParadize]

17 minutes ago, tater said:

There are 3d printing ideas to stabilize dust as well.

Thinking about it. How would you bury a relatively fragile structure that need to be airtight. Even if we would carry a bulldozer I do not think we would risk using it for that. Old sandbags might be a better option, easy to fill, carry and remove if needed.

[tater]

38 minutes ago, RedParadize said:

Thinking about it. How would you bury a relatively fragile structure that need to be airtight. Even if we would carry a bulldozer I do not think we would risk using it for that. Old sandbags might be a better option, easy to fill, carry and remove if needed.

If the modules are prefabricated, they'd be designed for the dead load needed. Inflatables are a different matter, though they are substantially thicker than people imagine, and they could be fitted out with internal braces as needed.

[Shadowmage]

1 minute ago, tater said:

If the modules are prefabricated, they'd be designed for the dead load needed. Inflatables are a different matter, though they are substantially thicker than people imagine, and they could be fitted out with internal braces as needed.

Also, don't forget, this is the Moon / Mun we're talking about.  ~1/6 the gravity.  You could support a surprising amount of dirt on fairly light structure under those conditions.

[RedParadize]

Indeed, I was not skeptical of the dead weight, but how do you move all that weight on top. Bulldozer seem excessive and dangerous. Shoveling it from the ground to the top would be ridiculous. Machine that fill sandbags already exist. The only thing left would be to place them. But I guess that a kind of "snow blower" but for dust could be a option. After the Canadian arms, we will give you the Canadian dust blower!

[Shadowmage]

...

...

(based loosely on the ModularStationCore module.... with hundreds of lines of new and changed code to account for the differences in function.... and still many hundreds/thousands more to go.  I don't anticipate that there will be any parts available using the module for a few weeks/months, as I'm still in the middle of tons of other stuff that needs to be finished)

[RedParadize]

25 minutes ago, Shadowmage said:

...

...

(based loosely on the ModularStationCore module.... with hundreds of lines of new and changed code to account for the differences in function.... and still many hundreds/thousands more to go.  I don't anticipate that there will be any parts available using the module for a few weeks/months, as I'm still in the middle of tons of other stuff that needs to be finished)

If I recall correctly I also used ModularStationCore to do this:

Spoiler

Excluding legs, it was a single part (note the Raptor engine behind the legs). I do not recall if I could still change its size when I went with ModularStationCore, I think not. But I could change top/bottom adapter, docking port and solar panel. I had to hide a hatch inside the main section to make the one on ALCOR work because as a adapter (or port?) it was not detected.

The texture switching broke it. Made me sad because it was the funniest thing to fly. It was perfectly balanced, I removed drags form legs so I could flip it as I wish under almost all circumstance. One day I will have to fix it. I wonder how the ALCOR will look like with PBR if I manage to convert it's texture.

[Shadowmage]

Well, so far the feature set that I'm working on for the service modules (and by extension, probe-core/satellite buses) includes:

• Switchable top/bottom adapters (e.g. the MFT tank adapter switching)
• Switchable 'core' model -- switch between 'variants', as well as several length options for each variant (vertical scaling is not, and will not be, supported)
  • Each variant can have its own selection of adapters defined in the config file.
  • Supports animated core models -- so a service bay might be included in one or more of the variants
  • Supports varying top/bottom aspect ratios, for Orion-like SM setups (larger top diameter than bottom), or other less mundane uses. (no guarantees that I'll include such setups... but they will be possible from a plugin perspective)
  • Solar panel positioning is setup on a per-core-per-panel basis.  So each core variant and length will require its own solar panel position specifications.  Going to be a few thousand lines of config file... but no other way around it.
• Standard texture set/texture switch/recoloring support (top/body/mount selections in recoloring GUI)
• Diameter/scale control.  Listed as 'diameter', but scales the entire model, just like on the other modular parts.
• Integrated switchable solar panels. 
  • What options are available depends on the currently selected 'core' and its current scale/size.  Solar panels are not scaled with the core, so at very small core sizes, not all solar panels will fit.
  • If fuel cell or RTGs are desired it would require a completely separate part(s) due to limitations in the stock modules.
• Integrated switchable RCS, with vertical-position control. 
  • Several RCS block types will be available, including 'none' as a valid option.  These will be taken from the current selection of SSTU RCS blocks.
  • RCS blocks (and rcs-thruster-power) scale with the SM diameter (square scaling). 
  • RCS fuel type selection is supported, so you can match your RCS fuel to whatever you use for your main engine, or some other combination as RP demands. 
  • Vertical offset allows for moving the RCS blocks up/down along the length of the SM body, to allow for some level of rcs balancing even with external payloads.
• Integrated antenna functionality.  There will not be any integrated/switchable antenna models or options because the stock ModuleDataTransmitter does not support run-time switching, and is limited to using the stock animation modules (which cannot be disabled).  Likely that this will be a simple short-range antenna as are built into the command pods/probe cores.  If you need longer range functionality, you will have to add a stand-alone antenna.  (not even touching on the difficulties of dynamically positioning a non-scalable model onto the scalable SM body)
• Integrated node-fairing support similar to that employed on the MUS -- where it will also extend the fairing to cover up whatever engine is attached to the part.
• Integrated SAS and ASAS capability (probe core/reaction wheels)
• Kerbnet... because... why not.

They will not have any of the following:

• No integrated engine of any kind
• No integrated docking port
• No antenna models, and only a short-range internal transmitter (stock module limitations).
• No fuel cell/rtg switching (stock module limitations)

So, at most, this should add 3 new parts for the 'Service Module' line -- one 'solar', one 'rtg', and one 'fuel cell' version.  The 'rtg' and 'fuel cell' versions could -also- have solar panels if desired.  Should allow for 2-piece service modules/satellite buses to be built for nearly any use with thousands of different variants/combinations available (SM + engine; payload+docking capabilities not included).

-- Just spending some downtime at work to prototype the module code and a couple config files to enable testing of it eventually.  I really don't anticipate that any of it will be publicly available/usable for at least several weeks, however, I might make available to a few people some of the prototype test configs/parts to allow for functionality testing and pre-release bug-hunting (might be as early as this weekend, depending on how broken the module code currently is/how much is left to implement and/or fix)

[RedParadize]

@Shadowmage Damn, that's sound a awesome. I didn't trough you would add that much feature to it. If I understand correctly this is much, much more than a modular service module core.

 

 When you say no integrated engine, do you mean that engine can't be added trough config or that there will be no engine number/kind editing?

Edit: I volunteer to test it if you want. Just Keep in mind that I tend to use stuff in un-intended ways. I will break it, for sure. 

Edited November 28, 2017 by RedParadize

[Shadowmage]

5 minutes ago, RedParadize said:

When you say no integrated engine, do you mean that engine can't be added trough config or that there will be no engine number/kind editing?

I mean 'No engine'.  None.  Zero.  Can't add them through config, can't add them through UI.  No engines.  (even if you try to 'weld' an engine into the models used in the part, its not going to work out as I'm not doing any hacky transform stuff to make it work)

As the ModuleEnginesXXX is one of those stock modules that cannot be disabled, it was deemed a waste of time to try integrating engines if they could not also be made optional.  Since they can't be made optional... they simply won't be an option at all.

Of course, the intent is that you can use -any of the existing engines- and just slap it on the lower attach node.

[RedParadize]

2 minutes ago, Shadowmage said:

I mean 'No engine'.  None.  Zero.  Can't add them through config, can't add them through UI.  No engines.  (even if you try to 'weld' an engine into the models used in the part, its not going to work out as I'm not doing any hacky transform stuff to make it work)

As the ModuleEnginesXXX is one of those stock modules that cannot be disabled, it was deemed a waste of time to try integrating engines if they could not also be made optional.  Since they can't be made optional... they simply won't be an option at all.

Of course, the intent is that you can use -any of the existing engines- and just slap it on the lower attach node.

I see, thanks for the clarification. I could stick to SSTUModularStationCore if I want to redo my lander exactly the same way. But I feel I will not, there is many very nice feature in there.

[Jimbodiah]

You keep saying no no, but then deliver something even better    Sounds awesome, Mage!!!!!  Thank you!

[RedParadize]

3 minutes ago, Jimbodiah said:

You keep saying no no, but then deliver something even better    Sounds awesome, Mage!!!!!  Thank you!

Yeah, when people were talking about modular SM, what I had in mind was a glorified MUS. Then Shadowmage came with this!

[Shadowmage]

6 minutes ago, Jimbodiah said:

You keep saying no no, but then deliver something even better

I kept saying no to 'scaled Orion SM's'.  And I'm still saying no to those.

(you'll be able to create very similar with the proposed module... but they will not have the Orion-SM texturing on them (until/unless someone pops up offering to start doing models/textures for me.... but I'm very sick of modeling/texturing work for now))

[Jimbodiah]

 

So what would you like to do besides modelling/texturing; more plug-in work?

Edited November 29, 2017 by Jimbodiah

[Shadowmage]

5 minutes ago, Jimbodiah said:

 

So what would you like to do besides modelling/texturing; more plug-in work?

Sadly, there is only so much plugin work that can reasonably be done before you are just making a mess (read: convoluted and hard-to-maintain code).  There are certainly a few ideas that I've never had time to explore properly, and a few long-standing problems that I would love to clean up (a few in each of my mods even...); but that could only go on for so long / only so many things to cleanup and fix.

I'm just a bit burned out after the MFT-LV fuel tanks (lots of modeling work), and then the big PBR-texture conversion (so very much texturing work).  Was not only a ton of work... but was mostly boring, repetitive,... work.  Need a break for a bit after that, though I am still working on cleaning up some of the missing/unfinished stuff as best I can.

^^^ Is why I've been tackling some of the more complicated plugin side stuff this week.  Needed to do something more engaging and with more material returns for the time invested.

I do plan on doing more modeling (and texturing) work in the near future as there are still a few part concepts that need to be developed.  I pretty sure next up will be some accessories for the new MFT-LV tanks (landing legs, service/cargo bay), with possibly a refresh of the LC-POD parts coming shortly after that.

[Jimbodiah]

The holidays are coming up. Take the month off and just relax. With all that has been improved/added/changed these last few releases, you more than deserve it. Who could have thought the recoloring/pbr functionality possible a year ago? It's freakin amazing!

[RedParadize]

Just now, Jimbodiah said:

The holidays are coming up. Take the month off and just relax. With all that has been improved/added/changed these last few releases, you more than deserve it. Who could have thought the recoloring/pbr functionality possible a year ago? It's freakin amazing!

Shush, you should know by now that he is only happy when working to death. And I want my Christmas gift!

[Shadowmage]

2 minutes ago, Jimbodiah said:

The holidays are coming up. Take the month off and just relax. With all that has been improved/added/changed these last few releases, you more than deserve it. Who could have thought the recoloring/pbr functionality possible a year ago? It's freakin amazing!

Hehe, I have been taking some time recently to actually -play- some KSP.  With the PBR shaders, its like a whole new game.  I've found myself just staring at some of the metallic parts/craft in the editor... so beautiful.  Even some of the stock-pbr-converted parts aren't too bad. (also been finding and squashing quite a few minor visual and balance bugs... so bonus' for you all as well)