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

[mechanicH]

Was this a planed thing to make the inflatable HABs dependent on "rocket parts" ..because im reading through the past pages and i cant find anything about it. What was the reason Shadowmage  decide to take this route.  

[tater]

Sstu tanks can have rocket parts. "Configure Containers" and add them.

[mechanicH]

There is no option to have rocket parts in SSTU tanks,  gives me the option for every other type of propellant , but no rocket parts.  

Edited November 7, 2016 by mechanicH

[tater]

3 minutes ago, mechanicH said:

There is no option to have rocket parts in SSTU tanks,  gives me the option for every other type of propellant , but no rocket parts.  

Read my post again. Right click. Configure container. Add rocket parts. Profit.

[Jimbodiah]

I think it was added this patch, have not seen it before (but admit I did not looked for it since 1.1.3).

[JoseEduardo]

I'll leave this here: http://imgur.com/a/xt4ja

[Jimbodiah]

Mic drop moment.  Wow, José, looks cool!!!!  Ya gotta bug Mage to make that umbrella now

[mechanicH]

23 minutes ago, tater said:

Read my post again. Right click. Configure container. Add rocket parts. Profit.

ok so i managed to figure out the rocket part thing,  but the ST-HAB-H still wont inflate.  

[JoseEduardo]

6 minutes ago, Jimbodiah said:

Mic drop moment.  Wow, José, looks cool!!!!  Ya gotta bug Mage to make that umbrella now

oh, yeah, that one is sold separately, I forgot to mention that I included a node for Raidernick's Parasol panel in most of the Skylab top options I'll include

[Jimbodiah]

LOL, and I just added an RL-60, RL10C-1, RS-83 and RS-100. We have no lives

[tater]

The C2 has a crew capacity of 18, and the C1 holds 12. This is 2xC1. The BA-2100 holds (by design, but it doesn't really exist) 16. I think the C1 is a little bigger to scale than the 2100, so it's certainly in the ballpark (16 seems ridiculously crowded to me for the 2100, frankly---least as a tourist).

Didn't need the airlock, but I sent one with one of the landers anyway, just to see it stuck to something, lol.

[JoseEduardo]

so, this is a thing now

btw, I just realized that Nova was last updated on July 11th, the dates might mess with US people haha

[tater]

I just threw this together so I could remember what parts held what numbers of crew:

HAB-A1: 4 crew
HAB-A2: 6 crew

HAB-B1: 6 crew
HAB-B2: 9 crew
HAB-B3: 6 crew
HAB-B4: 9 crew

HAB-C1: 12 crew
HAB-C2: 18 crew
HAB-C3: 12 crew
HAB-C4: 18 crew

I also wrote sample HAB boilerplate descriptions, as a model for what should be put there, since the other stats are auto-populated by presumably cfg values, and the crew doesn't show up (since it's not crewed until deployed). Note that I am calling the B/C 1/2 units as station cores, and assuming that they get command functionality (which they should have, IMHO).

description = SSTU - StationCore - HAB A1 - The HAB A1 inflatable habitation module is designed to add living volume that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The A1 provides extra living area for up to 4 crew when inflated from its initial 1.25m diameter to a final 2.5m diameter.

description = SSTU - StationCore - HAB A2 - The HAB A2 inflatable habitation module is designed to add living volume that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The A1 provides extra living area for up to 6 crew when inflated from its initial 1.25m diameter to a final 2.5m diameter.

description = SSTU - StationCore - HAB B1 - The HAB B1 inflatable habitation module is designed as a station core that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The module comes with full RCS, an airlock, and a selection of available solar panel arrays if desired. The B1 provides living area for up to 6 crew when inflated from its initial 2.5m diameter to its final 5m diameter.

description = SSTU - StationCore - HAB B2 - The HAB B2 inflatable habitation module is designed as a station core that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The module comes with full RCS, an airlock, and a selection of available solar panel arrays if desired. The B2 provides living area for up to 9 crew when inflated from its initial 2.5m diameter to its final 5m diameter.

description = SSTU - StationCore - HAB B3 - The HAB B3 inflatable habitation module is designed to add living volume that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The B3 provides extra living area for up to 6 crew when inflated from its initial 2.5m diameter to a final 5m diameter.

description = SSTU - StationCore - HAB B4 - The HAB B4 inflatable habitation module is designed to add living volume that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The B4 provides extra living area for up to 9 crew when inflated from its initial 2.5m diameter to a final 5m diameter.

