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

[Jimbodiah]

Yep, and I got IR to work in 1.3.1 and looky what I made... Width and length configurable on the spot :))))))))))))))

 

Not much to do with SSTU anymore, so sorry for going off-topic. I do miss my "construction yellow" paintjob though!

 

Spoiler

Narrow and long

 

Wide and short

 

Edited January 11, 2018 by Jimbodiah

[Sudragon]

dagnabbit, there once was a mod with a set of rcs booms that would extent out and up, but I cannot remember the name of the mod or part. May have to deep dive the forums and hope it's still there.

Found them. the KOS station tug. It is, however, optimised for the 1.85m form factor.

 

Edited January 11, 2018 by Sudragon

[Jimbodiah]

I'll check

Did you mean the Orbital Utility Vehicle?

Edited January 11, 2018 by Jimbodiah

[Sudragon]

2 hours ago, Jimbodiah said:

I'll check

Did you mean the Orbital Utility Vehicle?

Typo alert. That's meant to be KSO station tug. Too many TLA's starting with K.
 

 

[chrisl]

@Shadowmage, with the inflatable habitat modules, is there any way to have the volume availability change when inflated?

[Shadowmage]

Just now, chrisl said:

@Shadowmage, with the inflatable habitat modules, is there any way to have the volume availability change when inflated?

If using standard SSTU (no RO or RF), it -should- already increase available volume by 10x when it is inflated.  If using RO/RF -- uhh.. no clue.

(if it is not, then there is likely a bug or the feature is otherwise broken and so far unreported).

[chrisl]

41 minutes ago, Shadowmage said:

If using standard SSTU (no RO or RF), it -should- already increase available volume by 10x when it is inflated.  If using RO/RF -- uhh.. no clue.

(if it is not, then there is likely a bug or the feature is otherwise broken and so far unreported).

I've only looked at them in the VAB so far.  It shows the mass changing when you inflate but not he volume.  I'll put one in orbit and test it out.

[Pappystein]

17 hours ago, tater said:

I see what you're going for--getting the RCS out by the CM of the station modules to make maneuver a little better than just the tug at the back...

I use a different approach.   I put a small 0.9375 or 1.25m Probe core with identical RCS tank and 4 RCS ports (2 Identical Docking ports) on the Front of whatever module I am getting to the station.   I dock with it attached.   Make certain everything is stable, Un-dock and Back out.  Separate the baby probe, and then with just the Aft-half of the tug, re-dock.   I end up with a less complex 2 part tug rather than having to install something like IR (as Jimbodiah has done.)   Sure it is a few steps... But I don't have to worry too much about balance and the same tug setup works for all the station modules or fuel tanks I want to deploy.  Most of my tugs have been based on a SSTU 1.25m-x-0.5 front tank with 2x 1.25m DP-01 docking ports and SSTU or RLA 5x RCS ports (x4)   4 tiny Pioneer Solar panels from BDB complete the front half of the Tug.   The Rear half is often the BDB/ETS Aardvark Tug with the SSTU 1.25m DP-01 port.    Most of my lateral docking ports are 0.9375m instead of the 1.25m (I re-scaled the DP-01 to do this.)   Most ships I dock with my space station end up with a 0.9375m Nose connection.  This includes the Aardvark Resupply vehicle, Apollo Blk III/IV/and V and Agena based probes and resupply vessels.      

 

My stations tend to be based on the DOS/TKS group of parts.   (Shadowmage I think I have played with almost all of the Station parts packs out there and your DOS parts are STILL my favorite!)

Question for everyone.   I am looking for a Suggestion from the group on proper station construction.    I tend to fly CA Technologies Shuttles (Bruan mostly) to my Stations.   Other than adding a Tank/Structural fuselage part with a docking port on each end to dock the Shuttle (or SpaceX Dragon with it's 90degree port cover... etc etc etc)  Is there a suggestion to allow a space-plane to dock with the COS/DOS parts?  I am having too many collisions due to the docking port on the station being nearly flush and the space-plane/shuttles are RECESSED.      I think this might also be causing some docking problems (where the parts lock but never complete docking...  Ports to close to the edge of the Bounding box?)

 

 

 

Edited January 11, 2018 by Pappystein

[Jimbodiah]

I've tried that method before but I'm too lazy   Playing with IR is kind of fun, could open up some nice new builds    

You can offset the port and activate the extension so that it does not look like it is floating. Alternatively you can take an MFT-A tank, set it to Stuctural (no resource) and clip it into the station to make a passageway/tube with the port at the end. This is basically a radialy attached structural part then, but can come in very handy if you need to stretch out further than the port-extention will go. 

Edited January 11, 2018 by Jimbodiah

[Sudragon]

1 hour ago, Pappystein said:

    

 

My stations tend to be based on the DOS/TKS group of parts.   (Shadowmage I think I have played with almost all of the Station parts packs out there and your DOS parts are STILL my favorite!)

Question for everyone.   I am looking for a Suggestion from the group on proper station construction.    I tend to fly CA Technologies Shuttles (Bruan mostly) to my Stations.   Other than adding a Tank/Structural fuselage part with a docking port on each end to dock the Shuttle (or SpaceX Dragon with it's 90degree port cover... etc etc etc)  Is there a suggestion to allow a space-plane to dock with the COS/DOS parts?  I am having too many collisions due to the docking port on the station being nearly flush and the space-plane/shuttles are RECESSED.      I think this might also be causing some docking problems (where the parts lock but never complete docking...  Ports to close to the edge of the Bounding box?)

 

 

 

Flexible Docking. Extendable docking ports in .625, 1.25, 2.5.

[chrisl]

@Shadowmage, I've been thinking about this for the last couple days but have been hesitant to post about it figuring it's possible you've already thought about doing this and ruled it out due to the difficulty involved.  But it's been rattling around in my head and I need to get it out so..... You mentioned a few posts back that fuel tanks are basically simply because all their available volume is basically used for fuel.  Crew components like space stations, on the other hand, are more complicated because the available volume isn't all used for one thing.  So that got me thinking.  There are basically 4 things that use a station parts volume: Crew Tube, Equipment, Habitation and Storage.  I figure, for the most part, everything you might find in a space station will fit into one of those four areas.

The "Crew Tube" is easy.  You'd have a "shaft" of empty space running down the length of the station part so that crew could move from one end of the part to another, and access most everything in the part.  The "Crew Tube" would have a "static" diameter set in the cfg file just like the top/core/bottom diameter of the part.  So as an example, if we look at SSTU-ST-COS-M* with a 4.5m diameter and 6.1m length, we'd have 72.38 m3 of usable volume (91.23 from the part - 18.85 for a 2m diameter x 6m long "Crew Tube" leaves 72.38 m3).  It would also have a bass mass of a similarly sized, service module style fuel tank and a 0 CrewCapacity.

The last three (Equipment, Habitation and Storage) would be set in game as you're building the part
You'd use a slider for Equipment which represents everything from lab equipment, control stations, guidance computers, exercise equipment, etc.  For every kg of equipment you add with the slider, you use up some portion of the usable volume (0.005 m3 / kg, for example). 
You'd also use a slider for Habitation which represents sleeping "quarters", living space, lavatories, dining space, etc.  This slider would add CrewCapacity in exchange for usable volume.  For every CrewCapacity you add to the part, you use up 5m3 (for example) of usable space.
Whatever usable space is left after setting the Equipment and Habitation sliders would be Storage (i.e., fuel, life support supplies, etc). 

In this way you could use the same part to recreate the Unity, Harmony and Tranquility modules of the ISS.  All are basically the same size but each had very different internal setups.  Unity is basically all equipment with some storage.  Harmony has crew "quarters" with some equipment and some storage.  Tranquility as some habitation space with a fair bit of equipment but lots of storage.  You could also use the same parts to recreate Mir and ISS components like Kvant-2 from Mir which had lots of equipment and Zarya from ISS which had lots of storage.

I'm assuming the hardest part would be getting the two sliders to work together.  If you set the Equipment slider to 100%, you couldn't have any Habitation space, for example.

 

*I'm using basically real world scaled parts.  I'm assuming you would have started there, then scaled things down for Kerbal size.  I'm also assuming that 0.1m is used for the "skin" of the module.  So if SSTU-ST-COS-M has 4.5m diameter x 6.1m length dimensions, then volume would be calculated based on a 4.4m diameter x 6.0m length.  Finally, I'm basing my measurements on the core part with no caps.  Any caps you add would follow the same rules as the core but it was simpler to example this way.

[Jimbodiah]

The current stations parts consist of a hab space and built in equipment. If you were to use the raw volume of the COS modules, you would be able to put a lot more kerbals inside. So basically this already takes care of the hab and equipment portion. As for storage, there was a plan to have the MFT with COS textures, but the eva handles would not scale properly with the MFT diameter irrc, and was subsequently removed from the MFT configs. This is the reason I patched a COS clone for myself that was purely for storage and has the SSTUVolumeContainer module just like the MFT. The system you describe sounds very complicated to implement, and would not offer any real functionality over the current parts; maybe with exception to having a storage version of the COS modules.

[chrisl]

20 minutes ago, Jimbodiah said:

The current stations parts consist of a hab space and built in equipment. If you were to use the raw volume of the COS modules, you would be able to put a lot more kerbals inside. So basically this already takes care of the hab and equipment portion. As for storage, there was a plan to have the MFT with COS textures, but the eva handles would not scale properly with the MFT diameter irrc, and was subsequently removed from the MFT configs. This is the reason I patched a COS clone for myself that was purely for storage and has the SSTUVolumeContainer module just like the MFT. The system you describe sounds very complicated to implement, and would not offer any real functionality over the current parts; maybe with exception to having a storage version of the COS modules.

It would be complicated.  I get that.  But the advantage is using the same part to represent various station components.  You  could have a one component with low initial mass, little to no crew accommodations but very high storage capacity (i.e., the Zarya module of the ISS) and another component with high mass (to reflect it having a lot of extra equipment) and decent accommodations but little storage (like Kvant-2 from Mir).  Both Zarya and Kvant-2 are based on the same design and both have similar launch masses.  Zarya, however, has an 8t dry mass versus the Kvant-2 with around 17t. 

[Pappystein]

On 1/12/2018 at 1:31 PM, chrisl said:

It would be complicated.  I get that.  But the advantage is using the same part to represent various station components.  You  could have a one component with low initial mass, little to no crew accommodations but very high storage capacity (i.e., the Zarya module of the ISS) and another component with high mass (to reflect it having a lot of extra equipment) and decent accommodations but little storage (like Kvant-2 from Mir).  Both Zarya and Kvant-2 are based on the same design and both have similar launch masses.  Zarya, however, has an 8t dry mass versus the Kvant-2 with around 17t. 

Having read both your most recent posts, I get your Idea.  Thank you for sharing and posting it!   However, from my viewpoint it appears to be an Awful lot of work that requires some specific standard that doesn't exist anywhere in game or the Real world for that matter (Mass vs Volume trade off ratio.)   If Shadowmage were to put the (and I am ball-parking this here) 100's of hours of effort into a coding change for it, everyone would pipe in "But Experiment X doesn't mass that much,"   "I loose too much/too little volume when I slide the slider,"  and my favorite "But this part is made out of Unobtainium-57 which has a much lower SFG than standard CrazyOnesStructuralAlloy so my station part should have a lower empty mass" (ok so the alloy names are made up by me but you get my drift right?) 

So to simplify what I am saying (and hopefully this will give you a different viewpoint to think from for your ideas,)  There is no way to standardize a mass-volume conversion that would leave most people even content (let alone keep more than a few people happy.)   There would be a lot of work to make just a few people happy and the rest of the players not to want to use the parts at all (in my opinion.)   Your Ideas would limit part count in the VAB/SPH for station parts, but the cost to game play would likely be a negative effect (IE makes game play HARDER not EASIER.)  

NOW having said all of that.   PLEASE continue to SHARE your IDEAS!   Just like the only stupid question is either the one you didn't ask....  Well you get the Idea I hope

 

Edited January 14, 2018 by Pappystein
tweaked final line slightly to make more sense

[Jasseji]

Hello @Shadowmage i remember to have somewhere the option to remove docking ports - is it possible also for the Command Modules ?

If yes then maybe you (or someone) could point me to the proper patch - i remember i had it once but then lost it and cant find it anymore

[Shadowmage]

13 minutes ago, Jasseji said:

Hello @Shadowmage i remember to have somewhere the option to remove docking ports - is it possible also for the Command Modules ?

Yes.  All parts with integrated docking ports can have them removed through patches.

I do not have any examples at hand, but perhaps someone else might.

[Jasseji]

Thank you, then i wasnt wrong, i will keep looking for them.

Edit:

This is the place in the .cfg ?

MODEL
{
	model = SSTU/Assets/SC-GEN-DP-1P
	position = 0, 1.6556, 0
	rotation = 0, 180, 0
}

So in theory, any other port could be added just by changing the model path ?

What about animations from that other ports ?

I am speaking specifically about the APAS from cxAerospace

[Jimbodiah]

@Jasseji  Check out JoseEduardo's SSTU Expansion pack for examples. He has pod versions with the docks removed. Please note to not install that pack, as it is outdated and will cause problems in SSTU. But you can check it for examples of how he removed the ports and even added 3rd party ports like the APAS from Cx.

 

Again, DO NOT INSTALL IT !!!!

 

Edited January 14, 2018 by Jimbodiah

[Jasseji]

Aaaah, right, i actually posted there writing which parts work

[OscarJade]

Silly question: I recently loaded this mod...and some of the parts are invisible when I try to load them in the VAB. (They show the blue dots as connection points, but remain invisible when you attach them) Has anyone else experienced this? Thanks in advance 

Edited January 16, 2018 by OscarJade

[Jimbodiah]

Running KSP 1.3.1?

Do you have the 3 directories needed from the SSTU install?  (SSTU, 000_TexturesUnlimited, KSPWheel)

 

[StickyScissors]

Trying to do some testing of docking systems, but MechJeb is broken. I got a cool screenshot at least

[Starwaster]

On 1/14/2018 at 11:52 AM, Shadowmage said:

Yes.  All parts with integrated docking ports can have them removed through patches.

I do not have any examples at hand, but perhaps someone else might.

I use this on the landers @Jasseji

@PART[SSTU-LC2-POD|SSTU_LanderCore_LC3-POD|SSTU_LanderCore_LC5-POD]
{
	@node_stack_top[1] -= 0.13796
	!MODEL,1{}
	!MODULE[ModuleDockingNode]{}
	!MODULE[SSTUAnimateControlled]{}
	!MODULE[SSTUAnimateLight],0{}
}

 

[tater]

53 minutes ago, StickyScissors said:

Trying to do some testing of docking systems, but MechJeb is broken. I got a cool screenshot at least

They're that close and you can't dock them?

[StickyScissors]

2 minutes ago, tater said:

They're that close and you can't dock them?

Trying to dock them parallel with multiple ports, not face to face