description = SSTU - StationCore - HAB C1 - The HAB C1 inflatable habitation module is designed as a station core that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The module comes with full RCS, an airlock, and a selection of available solar panel arrays if desired. The C1 provides living area for up to 12 crew when inflated from its initial 3.75m diameter to its final 7.5m diameter.

description = SSTU - StationCore - HAB C2 - The HAB C2 inflatable habitation module is designed as a station core that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The module comes with full RCS, an airlock, and a selection of available solar panel arrays if desired. The C2 provides living area for up to 18 crew when inflated from its initial 3.75m diameter to its final 7.5m diameter.

description = SSTU - StationCore - HAB C3 - The HAB C3 inflatable habitation module is designed to add living volume that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The C3 provides extra living area for up to 12 crew when inflated from its initial 3.75m diameter to a final 7.5m diameter.

description = SSTU - StationCore - HAB C4 - The HAB C4 inflatable habitation module is designed to add living volume that can exceed the diameter of the launch vehicle upper stage diameter or LV fairing diameter. The C4 provides extra living area for up to 18 crew when inflated from its initial 3.75m diameter to a final 7.5m diameter.

 

Also part of me wants to suggest that you rename the A1 and A2 to A3 and A4, respectively. Why? Because the B1/2. and C1/2 have solar and RCS, making them suitable for name = ModuleCommand functionality, whereas the B3/4 and C3/4 are like the current A1/2---just the habs, with no RCS or solar, making them more akin to COS modules that get added for additional living volume, but that lack any control ability. Its certainly not critical, but there is an OCD part of me that wants them all to match up  .

 

[Jimbodiah]

You could also change the categories if Mage gives the go-ahead, and do a PR on github with this info.

Btw: Love that you've added tbe boiloff to the KSP career info menu now, Mage!!! Looks good!

[tater]

I'm still trying to grok github, but I'm happy to alter the cfgs and post them there is that is the drill. So to be clear, I could adjust the relevant cfgs in question, then upload them as a PR?

[Shadowmage]

17 minutes ago, Jimbodiah said:

You could also change the categories if Mage gives the go-ahead, and do a PR on github with this info.

Btw: Love that you've added tbe boiloff to the KSP career info menu now, Mage!!! Looks good!

 

11 minutes ago, tater said:

I'm still trying to grok github, but I'm happy to alter the cfgs and post them there is that is the drill. So to be clear, I could adjust the relevant cfgs in question, then upload them as a PR?

 

I -think- I've figured out the best method for the web-based PR's to allow multiple edits to be combined into a single PR.

1.)  Find the repo to be forked on GitHub.  ( https://github.com/shadowmage45/SSTULabs )
2.)  Click the 'Fork' button in the top right.  It will create a fork under your user-name/account.  ( https://github.com/shadowmage45/SSTULabs#fork-destination-box )
3.)  Create a new branch for your PR.  This is done by clicking on the 'branch' dropdown and typing in a new name.
4.)  Select your new PR branch as the active branch using that same dropdown.
5.)  Browse through the repository in the browser and edit files as needed.
6.)  When done making edits hit the 'New Pull Request' button (next to the branch dropdown).  Once done with this screen the PR will be sent to the parent repo of the fork.
7.)  If you then need to make more edits to your PR, select the branch of your fork, and make new edits.  They will automatically be added to the PR.

The forking step might need to be redone after each update to the parent repository -- I'm not sure how to synch forks through the website API.  So after your PR is accepted you may need to delete your fork and re-create it for the next PR.

(Most of those steps are a bit easier when using the local version of Git, but there are some features that are simply not supported through the web-api)

 

17 hours ago, mechanicH said:

Was this a planed thing to make the inflatable HABs dependent on "rocket parts" ..because im reading through the past pages and i cant find anything about it. What was the reason Shadowmage  decide to take this route.  

Yes.  They have been like that for several months (requiring RocketParts as a resource for in-flight inflation.

As was pointed out this is used as a 'kit-out' mechanic, lowering the amount of mass the part has at launch time but requiring extra infrastructure to bring the module fully online.

-- Thinking on it, this might be another good option for the in-game settings.  Toggle to change between requiring resources for inflatable module setup or allowing inflate/deflate at any time.  If enabled the same mechanics would be used as are currently seen; if disabled the modules would have a constant mass, be inflatable/deflatable at any time, and would not require additional kit-out resources, but would be at their maximum mass even during initial launch.

[tater]

I'll give that a go tonight (github glop).

I originally included a in in the description about the tonnage of rocket parts needed to "fit out" the interior for use. It;s already mentioned in the right click of the part in the VAB, so I didn't, but perhaps such a line would prevent some posts here.

Edited November 7, 2016 by tater

[Shadowmage]

18 hours ago, tater said:

MFT-A has the "Nose" stuff that includes many of the station adapters, which is great (though I'd love to see the VA adapter added for SMs, I can do that myself  ). The "Nose" selections don not, however, include any of the, well, nose parts---meaning none of the streamlined parts you might use for radially mounted booster tanks. The "Mount" options include those parts that you'd generally think of as nose parts (nosecones, basically). If the nosecones are meant to only be on one side, I'd assume the Nose would be the right side.

I was going to post a github issue on an odd VAB thing, but it seems to have self-resolved. I will wait until I can replicate it for a github. What happened was that the HAB parts were all showing translucent on the inflatable part of the part in the VAB. They were fine when launched---then fine after returning to the VAB, they showed as properly opaque. I will try later (leaving soon for dinner), and see if it happens again before posting to github.

The ratio adapters are nice to have. 1:2 seems like it might not be super useful for 2.5m parts, the 2:3 (up by 1.5X) seems like what you'd mostly use for 2.5m parts, since the only 5m parts (1:2) would be tanks... of course we haven't seen where you are going WRT huge tori  . Only posting this observation in case you decide to pear down options based on size. 1.25m parts would obviously nicely scale 2X to 2.5m, but 2.5m needs the 1.5X scale up (3:2) for 3.75 where the other hab parts all live far more than 2X.

Another part-sorting observation. The stock MPL is under category = Science, once more finalized, is that where the COS and DOS lab parts will reside? The stock hab part is in category = Utility as well, so to match the hab parts would go there I guess... here is observation/discussion bit: seems like some more of your station parts should have the same "probe core" functionality as the command pods and DOS parts. I would add "Command" to the HAB-B/C 1 and 2 parts as you have for the DOS (they have solar and RCS, after all, they seem self-controlling).

This is a great update!

I have seen the transparency in the VAB, but not after launch. Also, the inflatables require "rocket parts" to inflate. This is to represent the need for supplies to "fit out" the interior. So if you inflated them in the VAB, then they launch inflated. If you want to inflate after launch, attach a tank where you have used "configure containers" to add rocket parts.

@Shadowmage Note: It might be nice to add Rocket Parts as a standard choice (with LFO, EC, MP, etc) for Fuel type in the MFT tanks and COS parts.

HAB transparency in editor -- known issue.  Not quite sure what is causing it, only happens on non-root parts when pulled from the editor part list (alt-click cloned parts do not exhibit it, and it goes away on return-to-editor / revert).  Likely going to need to add some additional cleanup on the textures/material setup for those parts / modules.

Nose modules -- not sure where you are going with that.  What parts are lacking 'nose' options?  Pretty sure the MFT-A should have all of the nosecones as 'nose' options.

Adapter ratios -- if you see any specific parts/options that were missed, please let me know   The StationCore modules should be fairly well situated with adapters though (should all have the proper ratios for their top/bottom diameters).  The MFT parts are a bit less filled out, but should have most options on them.

Categories -- I would prefer to keep all of the ST modules in the same category; sadly stock lacks anything suitable for 'station modules' in general.  So, yeah, will likely be moving them around a bit (though not until I'm done testing things; I hate hunting through part categories for stuff, is why everything defaults to the 'Pods' category when I make new parts).

RP as a fuel type -- Really not fond of adding single-resource 'fuel types'.  The fuel types are supposed to be reserved for fuel combinations with specific ratios or commonly used fuel types.  Single resources are simple enough to add thorugh the GUI.  That is, after all, why I created the 'customize container' GUI and handling system.  I'll give it some thought though, might be a decent change.  Will probably have to wait and see how often I need to use RocketParts/etc during my next playthrough.  Either way, simple enough to add/change if/when deemed necessary.

 

37 minutes ago, tater said:

I just threw this together so I could remember what parts held what numbers of crew:

HAB-A1: 4 crew
HAB-A2: 6 crew

HAB-B1: 6 crew
HAB-B2: 9 crew
HAB-B3: 6 crew
HAB-B4: 9 crew

HAB-C1: 12 crew
HAB-C2: 18 crew
HAB-C3: 12 crew
HAB-C4: 18 crew

I also wrote sample HAB boilerplate descriptions, as a model for what should be put there, since the other stats are auto-populated by presumably cfg values, and the crew doesn't show up (since it's not crewed until deployed). Note that I am calling the B/C 1/2 units as station cores, and assuming that they get command functionality (which they should have, IMHO).

[snip]

 

Also part of me wants to suggest that you rename the A1 and A2 to A3 and A4, respectively. Why? Because the B1/2. and C1/2 have solar and RCS, making them suitable for name = ModuleCommand functionality, whereas the B3/4 and C3/4 are like the current A1/2---just the habs, with no RCS or solar, making them more akin to COS modules that get added for additional living volume, but that lack any control ability. Its certainly not critical, but there is an OCD part of me that wants them all to match up  .

 

Descriptions -- Excellent.  If you don't setup PR's I'll probably come and copy/paste them out of your post

Probe/command capability on the B1/B2/C1/C2 -- yea, probably should.  They are intended to be usable as stand-alone spacecraft if needed, and as such would need their own C&C computers/etc.

A1/A2 naming -- yea, I struggled with that a bit too.  In the end I would rather have the inconsistencies between series than blank/missing numbers (which would leave people asking 'where are the A1/A2 at?', which may never exist).

The good thing is -- those names only matter for the configs/patches.  We can make these things display whatever name we want in-game (editor, right-click menu, etc) without breaking any craft.  Parts have fields for 'name = XXX ' (the 'registry' name, must be unique), 'title = XXX' (which is displayed in the editor and in right-click menus), and 'description = XXX' (which is the detailed multi-line description in the large box on the parts).

On the note of part names -- I've been thinking of putting forward a bit of a 'naming contest' for SSTU parts.  I am by no means attached to the model-number-as-part-name setup that is in use currently; these parts don't have to be called ST-DOS-XXX and ST-HAB-XXX.  -But- if I were to do this I would want to find some way of making things consistent across the entire mod to some extent, and across part-series to a greater extent.  For example if the greater theme were 'animals', then a given part series could be 'predator birds' and another part series could be 'aquatic mammals'.  Could even just use a different set of part-numbers/model-numbers for the titles.

Really not my strong point though coming up with creative and appealing names for stuff, so this would be highly driven by your suggestions and ideas.  If anyone thinks they would like to be in charge of part naming and/or descriptions, please let me know and we can work out the details

 

 

 

[tater]

21 minutes ago, Shadowmage said:

Nose modules -- not sure where you are going with that.  What parts are lacking 'nose' options?  Pretty sure the MFT-A should have all of the nosecones as 'nose' options.

This went away. Maybe it was in my head, sorry. 

Quote

RP as a fuel type -- Really not fond of adding single-resource 'fuel types'.  The fuel types are supposed to be reserved for fuel combinations with specific ratios or commonly used fuel types.  Single resources are simple enough to add thorugh the GUI.  That is, after all, why I created the 'customize container' GUI and handling system.  I'll give it some thought though, might be a decent change.  Will probably have to wait and see how often I need to use RocketParts/etc during my next playthrough.  Either way, simple enough to add/change if/when deemed necessary.

I fielded a few posts about how to inflate, hence the suggestion. The configure containers isn;t clear to some people at first.

Quote

Descriptions -- Excellent.  If you don't setup PR's I'll probably come and copy/paste them out of your post

I'll mess with it tonight, I should learn the drill.

Quote

Probe/command capability on the B1/B2/C1/C2 -- yea, probably should.  They are intended to be usable as stand-alone spacecraft if needed, and as such would need their own C&C computers/etc.

Yeah, my thought as well. I tried to give that feel in the descriptions living space vs additional living space.

Quote

On the note of part names -- I've been thinking of putting forward a bit of a 'naming contest' for SSTU parts.  I am by no means attached to the model-number-as-part-name setup that is in use currently; these parts don't have to be called ST-DOS-XXX and ST-HAB-XXX.  -But- if I were to do this I would want to find some way of making things consistent across the entire mod to some extent, and across part-series to a greater extent.  For example if the greater theme were 'animals', then a given part series could be 'predator birds' and another part series could be 'aquatic mammals'.  Could even just use a different set of part-numbers/model-numbers for the titles.

Really not my strong point though coming up with creative and appealing names for stuff, so this would be highly driven by your suggestions and ideas.  If anyone thinks they would like to be in charge of part naming and/or descriptions, please let me know and we can work out the details

For the Hab parts, perhaps the name could reflect the capability? Ie: there is a number in there that represents the max crew. I tend towards less fanciful names, myself. Look at Apollo stages, S-1C, SII, S-IVB, etc.

It's like military aircraft, the "names" are for the masses, not the people using them.

Inflatable Station Core vs Inflatable Habitation Module?

 

 

Edited November 7, 2016 by tater

[tater]

You know, maybe the A1 holds too many crew. Its smaller than the small COS hab which holds 2. I'd drop it to 2. Heck, the COS XS holds 2... what about 3 for the A1?

The A2 is now 6, but it's smaller than the large COS. make the A2 5 crew.

The B1/3 hold 6, but they have substantially more volume than the large COS hab---but they can get a bump in habitability.

I suppose the "station core" versions  could hold 1 fewer crew (or the plain versions could hold 1 more crew) to make them have different utilities aside from the RCS, etc.

Then use names (like yours, not creative, lol) like ISC 6, ISC 9, ISC 12, etc, vs IHM 10, IHM 3, etc.

 

[JoseEduardo]

not sure if someone pointed this out already, but about the transparent inflatables, if you alt+click an transparent inflatable you get a opaque one in the editor, not sure if this can point out to something to track this issue though

EDIT: now I've read that you mentioned exactly that an hour before I posted...

Edited November 7, 2016 by JoseEduardo

[Shadowmage]

Expanding a bit on some of @RedParadize's concept sketches -- a 5m asymmetrical centrifuge.  The three-piece segment is the crew quarters (and the three segments would have some sort of crew tube joining them together), the single piece segment would be the counterweight.  Central pillar is 1.25m.  Bottom 5m segment is for display and comparison only, but the part would likely have some sort of end caps on it.  Nothing more than concept development at this point, trying out various geometries to see how they would work out and look.

Thinking for now that I'll work on the standard torus type inflatables while the concepts are being further developed for the non-torii/rigid centrifuges.  For the inflatables I pretty much already know how I'll be handling them regarding the geometry, rigging and animation setup.  Probably shouldn't take more than a few weeks to get those to the 'nearly finished' stage.  As the rigid centrifuges will likely require separate textures I'll probably do them as a second set of parts (the inflatable torus modules should all be able to share textures, similar to the HAB parts).

[tater]

I was messing with an Orion last night, and I forgot to mention an idea I had.

So you have an Orion CSM, and underneath it, you put an interim upper stage, for example. The problem visually is that they are not attached. As long as the side panels are on there, you don't really notice, but what if you want the panels deployed?

Is is possible to have a second fairing type? Say you put an engine on a tank, and put the whole thing inside a petal adapter. You would disable the engine fairing, because you have a fairing. The same is true sometimes with decouplers. You join tot he upper tank, and disable the engine fairing. What if there were an engine fairing, and the texture was mostly clear, but it had a "strut" framework? Then you enable that, and the upper stage looks strutted to the CSM, but there are no extra parts at all?

[Jimbodiah]

If anyone has changes but no idea how github works, let me know and I will add them for you. I can try out how to merge multiple PRs so not to shotgun Mage every time

[Shadowmage]

9 minutes ago, tater said:

I was messing with an Orion last night, and I forgot to mention an idea I had.

So you have an Orion CSM, and underneath it, you put an interim upper stage, for example. The problem visually is that they are not attached. As long as the side panels are on there, you don't really notice, but what if you want the panels deployed?

Is is possible to have a second fairing type? Say you put an engine on a tank, and put the whole thing inside a petal adapter. You would disable the engine fairing, because you have a fairing. The same is true sometimes with decouplers. You join tot he upper tank, and disable the engine fairing. What if there were an engine fairing, and the texture was mostly clear, but it had a "strut" framework? Then you enable that, and the upper stage looks strutted to the CSM, but there are no extra parts at all?

I guess I'm not seeing what you are getting at...  as far as I know the SC-C (orion) SM does have lower fairings on it (for placement on tanks/etc).  It should already have two fairings -- the 'side panels' which cover up the solar panels and can be ejected manually, and a set of lower fairings which connect the SM to the stage below it which are only ejected when the SM decouples from the stage.  So you should be able to 'disable side panels' on the SM, deploy the solar panels, and it should keep the lower fairings/mounts (as seen in my forum avatar; the side-panels are removed, but the lower fairing is still in place).  The lower diameter on the fairing should even be adjustable for use with different lower stages.

What you are suggesting is -theoretically- possible.  However it would require finding some sort of expert at procedural mesh generation -- just getting flat/cylindrical panel geometry generated was hard enough, no way I would want to try and make any sort of truss arrangement procedurally.